On 02/23/2017 10:47 AM, Paolo Bonzini wrote:
>
>
> On 23/02/2017 10:33, Cédric Le Goater wrote:
>> I still have migration issues with this patch on ppc, which fails
>> on the target guest with :
>>
>> qemu-system-ppc64: VQ 0 size 0x80 < last_avail_idx 0xe1e - used_idx 0x0
>> qemu-system-ppc64:
On 23/02/2017 10:33, Cédric Le Goater wrote:
> I still have migration issues with this patch on ppc, which fails
> on the target guest with :
>
> qemu-system-ppc64: VQ 0 size 0x80 < last_avail_idx 0xe1e - used_idx 0x0
> qemu-system-ppc64: Failed to load virtio-blk:virtio
> qemu-system-ppc64:
Hello,
On 02/23/2017 01:32 AM, Alex Williamson wrote:
> On Wed, 22 Feb 2017 10:03:56 +0100
> Paolo Bonzini wrote:
>
>> On 21/02/2017 18:54, Laszlo Ersek wrote:
>>> Actually, QEMU segfaults. From the dmesg:
>>>
>>> [Tue Feb 21 18:47:28 2017] CPU 0/KVM[8298]: segfault at 48
On Wed, 22 Feb 2017 10:03:56 +0100
Paolo Bonzini wrote:
> On 21/02/2017 18:54, Laszlo Ersek wrote:
> > Actually, QEMU segfaults. From the dmesg:
> >
> > [Tue Feb 21 18:47:28 2017] CPU 0/KVM[8298]: segfault at 48 ip
> > 7fcb5dd02105 sp 7fcb49efc270 error 4 in
> >
On 21/02/2017 18:54, Laszlo Ersek wrote:
> Actually, QEMU segfaults. From the dmesg:
>
> [Tue Feb 21 18:47:28 2017] CPU 0/KVM[8298]: segfault at 48 ip
> 7fcb5dd02105 sp 7fcb49efc270 error 4 in
> qemu-system-x86_64[7fcb5dae3000+905000]
>
> Complete backtrace below. (Thread 11 seems to
Hi,
> The bug reproduces for me with current upstream OVMF. I sent a full QEMU
> backtrace (SIGSEGV) in another message. I use libvirt (and I assume Gerd
> does that too, because otherwise the shell would report the SIGSEGV
> immediately).
libvirt indeed, config attached.
cheers,
Gerd
On 02/21/17 19:08, Paolo Bonzini wrote:
>
>
> On 21/02/2017 13:57, Gerd Hoffmann wrote:
>> This change breaks ovmf for me, although it isn't obvious to me why.
>> Bisect landed here, and reverting indeed makes things going again.
>>
>> Using q35 machine type, pcie virtio devices, with the rhel
On 21/02/2017 13:57, Gerd Hoffmann wrote:
> This change breaks ovmf for me, although it isn't obvious to me why.
> Bisect landed here, and reverting indeed makes things going again.
>
> Using q35 machine type, pcie virtio devices, with the rhel ovmf build
>
On 02/21/17 17:25, Laszlo Ersek wrote:
> On 02/21/17 13:57, Gerd Hoffmann wrote:
>> On Fr, 2017-02-17 at 21:54 +0200, Michael S. Tsirkin wrote:
>>> From: Paolo Bonzini
>>>
>>> The virtio-net change is necessary because it uses virtqueue_fill
>>> and virtqueue_flush instead of
On 02/21/17 13:57, Gerd Hoffmann wrote:
> On Fr, 2017-02-17 at 21:54 +0200, Michael S. Tsirkin wrote:
>> From: Paolo Bonzini
>>
>> The virtio-net change is necessary because it uses virtqueue_fill
>> and virtqueue_flush instead of the more convenient virtqueue_push.
>>
>>
On Fr, 2017-02-17 at 21:54 +0200, Michael S. Tsirkin wrote:
> From: Paolo Bonzini
>
> The virtio-net change is necessary because it uses virtqueue_fill
> and virtqueue_flush instead of the more convenient virtqueue_push.
>
> Reviewed-by: Stefan Hajnoczi
From: Paolo Bonzini
The virtio-net change is necessary because it uses virtqueue_fill
and virtqueue_flush instead of the more convenient virtqueue_push.
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Paolo Bonzini
Reviewed-by:
12 matches
Mail list logo