Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory events. Do not lose guest events

["Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>]

> On Tue, Nov 29, Andres Lagar-Cavilla wrote:
>
>>  xen/arch/x86/hvm/hvm.c          |   20 ++-
>>  xen/arch/x86/mm/mem_event.c     |  205
>> ++++++++++++++++++++++++++++++---------
>>  xen/arch/x86/mm/mem_sharing.c   |   27 +++-
>>  xen/arch/x86/mm/p2m.c           |  104 ++++++++++---------
>>  xen/common/memory.c             |    7 +-
>>  xen/include/asm-x86/mem_event.h |   16 ++-
>>  xen/include/asm-x86/p2m.h       |    6 +-
>>  xen/include/xen/mm.h            |    2 +
>>  xen/include/xen/sched.h         |    5 +-
>>  9 files changed, 268 insertions(+), 124 deletions(-)
>>
>>
>> The memevent code currently has a mechanism for reserving space in the
>> ring
>> before putting an event, but each caller must individually ensure that
>> the
>> vCPUs are correctly paused if no space is available.
>
> I have an improved patch which uses wait queues in
> mem_event_put_request() and also the new wake_up_nr(). Using pause here
> and wait queues in get_gfn does not mix well AFAICS. My wait queue patch
> for get_gfn is not yet finished.
>
> I propose to use wait queues for both mem_event and get_gfn.

Well, given the patch I submitted, my position ought to be clear :)

I have four cents to add:
- Our patch works. We're blasting the ring with multi-vcpu events. Nothing
is ever lost, no vcpu is left blocked and forgotten.

- This isn't a problem that necessitates wait-queues for solving. Just
careful logic.

- I am not sure what your concerns about the mix are. get_gfn* would call
populate on a paged out gfn, and then go to sleep if it's a guest vcpu.
With our patch, the guest vcpu event is guaranteed to go in the ring. vcpu
pausing will stack (and unwind) properly.

- This patch does not preclude wait queues where they are absolutely
needed. I think once wait queues are in, they'll be a welcome breakthrough
for hypervisor code that just can't handle paged out pages gracefully. I
look forward to that.

Andres

>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel