On Fri, 2015-10-16 at 10:06 +0100, Stefano Stabellini wrote: > > What's the reason for the "stumbling block" that requires the BIOS to > > tear down the Xen ring prior to the OS being able to replace it? The > > BIOS disk calls are all synchronous, so the ring wont be active when > > the OS brings up its own ring. Is there some low-level interaction > > that prevents the OS from just resetting the ring prior to enabling > > it? > > Xen only exports one PV disk interface for each disk to the guest, and > each PV interface only supports one frontend -- only SeaBIOS or the OS > can be connected to one PV disk, not both.
Which I think is just another way of saying that the Xen PV protocol currently lacks an explicit requirement for the OS to reset the device (or indeed the general PV infrastructure, grant tables etc) before use. Retrofitting that requirement is of course a little tricky. The unplug protocol might be extensible neough though. IIRC it does include provisions for the OS to specify a version and the reject the unplug, so upreving that to include a reset requirement _might_ be possible. At which point it can at least be made a config option which can be switch on for new enough guests. i.e. if the guest is configured to use PV drivers from SeaBIOS the unplug protocol would reject the attempt to unplug the (non-existent) IDE devices and the guest therefore should fail to bind to the PV devices, while a newer guest which knows it has to do a reset would declare itself to be newer and succeed in the unplug. (NB: details of the protocol are sketchy in my memory, and the above may need actual though applied to make it practical, but you get the gist I hope). Then you are just into some sort of multiyear transition/deprecation sequence before you make it the default. > In the case of OVMF, we > handle that by disconnecting the PV frontend in OVMF when > ExitBootServices is called, so that the OS driver can reconnect later.
