Swapping

this patchs allow the guest not shadowed memory to be swapped out.

to make it the must effective you should run -kvm-shadow-memory 1 (witch will make your machine slow)
with -kvm-shadow-memory 1, 3giga memory guest can get to be just 32mb on physical host!

when not using -kvm-shadow-memory, i saw 4100mb machine getting to as low as 168mb on the physical host (not as bad as i thought it would be, and surely not as bad as it can be with 41mb of shadow pages :))

Quoted 11 lines · Izik Eidus

this patchs allow the guest not shadowed memory to be swapped out.

to make it the must effective you should run -kvm-shadow-memory 1 (witch will make your machine slow)
with -kvm-shadow-memory 1, 3giga memory guest can get to be just 32mb on physical host!

when not using -kvm-shadow-memory, i saw 4100mb machine getting to as low as 168mb on the physical host (not as bad as i thought it would be, and surely not as bad as it can be with 41mb of shadow pages :))

So what exactly does this option do? Is it really worth exposing it as an option if it slows down guests so much?

At least, a better name for the option would be nice.

Regards,

Anthony Liguori

Quoted 14 lines · Anthony Liguori

Quoted 7 lines · Izik Eidus

this patchs allow the guest not shadowed memory to be swapped out.

to make it the must effective you should run -kvm-shadow-memory 1 (witch will make your machine slow)
with -kvm-shadow-memory 1, 3giga memory guest can get to be just 32mb on physical host!

Quoted 5 lines

when not using -kvm-shadow-memory, i saw 4100mb machine getting to as low as 168mb on the physical host (not as bad as i thought it would be, and surely not as bad as it can be with 41mb of shadow pages :))

Quoted 8 lines

So what exactly does this option do? Is it really worth exposing it as an option if it slows down guests so much?

At least, a better name for the option would be nice.

Regards,

Anthony Liguori

-kvm-shadow-memory was included in kvm from version 46.
it control how much pages will be allocated to the shadow cache, (from version 46 the default is 2% of the system (so 4.1giga have about 80 mbs of shadow cache by default))
the problem is that each page that present at the shadow cache ( mmu pages ) cant be swapped out, so as lower as the number of shadow caches you have as more swappable will be
useful.

(this option (kvm-shadow-memory) was included to make it possible that as less as possible shadow cache memory will be deleated ( beacuse it have big overhead to lose this cache)

Quoted 32 lines · Izik Eidus

Quoted 14 lines · Anthony Liguori

Quoted 7 lines · Izik Eidus

this patchs allow the guest not shadowed memory to be swapped out.

to make it the must effective you should run -kvm-shadow-memory 1 (witch will make your machine slow)
with -kvm-shadow-memory 1, 3giga memory guest can get to be just 32mb on physical host!

Quoted 5 lines

when not using -kvm-shadow-memory, i saw 4100mb machine getting to as low as 168mb on the physical host (not as bad as i thought it would be, and surely not as bad as it can be with 41mb of shadow pages :))

Quoted 8 lines

So what exactly does this option do? Is it really worth exposing it as an option if it slows down guests so much?

At least, a better name for the option would be nice.

Regards,

Anthony Liguori

-kvm-shadow-memory was included in kvm from version 46. it control how much pages will be allocated to the shadow cache, (from version 46 the default is 2% of the system (so 4.1giga have about 80 mbs of shadow cache by default))
the problem is that each page that present at the shadow cache ( mmu pages ) cant be swapped out, so as lower as the number of shadow caches you have as more swappable will be
useful.

Quoted 4 lines

