[PATCH v1] x86/nSVM: Expose the FlushByASID CPU Capability to L1 guests

[PATCH v1] x86/nSVM: Expose the FlushByASID CPU Capability to L1 guests

[Abdelkareem Abdelsaamad]

On the AMD platforms, the Xen hypervisor requires the FlushByASID CPU
capability to support HVM nested virtualization (see start_nested_svm).
Consequently, the L1 hypervisor must report FlushByASID CPU capability support
when intercepting CPUID instruction for the CPU feature from the L2 guest to
support nested virtualization levels beyond L1. Extend the exposed HVM CPU
policy to surface this CPU feature support for the guests.

While at it remove the dangling `exitinfo1 = ns_vmcb->exitinfo1;` assignment
inside the nested exit handling of svm_vmexit_handler().

Signed-off-by: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
---
Testing:
 - Using a locally developed XTF test to call cpuid_edx(0x8000000aU);
   - without the change, EDX returns 0x4AB (the FlushByASID 6th bit is not
     set).
   - with the change, EDX returns 0x4EB (the FlushByASID 6th bit set).
 - CI tests:
https://gitlab.com/xen-project/people/aabdelsa/xen/-/pipelines/2757859821
---
 xen/arch/x86/cpu-policy.c  | 1 +
 xen/arch/x86/hvm/svm/svm.c | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c
index eddcd9778f..48a3185eed 100644
--- a/xen/arch/x86/cpu-policy.c
+++ b/xen/arch/x86/cpu-policy.c
@@ -843,6 +843,7 @@ static void __init calculate_hvm_max_policy(void)
         p->extd.raw[0xa].d &= ((1u << SVM_FEATURE_NPT) |
                                (1u << SVM_FEATURE_LBRV) |
                                (1u << SVM_FEATURE_NRIPS) |
+                               (1u << SVM_FEATURE_FLUSHBYASID) |
                                (1u << SVM_FEATURE_PAUSEFILTER) |
                                (1u << SVM_FEATURE_DECODEASSISTS));
         /* Enable features which are always emulated. */
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 38c61db1d7..2f62981305 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2561,7 +2561,6 @@ void asmlinkage svm_vmexit_handler(void)
          * nestedsvm_check_intercepts() expects to have the correct
          * exitinfo1 value there.
          */
-        exitinfo1 = ns_vmcb->exitinfo1;
         ns_vmcb->exitinfo1 = vmcb->exitinfo1;
         nsret = nestedsvm_check_intercepts(v, regs, exit_reason);
         switch ( nsret )
-- 
2.53.0

Re: [PATCH v1] x86/nSVM: Expose the FlushByASID CPU Capability to L1 guests

[Jan Beulich]

On 13.08.2026 16:56, Abdelkareem Abdelsaamad wrote:
> On the AMD platforms, the Xen hypervisor requires the FlushByASID CPU
> capability to support HVM nested virtualization (see start_nested_svm).
> Consequently, the L1 hypervisor must report FlushByASID CPU capability support
> when intercepting CPUID instruction for the CPU feature from the L2 guest to
> support nested virtualization levels beyond L1. Extend the exposed HVM CPU
> policy to surface this CPU feature support for the guests.

While the change makes sense, I have to admit that I consider it a stretch
to justify changes by multi-level nesting, when a single level of nesting
is in need of a lot of work to actually behave sensibly. Further, "to
support nested virtualization levels beyond L1" looks pretty Xen-centric:
Other hypervisors may permit this without the feature.

> While at it remove the dangling `exitinfo1 = ns_vmcb->exitinfo1;` assignment
> inside the nested exit handling of svm_vmexit_handler().

Unrelated adjustments to somewhat nearby or related code are generally
okay, but here you're touching a different file and entirely unrelated
code. I think the two changes want splitting.

> Signed-off-by: Abdelkareem Abdelsaamad <abdelkareem.abdelsaamad@citrix.com>
> ---
> Testing:
>  - Using a locally developed XTF test to call cpuid_edx(0x8000000aU);
>    - without the change, EDX returns 0x4AB (the FlushByASID 6th bit is not
>      set).
>    - with the change, EDX returns 0x4EB (the FlushByASID 6th bit set).

And the CPUID test that XTF has wasn't suitable?

Finally: Can you please drop Roger's old email address that you still
had on Cc?

Jan