Re: [Qemu-devel] [RFC][PATCH] x86: Optional segment type and limit checks - v2

[Kevin O'Connor <kevin@koconnor.net>]

Hi Jamie,

On Mon, Jul 14, 2008 at 03:02:38PM +0100, Jamie Lokier wrote:
> Paul Brook wrote:
> > > For guests like older Linux, with zero base and non-maximum limit in
> > > user mode, could limit checking be done by the MMU TLB instead?
> > 
> > Not really. The only resonable way to do this would be to use a very
> > large virtual address space, with the high bits being the segment
> > descriptor.  This might work for 32-bit targets on 64-bit hosts, but
> > even then it's liable to be more pain than it's worth.
> 
> I was thinking more like this, on any host:
> 
>    - All segment bases are zero, and all limits are LIMIT
>      (3GiB for old Linux in user mode).
>    - When filling the MMU TLB, if it's for an address >= LIMIT,
>      treat as MMU exception.

That's interesting.

If I understand correctly, you're suggesting using segment checks in
translated code if any segment has a non-zero base or a different size
limit.  Thus limiting the optimization to those (common) cases where
the limits and bases are all the same.  Presumably this would also
require LIMIT to be page aligned.

One could probably allow ES, FS, and GS to have different bases/limits
as long as their ranges all fit within the primary range (0..LIMIT of
CS, DS, and SS).  It should be okay to always emit segment checks for
accesses that use these segments as they should be pretty rare.

Would this still work in 32bit flat mode?

>    - Flush MMU TLB on any interesting segment change (limit gets
>      smaller, etc.).
>    - Count rate of interesting segment changes.  When it's high,
>      switch to including segment checks in translated code (same as
>      non-zero bases) and not flushing TLB.  When it's low, don't put
>      segment checks into translated code, and use TLB flushes on
>      segment changes.
>    - Keep separate count for ring 0 and ring 3, or for
>      "code which uses segment prefixes" vs "code which doesn't".

Why are the heuristics needed?  I wonder if the tlb flush could just
be optimized.

One would only need to flush the tlb when transitioning from "segment
checks in translated code" mode to "segment checks in mmu" mode, or
when directly going to a new LIMIT.  In these cases one could just
flush NEWLIMIT..OLDLIMIT.

-Kevin