Re: [PATCH 1/1] QEMU: support USB cdrom devices
Hi,
-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.
Hmm, firmware bug? Does seabios work?
Also "info usb" just shows a single device. I just copied
these lines
from a normal libvirt SCSI setup with two cdroms.
That is normal, it actually is only one usb device after all ;)
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.
Yes.
As far I know libvirt wants move away from the old syntax and shift to
use -blockdev more, not the other way around.
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?
usb-storage simply doesn't support multiple LUNs, so when going that
route you can completely ignore the multiple LUN case.
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>
Yep, that is the other obvious approach.
So I still would like to see my much simpler solution merged.
See above, but I'm not a libvirt maintainer so that's not for me to
judge. I'm just pointing out that this can be fixed without switching
back to the old -drive syntax.
take care,
Gerd