Re: [xen-devel][PATCH] PV driver compatibility

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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