Re: [Xen-devel] [PATCH 4 of 5] Re-order calls to put_gfn() around wait queu invocations

[Tim Deegan <tim@xxxxxxx>]

At 14:56 -0500 on 01 Feb (1328108168), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/emulate.c       |   2 +-
>  xen/arch/x86/hvm/hvm.c           |  25 +++++++++++++------
>  xen/arch/x86/mm.c                |  10 +++---
>  xen/arch/x86/mm/guest_walk.c     |   2 +-
>  xen/arch/x86/mm/hap/guest_walk.c |   6 +---
>  xen/arch/x86/mm/mem_access.c     |  10 +++++++
>  xen/arch/x86/mm/mem_event.c      |   5 +++
>  xen/arch/x86/mm/p2m.c            |  52 
> ++++++++++++++++++++++-----------------
>  xen/common/grant_table.c         |   2 +-
>  xen/common/memory.c              |   2 +-
>  xen/include/asm-x86/mem_access.h |   1 +
>  xen/include/asm-x86/mem_event.h  |   3 ++
>  xen/include/asm-x86/p2m.h        |   6 +++-
>  13 files changed, 80 insertions(+), 46 deletions(-)
> 
> 
> Since we use wait queues to handle potential ring congestion cases,
> code paths that try to generate a mem event while holding a gfn lock
> would go to sleep in non-preemptible mode.
> 
> Most such code paths can be fixed by simply postponing event generation until
> locks are released.
> 
> Signed-off-by: Adin Scannell <adin@xxxxxxxxxxx>
> Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>

Looks OK, once the preceding patches are sorted out.  If you add some
comments to p2m_mem_access_check() describing its new argument and what
the caller's supposed to do about it, you can put my Ack on this next time.

Cheers,

Tim.

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