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
