All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Alex Bligh <alex@alex.org.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: 2.6.37 PV on HVM and emul_unplug=unnecessary
Date: Wed, 12 Jan 2011 14:04:57 +0100	[thread overview]
Message-ID: <4D2DA6F9.6090100@redhat.com> (raw)
In-Reply-To: <179F0F4F586F923A4B074564@nimrod.local>

On 01/12/2011 12:45 PM, Alex Bligh wrote:
> 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.

On Windows it is possible to add a "filter driver" above the PCI and IDE 
buses and hide the emulated devices this way.  It doesn't leave a dummy 
disk, but it does leave a dummy device in the PCI tree.  It's a kind of 
kernel-level blacklist.  Also, it couldn't be an external module if 
sd_mod is built in, which makes it much less interesting.

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

Something similar was done in the 2.6.18 "XenoLinux" kernels, but it's 
ugly and it touches into areas of the kernell that Xen support shouldn't 
affect.

If your "Xen Dom0 prior to 3.4.something" is RHEL/CentOS, the 5.6 
version will include a backport of PCI unplug support.  Then you only 
need to bug your cloud provider. :)

Paolo

  reply	other threads:[~2011-01-12 13:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-12 11:45 2.6.37 PV on HVM and emul_unplug=unnecessary Alex Bligh
2011-01-12 13:04 ` Paolo Bonzini [this message]
2011-01-12 13:25   ` Alex Bligh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D2DA6F9.6090100@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=alex@alex.org.uk \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.