(this option (kvm-shadow-memory) was included to make it possible that as less as possible shadow cache memory will be deleated ( beacuse it have big overhead to lose this cache)

just to make it clearer,
-kvm-shadow-memory main purpose is to speed up the guest, ( as more mmu pages you have to the shadow cache, as faster as your guest will be while
it working with alot of memory)
(the main mission is that kvm_free_some_pages() will get called as less as possible)

this patchs allow the guest not shadowed memory to be swapped out.

to make it the must effective you should run -kvm-shadow-memory 1 (witch will make your machine slow)
with -kvm-shadow-memory 1, 3giga memory guest can get to be just 32mb on physical host!

when not using -kvm-shadow-memory, i saw 4100mb machine getting to as low as 168mb on the physical host (not as bad as i thought it would be, and surely not as bad as it can be with 41mb of shadow pages :))

it seems to be very stable, it didnt crushed to me once, and i was able to run:
2 3giga each windows xp + 5giga linux guest

and
2 4.1 giga each windows xp and 2 2giga each windows xp.

few things to note:
ignore for now the ugly messages at dmesg, it is due to the fact that gfn_to_page try to sleep while local intrreupts disabled ( we have to split some emulator function so it wont do it)

and i saw some issue with the new rmapp at fedora 7 live cd, for some reason , in the nonpaging mode rmap_remove getting called about 50 times less than it need
it doesnt happen at other linux guests, need to check this... (for now it mean you might have about 200k of memory leak for each fedora 7 live cd you are runing )

also note that now kvm load much faster, beacuse no memset on all the memory is needed (beacuse gfn_to_page get called at run time)

(avi, and dor, note that this patch include small fix to a bug in the patch that i sent you)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Very nice!

I've tested this series (with your new 3/4) with win2k, winxp, ubuntu 7.10, and opensuse. Everything seemed to work just fine.

I also was able to create four 1G VMs on my 2G laptop :-) That was very neat.

Regards,

Anthony Liguori

Quoted 49 lines · Izik Eidus

this patchs allow the guest not shadowed memory to be swapped out.

to make it the must effective you should run -kvm-shadow-memory 1 (witch will make your machine slow)
with -kvm-shadow-memory 1, 3giga memory guest can get to be just 32mb on physical host!

when not using -kvm-shadow-memory, i saw 4100mb machine getting to as low as 168mb on the physical host (not as bad as i thought it would be, and surely not as bad as it can be with 41mb of shadow pages :))

it seems to be very stable, it didnt crushed to me once, and i was able to run:
2 3giga each windows xp + 5giga linux guest

and
2 4.1 giga each windows xp and 2 2giga each windows xp.

few things to note:
ignore for now the ugly messages at dmesg, it is due to the fact that gfn_to_page try to sleep while local intrreupts disabled ( we have to split some emulator function so it wont do it)

and i saw some issue with the new rmapp at fedora 7 live cd, for some reason , in the nonpaging mode rmap_remove getting called about 50 times less than it need
it doesnt happen at other linux guests, need to check this... (for now it mean you might have about 200k of memory leak for each fedora 7 live cd you are runing )

also note that now kvm load much faster, beacuse no memset on all the memory is needed (beacuse gfn_to_page get called at run time)

(avi, and dor, note that this patch include small fix to a bug in the patch that i sent you)

-------------------------------------------------------------------------

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Quoted 4 lines · Anthony Liguori

Very nice!

I've tested this series (with your new 3/4) with win2k, winxp, ubuntu 7.10, and opensuse. Everything seemed to work just fine.

Spoke too soon, found the following in dmesg:

