[PATCH 15/15] KVM: X86: Always set gpte_is_8_bytes when direct map

[PATCH 15/15] KVM: X86: Always set gpte_is_8_bytes when direct map

[Lai Jiangshan]

From: Lai Jiangshan <laijs@linux.alibaba.com>

When direct map, gpte_is_8_bytes has no meaning, but it is true for all
other cases except direct map when nonpaping.

Setting gpte_is_8_bytes to true when nonpaping can ensure that
!gpte_is_8_bytes means 32-bit gptes for shadow paging.

Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
---
 Documentation/virt/kvm/mmu.rst | 2 +-
 arch/x86/kvm/mmu/mmu.c         | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/virt/kvm/mmu.rst b/Documentation/virt/kvm/mmu.rst
index f60f5488e121..5d1086602759 100644
--- a/Documentation/virt/kvm/mmu.rst
+++ b/Documentation/virt/kvm/mmu.rst
@@ -179,7 +179,7 @@ Shadow pages contain the following information:
     unpinned it will be destroyed.
   role.gpte_is_8_bytes:
     Reflects the size of the guest PTE for which the page is valid, i.e. '1'
-    if 64-bit gptes are in use, '0' if 32-bit gptes are in use.
+    if direct map or 64-bit gptes are in use, '0' if 32-bit gptes are in use.
   role.efer_nx:
     Contains the value of efer.nx for which the page is valid.
   role.cr0_wp:
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 6948f2d696c3..0c92cbc07320 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -2083,7 +2083,7 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu,
 	role.level = level;
 	role.direct = direct;
 	role.access = access;
