[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.