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

[Keir Fraser <keir@xxxxxxx>]

On 19/05/2011 10:36, "Ian Campbell" <Ian.Campbell@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel