Re: [PATCH 9/9] x86emul+VMX: support {RD,WR}MSRLIST

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.04.2023 00:03, Andrew Cooper wrote:
> On 04/04/2023 3:55 pm, Jan Beulich wrote:
>> ---
>> 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.

I'm not really certain, but I'm tending to interpret your reply as
agreement with the choice made (and hence not as a request to change
anything in this regard); clarification appreciated.

>> 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.

Yeah, with PV dropped there it's quite obvious to not consider it here
either. I'll drop the remark.

>> 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

Which leaves me inclined to add preemption checking to writes, but
keep reads as they are. Thoughts?

Jan