-	if (!direct_mmu && !role.gpte_is_8_bytes) {
+	if (!role.gpte_is_8_bytes) {
 		quadrant = gaddr >> (PAGE_SHIFT + (PT64_PT_BITS * level));
 		quadrant &= (1 << ((PT32_PT_BITS - PT64_PT_BITS) * level)) - 1;
 		role.quadrant = quadrant;
@@ -4777,7 +4777,7 @@ kvm_calc_shadow_root_page_role_common(struct kvm_vcpu *vcpu,
 
 	role.base.smep_andnot_wp = role.ext.cr4_smep && !____is_cr0_wp(regs);
 	role.base.smap_andnot_wp = role.ext.cr4_smap && !____is_cr0_wp(regs);
-	role.base.gpte_is_8_bytes = ____is_cr0_pg(regs) && ____is_cr4_pae(regs);
+	role.base.gpte_is_8_bytes = !____is_cr0_pg(regs) || ____is_cr4_pae(regs);
 
 	return role;
 }
-- 
2.19.1.6.gb485710b

Re: [PATCH 15/15] KVM: X86: Always set gpte_is_8_bytes when direct map

[Paolo Bonzini]

On 11/18/21 12:08, Lai Jiangshan wrote:
> From: Lai Jiangshan <laijs@linux.alibaba.com>
> 
> When direct map, gpte_is_8_bytes has no meaning, but it is true for all
> other cases except direct map when nonpaping.
> 
> Setting gpte_is_8_bytes to true when nonpaping can ensure that
> !gpte_is_8_bytes means 32-bit gptes for shadow paging.

Then the right thing to do would be to rename it to has_4_byte_gptes and 
invert the direction.  But as things stand, it's a bit more confusing to 
make gpte_is_8_bytes=1 if there are no guest PTEs at all.

Paolo

> Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
> ---
>   Documentation/virt/kvm/mmu.rst | 2 +-
>   arch/x86/kvm/mmu/mmu.c         | 4 ++--
>   2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/virt/kvm/mmu.rst b/Documentation/virt/kvm/mmu.rst
> index f60f5488e121..5d1086602759 100644
> --- a/Documentation/virt/kvm/mmu.rst
> +++ b/Documentation/virt/kvm/mmu.rst
> @@ -179,7 +179,7 @@ Shadow pages contain the following information:
>       unpinned it will be destroyed.
>     role.gpte_is_8_bytes:
>       Reflects the size of the guest PTE for which the page is valid, i.e. '1'
> -    if 64-bit gptes are in use, '0' if 32-bit gptes are in use.
> +    if direct map or 64-bit gptes are in use, '0' if 32-bit gptes are in use.
>     role.efer_nx:
>       Contains the value of efer.nx for which the page is valid.
>     role.cr0_wp:
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 6948f2d696c3..0c92cbc07320 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -2083,7 +2083,7 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu,
>   	role.level = level;
>   	role.direct = direct;
>   	role.access = access;
> -	if (!direct_mmu && !role.gpte_is_8_bytes) {
> +	if (!role.gpte_is_8_bytes) {
>   		quadrant = gaddr >> (PAGE_SHIFT + (PT64_PT_BITS * level));
>   		quadrant &= (1 << ((PT32_PT_BITS - PT64_PT_BITS) * level)) - 1;
>   		role.quadrant = quadrant;
> @@ -4777,7 +4777,7 @@ kvm_calc_shadow_root_page_role_common(struct kvm_vcpu *vcpu,
>   
>   	role.base.smep_andnot_wp = role.ext.cr4_smep && !____is_cr0_wp(regs);
>   	role.base.smap_andnot_wp = role.ext.cr4_smap && !____is_cr0_wp(regs);
> -	role.base.gpte_is_8_bytes = ____is_cr0_pg(regs) && ____is_cr4_pae(regs);
> +	role.base.gpte_is_8_bytes = !____is_cr0_pg(regs) || ____is_cr4_pae(regs);
>   
>   	return role;
>   }
> 

Re: [PATCH 15/15] KVM: X86: Always set gpte_is_8_bytes when direct map

[Lai Jiangshan]

On 2021/11/18 19:12, Paolo Bonzini wrote:
> On 11/18/21 12:08, Lai Jiangshan wrote:
>> From: Lai Jiangshan <laijs@linux.alibaba.com>
>>
>> When direct map, gpte_is_8_bytes has no meaning, but it is true for all
>> other cases except direct map when nonpaping.
>>
>> Setting gpte_is_8_bytes to true when nonpaping can ensure that
>> !gpte_is_8_bytes means 32-bit gptes for shadow paging.
> 
> Then the right thing to do would be to rename it to has_4_byte_gptes and invert the direction.  But as things stand, 
> it's a bit more confusing to make gpte_is_8_bytes=1 if there are no guest PTEs at all.
> 

I will make the last 3 patches be a separated patchset and will do the rename.

Re: [PATCH 15/15] KVM: X86: Always set gpte_is_8_bytes when direct map

[Paolo Bonzini]

On 11/18/21 15:34, Lai Jiangshan wrote:
> 
> 
> On 2021/11/18 19:12, Paolo Bonzini wrote:
>> On 11/18/21 12:08, Lai Jiangshan wrote:
>>> From: Lai Jiangshan <laijs@linux.alibaba.com>
>>>
>>> When direct map, gpte_is_8_bytes has no meaning, but it is true for all
>>> other cases except direct map when nonpaping.
>>>
>>> Setting gpte_is_8_bytes to true when nonpaping can ensure that
>>> !gpte_is_8_bytes means 32-bit gptes for shadow paging.
>>
>> Then the right thing to do would be to rename it to has_4_byte_gptes 
>> and invert the direction.  But as things stand, it's a bit more 
>> confusing to make gpte_is_8_bytes=1 if there are no guest PTEs at all.
>>
> 
> I will make the last 3 patches be a separated patchset and will do the 
> rename.

Patches 13 and 14 are fine actually.

Paolo

Re: [PATCH 15/15] KVM: X86: Always set gpte_is_8_bytes when direct map

[Lai Jiangshan]

On 2021/11/18 23:01, Paolo Bonzini wrote:
> On 11/18/21 15:34, Lai Jiangshan wrote:
>>
>>
>> On 2021/11/18 19:12, Paolo Bonzini wrote:
>>> On 11/18/21 12:08, Lai Jiangshan wrote:
>>>> From: Lai Jiangshan <laijs@linux.alibaba.com>
>>>>
>>>> When direct map, gpte_is_8_bytes has no meaning, but it is true for all
>>>> other cases except direct map when nonpaping.
>>>>
>>>> Setting gpte_is_8_bytes to true when nonpaping can ensure that
>>>> !gpte_is_8_bytes means 32-bit gptes for shadow paging.
>>>
>>> Then the right thing to do would be to rename it to has_4_byte_gptes and invert the direction.  But as things stand, 
>>> it's a bit more confusing to make gpte_is_8_bytes=1 if there are no guest PTEs at all.
>>>
>>
>> I will make the last 3 patches be a separated patchset and will do the rename.
> 
> Patches 13 and 14 are fine actually.
> 

Hello

Since 13, and 14 is queued, could you also queue this one and I will do the rename
separately in the next patchset.  I found that the intent of this patch is hidden
in the lengthened squashed patch (of this patch and the renaming patch).

Thanks
Lai

Re: [PATCH 15/15] KVM: X86: Always set gpte_is_8_bytes when direct map

[Paolo Bonzini]

On 11/19/21 11:30, Lai Jiangshan wrote:
>> 
> 
> Hello
> 
> Since 13, and 14 is queued, could you also queue this one and I will
> do the rename separately in the next patchset.  I found that the
> intent of this patch is hidden in the lengthened squashed patch (of
> this patch and the renaming patch).

Then you can do the renaming first?

Paolo

Re: [PATCH 15/15] KVM: X86: Always set gpte_is_8_bytes when direct map

[Lai Jiangshan]

On 2021/11/19 18:34, Paolo Bonzini wrote:
> On 11/19/21 11:30, Lai Jiangshan wrote:
>>>
>>
>> Hello
>>
>> Since 13, and 14 is queued, could you also queue this one and I will
>> do the rename separately in the next patchset.  I found that the
>> intent of this patch is hidden in the lengthened squashed patch (of
>> this patch and the renaming patch).
> 
> Then you can do the renaming first?
> 

Then I would prefer to make the code match the name for the first time
when the name is introduced, which means it would be a squashed patch.

I will not fuss about it and will send the squashed patch.