[PATCH 1/1] QEMU: support USB cdrom devices

[Daniel P. Berrangé]

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