On Wed, Sep 24, 2014 at 1:27 AM, Paolo Bonzini wrote:
> Il 24/09/2014 09:20, Wanpeng Li ha scritto:
>>
>> This trace point still dup duplicated message for the same gfn in the
>> for loop.
>
> Yes, but the gfn argument lets you take it out again.
>
> Note that having the duplicated trace would mak
Il 24/09/2014 09:20, Wanpeng Li ha scritto:
>
> This trace point still dup duplicated message for the same gfn in the
> for loop.
Yes, but the gfn argument lets you take it out again.
Note that having the duplicated trace would make sense if you included
the accessed bit for each spte, instead o
Hi Paolo,
δΊ 9/24/14, 3:04 PM, Paolo Bonzini ει:
Il 24/09/2014 04:27, Wanpeng Li ha scritto:
Hi Andres,
On Mon, Sep 22, 2014 at 02:54:42PM -0700, Andres Lagar-Cavilla wrote:
1. We were calling clear_flush_young_notify in unmap_one, but we are
within an mmu notifier invalidate range scope. The sp
Il 24/09/2014 04:27, Wanpeng Li ha scritto:
> Hi Andres,
> On Mon, Sep 22, 2014 at 02:54:42PM -0700, Andres Lagar-Cavilla wrote:
>> 1. We were calling clear_flush_young_notify in unmap_one, but we are
>> within an mmu notifier invalidate range scope. The spte exists no more
>> (due to range_start)
Hi Andres,
On Mon, Sep 22, 2014 at 02:54:42PM -0700, Andres Lagar-Cavilla wrote:
>1. We were calling clear_flush_young_notify in unmap_one, but we are
>within an mmu notifier invalidate range scope. The spte exists no more
>(due to range_start) and the accessed bit info has already been
>propagated
Il 23/09/2014 19:04, Andres Lagar-Cavilla ha scritto:
> I'm not sure. The addition is not always by PAGE_SIZE, since it
> depends on the current level we are iterating at in the outer
> kvm_handle_hva_range(). IOW, could be PMD_SIZE or even PUD_SIZE, and
> is_large_pte() enough to tell?
>
> This i
On Tue, Sep 23, 2014 at 12:49 AM, Paolo Bonzini wrote:
> Il 22/09/2014 23:54, Andres Lagar-Cavilla ha scritto:
>> @@ -1406,32 +1406,24 @@ static int kvm_age_rmapp(struct kvm *kvm, unsigned
>> long *rmapp,
>> struct rmap_iterator uninitialized_var(iter);
>> int young = 0;
>>
>> - /
Il 22/09/2014 23:54, Andres Lagar-Cavilla ha scritto:
> @@ -1406,32 +1406,24 @@ static int kvm_age_rmapp(struct kvm *kvm, unsigned
> long *rmapp,
> struct rmap_iterator uninitialized_var(iter);
> int young = 0;
>
> - /*
> - * In case of absence of EPT Access and Dirty Bits s
1. We were calling clear_flush_young_notify in unmap_one, but we are
within an mmu notifier invalidate range scope. The spte exists no more
(due to range_start) and the accessed bit info has already been
propagated (due to kvm_pfn_set_accessed). Simply call
clear_flush_young.
2. We clear_flush_you