[35078.913071] BUG: scheduling while atomic: 
qemu-system-x86/0x10000001/21612
[35078.913077]
[35078.913079] Call Trace:
[35078.913112]  [<ffffffff804301c5>] thread_return+0x21e/0x6c9
[35078.913129]  [<ffffffff8027a00d>] zone_statistics+0x7d/0x80
[35078.913139]  [<ffffffff80273691>] get_page_from_freelist+0x441/0x5b0
[35078.913168]  [<ffffffff8022ffec>] __cond_resched+0x1c/0x50
[35078.913174]  [<ffffffff804306f2>] cond_resched+0x32/0x40
[35078.913181]  [<ffffffff8024e4d9>] down_read+0x9/0x20
[35078.913199]  [<ffffffff8839a87c>] :kvm:gfn_to_page+0x4c/0x130
[35078.913207]  [<ffffffff8027b76d>] vm_normal_page+0x3d/0xc0
[35078.913230]  [<ffffffff8839ff94>] :kvm:gpa_to_hpa+0x24/0x70
[35078.913249]  [<ffffffff883a007e>] 
:kvm:paging32_set_pte_common+0x9e/0x2b0
[35078.913285]  [<ffffffff883a02d9>] :kvm:paging32_set_pte+0x49/0x50
[35078.913308]  [<ffffffff883a091d>] :kvm:kvm_mmu_pte_write+0x33d/0x3b0
[35078.913350]  [<ffffffff883a0ca2>] :kvm:paging32_walk_addr+0x292/0x310
[35078.913383]  [<ffffffff883a0e30>] :kvm:paging32_page_fault+0xc0/0x300
[35078.913399]  [<ffffffff883a294c>] :kvm:x86_emulate_insn+0x11c/0x4190
[35078.913448]  [<ffffffff883ba36b>] 
:kvm_intel:handle_exception+0x21b/0x2a0
[35078.913474]  [<ffffffff8839ca5c>] :kvm:kvm_vcpu_ioctl+0xddc/0x1130
[35078.913488]  [<ffffffff8022cacc>] task_rq_lock+0x4c/0x90
[35078.913494]  [<ffffffff8022c599>] __activate_task+0x29/0x50
[35078.913504]  [<ffffffff8022f30c>] try_to_wake_up+0x5c/0x3f0
[35078.913511]  [<ffffffff8025240f>] futex_wait+0x2df/0x3c0
[35078.913521]  [<ffffffff8022cacc>] task_rq_lock+0x4c/0x90
[35078.913528]  [<ffffffff8022c599>] __activate_task+0x29/0x50
[35078.913545]  [<ffffffff8022c307>] __wake_up_common+0x47/0x80
[35078.913561]  [<ffffffff8022ca03>] __wake_up+0x43/0x70
[35078.913575]  [<ffffffff80326971>] __up_read+0x21/0xb0
[35078.913585]  [<ffffffff802528a0>] futex_wake+0xd0/0xf0
[35078.913617]  [<ffffffff80240810>] __dequeue_signal+0x110/0x1d0
[35078.913633]  [<ffffffff8023ffce>] recalc_sigpending+0xe/0x30

[35078.913638]  [<ffffffff8024212c>] dequeue_signal+0x5c/0x190
[35078.913662]  [<ffffffff802a6e05>] do_ioctl+0x35/0xe0
[35078.913675]  [<ffffffff802a6f24>] vfs_ioctl+0x74/0x2d0
[35078.913680]  [<ffffffff8023ffce>] recalc_sigpending+0xe/0x30
[35078.913684]  [<ffffffff80240057>] sigprocmask+0x67/0xf0
[35078.913697]  [<ffffffff802a7215>] sys_ioctl+0x95/0xb0
[35078.913715]  [<ffffffff80209e8e>] system_call+0x7e/0x83
[35078.913743]

Regards,

Anthony Liguori

Quoted 60 lines

I also was able to create four 1G VMs on my 2G laptop :-) That was very neat.

Regards,

Anthony Liguori

Quoted 50 lines · Izik Eidus

this patchs allow the guest not shadowed memory to be swapped out.

to make it the must effective you should run -kvm-shadow-memory 1 (witch will make your machine slow)
with -kvm-shadow-memory 1, 3giga memory guest can get to be just 32mb on physical host!

when not using -kvm-shadow-memory, i saw 4100mb machine getting to as low as 168mb on the physical host (not as bad as i thought it would be, and surely not as bad as it can be with 41mb of shadow pages :))

it seems to be very stable, it didnt crushed to me once, and i was able to run:
2 3giga each windows xp + 5giga linux guest

