[Qemu-devel] Re: [RFC][PATCH] x86: CS limit checks

[Jan Kiszka]

Fabrice Bellard wrote:
> Jan Kiszka wrote:
>> Here is a proposal for adding code segment limit checks to x86. This
>> patch should not need the -seg-checks switch as its tests are mostly
>> performed during translation time. Moreover, I tried to confine the
>> small additional overhead in the TB lookup procedure to x86 and Sparc.
>>
>> Note that this patch depends on my debugging series, namely [1], as that
>> one reduces the x86-specific code passages for TB generation. Also note
>> that this patch is early and only lightly tested so far, not yet
>> intended for inclusion, but definitely for commenting on!
> 
> Using more than 32 bits for cs_limit (and cs_base) in the TB is
> wasteful, so I strongly suggest to use a uint32_t type. In that case,
> cs_limit must be explicitely ignored in 64 bit code.
> 
> @@ -172,6 +173,8 @@ static inline TranslationBlock *tb_find_
>      flags = env->hflags;
>      flags |= (env->eflags & (IOPL_MASK | TF_MASK | VM_MASK));
>      cs_base = env->segs[R_CS].base;
> +    if ((env->hflags & (HF_PE_MASK | HF_CS64_MASK)) == HF_PE_MASK)
> +        cs_limit = env->segs[R_CS].limit;
>      pc = cs_base + env->eip;
> 
> This test should be suppressed for performance reasons.

Yes, the test should be moved to the translator code. This will also
allow to reduce the width of cs_base/limit.

> 
> Generally speaking as I said in a private mail, I don't want an option
> -seg-checks: the segment limit and right checks must always be enabled,
> even if there is a small performance hit. The way to implement it is to
> store in the TB.flags for each segment whether the limit must be tested
> and whether the segment is RW.

Switching a segment selector is not yet a TB termination reason IIRC.
I'm not sure about the implication of such a change, e.g. if there are
relevant use case that have relaxed segment limits and attributes, but
perform a lot segment register reloads.

And then there is the open question how much performance can be gained
with compile-time optimization for those guests who do use segmentation.
The worst case is very roughly about 50% slowdown right now (/w vs. w/o
-seg-checks). As answered privately, some -no-seg-checks switch could
remain a useful optimization.

Jan