Anthony Liguori wrote:
> So does MADV_REMOVE remove the backing page but still allow for memory
> to be faulted in? That is, after calling MADV_REMOVE, there's no
> guarantee that the contents of a give VA range will remain the same (but
> it won't SEGV the app if it accesses that memory)?
>
>
Anthony Liguori wrote:
> Avi Kivity wrote:
>
>> Anthony Liguori wrote:
>>
>>
>>> Now that we have userspace memory allocation, I wanted to play with
>>> ballooning.
>>> The idea is that when a guest "balloons" down, we simply unpin the
>>> underlying
>>> physical memory and the host ke
Avi Kivity wrote:
> Anthony Liguori wrote:
>
>> Now that we have userspace memory allocation, I wanted to play with
>> ballooning.
>> The idea is that when a guest "balloons" down, we simply unpin the underlying
>> physical memory and the host kernel may or may not swap it. To reclaim
>> ballo
Anthony Liguori wrote:
> Now that we have userspace memory allocation, I wanted to play with
> ballooning.
> The idea is that when a guest "balloons" down, we simply unpin the underlying
> physical memory and the host kernel may or may not swap it. To reclaim
> ballooned memory, the guest can jus
The idea being that kvm_read_guest_page() will effectively pin the page
and put_page() has the effect of unpinning it? It seems to me that we
should be using page_cache_release()'ing since we're not just
get_page()'ing the memory. I may be wrong though.
Both of these are an optimization th
Anthony Liguori wrote:
Izik Eidus wrote:
static void page_header_update_slot(struct kvm *kvm, void *pte,
gpa_t gpa)
{
int slot = memslot_id(kvm, gfn_to_memslot(kvm, gpa >>
PAGE_SHIFT));
-
kvm_memory_slot
he
Izik Eidus wrote:
>> static void page_header_update_slot(struct kvm *kvm, void *pte,
>> gpa_t gpa)
>> {
>> int slot = memslot_id(kvm, gfn_to_memslot(kvm, gpa >> PAGE_SHIFT));
>>
>> -
>>
>>
> kvm_memory_slot
>
> heh,
Anthony Liguori wrote:
> Now that we have userspace memory allocation, I wanted to play with
> ballooning.
> The idea is that when a guest "balloons" down, we simply unpin the underlying
> physical memory and the host kernel may or may not swap it. To reclaim
> ballooned memory, the guest can jus
Now that we have userspace memory allocation, I wanted to play with ballooning.
The idea is that when a guest "balloons" down, we simply unpin the underlying
physical memory and the host kernel may or may not swap it. To reclaim
ballooned memory, the guest can just start using it and we'll pin it
