On Fri, 1 Feb 2008, Andrea Arcangeli wrote:
> > The GRU not covered? Why would you think that way? mremap is covered
> > because of the callbacks in unmap_region().
>
> I wouldn't be so sure. ptep_clear_flush is called for a reason and you
> have zero range_start _before_ the ptep_clear_flush. I
On Thu, Jan 31, 2008 at 12:21:34PM -0800, Christoph Lameter wrote:
> On Thu, 31 Jan 2008, Andrea Arcangeli wrote:
>
> > I doubt Christoph's V4 was close to final yet, GRU wasn't covered at
> > all yet, not even mremap was covered at all (nor XPMEM nor GRU) in V4.
>
> The GRU not covered? Why woul
On Thu, 31 Jan 2008, Andrea Arcangeli wrote:
> I doubt Christoph's V4 was close to final yet, GRU wasn't covered at
> all yet, not even mremap was covered at all (nor XPMEM nor GRU) in V4.
The GRU not covered? Why would you think that way? mremap is covered
because of the callbacks in unmap_regi
This last update will work against mmu-notifiers #v4, this will make
the accessed bitflag in the spte visible to the linux VM so it will
provide an accurate working set detection w/o requiring vmexits.
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
diff --git a/arch/x86/kvm/Kconfig b/arch/x8
On Tue, Jan 22, 2008 at 06:17:38PM +0200, Avi Kivity wrote:
> There can be more than one rmapp per hva. Real world example:
>
> memslot 1: gfn range 0xe00 - 0xe080 @ hva 0x1000 (8MB
> framebuffer)
> memslot 2: gfn range 0xa - 0xa8000 @ hva 0x1000 (32KB VGA window)
>
> If the
Andrea Arcangeli wrote:
> On Tue, Jan 22, 2008 at 03:37:59PM +0200, Avi Kivity wrote:
>
>> Andrea Arcangeli wrote:
>>
>>> On Sun, Jan 20, 2008 at 05:16:03PM +0200, Avi Kivity wrote:
>>>
>>>
Yes, it's supposed to work (we can't prevent userspace from doing it).
On Tue, Jan 22, 2008 at 03:37:59PM +0200, Avi Kivity wrote:
> Andrea Arcangeli wrote:
>> On Sun, Jan 20, 2008 at 05:16:03PM +0200, Avi Kivity wrote:
>>
>>> Yes, it's supposed to work (we can't prevent userspace from doing it).
>>>
>>
>> Hmm, I think we already prevent it, so I don't think I
Andrea Arcangeli wrote:
> On Sun, Jan 20, 2008 at 05:16:03PM +0200, Avi Kivity wrote:
>
>> Yes, it's supposed to work (we can't prevent userspace from doing it).
>>
>
> Hmm, I think we already prevent it, so I don't think I need to update
> my swap code until the below is removed.
>
>
Andrea Arcangeli wrote:
> On Sun, Jan 20, 2008 at 05:16:03PM +0200, Avi Kivity wrote:
>
>> Yes, it's supposed to work (we can't prevent userspace from doing it).
>>
>
> Hmm, I think we already prevent it, so I don't think I need to update
> my swap code until the below is removed.
>
>
On Sun, Jan 20, 2008 at 05:16:03PM +0200, Avi Kivity wrote:
> Yes, it's supposed to work (we can't prevent userspace from doing it).
Hmm, I think we already prevent it, so I don't think I need to update
my swap code until the below is removed.
/* Check for overlaps */
r = -EEXIST;
Andrea Arcangeli wrote:
> On Tue, Jan 15, 2008 at 05:57:03PM +0200, Avi Kivity wrote:
>
>> It's the same hva for two different gpas. Same functionality as the alias,
>> but with less data structures.
>>
>
> Ok but if this is already supposed to work, then I need to at least
> change kvm_h
On Tue, Jan 15, 2008 at 05:57:03PM +0200, Avi Kivity wrote:
> It's the same hva for two different gpas. Same functionality as the alias,
> but with less data structures.
Ok but if this is already supposed to work, then I need to at least
change kvm_hva_to_rmapp not to stop when it find the first
Andrea Arcangeli wrote:
> On Tue, Jan 15, 2008 at 04:40:19PM +0200, Avi Kivity wrote:
>
>> Note that we can now replace aliases with slots; simply map the same hva
>> range to two different gpa ranges (using a kvm-private memslot for backward
>> compat).
>>
>
> Currently the host physical
On Tue, Jan 15, 2008 at 04:40:19PM +0200, Avi Kivity wrote:
> Note that we can now replace aliases with slots; simply map the same hva
> range to two different gpa ranges (using a kvm-private memslot for backward
> compat).
Currently the host physical page is a 1:1 mapping with the hva. Not
sure
Andrea Arcangeli wrote:
> On Mon, Jan 14, 2008 at 05:43:58PM +0200, Avi Kivity wrote:
>
>> heavy handed. Maybe it can be fixed in some clever way with rcu or with a
>> rwlock around the memory slot map.
>>
>
> Ok, first the alias looked superflous so I just dropped it (the whole
> point o
On Mon, Jan 14, 2008 at 05:43:58PM +0200, Avi Kivity wrote:
> heavy handed. Maybe it can be fixed in some clever way with rcu or with a
> rwlock around the memory slot map.
Ok, first the alias looked superflous so I just dropped it (the whole
point of the alias is to never call get_user_pages in
Andrea Arcangeli wrote:
>>
>> Aren't mmu notifiers called with mmap_sem held for read?
>>
>> Maybe not from the swap path?
>>
>
> Good point, the swap path isn't covered by the mmap_sem, so Marcelo's
> right I need to fixup the locking a bit.
>
One idea I had at a time was to add ->lock()
On Mon, Jan 14, 2008 at 04:09:03PM +0200, Avi Kivity wrote:
> Marcelo Tosatti wrote:
>>> +static void unmap_spte(struct kvm *kvm, u64 *spte)
>>> +{
>>> + struct page *page = pfn_to_page((*spte & PT64_BASE_ADDR_MASK) >>
>>> PAGE_SHIFT);
>>> + get_page(page);
>>> + rmap_remove(kvm, spte);
>>>
Marcelo Tosatti wrote:
>>
>> +static void unmap_spte(struct kvm *kvm, u64 *spte)
>> +{
>> +struct page *page = pfn_to_page((*spte & PT64_BASE_ADDR_MASK) >>
>> PAGE_SHIFT);
>> +get_page(page);
>> +rmap_remove(kvm, spte);
>> +set_shadow_pte(spte, shadow_trap_nonpresent_pte);
>> +
On Mon, Jan 14, 2008 at 11:45:39AM -0200, Marcelo Tosatti wrote:
> The alias and memslot maps are protected only by mmap_sem, so you
yes, they are already protected and furthermore in write mode.
> should make kvm_set_memory_region/set_memory_alias grab the mmu spinlock
> in addition to mmap_sem
Hi Andrea,
> path for kvm so I guess not worth optimizing in the short/mid term,
> but by optimizing the invalidate_page case we may halve the number of
> tlb flushes for some common case. I leave it for later, the swapping
> is heavily I/O bound anyway so a some more ipi in smp host shouldn't
> b
Andrea Arcangeli wrote:
> Hi everyone,
>
> So far KVM swapping has been a limited feature. Depending on the
> workloads huge chunks of the anonymous memory simulating the guest
> physical memory could get pinned and unswappable for extended periods
> of time. Whenever a spte mapps a host physical p
22 matches
Mail list logo