and
2 4.1 giga each windows xp and 2 2giga each windows xp.

few things to note:
ignore for now the ugly messages at dmesg, it is due to the fact that gfn_to_page try to sleep while local intrreupts disabled ( we have to split some emulator function so it wont do it)

and i saw some issue with the new rmapp at fedora 7 live cd, for some reason , in the nonpaging mode rmap_remove getting called about 50 times less than it need
it doesnt happen at other linux guests, need to check this... (for now it mean you might have about 200k of memory leak for each fedora 7 live cd you are runing )

also note that now kvm load much faster, beacuse no memset on all the memory is needed (beacuse gfn_to_page get called at run time)

(avi, and dor, note that this patch include small fix to a bug in the patch that i sent you)

-------------------------------------------------------------------------

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

this patchs allow the guest not shadowed memory to be swapped out.

Quoted 1 line · Izik Eidus

this patchs allow the guest not shadowed memory to be swapped out.

This patch has greatly improved since I've read the swapping code last time. While not having time for a deep review, it looks very clean and sane to me when scrolling over.

this patchs allow the guest not shadowed memory to be swapped out.

to make it the must effective you should run -kvm-shadow-memory 1 (witch will make your machine slow)
with -kvm-shadow-memory 1, 3giga memory guest can get to be just 32mb on physical host!

when not using -kvm-shadow-memory, i saw 4100mb machine getting to as low as 168mb on the physical host (not as bad as i thought it would be, and surely not as bad as it can be with 41mb of shadow pages :))

it seems to be very stable, it didnt crushed to me once, and i was able to run:
2 3giga each windows xp + 5giga linux guest

and
2 4.1 giga each windows xp and 2 2giga each windows xp.

few things to note:
ignore for now the ugly messages at dmesg, it is due to the fact that gfn_to_page try to sleep while local intrreupts disabled ( we have to split some emulator function so it wont do it)

and i saw some issue with the new rmapp at fedora 7 live cd, for some reason , in the nonpaging mode rmap_remove getting called about 50 times less than it need
it doesnt happen at other linux guests, need to check this... (for now it mean you might have about 200k of memory leak for each fedora 7 live cd you are runing )

also note that now kvm load much faster, beacuse no memset on all the memory is needed (beacuse gfn_to_page get called at run time)

(avi, and dor, note that this patch include small fix to a bug in the patch that i sent you)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

I've been playing around with these patches. If I do an madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the following bug. My knowledge of the mm is limited but since madvise(MADV_DONTNEED) effectively does a zap_page_range() I wonder if we're lacking the necessary callback to also remove any potential GPA covered by that range from shadow page cache.

Regards,

Anthony Liguori

Quoted 7 lines · Anthony Liguori

I've been playing around with these patches. If I do an madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the following bug. My knowledge of the mm is limited but since madvise(MADV_DONTNEED) effectively does a zap_page_range() I wonder if we're lacking the necessary callback to also remove any potential GPA covered by that range from shadow page cache.

Quoted 3 lines

Regards,

Anthony Liguori

it probably beacuse the changes of the first patch, ( that make all present shadow pages rmapped )
Anthony can you please check what happn if you run latest kvm with the patch (of the rmap) and without the patch?

Quoted 8 lines · Izik Eidus

Quoted 7 lines · Anthony Liguori

I've been playing around with these patches. If I do an madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the following bug. My knowledge of the mm is limited but since madvise(MADV_DONTNEED) effectively does a zap_page_range() I wonder if we're lacking the necessary callback to also remove any potential GPA covered by that range from shadow page cache.

Quoted 7 lines

Quoted 3 lines

Regards,

Anthony Liguori

it probably beacuse the changes of the first patch, ( that make all present shadow pages rmapped )
Anthony can you please check what happn if you run latest kvm with the patch (of the rmap) and without the patch?

