xen-mapcache: don't unmap locked entry during mapcache invalidation
PATCH 1/1 xen-mapcache: don't unmap locked entry during mapcache invalidation
When an IOREQ_TYPE_INVALIDATE is sent to QEMU, it invalidates all entry of the map cache even if it's locked.
QEMU is not able to know that entry was invalidated, so when an IO access is requested a segfault occured.
--- xen-mapcache.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
xen-mapcache.c +3 -1
@@ -370,6 +370,9 @@ void xen_invalidate_map_cache(void)continue ; } +if (entry->lock >0 ) +continue ; +if (munmap (entry->vaddr_base, entry->size) !=0 ) {perror ("unmap fails" );exit (-1 ); --
Julien Grall
Quoted 5 lines · Julien Grall
When an
IOREQ_TYPE_INVALIDATEis sent to QEMU, it invalidates all entry of the map cache even if it's locked.QEMU is not able to know that entry was invalidated, so when an IO access is requested a segfault occured.
The problem here is the long term mappings in QEMU that cannot easily be re-created.
I am not sure whether this can cause any trouble to things like xenpaging.
Quoted 10 lines
Signed-off-by Julien Grall <[email protected]>--- xen-mapcache.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)xen-mapcache.c +0
-0
xen-mapcache.c void xen_invalidate_map_cache(void) · line 377
Quoted 8 lines
xen-mapcache.c +3
-0@@ -370,6 +370,9 @@ void xen_invalidate_map_cache(void)continue ; } +if (entry->lock >0 ) +continue ; +if (munmap (entry->vaddr_base, entry->size) !=0 ) {perror ("unmap fails" );exit (-1 );
CODING_STYLE
Quoted 11 lines · Julien Grall
Quoted 5 lines
When an
IOREQ_TYPE_INVALIDATEis sent to QEMU, it invalidates all entry of the map cache even if it's locked.QEMU is not able to know that entry was invalidated, so when an IO access is requested a segfault occured.
The problem here is the long term mappings in QEMU that cannot easily be re-created.
I am not sure whether this can cause any trouble to things like xenpaging.
This is a performance optimization for xenpaging: it cannot page out pages that are mapped by qemu, so it asks qemu to drop the mappings. If denied (partially or fully) xenpaging won't crash, and the VM won't crash. xenpaging will just have to keep trying to find other candidates for paging out.
Andres
Quoted 23 lines
Quoted 12 lines
Signed-off-by Julien Grall <[email protected]>--- xen-mapcache.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)xen-mapcache.c +0
-0xen-mapcache.c void xen_invalidate_map_cache(void) · line 377
Quoted 8 lines
xen-mapcache.c +3
-0@@ -370,6 +370,9 @@ void xen_invalidate_map_cache(void)continue ; } +if (entry->lock >0 ) +continue ; +if (munmap (entry->vaddr_base, entry->size) !=0 ) {perror ("unmap fails" );exit (-1 );
CODING_STYLE
Quoted 11 lines · Stefano Stabellini
Quoted 5 lines · Julien Grall
When an
IOREQ_TYPE_INVALIDATEis sent to QEMU, it invalidates all entry of the map cache even if it's locked.QEMU is not able to know that entry was invalidated, so when an IO access is requested a segfault occured.
The problem here is the long term mappings in QEMU that cannot easily be re-created.
I am not sure whether this can cause any trouble to things like xenpaging.
Yes, I was wondering about this as well. If the request is made, then its expected that all mappings disappear because they can point to ballooned gfns. IF that case is safe, then all is fine.
In case of xenpaging its not an issue because xenpaging just asks qemu to release mappings so that the usage count of mfns drops to 1, so that they can be nominated for eviction. If that fails, not a big deal as it just means that no more pages can be evicted. xenpaging will retry.
Olaf
Quoted 9 lines · Olaf Hering
Quoted 7 lines · Stefano Stabellini
Quoted 5 lines · Julien Grall
When an
IOREQ_TYPE_INVALIDATEis sent to QEMU, it invalidates all entry of the map cache even if it's locked.QEMU is not able to know that entry was invalidated, so when an IO access is requested a segfault occured.
Quoted 8 lines
Quoted 4 lines
The problem here is the long term mappings in QEMU that cannot easily be re-created.
I am not sure whether this can cause any trouble to things like xenpaging.Yes, I was wondering about this as well. If the request is made, then its expected that all mappings disappear because they can point to ballooned gfns. IF that case is safe, then all is fine.
The long lived mappings shouldn't involve any ballooned gfns, unless something went terribly wrong.
Quoted 4 lines
In case of xenpaging its not an issue because xenpaging just asks qemu to release mappings so that the usage count of mfns drops to 1, so that they can be nominated for eviction. If that fails, not a big deal as it just means that no more pages can be evicted. xenpaging will retry.
Great, sounds like there is no problem then.
Quoted 11 lines · Stefano Stabellini
Quoted 5 lines · Julien Grall
When an
IOREQ_TYPE_INVALIDATEis sent to QEMU, it invalidates all entry of the map cache even if it's locked.QEMU is not able to know that entry was invalidated, so when an IO access is requested a segfault occured.
The problem here is the long term mappings in QEMU that cannot easily be re-created.
I am not sure whether this can cause any trouble to things like xenpaging.
It causes some trouble to ballooning - a guest might try to return memory to Xen only to find that Qemu won't let go of it.
If (as I hope is the case) qemu never has a locked mapping to something that the guets ought to be ballooning, that's OK. If this happens just because the page was recently a DMA target, then it's not.
Cheers,
Tim.
Quoted 9 lines
Quoted 8 lines · Stefano Stabellini
Quoted 1 line · Julien Grall
When an
IOREQ_TYPE_INVALIDATEis sent to QEMU, it invalidates allentry
Quoted 4 lines
of the map cache even if it's locked.
QEMU is not able to know that entry was invalidated, so when an IO access is requested a segfault occured.
Quoted 7 lines
Quoted 4 lines
The problem here is the long term mappings in QEMU that cannot easily be re-created.
I am not sure whether this can cause any trouble to things like xenpaging.It causes some trouble to ballooning - a guest might try to return memory to Xen only to find that Qemu won't let go of it.
That's the right causation (as opposed to invalidate cache being called after balloon).
All that will happen is that the balloon request will be (partially) failed. Up to the guest balloon driver to deal with it gracefully (and to not choose weird pages to balloon away in the first place!).
Andres
Quoted 9 lines
If (as I hope is the case) qemu never has a locked mapping to something that the guets ought to be ballooning, that's OK. If this happens just because the page was recently a DMA target, then it's not.
Cheers,
Tim.
Quoted 17 lines · Andres Lagar-Cavilla
Quoted 9 lines
Quoted 8 lines · Stefano Stabellini
Quoted 1 line · Julien Grall
When an
IOREQ_TYPE_INVALIDATEis sent to QEMU, it invalidates allentry
Quoted 4 lines
of the map cache even if it's locked.
QEMU is not able to know that entry was invalidated, so when an IO access is requested a segfault occured.
Quoted 7 lines
Quoted 4 lines
The problem here is the long term mappings in QEMU that cannot easily be re-created.
I am not sure whether this can cause any trouble to things like xenpaging.It causes some trouble to ballooning - a guest might try to return memory to Xen only to find that Qemu won't let go of it.
Quoted 6 lines
That's the right causation (as opposed to invalidate cache being called after balloon).
All that will happen is that the balloon request will be (partially) failed. Up to the guest balloon driver to deal with it gracefully (and to not choose weird pages to balloon away in the first place!).
No - the balloon call will succeed, and the page will be removed from the p2m and its ref dropped. But the guest's memory usage won't drop until qemu lets go of its mapping.
If qemu is liable to do this to a lot of memory, that's definitely a problem. But I suspect that in fact it won't do that.
Tim.
Quoted 13 lines · Tim Deegan
Quoted 11 lines · Stefano Stabellini
Quoted 5 lines · Julien Grall
When an
IOREQ_TYPE_INVALIDATEis sent to QEMU, it invalidates all entry of the map cache even if it's locked.QEMU is not able to know that entry was invalidated, so when an IO access is requested a segfault occured.
The problem here is the long term mappings in QEMU that cannot easily be re-created.
I am not sure whether this can cause any trouble to things like xenpaging.
Quoted 5 lines
It causes some trouble to ballooning - a guest might try to return memory to Xen only to find that Qemu won't let go of it.
If (as I hope is the case) qemu never has a locked mapping to something that the guets ought to be ballooning, that's OK.
That should be the case.
Quoted 2 lines
If this happens just
because the page was recently a DMA target, then it's not.
Only if the DMA is still in progress, in that case it is a bad idea to balloon out that page.