Resending the patch with the strncmp() bug fixed.
Its been a long long week when you mess up something as simple as this.
regards
ronnie sahlberg
On many platforms /dev/fd/ is used to refer to open filedescriptor of
the running process.
If we fail to open the provided filename and if the filename starts with
'/dev/fd/' then assume this is a platform which do not support these special
files.
In that case read out the descriptor value from
On many platforms /dev/fd/ ise used to refer to open filedescriptor of
the running process.
If we fail to open the provided filename and if the filename starts with
'/dev/fd/' then assume this is a platform which do not support these special
files.
In that case read out the descriptor value fro
Please find a patch to -readconfig.
On many platforms -readconfig /dev/fd/ can be used to read from an already
opened and inherited filedescriptor .
On platforms that do not natively provide /dev/fd/
add emulation of this by checking if the ofiginal fopen(path) failed, then IF
the path starts
Yes,
Very unfortuante since libiscsi is such a nice name for a
multiplatform library what even works on win32 :-(
I have so renamed it to libiscsiclient and sent a patch to qemu to
this list to use -liscsiclient instead of -liscsi
tarballs can be found at
https://github.com/sahlberg/libiscsi
Signed-off-by: Ronnie Sahlberg
---
configure |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index fb0e18e..294c0c1 100755
--- a/configure
+++ b/configure
@@ -2503,9 +2503,9 @@ if test "$libiscsi" != "no" ; then
#include
int main(void) { iscsi
Please find a patch that changes the name of the iscsi library from libiscsi to
libiscsiclient
While libiscsi is a very nice name that works on all platforms, including
win32, it clashes with a linux library.
regards
ronnie sahlberg
Hi Bill,
I am trying to run vxworks on KVM with X86_64 machine. I've downloaded
your binary Vxworks Image from
http://lists.gnu.org/archive/html/qemu-devel/2009-06/msg00401.html
and ran it by: *qemu -fda vxworks.img*. Unfortunately, I could not bootup
the vxworks. The vncviewer shows that:
On Sat, Mar 3, 2012 at 12:41 AM, Peter Maydell wrote:
> On 2 March 2012 16:01, Anthony Liguori wrote:
>> On 03/02/2012 06:38 AM, Zhi Yong Wu wrote:
>>> Can anyone explain their relationship and difference among them? It
>>> is very appreciated if you can make some comments. thanks.
>>
>>
>> IRQ
On Fri, Mar 2, 2012 at 11:12 PM, ���f任 wrote:
>> Can anyone explain their relationship and difference among them? It
>> is very appreciated if you can make some comments. thanks.
>
> I think IRQ number, interrupt number are quite similar things. You can
> check PIC [1] first, especially 8259A [2
HI, anthony.
On Sat, Mar 3, 2012 at 12:01 AM, Anthony Liguori wrote:
> Hi Zhi Yong,
>
>
> On 03/02/2012 06:38 AM, Zhi Yong Wu wrote:
>>
>> HI,
>>
>> Can anyone explain their relationship and difference among them? It
>> is very appreciated if you can make some comments. thanks.
>
>
> IRQ == inte
On 02/03/12 10:49 AM, Hans de Goede wrote:
VCARD_ATR_PREFIX is used as part of an array initializer so it should
not have () around it, so far this happened to work, but gcc-4.7 does
not like it.
This recent commit..
libcacard: fix reported ATR length
Broke the build on my OpenBSD (gcc 4.2.1)
On 02.03.2012, at 18:49, Peter Maydell wrote:
> On 27 February 2012 15:16, Bernhard M. Wiedemann wrote:
>> I found that running a debian arm5 bash with qemu runs into varying
>> problems with -R but works without.
>
> So I had a look at this this afternoon, and what seems to be happening
> is t
The Buildbot has detected a new failure on builder block_openbsd_current while
building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/block_openbsd_current/builds/154
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: brad_openbsd_cur
The Buildbot has detected a new failure on builder block_mingw32 while building
qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/block_mingw32/builds/144
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: kraxel_rhel61
Build Reason: The
The Buildbot has detected a new failure on builder default_openbsd_4.9 while
building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/default_openbsd_4.9/builds/195
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: kraxel_openbsd49
Bu
ram_addr_t must be large enough to address any address of the host.
For hosts with sizeof(unsigned long) == sizeof(void *), this patch
changes nothing. All currently supported hosts fall into this category.
For w64 hosts, sizeof(unsigned long) is 4 while sizeof(void *) is 8,
so the use of uintptr
On 02.03.2012, at 23:30, Stefan Weil wrote:
> The TCG targets i386 and tci needed a change of the function
> prototype for w64.
>
> This change is currently not needed here, but it can be applied
> to avoid code differences.
Both 4 and 5 look reasonable to me.
Alex
These patches are a step towards full 64 bit support for w64.
The patches 4 and 5 are optional.
Please apply this series.
Thanks,
Stefan Weil
[PATCH 1/6] w64: Fix size of ram_addr_t
[PATCH 2/6] tcg: Rearrange definitions and include statements
[PATCH 3/6] w64: Fix data type of parameters for flu
Signed-off-by: Stefan Weil
---
tcg/tcg.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/tcg/tcg.c b/tcg/tcg.c
index 351a0a3..cd2db3c 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -253,8 +253,8 @@ void tcg_prologue_init(TCGContext *s)
s->code_buf = code_gen_prolo
flush_icache_range takes two address parameters which must be large
enough to address any address of the host.
For hosts with sizeof(unsigned long) == sizeof(void *), this patch
changes nothing. All currently supported hosts fall into this category.
For w64 hosts, sizeof(unsigned long) is 4 while
The TCG targets i386 and tci needed a change of the function
prototype for w64.
This change is currently not needed for the other TCG targets,
but it can be applied to avoid code differences.
Cc: Blue Swirl
Cc: Andrzej Zaborowski
Cc: Richard Henderson
Cc: Aurelien Jarno
Cc: Alexander Graf
Si
The TCG targets i386 and tci needed a change of the function
prototype for w64.
This change is currently not needed here, but it can be applied
to avoid code differences.
Cc: Alexander Graf
Signed-off-by: Stefan Weil
---
cache-utils.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
This change makes tcg_target_ulong available in tcg-target.h.
Signed-off-by: Stefan Weil
---
tcg/tcg.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tcg/tcg.h b/tcg/tcg.h
index 5c28239..cc223ea 100644
--- a/tcg/tcg.h
+++ b/tcg/tcg.h
@@ -32,9 +32,6 @@
# error Unkn
On Sat, Feb 25, 2012 at 01:42:42PM -0600, Anthony Liguori wrote:
> This also includes a qtest wrapper script to make it easier to launch qtest
> tests directly.
>
> Signed-off-by: Anthony Liguori
> ---
> scripts/qtest|5 +
> tests/Makefile |2 +
> tests/libqtest.c | 334
> +++
* Serge Hallyn [2012-03-02 15:13]:
> Hi,
>
> I don't know where the best place to catch this would be, but
> with vnc and vmware_vga it's possible to get set_bit called on
> a negative index, crashing qemu. See
>
> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/918791
>
> for details.
cerr should only be decremented on errors which cause XactErr to be set, and
when that happens the failing transaction should be retried until cerr reaches
0 and only then should USBSTS_ERRINT be set (and inactive cleared and
USBSTS_INT set if requested).
Since we don't have any hardware level err
Hi,
I don't know where the best place to catch this would be, but
with vnc and vmware_vga it's possible to get set_bit called on
a negative index, crashing qemu. See
https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/918791
for details. This patch prevents that. It's possible this
should
This patch removes 2 bits of dead nakcnt code:
1) usb_ehci_execute calls ehci_qh_do_overlay which does:
nakcnt = reload;
and then has a block of code which is conditional on:
if (reload && !nakcnt) {
which ofcourse is never true now as nakcnt == reload.
2) ehci_state_fetchqh does:
nakcnt = reload
As clearly stated in the 2.3.2 of the EHCI spec, any time USBERRINT get
sets then if the td has its IOC bit set USBINT should be set as well.
This means that for any status except for USB_RET_NAK we should set
USBINT if the IOC bit is set.
Signed-off-by: Hans de Goede
---
hw/usb-ehci.c |2 +
Signed-off-by: Hans de Goede
---
usb-linux.c |8 +++-
usb-redir.c |4 ++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index 47994f3..38df9e6 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -364,6 +364,10 @@ static void async_complete(void *o
Am 02.03.2012 19:57, schrieb Jan Kiszka:
Well, this requeuing bug seems to have a long breath. Previous attempts
to fix it (mine included) neglected the fact that we need to walk the
queue of pending packets, not just restart from the beginning after a
requeue. This version should get it Right(TM
The purpose of the IAAD bit / the doorbell is to make the ehci controller
forget about cached qhs, this is mainly used when cancelling transactions,
the qh is unlinked from the async schedule and then the doorbell gets rung,
once the doorbell is acked by the controller the hcd knows that the qh is
Currently 'cpu_reset' doesn't fully compute all of the needed
HFLAGs and fails to setup fcr0 after clearing the CPU state.
This can cause instruction exceptions. For example, using
'madd.d' on machines that should support it is kindly greeted
with:
qemu: uncaught target signal 4 (Illegal instruct
Hi,
Here is a series of usb patches against current qemu master, mostly
consisting of a whole bunch of small ehci fixes, plus some redirection
fixes.
Changes in v2:
Due to some reshuffling of patches before sending [PATCH 04/13] "usb-ehci:
always call ehci_queues_rip_unused for period queues" end
The nakcnt code in ehci_execute_complete() marked transactions as finished
when a packet completed with a result of USB_RET_NAK, but USB_RET_NAK
means that the device cannot receive / send data at that time and that
the transaction should be retried later, which is also what the usb-uhci
and usb-oh
Since we don't use usb_desc.c we need to do this ourselves. This fixes
iso transfers no longer working for USB 2 devices due to the ep->type
check in ehci.c
Signed-off-by: Hans de Goede
---
usb-redir.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/usb-redir.c b/
All error statuses except for NAK are handled in a switch case, move the
handling of NAK into the same switch case.
Signed-off-by: Hans de Goede
---
hw/usb-ehci.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
i
We already have USB_RET_NAK, but that means that a device does not want
to send/receive right now. But with host / network redirection we can
actually have a transaction fail due to some io error, rather then ie
the device just not having any data atm.
This patch adds a new error code named USB_RE
Before this patch USB 2 devices with interrupt endpoints were not working
properly. The problem is that to avoid loops we stop processing as soon
as we encounter a queue-head (qh) we've already seen since qhs can be linked
in a circular fashion, this is tracked by the seen flag in our qh struct.
T
qhs can be part of both the async and the periodic schedule, as is shown
in later patches in this series it is useful to keep track of the qhs on
a per schedule basis.
Signed-off-by: Hans de Goede
---
hw/usb-ehci.c | 62 ++---
1 files changed
Signed-off-by: Hans de Goede
---
hw/usb-ehci.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
index b349003..d386b84 100644
--- a/hw/usb-ehci.c
+++ b/hw/usb-ehci.c
@@ -1076,7 +1076,8 @@ static void ehci_mem_writel(void *ptr, target_phys_
Before this patch the T-bit was not checked in 2 places, while it should be.
Once we properly check the T-bit everywhere we no longer need the weird
entry < 0x1000 and entry > 0x1000 checks, so this patch removes them.
Signed-off-by: Hans de Goede
---
hw/usb-ehci.c | 10 --
1 files ch
Applying the concept used for the *PICs once again: establish a base
class for the i8254 that can be used both by the current user space
emulation and the upcoming KVM in-kernel version. We share most of the
public interface of the i8254, specifically to the pcspk, vmstate, reset
and certain init p
To be used for in-kernel PIT emulation.
Signed-off-by: Jan Kiszka
---
kvm-all.c | 10 ++
kvm-stub.c |5 +
kvm.h |1 +
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 77eadf6..278085f 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@
This provides the required user space stubs to enable the in-kernel
i8254 emulation of KVM.
The in-kernel model supports lost tick compensation according to the
"delay" policy. This is enabled by default and can be switched off via a
device property.
Depending on the feature set of the host kerne
Same as for the APIC: To enable migration between accelerated and
non-accelerated models, we need to arm the channel 0 timer only inside
the emulated PIT model. The common code just saves/restores that timer
to the the next_transition_time field.
Signed-off-by: Jan Kiszka
---
hw/i8254.c|
This adds another piece of qemu-kvm to upstream: The accelerated
in-kernel model of the i8254. It does this in the same fashion as the
interrupt controllers were already introduced. And it even has one bug
less than qemu-kvm: PC speaker output still works with KVM acceleration
enabled.
Changes in
This patch removes 2 bits of dead nakcnt code:
1) usb_ehci_execute calls ehci_qh_do_overlay which does:
nakcnt = reload;
and then has a block of code which is conditional on:
if (reload && !nakcnt) {
which ofcourse is never true now as nakcnt == reload.
2) ehci_state_fetchqh does:
nakcnt = reload
Signed-off-by: Hans de Goede
---
usb-linux.c |8 +++-
usb-redir.c |4 ++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index 47994f3..38df9e6 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -364,6 +364,10 @@ static void async_complete(void *o
All error statuses except for NAK are handled in a switch case, move the
handling of NAK into the same switch case.
Signed-off-by: Hans de Goede
---
hw/usb-ehci.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
i
Before this patch USB 2 devices with interrupt endpoints were not working
properly. The problem is that to avoid loops we stop processing as soon
as we encounter a queue-head (qh) we've already seen since qhs can be linked
in a circular fashion, this is tracked by the seen flag in our qh struct.
T
qhs can be part of both the async and the periodic schedule, as is shown
in later patches in this series it is useful to keep track of the qhs on
a per schedule basis.
Signed-off-by: Hans de Goede
---
hw/usb-ehci.c | 62 ++---
1 files changed
The purpose of the IAAD bit / the doorbell is to make the ehci controller
forget about cached qhs, this is mainly used when cancelling transactions,
the qh is unlinked from the async schedule and then the doorbell gets rung,
once the doorbell is acked by the controller the hcd knows that the qh is
Another attempt to get this right: We need to carefully walk both the
fastq and the batchq in if_start while trying to send packets to
possibly not yet resolved hosts on the virtual network.
So far we just requeued a delayed packet where it was and then started
walking the queues from the top agai
Make sure that next_m always points to a packet if batchq is non-empty.
This will simplify walking the queues in if_start.
CC: Fabien Chouteau
CC: Zhi Yong Wu
CC: Stefan Weil
Signed-off-by: Jan Kiszka
---
slirp/if.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions
Well, this requeuing bug seems to have a long breath. Previous attempts
to fix it (mine included) neglected the fact that we need to walk the
queue of pending packets, not just restart from the beginning after a
requeue. This version should get it Right(TM).
This also comes with a fix for resource
Close & free sockets when shutting down a slirp instance, also release
all buffers.
CC: Michael S. Tsirkin
Signed-off-by: Jan Kiszka
---
slirp/ip_icmp.c |7 +++
slirp/ip_icmp.h |1 +
slirp/ip_input.c |7 +++
slirp/mbuf.c | 21 +
slirp/mbuf.h |
There is now a trivial check on entry of if_start for pending packets,
so we can drop the additional tracking via if_queued.
Signed-off-by: Jan Kiszka
---
slirp/if.c|8
slirp/slirp.c |7 +--
slirp/slirp.h |1 -
3 files changed, 1 insertions(+), 15 deletions(-)
diff
cerr should only be decremented on errors which cause XactErr to be set, and
when that happens the failing transaction should be retried until cerr reaches
0 and only then should USBSTS_ERRINT be set (and inactive cleared and
USBSTS_INT set if requested).
Since we don't have any hardware level err
I'll go stand up some vms to test that one out.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/524447
Title:
virsh save is very slow
Status in libvirt virtualization API:
Unknown
Status in QEMU:
Signed-off-by: Kevin Wolf
---
block/qcow2-cluster.c | 55 -
1 files changed, 36 insertions(+), 19 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index a791bbe..903454d 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-
When a write request spans both allocated and unallocated clusters, qcow2
splits the request in two parts. This is not necessary if we have sequential
writes: If the unallocated area can be allocated such that in the image file it
is adjacent to the already allocated part, a single request is enoug
If the first part of a write request is allocated, but the second isn't
and it can be allocated so that the resulting area is contiguous, handle
it at once. This is a common case for sequential writes.
After this patch, alloc_cluster_offset() only checks if the clusters are
already allocated or ho
This function allows to allocate clusters at a given offset in the image
file. This is useful if you want to allocate the second part of an area
that must be contiguous.
Signed-off-by: Kevin Wolf
---
block/qcow2-refcount.c | 28
block/qcow2.h |2 ++
2
We already have USB_RET_NAK, but that means that a device does not want
to send/receive right now. But with host / network redirection we can
actually have a transaction fail due to some io error, rather then ie
the device just not having any data atm.
This patch adds a new error code named USB_RE
Signed-off-by: Hans de Goede
---
hw/usb-ehci.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
index b349003..d386b84 100644
--- a/hw/usb-ehci.c
+++ b/hw/usb-ehci.c
@@ -1076,7 +1076,8 @@ static void ehci_mem_writel(void *ptr, target_phys_
The nakcnt code in ehci_execute_complete() marked transactions as finished
when a packet completed with a result of USB_RET_NAK, but USB_RET_NAK
means that the device cannot receive / send data at that time and that
the transaction should be retried later, which is also what the usb-uhci
and usb-oh
From: Paolo Bonzini [pbonz...@redhat.com]
Sent: Thursday, March 01, 2012 11:54 PM
To: Kai Meyer
Cc: Anthony Liguori; Stefan Weil; qemu-devel@nongnu.org; Nate Bushman
Subject: Re: Add support for new image type
Il 01/03/2012 22:14, Kai Meyer ha scritto:
> I
Before this patch the T-bit was not checked in 2 places, while it should be.
Once we properly check the T-bit everywhere we no longer need the weird
entry < 0x1000 and entry > 0x1000 checks, so this patch removes them.
Signed-off-by: Hans de Goede
---
hw/usb-ehci.c | 10 --
1 files ch
As clearly stated in the 2.3.2 of the EHCI spec, any time USBERRINT get
sets then if the td has its IOC bit set USBINT should be set as well.
This means that for any status except for USB_RET_NAK we should set
USBINT if the IOC bit is set.
Signed-off-by: Hans de Goede
---
hw/usb-ehci.c |2 +
Hi,
Here is a series of usb patches against current qemu master, mostly
consisting of a whole bunch of small ehci fixes, plus some redirection
fixes.
Regards,
Hans
Since we don't use usb_desc.c we need to do this ourselves. This fixes
iso transfers no longer working for USB 2 devices due to the ep->type
check in ehci.c
Signed-off-by: Hans de Goede
---
usb-redir.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/usb-redir.c b/
Ben, yes, sorry I missed the fact that there was already another bug
that needs verification in lucid-proposed. Bug #592010 needs to be
verified, or reverted, before this one can proceed to lucid-updates.
Verification is tricky, since one needs to do a hardy -> lucid upgrade
to verify it.
--
You
On Fri, Mar 2, 2012 at 9:10 AM, GaoYi wrote:
> Hi all,
>
>I am trying to run Vxworks on KVM under X86_64 platform. Now I can
> startup vxworks without 'no-kvm' option. However, the bootup failed with
> hardware virtualization selected. Has anybody run it successfully?
>
>Any of your sugges
On 27 February 2012 15:16, Bernhard M. Wiedemann wrote:
> I found that running a debian arm5 bash with qemu runs into varying
> problems with -R but works without.
So I had a look at this this afternoon, and what seems to be happening
is that with -R, the call to target_mmap() in elfload.c:setup_
Is something holding up the release to lucid-updates?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/524447
Title:
virsh save is very slow
Status in libvirt virtualization API:
Unknown
Status in
On 2 March 2012 16:01, Anthony Liguori wrote:
> On 03/02/2012 06:38 AM, Zhi Yong Wu wrote:
>> Can anyone explain their relationship and difference among them? It
>> is very appreciated if you can make some comments. thanks.
>
>
> IRQ == interrupt.
>
> GPIO is just another name for an input or out
On 2012-03-02 17:10, GaoYi wrote:
> Hi all,
>
>I am trying to run Vxworks on KVM under X86_64 platform. Now I can
> startup vxworks without 'no-kvm' option. However, the bootup failed with
> hardware virtualization selected. Has anybody run it successfully?
>
>Any of your suggestions woul
On Fri, Mar 02, 2012 at 11:15:48AM -0500, Marc-André Lureau wrote:
>
>
> - Mensaje original -
> > On Fri, Mar 02, 2012 at 01:49:22PM +0100, Marc-André Lureau wrote:
> > > This allows a Spice client to identify a VM
> >
> > My only problem with this is that if we have a monitor vmcchannel
- Mensaje original -
> On Fri, Mar 02, 2012 at 01:49:22PM +0100, Marc-André Lureau wrote:
> > This allows a Spice client to identify a VM
>
> My only problem with this is that if we have a monitor vmcchannel you
> could issue the command to query that, and much more, without having
> to
>
Hi all,
I am trying to run Vxworks on KVM under X86_64 platform. Now I can
startup vxworks without 'no-kvm' option. However, the bootup failed with
hardware virtualization selected. Has anybody run it successfully?
Any of your suggestions would be appreicated.
Yi
On Fri, Mar 02, 2012 at 01:49:22PM +0100, Marc-André Lureau wrote:
> This allows a Spice client to identify a VM
My only problem with this is that if we have a monitor vmcchannel you
could issue the command to query that, and much more, without having to
add any messages. And adding a monitor chan
Hi Zhi Yong,
On 03/02/2012 06:38 AM, Zhi Yong Wu wrote:
HI,
Can anyone explain their relationship and difference among them? It
is very appreciated if you can make some comments. thanks.
IRQ == interrupt.
GPIO is just another name for an input or output pin on a chip which could be a
IRQ l
VCARD_ATR_PREFIX is used as part of an array initializer so it should
not have () around it, so far this happened to work, but gcc-4.7 does
not like it.
Signed-off-by: Hans de Goede
---
libcacard/vcardt.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libcacard/vcard
On Fri, Mar 02, 2012 at 12:21:49PM +0100, Jörg Sommer wrote:
> Hi,
>
> as requested by the qemu software, here's my report that qemu says
>
> unknown keycodes `macintosh_aliases(qwertz)', please report to
> qemu-devel@nongnu.org
Thanks for the information, I have posted patches a few weeks bac
On 03/02/2012 06:19 PM, Andreas Färber wrote:
Hi Igor,
Am 02.03.2012 12:35, schrieb Igor Mitsyanko:
diff --git a/Makefile.target b/Makefile.target
index 7968120..05ce652 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -349,6 +349,7 @@ obj-arm-y += exynos4210_gic.o exynos4210_combiner.o
e
Hi Igor,
Am 02.03.2012 12:35, schrieb Igor Mitsyanko:
> diff --git a/Makefile.target b/Makefile.target
> index 7968120..05ce652 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -349,6 +349,7 @@ obj-arm-y += exynos4210_gic.o exynos4210_combiner.o
> exynos4210.o
> obj-arm-y += exynos4_b
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Friday, March 02, 2012 8:14 PM
> To: Zhang, Yang Z
> Cc: qemu-devel@nongnu.org; Jan Kiszka; k...@vger.kernel.org;
> aligu...@us.ibm.com; Marcelo Tosatti
> Subject: Re: [PATCH v3
> But: This + the latest GIT master causes again my problems with the
With or without this one:
commit 5ca2358ac895139e624881c5b3bf3095d3cc4515
Date: Wed Feb 29 09:11:00 2012 -0600
Merge remote-tracking branch 'kraxel/usb.39' into staging
?
cheers,
Gerd
On 03/02/12 14:59, Marc-André Lureau wrote:
> On Fri, Mar 2, 2012 at 2:25 PM, Gerd Hoffmann wrote:
>> On 03/02/12 13:49, Marc-André Lureau wrote:
>>> This allows a Spice client to identify a VM
>>
>> Patch doesn't apply, please rebase.
>
> It applies here on top of git://git.qemu.org/qemu.git/mas
@Jamie,
yes libvirt supports spice. You do have to set the video section
accordingly. Here is an example xml file that works for me:
spice
524288
524288
1
hvm
destroy
restart
restart
/usr/bin/kvm-spice
On Fri, Mar 2, 2012 at 2:25 PM, Gerd Hoffmann wrote:
> On 03/02/12 13:49, Marc-André Lureau wrote:
>> This allows a Spice client to identify a VM
>
> Patch doesn't apply, please rebase.
It applies here on top of git://git.qemu.org/qemu.git/master:
commit 88e6c60671df4c8b1b6c1eb8f76950ab1bea0ec2
Use the new, direct control transfer submission method instead of
bypassing the usb core by calling usb_device_handle_control directly.
The later fails for async control transfers.
This patch gets xhci + usb-host combo going.
---
hw/usb-xhci.c | 13 +
1 files changed, 5 insertions(+
Add a more direct code path to submit control transfers. Instead of
feeding three usb packets (setup, data, ack) to usb_handle_packet and
have the do_token_* functions in usb.c poke the control transfer
parameters out of it just submit a single packet carrying the actual
data with the control xfer
Signed-off-by: Kevin Wolf
---
block/qcow2-cache.c | 18 ++
block/qcow2-cluster.c | 15 ++-
block/qcow2.c |9 +
trace-events | 24
4 files changed, 65 insertions(+), 1 deletions(-)
diff --git a/block/qcow2-c
Am 02.03.2012 14:25, schrieb Paolo Bonzini:
> Il 02/03/2012 14:00, Kevin Wolf ha scritto:
>> Am 01.03.2012 17:52, schrieb Paolo Bonzini:
> But you can even keep from your first patch the drive-reopen command and
> not make it atomic, that shouldn't be a problem.
I'm not sure wheth
This can happen today in case the ->complete() callback queues up the
next packet. Also we'll support pipelining soon, which allows to have
multiple packets per queue in flight (aka ASYNC) state.
Signed-off-by: Gerd Hoffmann
---
hw/usb.c |3 +++
1 files changed, 3 insertions(+), 0 deletions
Il 02/03/2012 14:00, Kevin Wolf ha scritto:
> Am 01.03.2012 17:52, schrieb Paolo Bonzini:
But you can even keep from your first patch the drive-reopen command and
not make it atomic, that shouldn't be a problem.
>>>
>>> I'm not sure whether it makes sense for a separate drive-reopen or
>>
On 03/02/12 13:49, Marc-André Lureau wrote:
> This allows a Spice client to identify a VM
Patch doesn't apply, please rebase.
cheers,
Gerd
1 - 100 of 167 matches
Mail list logo