It looks like it's my patch for doing an in kernel mmap() to support older userspaces. I'll figure out what the problem is.

But at any rate, would madvise() be able to evict the current contents of something in the shadow page cache or will the guest not pick up the new memory until the old gets evicted from the shadow page cache?

Regards,

Anthony Liguori

Quoted 20 lines · Anthony Liguori

Quoted 8 lines · Izik Eidus

Quoted 7 lines · Anthony Liguori

I've been playing around with these patches. If I do an madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the following bug. My knowledge of the mm is limited but since madvise(MADV_DONTNEED) effectively does a zap_page_range() I wonder if we're lacking the necessary callback to also remove any potential GPA covered by that range from shadow page cache.

Quoted 7 lines

Quoted 3 lines

Regards,

Anthony Liguori

it probably beacuse the changes of the first patch, ( that make all present shadow pages rmapped )
Anthony can you please check what happn if you run latest kvm with the patch (of the rmap) and without the patch?

It looks like it's my patch for doing an in kernel mmap() to support older userspaces. I'll figure out what the problem is.

Quoted 4 lines

But at any rate, would madvise() be able to evict the current contents of something in the shadow page cache or will the guest not pick up the new memory until the old gets evicted from the shadow page cache?

if i understand you right, then madvise() wont harm us, beacuse we protect all our shadow memory by removing the writable bit from it. therefor the guest cant change anything without we know it.

Quoted 5 lines

Regards,

Anthony Liguori

Quoted 21 lines · Izik Eidus

Quoted 20 lines · Anthony Liguori

Quoted 8 lines · Izik Eidus

Quoted 7 lines · Anthony Liguori

I've been playing around with these patches. If I do an madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the following bug. My knowledge of the mm is limited but since madvise(MADV_DONTNEED) effectively does a zap_page_range() I wonder if we're lacking the necessary callback to also remove any potential GPA covered by that range from shadow page cache.

Quoted 7 lines

Quoted 3 lines

Regards,

Anthony Liguori

it probably beacuse the changes of the first patch, ( that make all present shadow pages rmapped )
Anthony can you please check what happn if you run latest kvm with the patch (of the rmap) and without the patch?

It looks like it's my patch for doing an in kernel mmap() to support older userspaces. I'll figure out what the problem is.

Quoted 7 lines

Quoted 4 lines

But at any rate, would madvise() be able to evict the current contents of something in the shadow page cache or will the guest not pick up the new memory until the old gets evicted from the shadow page cache?

if i understand you right, then madvise() wont harm us, beacuse we protect all our shadow memory by removing the writable bit from it. therefor the guest cant change anything without we know it.

That's not quite what I was wondering.

When you do an madvise() in userspace, the result is that when that memory is accessed again, linux will demand-fault in a zero page and COW it appropriately. If we do madvise() on the VA representing guest physical memory, what I'm curious about is whether the guest will actually see this change. If the guest happens to have the page mapped before we do the madvise(), what triggers KVM to kick any shadow page table entries out of it's cache?

IIUC, today, after the madvise, the guest will have access to the old page until that entry gets evicted and reloaded from the shadow page table cache.

Quoted 11 lines

That's not quite what I was wondering.

When you do an madvise() in userspace, the result is that when that memory is accessed again, linux will demand-fault in a zero page and COW it appropriately. If we do madvise() on the VA representing guest physical memory, what I'm curious about is whether the guest will actually see this change. If the guest happens to have the page mapped before we do the madvise(), what triggers KVM to kick any shadow page table entries out of it's cache?

Quoted 3 lines

IIUC, today, after the madvise, the guest will have access to the old page until that entry gets evicted and reloaded from the shadow page table cache.

ok i am no familier with madvise() so i might talk nonsense but, if the guest have the page mapped before the madvise(), this mean we have high refernce to it, this is our only protection and as far as i understand this should be enough

Quoted 11 lines · Izik Eidus

Quoted 11 lines

That's not quite what I was wondering.

