| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [RFC] implement "trap-process-return"-like behavior with
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.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home