* [Qemu-devel] virtio block device is not working
@ 2018-01-23 3:05 joserz
2018-01-23 12:34 ` joserz
0 siblings, 1 reply; 4+ messages in thread
From: joserz @ 2018-01-23 3:05 UTC (permalink / raw)
To: ghammer, mst; +Cc: qemu-devel
Hello people!
I'm not able to boot any guest that sets a virtio block device like:
(branch master)
[PPC64]
qemu-system-ppc64 -cpu POWER8 -nographic -vga none -m 4G -M pseries,accel=kvm,kvm-type=PR -drive file=disk.qcow2,if=virtio
QEMU Starting
Build Date = Dec 18 2017 13:08:00
FW Version = git-fa981320a1e0968d
Press "s" to enter Open Firmware.
Populating /vdevice methods
Populating /vdevice/vty@71000000
Populating /vdevice/nvram@71000001
Populating /vdevice/v-scsi@71000002
SCSI: Looking for devices
8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+"
Populating /pci@800000020000000
00 0000 (D) : 1af4 1000 virtio [ net ]
Aborted
[x86]
qemu-system-x86_64 -m 4G -enable-kvm -drive file=util.qcow2,if=virtio
Running QEMU with GTK 2.x is deprecated, and will be removed
in a future release. Please switch to GTK 3.x instead
[1] 5282 abort
[Cause]
The commit 4fe6d78b2e introduces the
...
kvm_mem_ioeventfd_del(...) {
...
r = kvm_set_ioeventfd_mmio(fd, ...
if (r < 0) {
abort();
}
+ if (e->cleanup) {
+ e->cleanup(e);
+ }
}
For some reason, not yet clear to me, cleanup() calls the same
kvm_mem_ioeventfd_del again and again until kvm_set_ioeventfd_mmio
returns < 0 and abort().
I was going to send a patch to revert that 'if ()' but I think it could
cause a regression. What do you guys think?
Thanks,
Jose Ricardo Ziviani
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] virtio block device is not working
2018-01-23 3:05 [Qemu-devel] virtio block device is not working joserz
@ 2018-01-23 12:34 ` joserz
2018-01-23 12:47 ` Daniel Henrique Barboza
0 siblings, 1 reply; 4+ messages in thread
From: joserz @ 2018-01-23 12:34 UTC (permalink / raw)
To: ghammer, mst; +Cc: qemu-devel
On Tue, Jan 23, 2018 at 01:05:28AM -0200, joserz@linux.vnet.ibm.com wrote:
> Hello people!
>
> I'm not able to boot any guest that sets a virtio block device like:
> (branch master)
>
> [PPC64]
> qemu-system-ppc64 -cpu POWER8 -nographic -vga none -m 4G -M pseries,accel=kvm,kvm-type=PR -drive file=disk.qcow2,if=virtio
my bad, actually the command line is:
qemu-system-ppc64 -cpu POWER8 -nographic -vga none -m 4G -M pseries,accel=kvm -netdev type=user,id=net0 -device virtio-net-pci,netdev=net0 -drive file=../disk.qcow2,if=virtio
and the problem seem to be in virtio-net-pci, not in the block device
> QEMU Starting
> Build Date = Dec 18 2017 13:08:00
> FW Version = git-fa981320a1e0968d
> Press "s" to enter Open Firmware.
>
> Populating /vdevice methods
> Populating /vdevice/vty@71000000
> Populating /vdevice/nvram@71000001
> Populating /vdevice/v-scsi@71000002
> SCSI: Looking for devices
> 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+"
> Populating /pci@800000020000000
> 00 0000 (D) : 1af4 1000 virtio [ net ]
> Aborted
>
> [x86]
>
> qemu-system-x86_64 -m 4G -enable-kvm -drive file=util.qcow2,if=virtio
> Running QEMU with GTK 2.x is deprecated, and will be removed
> in a future release. Please switch to GTK 3.x instead
> [1] 5282 abort
>
> [Cause]
>
> The commit 4fe6d78b2e introduces the
>
> ...
> kvm_mem_ioeventfd_del(...) {
> ...
> r = kvm_set_ioeventfd_mmio(fd, ...
> if (r < 0) {
> abort();
> }
>
> + if (e->cleanup) {
> + e->cleanup(e);
> + }
> }
>
> For some reason, not yet clear to me, cleanup() calls the same
> kvm_mem_ioeventfd_del again and again until kvm_set_ioeventfd_mmio
> returns < 0 and abort().
>
> I was going to send a patch to revert that 'if ()' but I think it could
> cause a regression. What do you guys think?
>
> Thanks,
>
> Jose Ricardo Ziviani
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] virtio block device is not working
2018-01-23 12:34 ` joserz
@ 2018-01-23 12:47 ` Daniel Henrique Barboza
2018-01-23 13:02 ` Daniel Henrique Barboza
0 siblings, 1 reply; 4+ messages in thread
From: Daniel Henrique Barboza @ 2018-01-23 12:47 UTC (permalink / raw)
To: joserz, ghammer, mst; +Cc: qemu-devel
Yeah, the problem looks like in virtio-pci-net. This is the output when
running in a Power 9
host:
sudo ./qemu-system-ppc64 -nographic -vga none -m 4G -M pseries,accel=kvm
-netdev type=user,id=net0 -device virtio-net-pci,netdev=net0
SLOF **********************************************************************
QEMU Starting
Build Date = Dec 18 2017 13:08:00
FW Version = git-fa981320a1e0968d
Press "s" to enter Open Firmware.
Populating /vdevice methods
Populating /vdevice/vty@71000000
Populating /vdevice/nvram@71000001
Populating /vdevice/v-scsi@71000002
SCSI: Looking for devices
8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+"
Populating /pci@800000020000000
00 0000 (D) : 1af4 1000 virtio [ net ]
Aborted
As Ziviani mentioned, reverting 4fe6d78b2e fixes it:
$ git diff
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 071f4f5..f290f48 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -812,10 +812,6 @@ static void kvm_mem_ioeventfd_del(MemoryListener
*listener,
if (r < 0) {
abort();
}
-
- if (e->cleanup) {
- e->cleanup(e);
- }
}
$ sudo ./qemu-system-ppc64 -nographic -vga none -m 4G -M
pseries,accel=kvm -netdev type=user,id=net0 -device
virtio-net-pci,netdev=net0
SLOF **********************************************************************
QEMU Starting
Build Date = Dec 18 2017 13:08:00
FW Version = git-fa981320a1e0968d
Press "s" to enter Open Firmware.
Populating /vdevice methods
Populating /vdevice/vty@71000000
Populating /vdevice/nvram@71000001
Populating /vdevice/v-scsi@71000002
SCSI: Looking for devices
8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+"
Populating /pci@800000020000000
00 0000 (D) : 1af4 1000 virtio [ net ]
No NVRAM common partition, re-initializing...
Scanning USB
Using default console: /vdevice/vty@71000000
Welcome to Open Firmware
Copyright (c) 2004, 2017 IBM Corporation All rights reserved.
This program and the accompanying materials are made available
under the terms of the BSD License available at
http://www.opensource.org/licenses/bsd-license.php
Trying to load: from: disk ...
E3405: No such device
Trying to load: from: /vdevice/v-scsi@71000002/disk@8200000000000000
... No medium !
E3405: No such device
Trying to load: from: /pci@800000020000000/ethernet@0 ...
Initializing NIC
Reading MAC address from device: 52:54:00:12:34:56
Requesting information via DHCP: done
Using IPv4 address: 10.0.2.15
Requesting file "" via TFTP from 10.0.2.2
Receiving data: 0 KBytes
E3010 (net) TFTP access violation
E3407: Load failed
Type 'boot' and press return to continue booting the system.
Type 'reset-all' and press return to reboot the system.
Ready!
0 >
On 01/23/2018 10:34 AM, joserz@linux.vnet.ibm.com wrote:
> On Tue, Jan 23, 2018 at 01:05:28AM -0200, joserz@linux.vnet.ibm.com wrote:
>> Hello people!
>>
>> I'm not able to boot any guest that sets a virtio block device like:
>> (branch master)
>>
>> [PPC64]
>> qemu-system-ppc64 -cpu POWER8 -nographic -vga none -m 4G -M pseries,accel=kvm,kvm-type=PR -drive file=disk.qcow2,if=virtio
> my bad, actually the command line is:
>
> qemu-system-ppc64 -cpu POWER8 -nographic -vga none -m 4G -M pseries,accel=kvm -netdev type=user,id=net0 -device virtio-net-pci,netdev=net0 -drive file=../disk.qcow2,if=virtio
>
> and the problem seem to be in virtio-net-pci, not in the block device
>
>
>> QEMU Starting
>> Build Date = Dec 18 2017 13:08:00
>> FW Version = git-fa981320a1e0968d
>> Press "s" to enter Open Firmware.
>>
>> Populating /vdevice methods
>> Populating /vdevice/vty@71000000
>> Populating /vdevice/nvram@71000001
>> Populating /vdevice/v-scsi@71000002
>> SCSI: Looking for devices
>> 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+"
>> Populating /pci@800000020000000
>> 00 0000 (D) : 1af4 1000 virtio [ net ]
>> Aborted
>>
>> [x86]
>>
>> qemu-system-x86_64 -m 4G -enable-kvm -drive file=util.qcow2,if=virtio
>> Running QEMU with GTK 2.x is deprecated, and will be removed
>> in a future release. Please switch to GTK 3.x instead
>> [1] 5282 abort
>>
>> [Cause]
>>
>> The commit 4fe6d78b2e introduces the
>>
>> ...
>> kvm_mem_ioeventfd_del(...) {
>> ...
>> r = kvm_set_ioeventfd_mmio(fd, ...
>> if (r < 0) {
>> abort();
>> }
>>
>> + if (e->cleanup) {
>> + e->cleanup(e);
>> + }
>> }
>>
>> For some reason, not yet clear to me, cleanup() calls the same
>> kvm_mem_ioeventfd_del again and again until kvm_set_ioeventfd_mmio
>> returns < 0 and abort().
>>
>> I was going to send a patch to revert that 'if ()' but I think it could
>> cause a regression. What do you guys think?
>>
>> Thanks,
>>
>> Jose Ricardo Ziviani
>>
>>
>
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] virtio block device is not working
2018-01-23 12:47 ` Daniel Henrique Barboza
@ 2018-01-23 13:02 ` Daniel Henrique Barboza
0 siblings, 0 replies; 4+ messages in thread
From: Daniel Henrique Barboza @ 2018-01-23 13:02 UTC (permalink / raw)
To: joserz, ghammer, mst; +Cc: qemu-devel
With a gdb attached I got the following backtrace:
Program received signal SIGABRT, Aborted.
0x00007ffff5f5eff0 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff5f5eff0 in raise () at /lib64/libc.so.6
#1 0x00007ffff5f6136c in abort () at /lib64/libc.so.6
#2 0x000000001009e704 in kvm_mem_ioeventfd_del (listener=<optimized
out>, section=0x7ffff2e6da00, match_data=<optimized out>, data=0,
e=0x7ffff23d0080)
at /home/danielhb/qemu/accel/kvm/kvm-all.c:813
#3 0x000000001008845c in address_space_add_del_ioeventfds
(as=0x10c2df10 <address_space_memory>, fds_new=0x0,
fds_new_nb=<optimized out>, fds_old=0x7fffe4078f20,
fds_old_nb=<optimized out>) at /home/danielhb/qemu/memory.c:832
#4 0x0000000000000000 in ()
(gdb)
At first glance it looks like kvm_mem_ioeventfd_del can't cleanup the
EventNotifier
it received by itself. Reverting the patch that introduced it looks like
a good
short term solution.
Daniel
On 01/23/2018 10:47 AM, Daniel Henrique Barboza wrote:
> Yeah, the problem looks like in virtio-pci-net. This is the output
> when running in a Power 9
> host:
>
> sudo ./qemu-system-ppc64 -nographic -vga none -m 4G -M
> pseries,accel=kvm -netdev type=user,id=net0 -device
> virtio-net-pci,netdev=net0
>
>
> SLOF
> **********************************************************************
> QEMU Starting
> Build Date = Dec 18 2017 13:08:00
> FW Version = git-fa981320a1e0968d
> Press "s" to enter Open Firmware.
>
> Populating /vdevice methods
> Populating /vdevice/vty@71000000
> Populating /vdevice/nvram@71000001
> Populating /vdevice/v-scsi@71000002
> SCSI: Looking for devices
> 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+"
> Populating /pci@800000020000000
> 00 0000 (D) : 1af4 1000 virtio [ net ]
> Aborted
>
>
> As Ziviani mentioned, reverting 4fe6d78b2e fixes it:
>
>
> $ git diff
> diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
> index 071f4f5..f290f48 100644
> --- a/accel/kvm/kvm-all.c
> +++ b/accel/kvm/kvm-all.c
> @@ -812,10 +812,6 @@ static void kvm_mem_ioeventfd_del(MemoryListener
> *listener,
> if (r < 0) {
> abort();
> }
> -
> - if (e->cleanup) {
> - e->cleanup(e);
> - }
> }
>
> $ sudo ./qemu-system-ppc64 -nographic -vga none -m 4G -M
> pseries,accel=kvm -netdev type=user,id=net0 -device
> virtio-net-pci,netdev=net0
>
>
> SLOF
> **********************************************************************
> QEMU Starting
> Build Date = Dec 18 2017 13:08:00
> FW Version = git-fa981320a1e0968d
> Press "s" to enter Open Firmware.
>
> Populating /vdevice methods
> Populating /vdevice/vty@71000000
> Populating /vdevice/nvram@71000001
> Populating /vdevice/v-scsi@71000002
> SCSI: Looking for devices
> 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+"
> Populating /pci@800000020000000
> 00 0000 (D) : 1af4 1000 virtio [ net ]
> No NVRAM common partition, re-initializing...
> Scanning USB
> Using default console: /vdevice/vty@71000000
>
> Welcome to Open Firmware
>
> Copyright (c) 2004, 2017 IBM Corporation All rights reserved.
> This program and the accompanying materials are made available
> under the terms of the BSD License available at
> http://www.opensource.org/licenses/bsd-license.php
>
>
> Trying to load: from: disk ...
> E3405: No such device
> Trying to load: from: /vdevice/v-scsi@71000002/disk@8200000000000000
> ... No medium !
>
> E3405: No such device
> Trying to load: from: /pci@800000020000000/ethernet@0 ...
> Initializing NIC
> Reading MAC address from device: 52:54:00:12:34:56
> Requesting information via DHCP: done
> Using IPv4 address: 10.0.2.15
> Requesting file "" via TFTP from 10.0.2.2
> Receiving data: 0 KBytes
> E3010 (net) TFTP access violation
>
> E3407: Load failed
>
> Type 'boot' and press return to continue booting the system.
> Type 'reset-all' and press return to reboot the system.
>
>
> Ready!
> 0 >
>
>
>
> On 01/23/2018 10:34 AM, joserz@linux.vnet.ibm.com wrote:
>> On Tue, Jan 23, 2018 at 01:05:28AM -0200, joserz@linux.vnet.ibm.com
>> wrote:
>>> Hello people!
>>>
>>> I'm not able to boot any guest that sets a virtio block device like:
>>> (branch master)
>>>
>>> [PPC64]
>>> qemu-system-ppc64 -cpu POWER8 -nographic -vga none -m 4G -M
>>> pseries,accel=kvm,kvm-type=PR -drive file=disk.qcow2,if=virtio
>> my bad, actually the command line is:
>>
>> qemu-system-ppc64 -cpu POWER8 -nographic -vga none -m 4G -M
>> pseries,accel=kvm -netdev type=user,id=net0 -device
>> virtio-net-pci,netdev=net0 -drive file=../disk.qcow2,if=virtio
>>
>> and the problem seem to be in virtio-net-pci, not in the block device
>>
>>
>>> QEMU Starting
>>> Build Date = Dec 18 2017 13:08:00
>>> FW Version = git-fa981320a1e0968d
>>> Press "s" to enter Open Firmware.
>>>
>>> Populating /vdevice methods
>>> Populating /vdevice/vty@71000000
>>> Populating /vdevice/nvram@71000001
>>> Populating /vdevice/v-scsi@71000002
>>> SCSI: Looking for devices
>>> 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+"
>>> Populating /pci@800000020000000
>>> 00 0000 (D) : 1af4 1000 virtio [ net ]
>>> Aborted
>>>
>>> [x86]
>>>
>>> qemu-system-x86_64 -m 4G -enable-kvm -drive file=util.qcow2,if=virtio
>>> Running QEMU with GTK 2.x is deprecated, and will be removed
>>> in a future release. Please switch to GTK 3.x instead
>>> [1] 5282 abort
>>>
>>> [Cause]
>>>
>>> The commit 4fe6d78b2e introduces the
>>>
>>> ...
>>> kvm_mem_ioeventfd_del(...) {
>>> ...
>>> r = kvm_set_ioeventfd_mmio(fd, ...
>>> if (r < 0) {
>>> abort();
>>> }
>>>
>>> + if (e->cleanup) {
>>> + e->cleanup(e);
>>> + }
>>> }
>>>
>>> For some reason, not yet clear to me, cleanup() calls the same
>>> kvm_mem_ioeventfd_del again and again until kvm_set_ioeventfd_mmio
>>> returns < 0 and abort().
>>>
>>> I was going to send a patch to revert that 'if ()' but I think it could
>>> cause a regression. What do you guys think?
>>>
>>> Thanks,
>>>
>>> Jose Ricardo Ziviani
>>>
>>>
>>
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-01-23 13:02 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-01-23 3:05 [Qemu-devel] virtio block device is not working joserz
2018-01-23 12:34 ` joserz
2018-01-23 12:47 ` Daniel Henrique Barboza
2018-01-23 13:02 ` Daniel Henrique Barboza
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).