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 :|
