On Wed, Dec 02, 2009 at 01:04:16PM +0100, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > On Tue, Dec 01, 2009 at 10:51:26AM -0200, Glauber Costa wrote:
> >> This is a repost of the -smp series. Note that it depends on
> >> irqchip-in-kernel,
> >> that is already in staging. Also, you'll have to enabl
Hi,
In qemu 0.11.0, it handle lddqu as:
case 0x3f0: /* lddqu */
if (mod == 3)
goto illegal_op;
gen_lea_modrm(s, modrm, ®_addr, &offset_addr);
gen_sto_env_A0(s->mem_index, offsetof(CPUX86State,xmm_regs[reg]));
break;
It st the
Add generic support for debugging consoles (simple I/O ports which
when written to cause debugging output to be written to a target.)
The current implementation matches Bochs' port 0xe9, allowing the same
debugging code to be used for both Bochs and Qemu.
There is no vm state associated with the d
On Wed, 2 Dec 2009, H. Peter Anvin wrote:
> Add generic support for debugging consoles (simple I/O ports which
> when written to cause debugging output to be written to a target.)
> The current implementation matches Bochs' port 0xe9, allowing the same
> debugging code to be used for both Bochs an
Add generic support for debugging consoles (simple I/O ports which
when written to cause debugging output to be written to a target.)
The current implementation matches Bochs' port 0xe9, allowing the same
debugging code to be used for both Bochs and Qemu.
There is no vm state associated with the d
Hello Ian,
Pasting chunks, then commenting:
+static int qemu_chr_sched_reconnect(TCPCharDriver *s)
+{
+struct reconnect_list *new = qemu_malloc(sizeof(*new));
+struct timeval tv;
+
+if(!new)
+return 1;
Qemu_malloc will never return 0, so sched function can return void.
+
Some recent change made PPC guests always start at address 0x0 because env
isn't synced to kvm_state on first bootup.
I'm not sure if this is the correct bugfix, but at least it makes PPC boot
again with KVM enabled.
Signed-off-by: Alexander Graf
---
hw/ppc_newworld.c |4
hw/ppc_oldwor
While x86 only needs to sync cr0-4 to know all about its MMU state and enable
qemu to resolve virtual to physical addresses, we need to sync all of the
segment registers on PPC to know which mapping we're in.
So let's grab the segment register contents to be able to use the "x" monitor
command and
Jan Kiszka wrote:
Artyom Tarasenko wrote:
2009/12/1 Alexander Graf :
Hi,
Could someone with commit rights please stand up to feel responsible for
PPC?
Usually, when I send a patch to qemu-devel, I know who to address to
increase chances of it getting committed. For kvm/vnc/block I jus
Am Mittwoch 02 Dezember 2009 09:54:04 schrieb Alexander Graf:
> >
> > Experience has shown that it doesn't work like that. It happens the
> > person writing the patches never provides a fix, and the committer
> > receives the complains, and in fine fixes the commit.
>
> Then revert the patch. I a
Reposting as requested. hopefully t-brid doesnt whitespace-mangle it.
Anthony Liguori wrote:
> > sleep() in qemu is very, very wrong. It will pause the guest's
> > execution and all sorts of badness can ensue.
Quite...
> > The right thing to do is set a timer and not generate data while
> > di
On Wed, 02 Dec 2009 13:54:20 -0600
Anthony Liguori wrote:
> Luiz Capitulino wrote:
> > On Wed, 02 Dec 2009 10:46:11 -0600
> > Anthony Liguori wrote:
> >
> >
> >> I've got all of the patches I'm considering for 0.12 currently in
> >> staging. I'm going to work through and test/commit these i
Ian Molton wrote:
Anthony Liguori wrote:
sleep() in qemu is very, very wrong. It will pause the guest's
execution and all sorts of badness can ensue.
Quite...
The right thing to do is set a timer and not generate data while
disconnected.
New patch attached, now with less
Ian Molton wrote:
Anthony Liguori wrote:
Ian Molton wrote:
Actually, that patch would break a production environment. You cannot
sleep in qemu. It will severely impact the guest.
I refer to the version posted today, which doesnt sleep, but uses a
timer instead. (or did I m
Luiz Capitulino wrote:
On Wed, 02 Dec 2009 10:46:11 -0600
Anthony Liguori wrote:
I've got all of the patches I'm considering for 0.12 currently in
staging. I'm going to work through and test/commit these in a few
chunks over the next few days before freezing the tree.
If you have a pend
Anthony Liguori wrote:
> Ian Molton wrote:
> Actually, that patch would break a production environment. You cannot
> sleep in qemu. It will severely impact the guest.
I refer to the version posted today, which doesnt sleep, but uses a
timer instead. (or did I miss something and a callled functi
Ian Molton wrote:
Anthony Liguori wrote:
I've got all of the patches I'm considering for 0.12 currently in
staging.
http://repo.or.cz/w/qemu/aliguori-queue.git
I see you have my rng and size patches in there, thanks for the quick
review!
Is it too late to get the timer base
Anthony Liguori wrote:
> I've got all of the patches I'm considering for 0.12 currently in
> staging.
> http://repo.or.cz/w/qemu/aliguori-queue.git
I see you have my rng and size patches in there, thanks for the quick
review!
Is it too late to get the timer based socket reconnect patch in and th
On Wed, 02 Dec 2009 10:46:11 -0600
Anthony Liguori wrote:
> I've got all of the patches I'm considering for 0.12 currently in
> staging. I'm going to work through and test/commit these in a few
> chunks over the next few days before freezing the tree.
>
> If you have a pending patch that you
"Michael S. Tsirkin" wrote:
> On Wed, Dec 02, 2009 at 07:38:03PM +0100, Juan Quintela wrote:
>> "Michael S. Tsirkin" wrote:
> I expect it fits in practice.
> But you should range check the value and fail migration on error.
>
>> That is only
>> needed for old versions that we are reading (get_*
Jan Kiszka wrote:
Anthony Liguori wrote:
I've got all of the patches I'm considering for 0.12 currently in
staging. I'm going to work through and test/commit these in a few
chunks over the next few days before freezing the tree.
If you have a pending patch that you think should be in 0.12,
Ryan Harper wrote:
> * Ryan Harper [2009-12-02 13:11]:
>> * Jan Kiszka [2009-12-02 12:45]:
> So far, so consistent. Could you try kvm-kmod-2.6.32-rc7 on top of that?
>
Sure, can you remind me of the kvm-kmod build magic for building that
branch?
>>> If you want to build fro
* Ryan Harper [2009-12-02 13:11]:
> * Jan Kiszka [2009-12-02 12:45]:
> > >>>
> > >> So far, so consistent. Could you try kvm-kmod-2.6.32-rc7 on top of that?
> > >>
> > >
> > > Sure, can you remind me of the kvm-kmod build magic for building that
> > > branch?
> > >
> >
> > If you want to build
Anthony Liguori wrote:
> I've got all of the patches I'm considering for 0.12 currently in
> staging. I'm going to work through and test/commit these in a few
> chunks over the next few days before freezing the tree.
>
> If you have a pending patch that you think should be in 0.12, please
> check
"Michael S. Tsirkin" wrote:
> On Wed, Dec 02, 2009 at 01:04:31PM +0100, Juan Quintela wrote:
>>
>> Signed-off-by: Juan Quintela
>> ---
>> hw/virtio-net.c | 148
>> ---
>> 1 files changed, 64 insertions(+), 84 deletions(-)
>>
>> diff --git a
Artyom Tarasenko wrote:
I thought attaching a second copy were the way to send the patch properly.
Attaching as an application/octet-stream is not terribly helpful. It
basically means you've attached a binary blob.
Is the proper way described somewhere?
The proper way is to use a m
* Jan Kiszka [2009-12-02 12:45]:
> >>>
> >> So far, so consistent. Could you try kvm-kmod-2.6.32-rc7 on top of that?
> >>
> >
> > Sure, can you remind me of the kvm-kmod build magic for building that
> > branch?
> >
>
> If you want to build from git, check Wolfgang's nice README. But it
> might
"Michael S. Tsirkin" wrote:
> I don't understand.
> container_of is just more generic than DO_UPCAST.
> So why *ever* use DO_UPCAST? Let's get rid of it.
functions that use a PCIDevice and you pass FooState "require" that
PCIDevice to be the 1st element in the struct.
Notice that it is "require
"Michael S. Tsirkin" wrote:
> On Wed, Dec 02, 2009 at 07:22:11PM +0100, Juan Quintela wrote:
>> "Michael S. Tsirkin" wrote:
>> > On Wed, Dec 02, 2009 at 01:04:13PM +0100, Juan Quintela wrote:
>> >> diff --git a/hw/virtio.c b/hw/virtio.c
>> >> index c136005..b565bf9 100644
>> >> --- a/hw/virtio.c
On Wed, Dec 02, 2009 at 07:56:58PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Wed, Dec 02, 2009 at 01:04:36PM +0100, Juan Quintela wrote:
> >> viltio_blak_dma_restart_bh() was unsafe, it used req->next after having
> >> (possible) put req in another list
> >>
> >> Signed-off
On Wed, Dec 02, 2009 at 07:55:51PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Wed, Dec 02, 2009 at 07:30:18PM +0100, Juan Quintela wrote:
>
> >> We can change things to be int32_t if that makes more sense (they were sent
> >> as uint32).
> >>
> >> vmstate checks that the ty
On Wed, Dec 02, 2009 at 07:50:33PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Wed, Dec 02, 2009 at 07:22:11PM +0100, Juan Quintela wrote:
> >> "Michael S. Tsirkin" wrote:
> >> > On Wed, Dec 02, 2009 at 01:04:13PM +0100, Juan Quintela wrote:
> >> >> diff --git a/hw/virtio.c b
"Michael S. Tsirkin" wrote:
> You probably can just roll "not used anymore"
> lines in the parent patch. It does not help
> splitting this part out IMO.
I reordered the other patches several times.
Later, Juan.
"Michael S. Tsirkin" wrote:
> On Wed, Dec 02, 2009 at 01:04:36PM +0100, Juan Quintela wrote:
>> viltio_blak_dma_restart_bh() was unsafe, it used req->next after having
>> (possible) put req in another list
>>
>> Signed-off-by: Juan Quintela
>
> Sounds good, but why is this part of vmstate patchs
"Michael S. Tsirkin" wrote:
> On Wed, Dec 02, 2009 at 07:30:18PM +0100, Juan Quintela wrote:
>> We can change things to be int32_t if that makes more sense (they were sent
>> as uint32).
>>
>> vmstate checks that the type of the value that you sent and the function
>> that you use for sending ma
On 02.12.2009, at 19:53, Artyom Tarasenko wrote:
> 2009/12/2 Anthony Liguori :
>> Artyom Tarasenko wrote:
>>>
>>> 2009/12/1 Alexander Graf :
>>>
Hi,
Could someone with commit rights please stand up to feel responsible for
PPC?
Usually, when I send a patch t
"Michael S. Tsirkin" wrote:
> On Wed, Dec 02, 2009 at 07:26:30PM +0100, Juan Quintela wrote:
>> "Michael S. Tsirkin" wrote:
>> > On Wed, Dec 02, 2009 at 01:04:25PM +0100, Juan Quintela wrote:
>> >>
>> >> Signed-off-by: Juan Quintela
>> >> ---
>> >> hw/virtio-net.c | 21 ++---
2009/12/2 Anthony Liguori :
> Artyom Tarasenko wrote:
>>
>> 2009/12/1 Alexander Graf :
>>
>>>
>>> Hi,
>>>
>>> Could someone with commit rights please stand up to feel responsible for
>>> PPC?
>>>
>>> Usually, when I send a patch to qemu-devel, I know who to address to
>>> increase chances of it get
On Wed, 2009-12-02 at 19:33 +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > No objection to this or similar change with vlans,
> > but I'd like to know why was this made a separate buffer
> > originally.
>
> Dunno, either, but I think that this has been always that way.
>
> commit
2009/12/2 Jan Kiszka :
> Artyom Tarasenko wrote:
>> 2009/12/1 Alexander Graf :
>>> Hi,
>>>
>>> Could someone with commit rights please stand up to feel responsible for
>>> PPC?
>>>
>>> Usually, when I send a patch to qemu-devel, I know who to address to
>>> increase chances of it getting committed.
On Wed, Dec 02, 2009 at 07:42:35PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Wed, Dec 02, 2009 at 07:19:17PM +0100, Juan Quintela wrote:
> >> "Michael S. Tsirkin" wrote:
> >> > On Wed, Dec 02, 2009 at 01:04:04PM +0100, Juan Quintela wrote:
> >> >> virtio_common_init() creat
On Wed, Dec 02, 2009 at 01:04:09PM +0100, Juan Quintela wrote:
>
> Signed-off-by: Juan Quintela
Let's just use binding for this.
> ---
> hw/syborg_virtio.c |1 +
> hw/virtio-pci.c|2 +-
> hw/virtio.h|6 ++
> 3 files changed, 8 insertions(+), 1 deletions(-)
>
> diff
Ryan Harper wrote:
> * Jan Kiszka [2009-12-02 12:18]:
>> Ryan Harper wrote:
>>> * Jan Kiszka [2009-12-02 12:07]:
Ryan Harper wrote:
> * Jan Kiszka [2009-12-02 09:28]:
>> Hi,
>>
>> I'm facing stalled x86-64 guests after live migration when using kvm
>> (share disk images)
"Michael S. Tsirkin" wrote:
> On Wed, Dec 02, 2009 at 07:19:17PM +0100, Juan Quintela wrote:
>> "Michael S. Tsirkin" wrote:
>> > On Wed, Dec 02, 2009 at 01:04:04PM +0100, Juan Quintela wrote:
>> >> virtio_common_init() creates a struct with the right size, DO_UPCAST
>> >> is the appropiate thing
On Wed, Dec 02, 2009 at 01:03:59PM +0100, Juan Quintela wrote:
>
> Signed-off-by: Juan Quintela
container_of please
> ---
> hw/virtio-balloon.c | 11 +++
> 1 files changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/hw/virtio-balloon.c b/hw/virtio-balloon.c
> index cfd3b41..23
On Wed, Dec 02, 2009 at 07:38:03PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Wed, Dec 02, 2009 at 01:04:31PM +0100, Juan Quintela wrote:
> >>
> >> Signed-off-by: Juan Quintela
> >> ---
> >> hw/virtio-net.c | 148
> >> -
On Wed, Dec 02, 2009 at 01:04:31PM +0100, Juan Quintela wrote:
>
> Signed-off-by: Juan Quintela
> ---
> hw/virtio-net.c | 148
> ---
> 1 files changed, 64 insertions(+), 84 deletions(-)
>
> diff --git a/hw/virtio-net.c b/hw/virtio-net.c
> in
Artyom Tarasenko wrote:
2009/12/1 Alexander Graf :
Hi,
Could someone with commit rights please stand up to feel responsible for
PPC?
Usually, when I send a patch to qemu-devel, I know who to address to
increase chances of it getting committed. For kvm/vnc/block I just CC
Anthony, for Audio
"Michael S. Tsirkin" wrote:
> On Wed, Dec 02, 2009 at 01:04:31PM +0100, Juan Quintela wrote:
>>
>> Signed-off-by: Juan Quintela
>> ---
>> hw/virtio-net.c | 148
>> ---
>> 1 files changed, 64 insertions(+), 84 deletions(-)
>>
>> diff --git a
"Michael S. Tsirkin" wrote:
> No objection to this or similar change with vlans,
> but I'd like to know why was this made a separate buffer
> originally.
Dunno, either, but I think that this has been always that way.
commit b6503ed9b8815ecfb82fe9faba28936365321248 was when it was introduced
Al
* Jan Kiszka [2009-12-02 12:18]:
> Ryan Harper wrote:
> > * Jan Kiszka [2009-12-02 12:07]:
> >> Ryan Harper wrote:
> >>> * Jan Kiszka [2009-12-02 09:28]:
> Hi,
>
> I'm facing stalled x86-64 guests after live migration when using kvm
> (share disk images). This does not happen
On Wed, Dec 02, 2009 at 07:30:18PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Wed, Dec 02, 2009 at 01:04:27PM +0100, Juan Quintela wrote:
> >> And they were saved/loaded as unsigned already
> >
> > I'm not sure how does on save/load a value as unsigned.
> > Could you please p
On Wed, Dec 02, 2009 at 07:26:30PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Wed, Dec 02, 2009 at 01:04:25PM +0100, Juan Quintela wrote:
> >>
> >> Signed-off-by: Juan Quintela
> >> ---
> >> hw/virtio-net.c | 21 ++---
> >> 1 files changed, 18 insertions(
Artyom Tarasenko wrote:
> 2009/12/1 Alexander Graf :
>> Hi,
>>
>> Could someone with commit rights please stand up to feel responsible for
>> PPC?
>>
>> Usually, when I send a patch to qemu-devel, I know who to address to
>> increase chances of it getting committed. For kvm/vnc/block I just CC
>> A
"Michael S. Tsirkin" wrote:
> On Wed, Dec 02, 2009 at 01:04:27PM +0100, Juan Quintela wrote:
>> And they were saved/loaded as unsigned already
>
> I'm not sure how does on save/load a value as unsigned.
> Could you please provide motivation for this
> and similar changes?
> Not that it matters ver
On Wed, Dec 02, 2009 at 07:22:11PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Wed, Dec 02, 2009 at 01:04:13PM +0100, Juan Quintela wrote:
> >> diff --git a/hw/virtio.c b/hw/virtio.c
> >> index c136005..b565bf9 100644
> >> --- a/hw/virtio.c
> >> +++ b/hw/virtio.c
> >> @@ -643,
"Michael S. Tsirkin" wrote:
> On Wed, Dec 02, 2009 at 01:04:25PM +0100, Juan Quintela wrote:
>>
>> Signed-off-by: Juan Quintela
>> ---
>> hw/virtio-net.c | 21 ++---
>> 1 files changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/hw/virtio-net.c b/hw/virtio-net.c
>> i
On Wed, Dec 02, 2009 at 07:24:12PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Wed, Dec 02, 2009 at 01:04:17PM +0100, Juan Quintela wrote:
> >>
> >> Signed-off-by: Juan Quintela
> >> ---
> >> hw/virtio.c |8
> >> 1 files changed, 4 insertions(+), 4 deletions(-)
"Michael S. Tsirkin" wrote:
> On Wed, Dec 02, 2009 at 01:04:17PM +0100, Juan Quintela wrote:
>>
>> Signed-off-by: Juan Quintela
>> ---
>> hw/virtio.c |8
>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/hw/virtio.c b/hw/virtio.c
>> index fd617ff..2b36cad 1006
On Wed, Dec 02, 2009 at 01:04:19PM +0100, Juan Quintela wrote:
> We need to do the virt queue msix and not msix version because we know
> if there is msix at virtio level, not at queue element level
>
> Signed-off-by: Juan Quintela
> ---
> hw/hw.h | 10 +
> hw/virtio.c | 121
> ++
"Michael S. Tsirkin" wrote:
> On Wed, Dec 02, 2009 at 01:04:13PM +0100, Juan Quintela wrote:
>> diff --git a/hw/virtio.c b/hw/virtio.c
>> index c136005..b565bf9 100644
>> --- a/hw/virtio.c
>> +++ b/hw/virtio.c
>> @@ -643,8 +643,10 @@ void virtio_save(VirtIODevice *vdev, QEMUFile *f)
>> qe
On Wed, Dec 02, 2009 at 07:19:17PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
> > On Wed, Dec 02, 2009 at 01:04:04PM +0100, Juan Quintela wrote:
> >> virtio_common_init() creates a struct with the right size, DO_UPCAST
> >> is the appropiate thing here
> >>
> >> Signed-off-by: Juan
You probably can just roll "not used anymore"
lines in the parent patch. It does not help
splitting this part out IMO.
On Wed, Dec 02, 2009 at 01:04:39PM +0100, Juan Quintela wrote:
>
> Signed-off-by: Juan Quintela
> ---
> hw/virtio.c | 10 --
> hw/virtio.h |4
> 2 files chan
"Michael S. Tsirkin" wrote:
> On Wed, Dec 02, 2009 at 01:04:04PM +0100, Juan Quintela wrote:
>> virtio_common_init() creates a struct with the right size, DO_UPCAST
>> is the appropiate thing here
>>
>> Signed-off-by: Juan Quintela
>
> BTW why not container_of? That one does not require
> field
Jan Kiszka wrote:
> Hi,
>
> I'm facing stalled x86-64 guests after live migration when using kvm
> (share disk images). This does not happen with x86-32 guests or when
> disabling kvm. Both qemu and qemu-kvm git heads are affected (recent
> vmstate fixes applied). Running I/O load during the migra
Ryan Harper wrote:
> * Jan Kiszka [2009-12-02 12:07]:
>> Ryan Harper wrote:
>>> * Jan Kiszka [2009-12-02 09:28]:
Hi,
I'm facing stalled x86-64 guests after live migration when using kvm
(share disk images). This does not happen with x86-32 guests or when
disabling kvm. Bo
* Jan Kiszka [2009-12-02 12:07]:
> Ryan Harper wrote:
> > * Jan Kiszka [2009-12-02 09:28]:
> >> Hi,
> >>
> >> I'm facing stalled x86-64 guests after live migration when using kvm
> >> (share disk images). This does not happen with x86-32 guests or when
> >> disabling kvm. Both qemu and qemu-kvm g
Ryan Harper wrote:
> * Jan Kiszka [2009-12-02 09:28]:
>> Hi,
>>
>> I'm facing stalled x86-64 guests after live migration when using kvm
>> (share disk images). This does not happen with x86-32 guests or when
>> disabling kvm. Both qemu and qemu-kvm git heads are affected (recent
>> vmstate fixes a
Is -icount option supposed to work under qemu-system-sparc?
Tried a couple of values between 1 and 30 and get
qemu: fatal: Raised interrupt while not in I/O function
On Wed, Dec 02, 2009 at 01:04:38PM +0100, Juan Quintela wrote:
> This driver send a struct directly in the wire, where the struct
> contains:
> - target_phis_addr_t (can be 32 or 64 bits depending of host)
> - void * (on host)
> - size_t.
>
> It has no hope of working across 32/64 or big/little en
On Wed, Dec 02, 2009 at 01:04:36PM +0100, Juan Quintela wrote:
> viltio_blak_dma_restart_bh() was unsafe, it used req->next after having
> (possible) put req in another list
>
> Signed-off-by: Juan Quintela
Sounds good, but why is this part of vmstate patchset?
> ---
> hw/virtio-blk.c | 29 +
I've got all of the patches I'm considering for 0.12 currently in
staging. I'm going to work through and test/commit these in a few
chunks over the next few days before freezing the tree.
If you have a pending patch that you think should be in 0.12, please
check to make sure it's there. If y
* Jan Kiszka [2009-12-02 09:28]:
> Hi,
>
> I'm facing stalled x86-64 guests after live migration when using kvm
> (share disk images). This does not happen with x86-32 guests or when
> disabling kvm. Both qemu and qemu-kvm git heads are affected (recent
> vmstate fixes applied). Running I/O load
Can you update this against staging (or master if you want 24 hours) to
take into account Mark's nic refactoring series? The changes looked
non-trivial to me.
Regards,
Anthony Liguori
Arnd Bergmann wrote:
With the upcoming macvtap, we will want to open devices other than
/dev/net/tun but no longer need to call TUNSETIFF.
What are the names of these devices and how do you the character devices
get created in the first place?
This really isn't an "arbitrary" char device
2009/12/1 Alexander Graf :
> Hi,
>
> Could someone with commit rights please stand up to feel responsible for
> PPC?
>
> Usually, when I send a patch to qemu-devel, I know who to address to
> increase chances of it getting committed. For kvm/vnc/block I just CC
> Anthony, for Audio I just CC malc,
Hi,
I'm facing stalled x86-64 guests after live migration when using kvm
(share disk images). This does not happen with x86-32 guests or when
disabling kvm. Both qemu and qemu-kvm git heads are affected (recent
vmstate fixes applied). Running I/O load during the migration (e.g. a
simple "ls -R /")
On Wed, Dec 02, 2009 at 01:04:31PM +0100, Juan Quintela wrote:
>
> Signed-off-by: Juan Quintela
> ---
> hw/virtio-net.c | 148
> ---
> 1 files changed, 64 insertions(+), 84 deletions(-)
>
> diff --git a/hw/virtio-net.c b/hw/virtio-net.c
> in
Markus Armbruster wrote:
The commit message is bogus. The patch is a minor fix of commit
e8ee28fb, and the message is a copy of that commit's message.
Thanks, I've updated the commit message appropriately.
Regards,
Anthony Liguori
No objection to this or similar change with vlans,
but I'd like to know why was this made a separate buffer
originally.
On Wed, Dec 02, 2009 at 01:04:29PM +0100, Juan Quintela wrote:
>
> Signed-off-by: Juan Quintela
> ---
> hw/virtio-net.c |6 +-
> 1 files changed, 1 insertions(+), 5 d
On Wed, Dec 02, 2009 at 01:04:27PM +0100, Juan Quintela wrote:
> And they were saved/loaded as unsigned already
I'm not sure how does on save/load a value as unsigned.
Could you please provide motivation for this
and similar changes?
Not that it matters very much, but int is slightly cleaner
than
Gerd Hoffmann wrote:
On 11/23/09 16:20, Anthony Liguori wrote:
Gerd Hoffmann wrote:
On 11/23/09 14:26, Paul Brook wrote:
I thinking more that this should be done by the character backend
itself. For
example, the "graphical" consoles should probably be putting this as
part of
the window title
On Wed, Dec 02, 2009 at 01:04:26PM +0100, Juan Quintela wrote:
> This fixes endianess problems. Using ints and saving the state as bytes
> break cross-endian migration.
>
> Signed-off-by: Juan Quintela
Good catch in itself, but relies on a broken patch before that.
> ---
> hw/virtio-net.c |
On Wed, Dec 02, 2009 at 01:04:25PM +0100, Juan Quintela wrote:
>
> Signed-off-by: Juan Quintela
> ---
> hw/virtio-net.c | 21 ++---
> 1 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/hw/virtio-net.c b/hw/virtio-net.c
> index 97db0d0..cf13e94 100644
> --- a/hw
On Wed, Dec 02, 2009 at 01:04:14PM +0100, Juan Quintela wrote:
>
> Signed-off-by: Juan Quintela
> ---
> hw/virtio.c | 32 +++-
> hw/virtio.h |2 ++
> 2 files changed, 21 insertions(+), 13 deletions(-)
>
> diff --git a/hw/virtio.c b/hw/virtio.c
> index b565bf9..
On Wed, Dec 02, 2009 at 01:04:13PM +0100, Juan Quintela wrote:
> It was used only for PCI virtio devices, state that explicitely
>
> Signed-off-by: Juan Quintela
> ---
> hw/virtio-pci.c | 24 ++--
> hw/virtio.c | 22 --
> hw/virtio.h |4 ++-
On Wed, Dec 02, 2009 at 01:04:10PM +0100, Juan Quintela wrote:
>
> Signed-off-by: Juan Quintela
> ---
> hw/virtio-pci.c | 72 ++
> 1 files changed, 50 insertions(+), 22 deletions(-)
>
> diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
> index
> > Our cpu keeps multiple seperate address spaces open at the same time
> > (similar to x86 with a bunch of cr0s), defined by address space control
> > elements in various control registers. Linux uses primary, secondary and
> > home space to address user space and kernel space. The third one is u
Kevin Wolf wrote:
Am 02.12.2009 12:24, schrieb Kevin Wolf:
We're leaking file descriptors to child processes. Set FD_CLOEXEC on file
descriptors that don't need to be passed to children to stop this misbehaviour.
Signed-off-by: Kevin Wolf
---
v2:
- The existence of SOCK_CLOEXEC doesn't mea
On Wed, Dec 02, 2009 at 11:54:45AM -0200, Marcelo Tosatti wrote:
> On Wed, Dec 02, 2009 at 11:41:19AM -0200, Glauber Costa wrote:
> > > KVM vcpu threads should block SIGUSR1, set the in-kernel signal mask
> > > with KVM_SET_SIGNAL_MASK ioctl, and eat the signal in
> > > qemu_wait_io_event (qemu_fl
This does not make a lot of sense separately:
you are changing routines that you yourself
then remove. And there is another helper not_msix
which you add in the next patch.
Maybe just roll this patch in
with the next one and be done with it.
On Wed, Dec 02, 2009 at 01:04:18PM +0100, Juan Quint
On Wed, Dec 02, 2009 at 11:41:19AM -0200, Glauber Costa wrote:
> > KVM vcpu threads should block SIGUSR1, set the in-kernel signal mask
> > with KVM_SET_SIGNAL_MASK ioctl, and eat the signal in
> > qemu_wait_io_event (qemu_flush_work should run after eating
> > the signal). Similarly to qemu-kvm's
On Wed, Dec 02, 2009 at 01:04:17PM +0100, Juan Quintela wrote:
>
> Signed-off-by: Juan Quintela
> ---
> hw/virtio.c |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/hw/virtio.c b/hw/virtio.c
> index fd617ff..2b36cad 100644
> --- a/hw/virtio.c
> +++ b/hw/virti
It is much faster than pthread_{g,s}et_specific.
Signed-off-by: Glauber Costa
---
configure | 17 +
vl.c | 16
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index dca5a43..ce7bcc4 100755
--- a/configure
+++ b/confi
We don't support smp without irqchip in kernel, so only abort in
that situation
Signed-off-by: Glauber Costa
---
kvm-all.c | 10 +-
kvm.h |2 ++
target-i386/kvm.c |7 +++
target-ppc/kvm.c |5 +
4 files changed, 19 insertions(+), 5 deletions(-)
The proposal in this patch is to add a system_reset caller that only
resets state related to the cpu. This will guarantee that does functions
are called from the cpu-threads, not the I/O thread.
In principle, it might seem close to the remote execution mechanism, but:
* It does not involve any ex
This have already been identified in qemu-kvm. We have to synchronously
tell the kernel about the APIC state. Otherwise, other cpus can see
bogus state for this lapic.
Signed-off-by: Glauber Costa
---
hw/apic-kvm.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/hw/apic
All reset functions are called from the same place, and this was a leftover
Signed-off-by: Glauber Costa
---
kvm-all.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 596416a..1072d63 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -204,8 +204,6 @@
Before signalling a cpu, we have to set exit_request = 1, otherwise
it may go back to executing itself. So every cpu wakeup becomes
at least two statements. The qemu_cpu_kick already provides semantics
to that. So use it all over.
Signed-off-by: Glauber Costa
---
vl.c |6 +++---
1 files chan
This fix a bug with -smp in kvm. Since we have updated apic_base,
we also have to tell kernel about it. So instead of just updating
mp_state, update every regs.
It is mandatory that this happens synchronously, without waiting for
the next vcpu run. Otherwise, if we are migrating, or initializing
t
1 - 100 of 244 matches
Mail list logo
