Re: [XEN][PATCH] x86/hvm: move hvm_shadow_handle_cd() under CONFIG_INTEL_VMX ifdef

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 28/10/2025 12:43 pm, Grygorii Strashko wrote:
> On 25.10.25 21:10, Teddy Astie wrote:
>> Le 23/10/2025 à 17:22, Grygorii Strashko a écrit :
>>> From: Grygorii Strashko <grygorii_strashko@xxxxxxxx>
>>>
>>> Functions:
>>>    hvm_shadow_handle_cd()
>>>    hvm_set_uc_mode()
>>>    domain_exit_uc_mode()
>>> are used only by Intel VMX code, so move them under CONFIG_INTEL_VMX
>>> ifdef.
>>>
>>
>> If they are actually Intel VMX specific, they should rather be moved to
>> VMX code (and named appropriately) rather than if-defed in shared hvm
>> code. If AMD code happens to need these functions in the future, it
>> would make things break pretty confusingly (as headers are not updated
>> consistently).
>
> I agree and like it even better. Can try if there is no objections?
>
> There is hvm_prepare_vm86_tss() also which is also used by VMX code only.


There is some horrible complexity here.

With SVM, we can run guests perfectly well in Cache Disable mode (i.e.
gCR0.CD=1).  Nothing extra is needed.

With VT-x, for unknown reasons, entering a VM explicitly leaves
CR0.{CD,NW} unmodified, i.e. always the Xen settings, which will be
neither bit set.  As a result, when the guest wishes to set
gCR0.{CD,NW}, we have to jump through hoops to make this happen.

Without going into the details, the upshot is that this "handle uc mode"
logic is VT-x specific, and oughtn't to be in hvm.c.  Moving it seems
fine, but the data, d->arch.hvm.uc_*, wants to move into the vmx union too.


hvm_prepare_vm86_tss() is rather different.  It, ultimately, is because
of limitations in early VT-x and it's probably fine to move too,
although the infrastructure surrounding it has bigger changes needed.

~Andrew