On Thu, 2010-01-21 at 23:04 +0000, Ky Srinivasan wrote:
>
> >>> On 1/21/2010 at 3:38 PM, in message
> < 1264106300.21707.57.camel@xxxxxxxxxxxxxxxxxxxxx >, Ian Campbell
> < Ian.Campbell@xxxxxxxxxx > wrote:
> > On Wed, 2010-01-20 at 16:07 +0000, Keir Fraser wrote:
> >> On 20/01/2010 16:02, "Ky Srinivasan" < ksrinivasan@xxxxxxxxxx > wrote:
> >>
> >> > The attached patch fixes what I believe is a typo and permits guests
> > running
> >> > the latest PV drivers to correctly interact with older back-ends.
> >> >
> >> > Signed-off-by: K. Y. Srinivasan < ksrinivasan@xxxxxxxxxx >
> >>
> >> Ian,
> >>
> >> You introduced the magic port value check, in xen-unstable:19964.
> >
> > I'm guilty of pretty poor changelogging there, aren't I, I've no idea
> > how the unmodified drivers part of the change relates to the comment :-(
> >
> >> Can you ack/nack this please?
> >
> > What vintage of older back-ends are we talking about?
> We shipped sles11 on xen-3.3.1 and this is where we encountered the
> problem - hosting a sles11 sp1 (based on xen-4.0.0) guest on a sles11
> host.
OK, so not ancient.
> >
> > What is their behaviour when reading from that port? Can we test for a
> > specific value instead of anything != MAGIC or is there some other way
> > to identify them?
>
> Looking at your documentation for this new protocol, I recall seeing
> that if the magic value was not read, it was ok to silently return to
> be compatible.
Which docs? i386-dm/README.hvm-pv-magic-ioport-disable in the qemu-xen
tree says:
1) When the drivers first come up, they check whether the unplug logic
is available by reading a two-byte magic number from IO port 0x10.
These should be 0x49d2. If the magic number doesn't match, the
drivers don't do anything.
I take that to mean the drivers should not load if the magic value
doesn't match.
> > Without some sort of unplugging mechanism we run the risk of having both
> > PV and Emulated disk controllers active, accessing the same virtual disk
> > and with drivers loaded in the guest, which is potentially very
> > dangerous for the user's data. Did those older backends implement some
> > alternative unplugging mechanism we should be trying?
> We have had a mechanism for disabling the emulation when the PV
> drivers are loaded for some time now.
What is the mechanism? Why doesn't your patch add support for that
mechanism instead of just nobbling the current one?
> > The whole point of this magic check is to ensure we are running on a
> > backend which is new enough to do the unplugging in a safe way, so I
> > think failing to switch to PV and sticking with emulated on such
> > platforms the safe approach.
>
> This breaks the compatibility with systems that have already been
> shipped in the sense we cannot run the guests with PV drivers. The
> proposed patch fixes the problem.
The guest still work though, right? Just with emulated drivers.
If you add a module option override instead of just skipping the safety
latch which the current mechanism implements then this patch would be OK
and it would be a simple guest tweak to switch PV drivers back on if you
have arranged out-of-band for the emulated devices to be unplugged.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home