[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] hvc_xen: introduce HVC_XEN_FRONTEND
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. 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. 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? 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? _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |