On Sun, Oct 26, 2008 at 01:48:22PM +0200, Avi Kivity wrote:
>> Index: kvm/arch/x86/kvm/mmu.c
>> ===================================================================
>> --- kvm.orig/arch/x86/kvm/mmu.c
>> +++ kvm/arch/x86/kvm/mmu.c
>> @@ -2365,7 +2365,8 @@ static void kvm_mmu_access_page(struct k
>> }
>> void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
>> - const u8 *new, int bytes)
>> + const u8 *new, int bytes,
>> + bool speculative)
>>
>
> kvm_mmu_pte_write()s are always speculative. Maybe this is misnamed?
Yep.
>> + sw->pte_gpa = (sp->gfn << PAGE_SHIFT);
>> + sw->pte_gpa += (sptep - sp->spt) * sizeof(pt_element_t);
>> +
>> + if (is_shadow_present_pte(*sptep)) {
>> rmap_remove(vcpu->kvm, sptep);
>> + sw->pte_gpa = -1;
>>
>
> Why? The pte could have heen replaced (for example, a write access to a
> cow page).
Well look-aheads on address space teardown will be useless. OTOH the
guest pte read cost is minimal compared to an exit.
Whatever you prefer. Learning guest behaviour as suggested earlier would
be optimal, but simple is good.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
