This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] 2.6.37 PV on HVM and emul_unplug=unnecessary

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] 2.6.37 PV on HVM and emul_unplug=unnecessary
From: Alex Bligh <alex@xxxxxxxxxxx>
Date: Wed, 12 Jan 2011 11:45:47 +0000
Cc: Alex Bligh <alex@xxxxxxxxxxx>
Delivery-date: Wed, 12 Jan 2011 03:46:33 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Reply-to: Alex Bligh <alex@xxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On modern mainline, when a PV on HVM kernel boots, it will detect the
ability to PCI unplug the PCI SD devices, so to avoid producing
/dev/xvdX and /dev/sdX referring to the same device. On Xen Dom0 prior
to 3.4.something, this fails because PCI unplug is not supported.
The check can be worked around by using emulunplug=unnecessary, but
this is not optimal as
a) you still end up with 2 devices; and
b) it requires modifying the kernel boot line, which is not always
   easy (e.g. if your bootloader is supplied by a third party IAAS
   provider and you wish to use a mainline kernel).

Another approach would be to stop sd_mod loading another way
(e.g. blacklist sd_mod). This does not work well as many kernels have
sd_mod built in.

I am trying to think of a non-intrusive way to prevent sd_mod initialising
if we are doing PV on HVM and PCI unplug is not supported (other than
upgrade Xen). One possibility would be to manually register dummy
block major device with the same major number as used by sd. This would
cause register_blkdev to return EBUSY and the module not to init. However,
it would leave the dummy block device around. Another more intrusive
method would simply be to put a check into sd_mod. Yet more intrusive
would be to modify the entire do_initcalls/module_init subsystem
to provide a generalised method for one bit of code to disable another.

Has someone already looked into this and concluded it's impossible? Or
is this worth a little time?

Alex Bligh

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>