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


[Xen-devel] Re: [RFC] implement "trap-process-return"-like behavior with

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC] implement "trap-process-return"-like behavior with grant ring + evtchn
From: Wei Liu <liuw@xxxxxxxxx>
Date: Thu, 23 Jun 2011 16:01:32 +0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 23 Jun 2011 01:03:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1308814922.6920.192.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>
References: <BANLkTi=eKOzHTTCBNKnyCiUcfkKj246fNw@xxxxxxxxxxxxxx> <1308814922.6920.192.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, Jun 23, 2011 at 3:42 PM, Ian Campbell
<Ian.Campbell@xxxxxxxxxxxxx> wrote:
> You don't need to spin in the frontend (Stefano just suggested this was
> the simplest possible thing to implement) and really you want to get the
> backend to notify you (via the same evtchn) when it has finished
> processing and arrange for the frontend to wait for that return signal
> before reading the response.
> If these CFG space operations are happening in a sleeping context (as
> far as the guest kernel is concerned) then you can simply treat this
> returning evtchn as an IRQ and use one of the kernel's
> queuing/waiting/completion type primitives to sleep until your IRQ
> handler wakes you up.

I would rather not sleep in the transport layer. I'm not sure if it
will get called from some unsleepable context.

> If you cannot sleep in the context these activities are happening in
> then I think you can use the evtchn poll hypercall to block until the
> evtchn is triggered -- this is no worse than the existing blocking
> behaviour while the PCI CFG space accesses are trapped, it's just
> explicit in the code instead of hidden behind a magic I/O instruction
> emulation.

This evtchn poll hypercall seems the right answer to me. I haven't
noticed this hypercall before. I will investigate more. Thank you.


Xen-devel mailing list