[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 2/4] x86/hvm: Disable non-FEP cross-vendor handling in #UD handler
- To: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Fri, 23 Jan 2026 18:40:43 +0000
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0fz4wPS5udrYlnYBDJTD1OiXCF+tx0Wx0BbqzQz+xd4=; b=laepI447sqaNfyn/vW9l1B8YHAk8LFFt78CmfJVZHI9qVPzseUJ5G22CpB8Zp6hA1PWiwkwJjCNptWW7uCTcawaANytjU3QQe/0LGeUXNiUhqYmN/Acrd7nAXTR8iZPDkPe08WDeb5bMPRzNcCkYcdw8dHqRHBJzfie2iHpSUvq6wPCq42OXUQ/9yGFPAj8RTaYgoNJH/Tfki0J/DT/sV0o9n9G2aLO+PhlaQJbPZbqiW7hu57skvf9Q/7ZqqJ8veGyq2eJchPPFy18U4LMre3ZyFvVL6EZXlFBdamvPqFD0/FwfxiazlRa8wYkdnya78NOrfivagIloDhaBRynHDQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Uf4f1qZx9qNm4ZAu0cshiSmFJCQlX23NpZZFNI4Jc6PYnrVbqT/3q1oJzz/TO5G543AYaVGZLjfJ/SAbAia0s4CO2bRACPmOB8W/dLHmHsz6lunAx908KjFbN23RMff16xdW4dlxawXOkc0aA4EZQFyG/FbAm+n9/8jbPw8NrCCSK2dNIlphKFvDGlDpZat2NT/qokJewSY+NBh2Z2XvgtXL+h49pZ1YLF6MvC+gjqREjoOKI7Fr6ILQqWDa+31rJc+kfWMtCDiG/1yzvdCG8vD8J6Joal0+pOrEYI4pKEQqLs8lpPVLQMuRCMMM3nrf/BFPojTas5lDvEm4vRnqqQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Jason Andryuk <jason.andryuk@xxxxxxx>
- Delivery-date: Fri, 23 Jan 2026 18:41:00 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 40e4c71244..34e988ee61 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -797,8 +797,7 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu
> *v)
> const struct cpu_policy *cp = v->domain->arch.cpu_policy;
> int rc = 0;
>
> - if ( opt_hvm_fep ||
> - (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) )
> + if ( opt_hvm_fep )
> v->arch.hvm.vmx.exception_bitmap |= (1U << X86_EXC_UD);
> else
> v->arch.hvm.vmx.exception_bitmap &= ~(1U << X86_EXC_UD);
> @@ -4576,6 +4575,7 @@ void asmlinkage vmx_vmexit_handler(struct cpu_user_regs
> *regs)
> /* Already handled above. */
> break;
> case X86_EXC_UD:
> + BUG_ON(!IS_ENABLED(CONFIG_HVM_FEP));
> TRACE(TRC_HVM_TRAP, vector);
> hvm_ud_intercept(regs);
> break;
Again, nested virt makes this more complicated than to simply believe it
doesn't happen.
Also, more often than I'd like, I enable #UD interception for other
reasons, and I'd prefer that that doesn't get any harder than it does
right now.
In an ideal world I'd have already upstreamed the logic to decompose
double/triple faults...
~Andrew
|
