On 19/05/2011 10:36, "Ian Campbell" Ian.Campbell@citrix.com wrote:
On Thu, 2011-05-19 at 09:20 +0100, Tim Deegan wrote:
As for how you tidy up cleanly, I can't think of anything better than a sort of virtual SMM, where you register an area of code to be run in a known sane environment and have Xen trigger it based on, e.g. the disable-my-devices ioport write. It's pretty ugly but at least it'd be fairly self-contained compared to having Xen or qemu try to tear down grant-table entries &c.
Tim and I just had a bit of a think about whether or not this could be done from AML }:-). (Lets ignore the fact that require ACPI support in the guest for this functionality would be a bit lame...)
Turns out it cannot (phew!) without adding some very hacky way to make hypercalls (e.g. via an I/O write), hypercalls are needed to kick the xenstore evtchn and also to close any other evtchns. The rest, such as clearing down grant entries and zeroing the xenstore ring could be done from AML, we reckon.
Yuk, no. The SMM type thing (maybe not really emulated SMM, but kidn of inspired by the principle of SMM) is the best idea I have so far. That was the kind of thing in my mind when I replied yesterday.
-- Keir
FWIW the set of things which needs to be done seems to be:
* xenbus writes to move devices to state 5 (provoking backend reset), notify xenbus evtchn, wait for responses to complete (or otherwise interlock against the xenstore ring reset below). * make hypercalls to close event channels * clear grant table entries * reset the xenstore ring ready for use by next OS.So it looks like some sort of SMM alike thing is going to be the best answer here, although "real virtual" SMM looks like a complete snake/tar pit. A simpler callback with flat segments seems plausibly doable.
As an aside we will also need to handle the case where the guest is not PV aware and hence uses the emulated devices and never triggers any of the above activities. So we need to ensure that the backends are sync'd even if none of the above takes place. The PV devices will remain open but that needn't be a problem if the guest never uses them.
Possibly this means making sure all writes via this PV interface go straight to disk (using the appropriate barriers) or by having qemu do the necessary flush when the emulated device is first used.
Ian.
Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel