This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Ideas for PV on SeaBIOS
From: Keir Fraser <keir@xxxxxxx>
Date: Thu, 19 May 2011 16:02:01 +0100
Cc: Daniel Castro <evil.dani@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "seabios@xxxxxxxxxxx" <seabios@xxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Thu, 19 May 2011 08:03:23 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:user-agent:date:subject:from:to:cc :message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=3H721aBfFASTvP4MTfux/p6W75S8mUvLtJSWuAsqVtc=; b=WeOQxroPYnN2bBdBGSfvtl8Oc5JPYZ4zNh5ODj7mOhAIWf+IjH6YCaWD1GPRc3y+Mv q8aLptz4MjANHH0gv1yBpR1w7rIaXNkOd6LNIKtLEM7F5Zv9g4gZfNq5mXN1FJK6f6xS 8mqDVXDXavmUhUgTwinz0WO94bwrnZ/wn4tok=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=UozlKuwKp5WGoI1OnucTFaoDo1jHzItDPWO+WnGyDOcmpI7fj5zhl0NELw1sGv0OZ9 e1IkoljzJpG9VnNSF0MKhr05cdEI+NIEUgltlE9MWDmLIzaEggghmvXPyY1a+dw5qkrE aSWpWcPssYhjp4CJJ5AAiudD35M45tOmtsPNY=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1305797813.20907.175.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwWNbTXC5ou1mbjhUKoBDtSbEMjgg==
Thread-topic: [Xen-devel] Ideas for PV on SeaBIOS
User-agent: Microsoft-Entourage/
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