Re: [PATCH 3/5] target/i386: Fix physical address truncation

[Michael Brown]

On 23/12/2023 11:47, Paolo Bonzini wrote:
> The linear address is the one that has the segment base added, and it is 
> not truncated to 16 bits (otherwise the whole A20 thing would not 
> exist). The same should be true of e.g. an FSAVE instruction; it would 
> allow access slightly beyond the usual 1M+64K limit that is possible in 
> real mode with 286 and later processors.
>
> In big real mode with 32-bit addresses, it should not be possible to go 
> beyond 4G physical address by adding the segment base, it should wrap 
> around and that's what I implemented. However you're probably right that 
> this patch has a hole for accesses made from 32-bit code segments with 
> paging enabled. I think LMA was the wrong bit to test all the time, and 
> I am not even sure if the masking must be applied even before the call 
> to mmu_translate(). I will ponder it a bit and possibly send a revised 
> version.

You are of course correct that the linear address is not truncated to 16 
bits when the address size is 16 bits - my mistake.

I've been looking through the SDM for any definitive statement on the 
topic.  The closest I can find is in volume 3 table 4-1, which states 
that the linear address width is:

 - 32 bits with paging disabled

 - 32 bits with 32-bit paging

 - 32 bits with PAE paging

 - 48 bits with 4-level paging

 - 57 bits with 5-level paging

My previous experiment seems to show that the linear address *does* also 
get truncated to 32 bits for an instruction with a 32-bit address size 
even when running in long mode with 4-level paging (on a Core i7-6600U), 
so this table definitely isn't telling the complete story.

My best guess at this point is that the linear address gets truncated to 
32 bits when the address size is 32 bits (which will always be the case 
when paging is disabled, or when using 32-bit paging or PAE paging).

Thanks,

Michael