From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Ideas for PV on SeaBIOS Date: Thu, 19 May 2011 16:02:01 +0100 Message-ID: References: <1305797813.20907.175.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1305797813.20907.175.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell , Tim Deegan Cc: Daniel Castro , "xen-devel@lists.xensource.com" , "seabios@seabios.org" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 19/05/2011 10:36, "Ian Campbell" 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