Avi Kivity wrote:
> Dong, Eddie wrote:
>> Avi Kivity wrote:
>>
>>> On a pte update, npte will always be 1. On a pde update, we won't
>>> do anything in mmu_pte_write_new_pte because it doesn't handle
>>> pdes. If we extend it to handle pdes, then we need either to
>>> modify the new gpde or to h
Dong, Eddie wrote:
> Avi Kivity wrote:
>
>> On a pte update, npte will always be 1. On a pde update, we won't do
>> anything in mmu_pte_write_new_pte because it doesn't handle
>> pdes. If we
>> extend it to handle pdes, then we need either to modify the
>> new gpde or
>> to have the update tak
Avi Kivity wrote:
> On a pte update, npte will always be 1. On a pde update, we won't do
> anything in mmu_pte_write_new_pte because it doesn't handle
> pdes. If we
> extend it to handle pdes, then we need either to modify the
> new gpde or
> to have the update take the quadrant into account.
Ag
Dong, Eddie wrote:
> BTW, in kvm_mmu_pte_write, I feel a little bit stranger for following
> code:
>
>
>
>>level = page->role.level;
>>npte = 1;
>>if (page->role.glevels == PT32_ROOT_LEVEL) {
>>page_offset <<= 1; /* 32-
Avi Kivity wrote:
> Earlier we check if the accessed bit is off, and if so, we
> don't set the
> shadow pte. This won't happen in practice because the guest's page
> fault handler will set the accessed bit when it modifies a pte
> to avoid
> an RMW cycle by the hardware page table walker.
>
Thank
Dong, Eddie wrote:
> Not sure if we should use PT_USER_MASK | PT_WRITABLE_MASK here.
>
> diff --git a/drivers/kvm/paging_tmpl.h b/drivers/kvm/paging_tmpl.h
> index 6dd0da9..183d4ca 100644
> --- a/drivers/kvm/paging_tmpl.h
> +++ b/drivers/kvm/paging_tmpl.h
> @@ -213,7 +213,7 @@ static void FNAME(upd
Not sure if we should use PT_USER_MASK | PT_WRITABLE_MASK here.
diff --git a/drivers/kvm/paging_tmpl.h b/drivers/kvm/paging_tmpl.h
index 6dd0da9..183d4ca 100644
--- a/drivers/kvm/paging_tmpl.h
+++ b/drivers/kvm/paging_tmpl.h
@@ -213,7 +213,7 @@ static void FNAME(update_pte)(struct kvm_vcpu *vcpu,
