| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Ideas for PV on SeaBIOS
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
|
|
|
| |
|
Home