WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] xen_emul_unplug on xen 4.1, HVM guest 2.6.38

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] xen_emul_unplug on xen 4.1, HVM guest 2.6.38
From: Alex Bligh <alex@xxxxxxxxxxx>
Date: Wed, 26 Oct 2011 18:43:20 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Alex Bligh <alex@xxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Wed, 26 Oct 2011 10:44:06 -0700
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
Ian,

I'm a bit fuzzy on the details but I'm not sure what this has to do with
the host, the device naming and behaviour on unplug are kernel side
things, I'd expect that if /dev/sdaX as /boot worked on 3.3 it'll work
on 4.1 too. (I believe you that it doesn't work, I'm just wondering
aloud what I'm missing).

Can you give us the specifics of a setup which fails, e.g. a complete
guest cfg file, the kernel version, command line options, /etc/fstab,
dmesg etc.

I am not avoiding answering your question (I will get you this) but
what is /meant/ to happen in the following scenario:

* Install on recent kernel (e.g. 2.6.37) running on Xen 3.3
* No fancy boot options, xen_emul_unplug not set
* No XEN_IOPORT_MAGIC implemented, so check_platform_magic()
 returns an error
* Therefore xen_platform_pci_unplug=0
* Therefore blkfront etc. don't init (probe returns
 -ENODEV)
* Therefore OS boots with root=/dev/sda

Now Xen 3.3 is upgraded to Xen 4
* Kernel boots, and XEN_IOPORT_MAGIC now exists
* Therefore unplug occurs, and xen_platform_pci_unplug is non zero
* Therefore blkfront etc. inits, and PV drivers start
* OS still boots with root=/dev/sda

Are the PV devices meant to appear as /dev/sdX rather than /dev/xvdX?
If so, how in the code does this happen? If not, won't the boot fail?

Hmm, yes I think the special treatment of XEN_IOPORT_MAGIC mismatch on
the kernel side is what I was missing.

It might make sense to have a guest level config option which disables
these magic ports, i.e. makes them return 0xffff like they would have
done in 3.3 (I think 0xffff is what you'll get from an invalid port in
general).

Actually I don't think this will work. If we do this,
xen_plaftofm_pci_unplug will still be zero (as it's only set on exit
of the function after a successful unplug), and that's enough to
prevent blkfront and xenbus_probe_frontend from doing anything useful,
so will effectively disable PV drivers even where they should be enabled.

Out of interest, with a default guest Ubuntu Natty install CD, using the
default Xen 4.1 settings, we are seeing the guest (a) unplugging the
emulated devices (fine), then (b) failing to find the emulated devices,
and (c) the install failing. Is that to be expected?

Sounds like an Ubuntu bug to me, but I don't follow Ubuntu closely
enough to know if it is known or not.

We will investigate further. Currently we can't seem to get /any/
distro using PV drivers, and only old ones using emulated drivers.

--
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel