Re: [PATCH 0/4] x86: Drop cross-vendor support

[Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>]

On Fri Jan 23, 2026 at 3:05 PM CET, Jan Beulich wrote:
> 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

That's a rather obscure optimisation, thanks for bringing it up.
multi.c:sh_page_fault() is rather... opaque to just look at it and expect to
find anything.

Cheers,
Alejandro