On 23.01.2026 13:10, Alejandro Vallejo wrote:
> On Thu Jan 22, 2026 at 7:16 PM CET, Teddy Astie wrote:
>> Le 22/01/2026 à 18:44, Alejandro Vallejo a écrit :
>>> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote:
>>>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>>>>> Open question unrelated to the series: Does it make sense to
>>>>> conditionalise the
>>>>> MSR handlers for non intercepted MSRs on HVM_FEP?
>>>>
>>>> I'm not quite sure what you're asking here.
>>>>
>>>> ~Andrew
>>>
>>> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as
>>> far
>>> as I can tell. The question I'm asking is whether there is another code path
>>> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but
>>> I'm not sure.
>>>
>>> If there isn't I'm considering (conditionally) getting rid of them.
>>>
>>
>> I think you can enter this path by making the guest execute directly or
>> indirectly a rdmsr in a emulated path (there are some cases like certain
>> cases of real mode or maybe vm introspection). I don't think that FEP is
>> the only way to do that.
>
> For the emulation path, I think HVM_FEP is the only means to trigger it, as
> neither {rd,wr}msr access memory. VMI (as you mention) and nSVM (as Andrew
> did)
> do make sense, but I don't see any others. I don't see how real mode could
> cause
> anything (I'm fuzzy on VMX, but I _think_ instructions do execute, just in
> a weird paging-on mode akin to v8086).
Iirc there's still the situation where for PAE shadow code tries to emulate up
to 4 insns in a row, in the hope to find the other half of a full PTE update.
Jan