When you do an madvise() in userspace, the result is that when that memory is accessed again, linux will demand-fault in a zero page and COW it appropriately. If we do madvise() on the VA representing guest physical memory, what I'm curious about is whether the guest will actually see this change. If the guest happens to have the page mapped before we do the madvise(), what triggers KVM to kick any shadow page table entries out of it's cache?

Quoted 7 lines

Quoted 3 lines

IIUC, today, after the madvise, the guest will have access to the old page until that entry gets evicted and reloaded from the shadow page table cache.

ok i am no familier with madvise() so i might talk nonsense but, if the guest have the page mapped before the madvise(), this mean we have high refernce to it, this is our only protection and as far as i understand this should be enough

Right, we will have a reference to the page. But we want to propagate
this change to the guest. So madvise() may be a bad example.

What if you wanted to do shared memory for multiple guests. You start out with an anonymous mmap(), and you now what to mmap() a file in /dev/shm to be shared among multiple guests so you mmap(MAP_FIXED) to phys_ram_base + guest_pa in each guest.

So what if guest_pa was in the guest's shadow page cache? In order for the guest to see the right hpa (the new shared memory), we have to be able to evict guest_pa. We could do this with something like mmu_unshadow().

What I don't understand, is how we can have something like mmu_unshadow() called automatically when an mmap() is initiated from userspace. We could just add an ioctl() to do it from userspace but I think it would be nicer if it Just Worked.

Regards,

Anthony Liguori

Quoted 4 lines

Quoted 10 lines · Izik Eidus

Quoted 10 lines

That's not quite what I was wondering.

When you do an madvise() in userspace, the result is that when that memory is accessed again, linux will demand-fault in a zero page and COW it appropriately. If we do madvise() on the VA representing guest physical memory, what I'm curious about is whether the guest will actually see this change. If the guest happens to have the page mapped before we do the madvise(), what triggers KVM to kick any shadow page table entries out of it's cache?

Quoted 9 lines

Quoted 4 lines

IIUC, today, after the madvise, the guest will have access to the old page until that entry gets evicted and reloaded from the shadow page table cache.

ok i am no familier with madvise() so i might talk nonsense but, if the guest have the page mapped before the madvise(), this mean we have high refernce to it, this is our only protection and as far as i understand this should be enough

Right, we will have a reference to the page. But we want to propagate
this change to the guest. So madvise() may be a bad example.

What if you wanted to do shared memory for multiple guests. You start out with an anonymous mmap(), and you now what to mmap() a file in /dev/shm to be shared among multiple guests so you mmap(MAP_FIXED) to phys_ram_base + guest_pa in each guest.

So what if guest_pa was in the guest's shadow page cache? In order for the guest to see the right hpa (the new shared memory), we have to be able to evict guest_pa. We could do this with something like mmu_unshadow().

What I don't understand, is how we can have something like mmu_unshadow() called automatically when an mmap() is initiated from userspace. We could just add an ioctl() to do it from userspace but I think it would be nicer if it Just Worked.

Quoted 35 lines · Anthony Liguori

Quoted 10 lines · Izik Eidus

Quoted 10 lines

That's not quite what I was wondering.

When you do an madvise() in userspace, the result is that when that memory is accessed again, linux will demand-fault in a zero page and COW it appropriately. If we do madvise() on the VA representing guest physical memory, what I'm curious about is whether the guest will actually see this change. If the guest happens to have the page mapped before we do the madvise(), what triggers KVM to kick any shadow page table entries out of it's cache?

Quoted 9 lines

Quoted 4 lines

IIUC, today, after the madvise, the guest will have access to the old page until that entry gets evicted and reloaded from the shadow page table cache.

ok i am no familier with madvise() so i might talk nonsense but, if the guest have the page mapped before the madvise(), this mean we have high refernce to it, this is our only protection and as far as i understand this should be enough

