Re: [Xen-devel] [PATCH] hvc_xen: introduce HVC_XEN_FRONTEND

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Mon, Mar 05, 2012 at 10:45:33PM +0000, Stefano Stabellini wrote:
> On Sun, 4 Mar 2012, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 21, 2012 at 11:30:42AM +0000, Stefano Stabellini wrote:
> > > Introduce a new config option HVC_XEN_FRONTEND to enable/disable the
> > > xenbus based pv console frontend.
> > 
> > One concern I have - not with this patch - but rather with the whole
> > PV consoel functionality - is how it is going to work with older 
> > hypervisors/QEMU.
> > 
> > I am specifically thinking about Amazon EC2 or 3.4 Xen installations.
> > I recall that a patch was required to QEMU to make this work flawlessly - so
> > perhaps all of this code should be gated on checking fora version (so Xen 
> > 4.2?)
> > or by looking for a 'feature-pv-on-hvm-console' XenBus attribute?
> 
> I agree that this issue needs more thoughts about compatibility with old
> xen installations, but if it is possible I would rather avoid
> introducing a this-bug-is-now-fixed kind of flag.

Think of it as working around broken implementations. Like dealing with BIOSes
that aren't exactly working right.

> 
> Only xen installations supporting vfb and qemu as a console backend are
> susceptible, so Amazon should be safe because I don't think they use any
> of them.

I think they use the normal xenconsole .. but then the patch to return 0
would work .. but upset future version of QEMU (or is it the other way
around).

> Also looking through the code I have found that qemu-xen 3.4, 4.0 and
> 4.1 are all susceptible to this bug the same way and they can all be
> fixed with the same patch.
> 
> >From the Linux side the best thing we could do is completely ignore
> devices/console/0, the problem is that if we don't we are either going
> to upset QEMU or xenconsoled.
> If we return 0 from xencons_probe we are going to pretend everything is
> normal so as a consequence the xenbus state is going to be set to 4,
> upsetting xenconsoled.
> If we return -ENODEV we are going to admit that the device shouldn't
> even be there and in that case the xenbus drivers set the state to 6
> causing the unpatched qemu to crash.
> I don't think there is anything we can do within xencons_probe to avoid
> the bug: what return value are we supposed to return so that the
> xenbus drivers does not take any further actions?

Right. So I was thinking that finding out what hypervisor is present - 
if 4.2, then it is OK to assume QEMU has it fixed.

> Even a 'feature-pv-on-hvm-console' flag  wouldn't help.
> 
> Maybe we need to introduce an explicit check in xenbus_probe_device_type
> to avoid calling bus->probe if type == "console" and dir[i] == "0", what
> do you think?

If that works..?

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel