[PATCH 2/5] x86/pvh: Use correct size value in GDT descriptor

Ard Biesheuvel posted 5 patches 2 months, 3 weeks ago
There is a newer version of this series
[PATCH 2/5] x86/pvh: Use correct size value in GDT descriptor
Posted by Ard Biesheuvel 2 months, 3 weeks ago
From: Ard Biesheuvel <ardb@kernel.org>

The size field in a GDT descriptor is offset by 1, so subtract 1 from
the calculated range.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 arch/x86/platform/pvh/head.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform/pvh/head.S
index 98ddd552885a..f09e0fb832e4 100644
--- a/arch/x86/platform/pvh/head.S
+++ b/arch/x86/platform/pvh/head.S
@@ -223,7 +223,7 @@ SYM_CODE_END(pvh_start_xen)
 	.section ".init.data","aw"
 	.balign 8
 SYM_DATA_START_LOCAL(gdt)
-	.word gdt_end - gdt_start
+	.word gdt_end - gdt_start - 1
 	.long _pa(gdt_start) /* x86-64 will overwrite if relocated. */
 	.word 0
 SYM_DATA_END(gdt)
-- 
2.46.0.792.g87dc391469-goog
Re: [PATCH 2/5] x86/pvh: Use correct size value in GDT descriptor
Posted by Jason Andryuk 2 months, 3 weeks ago
On 2024-09-26 06:41, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
> 
> The size field in a GDT descriptor is offset by 1, so subtract 1 from
> the calculated range.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

I guess with s/size/limit/ per Andrew.

Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Tested-by: Jason Andryuk <jason.andryuk@amd.com>

Thanks,
Jason
Re: [PATCH 2/5] x86/pvh: Use correct size value in GDT descriptor
Posted by Andrew Cooper 2 months, 3 weeks ago
On 26/09/2024 11:41 am, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> The size field in a GDT descriptor is offset by 1, so subtract 1 from
> the calculated range.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

I realise this is probably nitpicking, but the GDT descriptor has a
limit field, which is (intentionally) not a size field.

This is why there's a difference of 1 between them.

Working in terms of limits rather than sizes avoids needing a 16th bit
on the segment limit circuitry, which mattered for the 286.

~Andrew