On Mon, Sep 07, 2020 at 01:45:09PM +0200, Gerd Hoffmann wrote:
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.
Switching back to -drive is out of the question. We've worked very hard to eliminate its usage and get to an exclusively -blockdev based solution because supporting both approaches in parallel complicates too much. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|