On 04/04/2023 3:55 pm, Jan Beulich wrote:
> These are "compound" instructions to issue a series of RDMSR / WRMSR
> respectively. In the emulator we can therefore implement them by using
> the existing msr_{read,write}() hooks. The memory accesses utilize that
> the HVM ->read() / ->write() hooks are already linear-address
> (x86_seg_none) aware (by way of hvmemul_virtual_to_linear() handling
> this case).
>
> Signed-off-by: Jan Beulich <jbeul...@suse.com>
> ---
> TODO: Use VMX tertiary execution control (once bit is known; see
> //todo-s) and then further adjust cpufeatureset.h.
>
> RFC: In vmx_vmexit_handler() handling is forwarded to the emulator
> blindly. Alternatively we could consult the exit qualification and
> process just a single MSR at a time (without involving the
> emulator), exiting back to the guest after every iteration. (I
> don't think a mix of both models makes a lot of sense.)
{RD,WR}MSRLIST are supposed to be used for context switch paths. They
really shouldn't be exiting in the common case.
What matters here is the conditional probability of a second MSR being
intercepted too, given that one already has been. And I don't have a
clue how to answer this.
I would not expect Introspection to be intercepting a fastpath MSR.
(And if it does, frankly it can live with the consequences.)
For future scenarios such as reloading PMU/LBR/whatever, these will be
all-or-nothing and we'd expect to have them eagerly in context anyway.
If I were going to guess, I'd say that probably MSR_XSS or MSR_SPEC_CTRL
will be giving us the most grief here, because they're both ones that
are liable to be touched on a context switch path, and have split
host/guest bits.
> RFC: For PV priv_op_ops would need to gain proper read/write hooks,
> which doesn't look desirable (albeit there we could refuse to
> handle anything else than x86_seg_none); we may want to consider to
> instead not support the feature for PV guests, requiring e.g. Linux
> to process the lists in new pvops hooks.
Ah - funny you should ask. See patch 2. These are even better reasons
not to support on PV guests.
> RFC: I wasn't sure whether to add preemption checks to the loops -
> thoughts?
I'd be tempted to. Mostly because a guest can exert 64* longest MSR
worth of pressure here, along with associated emulation overhead.
64* "write hypercall page" sounds expensive. So too does 64* MSR_PAT,
given all the EPT actions behind the scenes.
Its probably one of those
> With the VMX side of the spec still unclear (tertiary execution control
> bit unspecified in ISE 046) we can't enable the insn yet for (HVM) guest
> use. The precise behavior of MSR_BARRIER is also not spelled out, so the
> (minimal) implementation is a guess for now.
MSRs are expensive for several reasons. The %ecx decode alone isn't
cheap, nor is the reserved bit checking, and that's before starting the
action itself.
What the list form gets you is the ability to pipeline the checks on the
following MSR while performing the action of the current one. I suspect
there are plans to try and parallelise the actions too if possible.
As I understand it, BARRIER just halts the piplineing of processing the
next MSR.
~Andrew