Right, we will have a reference to the page. But we want to
propagate this change to the guest. So madvise() may be a bad example.

What if you wanted to do shared memory for multiple guests. You start out with an anonymous mmap(), and you now what to mmap() a file in /dev/shm to be shared among multiple guests so you mmap(MAP_FIXED) to phys_ram_base + guest_pa in each guest.

So what if guest_pa was in the guest's shadow page cache? In order for the guest to see the right hpa (the new shared memory), we have to be able to evict guest_pa. We could do this with something like mmu_unshadow().

Quoted 5 lines

What I don't understand, is how we can have something like mmu_unshadow() called automatically when an mmap() is initiated from userspace. We could just add an ioctl() to do it from userspace but I think it would be nicer if it Just Worked.

Behold the magic of pte notifiers! Every time the host touches a host page table entry, it calls kvm which zaps the corresponding shadow pte entries and invalidates any tlb entries in running vcpus.

Quoted 6 lines

Quoted 5 lines

What I don't understand, is how we can have something like mmu_unshadow() called automatically when an mmap() is initiated from userspace. We could just add an ioctl() to do it from userspace but I think it would be nicer if it Just Worked.

Quoted 3 lines

Behold the magic of pte notifiers! Every time the host touches a host page table entry, it calls kvm which zaps the corresponding shadow pte entries and invalidates any tlb entries in running vcpus.

/me bows down to the greatness of pte notifiers

So yeah, that would solve the problem nicely. Are you planning on resubmitting those patches or did they end up in Linus' tree?

Quoted 23 lines · Anthony Liguori

Quoted 9 lines · Izik Eidus

Quoted 7 lines · Anthony Liguori

I've been playing around with these patches. If I do an madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the following bug. My knowledge of the mm is limited but since madvise(MADV_DONTNEED) effectively does a zap_page_range() I wonder if we're lacking the necessary callback to also remove any potential GPA covered by that range from shadow page cache.

Quoted 9 lines

Quoted 4 lines

Regards,

Anthony Liguori

it probably beacuse the changes of the first patch, ( that make all present shadow pages rmapped )
Anthony can you please check what happn if you run latest kvm with the patch (of the rmap) and without the patch?

It looks like it's my patch for doing an in kernel mmap() to support older userspaces. I'll figure out what the problem is.

Quoted 4 lines

But at any rate, would madvise() be able to evict the current contents of something in the shadow page cache or will the guest not pick up the new memory until the old gets evicted from the shadow page cache?

if i understand you right, then madvise() wont harm us, beacuse we protect all our shadow memory by removing the writable bit from it. therefor the guest cant change anything without we know it.

Quoted 9 lines · Izik Eidus

Quoted 7 lines · Anthony Liguori

I've been playing around with these patches. If I do an madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the following bug. My knowledge of the mm is limited but since madvise(MADV_DONTNEED) effectively does a zap_page_range() I wonder if we're lacking the necessary callback to also remove any potential GPA covered by that range from shadow page cache.

Quoted 9 lines

Quoted 4 lines

Regards,

Anthony Liguori

it probably beacuse the changes of the first patch, ( that make all present shadow pages rmapped )
Anthony can you please check what happn if you run latest kvm with the patch (of the rmap) and without the patch?

It looks like it's my patch for doing an in kernel mmap() to support older userspaces. I'll figure out what the problem is.

But at any rate, would madvise() be able to evict the current contents of something in the shadow page cache or will the guest not pick up the new memory until the old gets evicted from the shadow page cache?

I've been playing around with these patches. If I do an madvise(MADV_DONTNEED) in userspace, when I close the VM, I get the following bug. My knowledge of the mm is limited but since madvise(MADV_DONTNEED) effectively does a zap_page_range() I wonder if we're lacking the necessary callback to also remove any potential GPA covered by that range from shadow page cache.

Regards,

Anthony Liguori

[  860.724555] rmap_remove: ffff81004c48cf00 506d1025 0->BUG