Re: [Xen-devel] [PATCH qemu-xen-traditional 1/2] xen_platform: unplug also SCSI disks [and 1 more messages]

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Olaf Hering writes ("[PATCH qemu-xen-traditional 1/2] xen_platform: unplug also 
SCSI disks"):
> From: Olaf Hering <ohering@xxxxxxx>
> 
> Using 'vdev=sd[a-o]' will create an emulated LSI controller, which can
> be used by the emulated BIOS to boot from disk. If the HVM domU has also
> PV driver the disk may appear twice in the guest. To avoid this an
> unplug of the emulated hardware is needed, similar to what is done for
> IDE and NIC drivers already.

qemu-xen-traditional is in the deep freeze.  I'm only fixes for quite
serious problems (such as security problems).

> Impact of the change for classic and pvops based guest kernels:

While I think this change has a risk of breaking things, and certainly
wouldn't warrant backporting to earlier Xen releases, I think there is
an arguable case for this patch.  At the very least it only affects
users with scsi disks.

That the patch has been in use in SUSE for a long time is also a
helpful datapoint.

I am inclined to accept this patch but would welcome opinions from
others.  Olaf, if no-one replies, please ping me about this again, and
I will apply it.

Olaf Hering writes ("[PATCH qemu-xen-traditional 2/2] xen_platform: SUSE 
xenlinux unplug for emulated PCI"):
> From: Olaf Hering <ohering@xxxxxxx>
> 
> Implement SUSE specific unplug protocol for emulated PCI devices
> in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'.
> This protocol was implemented and used since Xen 3.0.4.
> It is used in all SUSE/SLES/openSUSE releases up to SLES11SP3 and
> openSUSE 12.3.
> In addition old (pre-2011) VMDP versions are handled as well.

On the other hand, I am very reluctant to apply this.

I don't see a good reason for SUSE to have a custom unplug protocol.
Why can't your guests use the standard one ?  Why haven't they been
updated to use the standard one some time in the last ?5-10 years ?

We had a similar question about certain Citrix XenServer behaviours.
I forget the details.  But if I remember that was also a case where a
downstream had invented a private variant of an upstream protocol,
failed to coordinate with upstream, and simply shipped a revised
protocol.  Again there we resisted incorporation of ad-hoc protocols.

Sorry.

Thanks,
Ian.

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