Re: [Xen-devel] missing unplug of SCSI devices in HVM guest

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: dunlapg@xxxxxxxxx [mailto:dunlapg@xxxxxxxxx] On Behalf Of
> George Dunlap
> Sent: 06 September 2016 17:42
> To: Olaf Hering <olaf@xxxxxxxxx>; Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] missing unplug of SCSI devices in HVM guest
> 
> On Wed, Aug 24, 2016 at 10:24 AM, Olaf Hering <olaf@xxxxxxxxx> wrote:
> > Does anyone remember why the the vbd frontend drivers also claim the
> > SCSI disks, but the vbd backend in qemu has no unplug support for SCSI?
> >
> > The current situation for qemu-xen and qemu-xen-traditional is that
> > both will create an emulated LSI controller with disk=[vdev=sda]. The
> > xenlinux and pvops frontend drivers will claim the disk, but the
> > sym53c8xx will see and claim it as well. As a result each disk is
> > visible twice. One has to blacklist the sym53c8xx driver to avoid that.
> >
> > What should be done to fix this?
> > #1 new unplug protocol for SCSI, but old guests dont know about it
> > #2 reuse IDE flag to also unplug SCSI. This would cover pvops and guests
> >    where xenlinux based xen-platform-pci.ko is loaded before
> >    sym53c8xx.ko. It would break guests with frontend drivers that do not
> >    claim SCSI disks, the SCSI disk would disappear (if such frontends
> >    really exist).
> > #3 do not provide SCSI if guest has PV drivers
> 
> I think #3 was has been done in practice, but obviously not enforced by the
> toolstack -- i.e., "Doctor, it hurts when I do this <makes
> motion>."  "Then don't do that."
> 
> The problem with enforcing #3 is that there's no real way for the toolstack to
> know if the guest will have PV drivers before booting.
> 
> There's also #4: Do not provide a PV backend for SCSI disks.  Not sure that's
> actually possible, as libxl has historically used the PV backend as the 
> canonical
> place for listing disks associated with a domain (although that may have
> changed since XSA-whatever which resulted in libxl having its own local copy
> of the backend information).
> 
> Paul, do you have any thoughts?
> 

I agree that #3 is not practical.

I would have thought option #1 is the most logical and desirable in the long 
run, but #2 could perhaps be used (by means of a configuration option to qemu) 
in the meantime. In practice I doubt there is anything out there that would use 
emulated SCSI as well as PV storage.

  Paul

>  -George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel