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
