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

[Kevin O'Connor]

Hi Jan,

On Tue, Jul 15, 2008 at 05:48:23PM +0200, Jan Kiszka wrote:
> > Kevin O'Connor wrote:
> >>Thus limiting the optimization to those (common) cases where
> >> the limits and bases are all the same.
> >> 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.
[...]
> Don't want to stop all your creativity, but just like Paul I'm also a
> bit skeptical about the TLB way of achieving range and type safety.
> 
> My major concern once was that the TLB works on a global scope so that
> you cannot tell the original segments behind some address apart.

If all five segments have the same base and limit (0..LIMIT) then I
would think it would not matter what segment filled a TLB.  (It should
not be possible to fill a TLB outside of 0..LIMIT, and any access to a
tlb in 0..LIMIT should be okay regardless of the segment used.)

Of course, it's not uncommon for FS and GS to have a different base.
In this case, it should still be safe as long as FS/GS don't allow
access outside of 0..LIMIT (so that invalid TLBs don't get loaded) and
one emits limit checks on each FS/GS use (so that the limits on FS/GS
are enforced).

Qemu already has an optimization (HF_ADDSEG_MASK) for the case where
DS/ES/SS all have a zero base.  I was thinking that an optimization
could noticeably reduce the cost of limit checks for the common case
where DS/ES/SS all have a zero base and the same limit.  (I
incorrectly stated CS/DS/SS above.)

Of course, it would require a lot of work, and it would be hard to
verify that all the corner cases were handled.  So, I was more
thinking out loud than proposing a solution.  :-)

>And
> extending the virtual address space for this is a no-go on 32-bit hosts
> (which I unfortunately had and still have to support here :->).

Yeah - I wouldn't want to go there.  Trying to maintain multiple TLBs
or adding more bits to the TLB hash just seems silly to me.

-Kevin