[SeaBIOS] [Xen-devel] Ideas for PV on SeaBIOS

[Ian Campbell]

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.

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.