[MODERATED] Re: Some microperf tests

On Sat, Feb 23, 2019 at 10:27 AM speck for Andrew Cooper
<[email protected]> wrote:
>
>
> Pre microcode:
> * VERW of NUL   => 65-69 cycles
> * VERW of %ds   => 33-37 cycles
>
> Post microcode:
> * VERW of NUL   => 512-520 cycles
> * VERW of %ds   => 520-540 cycles

Ok, those numbers actually make sense to me.

Before the whole "let's use verw for state flushing" issue, the
*normal* use of verw would have been for an actual used segment, and
making the microcode optimize the branches for that would case have
made sense.

Admittedly nobody really uses verw for that reason any more, but from
a legacy standpoint it would seem to be sensible. Maybe old Windows
models really did use verw regularly on real loads.

After the microcode changes, that's no longer true, and using verw on
a real descriptor is pointless, because the only real expected use of
that instruction is flushing, and avoiding the load of the actual
segment value from the LDT/GDT should be the fast case.

So those numbers are actually sensible.

Of course, the fact that verw on a NUL descriptor is so much slower in
the old case is very inconvenient for the "we should do verw even if
the CPU says it doesn't have the microcode update, for vmware rasons",
aka vmverw.

So it would be good to verify that

 (a) yes, this is the intended performance profile from intel

 (b) we probably should give a NUL descriptor for the workaround

 (c) it hurts the vmverw case, but maybe we can only do vmverw when we
notice we are actually running under vmware.

Is there any way to do that vmware detection?

                 Linus