Re: [PATCH v1 2/6] nestedsvm: Adjust L2's DR intercept when adjusting L1

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 26/05/2026 1:40 pm, Ross Lagerwall wrote:
> If L2 accesses a debug register (like reading DR7) without L1 intercepting
> it, it locks up the vCPU. L0 intercepts VMEXIT_DR7_READ, which disables
> the intercept for L1 and then restarts L2 which re-executes the
> instruction and then this repeats indefinitely.
>
> Disable the intercept for the current VMCB if in guest mode to reflect
> what would happen if the VMCB were recreated via
> nsvm_vmcb_prepare4vmrun().
>
> Fixes: a59a7be91b61 ("nestedsvm: fix DRn handling")
> Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
> ---
>  xen/arch/x86/hvm/svm/svm.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 49fcdd906cf8..209edcba321a 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1657,6 +1657,8 @@ static void svm_dr_access(struct vcpu *v, struct cpu_user_regs *regs)
>  
>      TRACE(TRC_HVM_DR_WRITE);
>      __restore_debug_registers(vmcb, v);
> +    if ( nestedhvm_enabled(v->domain) && nestedhvm_vcpu_in_guestmode(v) )
> +        vmcb_set_dr_intercepts(v->arch.hvm.svm.vmcb, 0);
>  }
>  
>  static int cf_check svm_msr_read_intercept(

In Xen, debug registers are generally lazily.  When DR7 is not active
(which is expected to be ~100% of the time for a regular guest), there's
no point context switching DR{0..3} or (on AMD) the mask DBG Mask MSRs[1].

The debug registers are brought into sync if DR7 is active at context
switch, or any DR is accessed, or if a #DB is injected[2].

Now, in the logic above, you're saying that L1 didn't intercept DR which
is why we didn't Virtual VMExit earlier, so when we're bringing DRs into
sync we need to drop the L02 intercept too.  I think this is fine, but
it deserves a comment explaining that it's an artefact of Xen's lazy
context DR switching.

But, what about emulated MOV DR, or a #DB injection?  Those paths will
still end up being wrong.

I think this logic to alter the DR intercepts needs to be inside
__restore_debug_registers(), and needs to cross-check the L12 settings
before modifying L02.

~Andrew

[1] Although the Mask MSRs are currently inefficiently switched because
I didn't have time to optimise things after the last XSA fixing them.
[2] This path is wonky.  DRs should be made active irrespective of TF
because the #DB handler always needs to read DR6[3].
[3] This is a fun FRED bug, as the FRED #DB handler does not need to
read DR6, meaning that I think we need to force DR6 always to be in
sync.  And this gets extra complicated on Intel...