Re: [PATCH 1/1] QEMU: support USB cdrom devices
Am 07.09.20 um 08:04 schrieb Gerd Hoffmann:
> USB disks. The main problem is, that -blockdev mechanism relies
> on the device type to handle the media type, like ide-cd and
> ide-hd. But there is just usb-storage.
You can use -device usb-bot + -device scsi-cd ...
So I tried
-blockdev
'{"driver":"file","filename":"/tmp/win10_arm64_wim_18363.959_en-us.iso","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-1-format","read-only":true,"driver":"raw","file":"libvirt-1-storage"}'
\
-blockdev
'{"driver":"file","filename":"/var/lib/libvirt/images/virtio-win-0.1.189.iso","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-2-format","read-only":true,"driver":"raw","file":"libvirt-2-storage"}'
\
with
-device nec-usb-xhci,id=xhci \
-device usb-bot,id=scsi0,bus=xhci.0 \
-device
scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=libvirt-1-format,id=scsi0-0-0-0,bootindex=1
\
-device
scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=libvirt-1-format,id=scsi0-0-0-1
\
which starts, but gives me a "Synchronous Exception" from the TianoCore
firmware, which I often saw with PCI enumeration problems.
Also "info usb" just shows a single device. I just copied these lines
from a normal libvirt SCSI setup with two cdroms.
Switching to
-device nec-usb-xhci,id=xhci \
-device usb-bot,id=scsi0,bus=xhci.0 \
-device
scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=libvirt-1-format,id=scsi0-0-0-0,bootindex=1
\
-device usb-bot,id=scsi1,bus=xhci.0 \
-device
scsi-cd,bus=scsi1.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi1-0-0-0,drive=libvirt-2-format,id=scsi1-0-0-0
\
boots here. Don't know if this is a error in my edk2 2020.05-2 Debian
package or my QEMU 5.1 build.
But compared to my small patch with the usb-storage based USB CDROM,
this looks like a much larger change and a lot of work implement.
Current configuration is:
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/virtio-win-0.1.189.iso'/>
<target dev='sdb' bus='usb' removable='off'/>
<readonly/>
<address type='usb' bus='0' port='2'/>
</disk>
<controller type='usb' index='0' model='nec-xhci'>
<address type='pci' domain='0x0000' bus='0x02'
slot='0x00'
function='0x0'/>
</controller>
Now you would have to insert an usb-bot SCSI controller. I guess it
could be done by either
1. doing this transparently with a controller per device, just like the
usb-storage controller does internally (ok - it's just a scsi-cd there),
even if the usb-bot supports multiple LUNs. Guess multiple LUNs would
act like an USB hub?
or
2. invalidating the cdrom with USB addresses configurations and exposing
the controller in the XML. This seems easier from the libvirt code POV,
like:
<controller type='scsi' model='usb-bot'>
<address type='usb' port='1'/>
</controller>
But that isn't easy or obvious to setup.
So I still would like to see my much simpler solution merged. Maybe I'm
missing something, and the implementation of this special case is easier
then my "quick" look at the code suggested, but for me it looks like at
least a week of work, notwithstanding the other problems with the
installer timeouts in QEMU (where I just saw that
https://bugs.launchpad.net/qemu/+bug/1717708 is now closed as invaid...).
Jan-Marek