1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
|
KVM: 0.888
virtual: 0.788
device: 0.787
user-level: 0.779
VMM: 0.773
peripherals: 0.754
vnc: 0.752
hypervisor: 0.730
register: 0.730
TCG: 0.730
files: 0.717
boot: 0.715
ppc: 0.711
architecture: 0.711
arm: 0.700
assembly: 0.694
permissions: 0.691
semantic: 0.688
network: 0.687
graphic: 0.678
risc-v: 0.676
debug: 0.675
mistranslation: 0.674
kernel: 0.666
performance: 0.657
socket: 0.644
x86: 0.635
PID: 0.623
i386: 0.520
aarch64: virtio disks don't show up in guest (neither blk nor scsi)
kernel-3.18.0-0.rc1.git0.1.rwmj5.fc22.aarch64 (3.18 rc1 + some hardware enablement)
qemu from git today
When I create a guest with virtio-scsi disks, they don't show up inside the guest.
Literally after the virtio_mmio.ko and virtio_scsi.ko modules are loaded, there are
no messages about disks, and of course nothing else works.
Really long command line (generated by libvirt):
HOME=/home/rjones USER=rjones LOGNAME=rjones QEMU_AUDIO_DRV=none TMPDIR=/home/rjones/d/libguestfs/tmp /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 -name guestfs-oqv29um3jp03kpjf -S -machine virt,accel=tcg,usb=off -cpu cortex-a57 -m 500 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid a5f1a15d-2bc7-46df-9974-1d1f643b2449 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/rjones/.config/libvirt/qemu/lib/guestfs-oqv29um3jp03kpjf.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-reboot -boot strict=on -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd -append panic=1 console=ttyAMA0 earlyprintk=pl011,0x9000000 ignore_loglevel efi-rtc=noprobe udevtimeout=6000 udev.event-timeout=6000 no_timer_check lpj=500000 acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color -device virtio-scsi-device,id=scsi0 -device virtio-serial-device,id=virtio-serial0 -usb -drive file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/scratch.1,if=none,id=drive-scsi0-0-0-0,format=raw,cache=unsafe -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/overlay2,if=none,id=drive-scsi0-0-1-0,format=qcow2,cache=unsafe -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0 -serial unix:/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/console.sock -chardev socket,id=charchannel0,path=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/guestfsd.sock -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 -msg timestamp=on
There are no kernel messages about the disks, they just are not seen.
Worked with kernel 3.16 so I suspect this could be a kernel bug rather than a
qemu bug, but I've no idea where to report those.
On 21 October 2014 20:07, Richard Jones <email address hidden> wrote:
> Public bug reported:
>
> kernel-3.18.0-0.rc1.git0.1.rwmj5.fc22.aarch64 (3.18 rc1 + some hardware enablement)
> qemu from git today
>
> When I create a guest with virtio-scsi disks, they don't show up inside the guest.
> Literally after the virtio_mmio.ko and virtio_scsi.ko modules are loaded, there are
> no messages about disks, and of course nothing else works.
> There are no kernel messages about the disks, they just are not seen.
>
> Worked with kernel 3.16 so I suspect this could be a kernel bug rather than a
> qemu bug, but I've no idea where to report those.
Yeah, "regressed with this newer kernel" sounds more like a kernel
bug than a QEMU bug to me, especially if all the other virt devices
still work.
-- PMM
I have now also tried virtio-blk and that doesn't work either. Same symptoms: no log messages at all (even with ignore_loglevel), and no disks appear.
> Yeah, "regressed with this newer kernel" sounds more like a kernel
> bug than a QEMU bug to me, especially if all the other virt devices
> still work.
It seems like no virtio drivers work, but it's very hard to tell when your guest has no disks and therefore no operating system. How can I debug this further?
On 21 October 2014 22:15, Richard Jones <email address hidden> wrote:
> I have now also tried virtio-blk and that doesn't work either. Same
> symptoms: no log messages at all (even with ignore_loglevel), and no
> disks appear.
>
>> Yeah, "regressed with this newer kernel" sounds more like a kernel
>> bug than a QEMU bug to me, especially if all the other virt devices
>> still work.
>
> It seems like no virtio drivers work, but it's very hard to tell when
> your guest has no disks and therefore no operating system. How can I
> debug this further?
Oh. I assumed from the fact your commandline had other virtio
devices and you were only complaining about virtio-scsi that it
was a single-backend issue.
Suggestions:
* bisect the kernel to find out when it broke
* add a bunch of debug printks to the kernel to find out why
it's not finding the disks. The logging here is terrible IMHO:
the kernel usually detects a specific problem and then throws
all this info away in favour of just silently deciding there's
no hardware there
thanks
-- PMM
On 21 October 2014 22:33, Peter Maydell <email address hidden> wrote:
> Suggestions:
...you might also try asking on <email address hidden>, which
is where the KVM/ARM kernel devs hang out, to see if somebody
else has seen this.
-- PMM
Finally finished the git bisect (of the guest kernel, not qemu):
421520ba98290a73b35b7644e877a48f18e06004 is the first bad commit
commit 421520ba98290a73b35b7644e877a48f18e06004
Author: Yalin Wang <email address hidden>
Date: Fri Sep 26 03:07:09 2014 +0100
ARM: 8167/1: extend the reserved memory for initrd to be page aligned
This patch extends the start and end address of initrd to be page aligned,
so that we can free all memory including the un-page aligned head or tail
page of initrd, if the start or end address of initrd are not page
aligned, the page can't be freed by free_initrd_mem() function.
Signed-off-by: Yalin Wang <email address hidden>
Acked-by: Catalin Marinas <email address hidden>
Signed-off-by: Russell King <email address hidden>
:040000 040000 23bd54d302533c173a4ae592969dd2868794e9ed f1833b44ee7a389902f6f9d2fb55f4b89ba0de16 M arch
Now might be a good time to mention that Fedora has very recently switched to using 64k pages.
I'll continue this on the mailing list you suggested.
Still happening with latest upstream kernel. It seems to involve using the -initrd option at all, with any cpio file, even a tiny one. More results posted here:
https://lists.cs.columbia.edu/pipermail/kvmarm/2014-December/012557.html
Finally found the problem, patch posted:
https://lists.gnu.org/archive/html/qemu-devel/2014-12/msg00034.html
I was just about to get to testing this stuff, but thanks for working
through it on your own, and apologies I didn't get to it before.
Cc'ing Marc so he's aware of the progress.
-Christoffer
On Mon, Dec 1, 2014 at 3:46 PM, Richard Jones <email address hidden> wrote:
> Finally found the problem, patch posted:
> https://lists.gnu.org/archive/html/qemu-devel/2014-12/msg00034.html
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1383857
>
> Title:
> aarch64: virtio disks don't show up in guest (neither blk nor scsi)
>
> Status in QEMU:
> New
>
> Bug description:
> kernel-3.18.0-0.rc1.git0.1.rwmj5.fc22.aarch64 (3.18 rc1 + some hardware enablement)
> qemu from git today
>
> When I create a guest with virtio-scsi disks, they don't show up inside the guest.
> Literally after the virtio_mmio.ko and virtio_scsi.ko modules are loaded, there are
> no messages about disks, and of course nothing else works.
>
> Really long command line (generated by libvirt):
>
> HOME=/home/rjones USER=rjones LOGNAME=rjones QEMU_AUDIO_DRV=none
> TMPDIR=/home/rjones/d/libguestfs/tmp
> /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 -name guestfs-
> oqv29um3jp03kpjf -S -machine virt,accel=tcg,usb=off -cpu cortex-a57 -m
> 500 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
> a5f1a15d-2bc7-46df-9974-1d1f643b2449 -nographic -no-user-config
> -nodefaults -chardev
> socket,id=charmonitor,path=/home/rjones/.config/libvirt/qemu/lib
> /guestfs-oqv29um3jp03kpjf.monitor,server,nowait -mon
> chardev=charmonitor,id=monitor,mode=control -rtc
> base=utc,driftfix=slew -no-reboot -boot strict=on -kernel
> /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel -initrd
> /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd -append
> panic=1 console=ttyAMA0 earlyprintk=pl011,0x9000000 ignore_loglevel
> efi-rtc=noprobe udevtimeout=6000 udev.event-timeout=6000
> no_timer_check lpj=500000 acpi=off printk.time=1 cgroup_disable=memory
> root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color -device
> virtio-scsi-device,id=scsi0 -device virtio-serial-device,id=virtio-
> serial0 -usb -drive
> file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/scratch.1,if=none,id
> =drive-scsi0-0-0-0,format=raw,cache=unsafe -device scsi-
> hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-
> scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive
> file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/overlay2,if=none,id
> =drive-scsi0-0-1-0,format=qcow2,cache=unsafe -device scsi-
> hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-
> scsi0-0-1-0,id=scsi0-0-1-0 -serial
> unix:/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/console.sock
> -chardev
> socket,id=charchannel0,path=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/guestfsd.sock
> -device virtserialport,bus=virtio-
> serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0
> -msg timestamp=on
>
> There are no kernel messages about the disks, they just are not seen.
>
> Worked with kernel 3.16 so I suspect this could be a kernel bug rather than a
> qemu bug, but I've no idea where to report those.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1383857/+subscriptions
Richard -- I assume we fixed this one way or another, right?
Oh yes, long fixed.
|