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

[Gerd Hoffmann]

  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