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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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?

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? 

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?

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.

I'd suggest that this issue should be fixed by backporting the backend
support for the safe unplug protocol -- I don't think the patch for such
minimal support is that big or risky. Failing that perhaps it could at
least be something you need to explicitly ask for if you have somehow
verified that there is no danger of the emulated and PV backends
trampling each other, e.g. via a frontend module parameter.

Ian.


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