On Mon, Aug 20, 2018 at 6:06 AM Paolo Bonzini <[email protected]> wrote: > > On 17/08/2018 20:04, Andrew Oates wrote: > >>> [1] this is an invalid configuration (in protected mode the L bit is > >>> reserved and should be set to zero), but qemu doesn't enforce that. > > > > Is there a central place to do that sort of validation? We could do it > > in load_segment_ra, but that doesn't feel quite right. Otherwise it's > > whack-a-mole to check validity at every place a code segment is > > referenced---but maybe that's ok, there probably aren't too many of them. > > > > WDYT? > > To find them you have to look for the calls to cpu_x86_load_seg_cache. > > However, the L bit is simply ignored in the descriptor cache outside > 64-bit mode (at least that's what you can guess from the Intel manual's > 26.3 CHECKING AND LOADING GUEST STATE, which is as close as you can get > to an official explanation of the descriptor cache), so you'd have to > take that into account too and do the check in the callers of > cpu_x86_load_seg_cache. > > And in fact, the wording is a bit wishy-washy in both the Intel and AMD > manuals, for example AMD says of bit 21 that > > Generally, software should clear all reserved bits to 0, so they > can be defined in future revisions to the AMD64 architecture. > > so I am not 100% sure that the processor will actually raise an > exception if L is 1.
That's good enough for me :) My vote would be to continue to ignore the L bit in 32-bit mode, then. We should just remove the part that implies qemu should enforce it from my patch commit message. > > Thanks, > > Paolo
