[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v1] x86/svm: Fix VMLOAD/VMSAVE state handling when using nested virt
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
- Date: Wed, 23 Sep 2026 15:37:23 +0100
- 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=wTO4s41TL6DXseZuSSKT4rCXXUTREqY6kYM3Ro3m/9M=; b=adLsNpiMJKPniLuu0G3cxx0hY8BNoUKU7Oy8VMU3YCupkUQyAsTTEuTTMck7Dsn68suETLymoKxYaPEe69ooF+rULTyq0FJi2hQRnpMOn2Aw5QNkfpI9mqAGtoKseON7+oJL1lXzsKLHMCTkOW1PiKfyyi6iIqQwplzGzyhmMA7qFnYPHMc3F6nEELlmieqWvTqf7ppIrY4Ry+6scj5LC66Qe2kIs1lPRmi0e1N5mCZjaOegId6VlDKIdTOPsJyFaBmdvqhfSJ+3FeAofy1UTxDJJf/VaSqpuTUEPOmGd7hI4L+RoCvTHBhc34ld0N0JBC5UI9W3RpHogfCE2kMz1A==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Mk6EmlHme4d7QuiKzZFEgXXgyr+Jtzp802UUrskyYAhuRKUKZwxxhDxseSl3b7RNf2yWAR9Ls0loFNDUeuw8FV3Dn4ryECbTx2mZqN4K1Z13b1OhIyVy6wbk/Yui6SVQiZizJ+uddi/4a9TR7UYrTCvpudtLXvZULzqxVYU3Jwf8n2VP2I8n1nJDIClIJ7kA30uLYEEe6kwkQhXjmkgF0yiLB5bpdUmG1eE529RE8t+/U00HxIUK/XHVS2VyUPsjyMcEB2aBo+fF+hYvh2bGfzRZds1ua1pwOr97MBL219wQ3wqLv229BV+ve90lk1ohy1w1kSquQvPtYquxGySpSA==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
- Authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger@xxxxxxxxxxxxxx>, Jason Andryuk <jason.andryuk@xxxxxxx>, Teddy Astie <teddy.astie@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Wed, 23 Sep 2026 14:37:44 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 9/21/26 12:21 PM, Jan Beulich wrote:
On 11.09.2026 17:12, Ross Lagerwall wrote:
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -444,30 +444,30 @@ static int svm_vmcb_restore(struct vcpu *v, struct
hvm_hw_cpu *c)
static void svm_save_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data)
{
- struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
+ struct vmcb_struct *n1_vmcb = vcpu_nestedhvm(v).nv_n1vmcx;
Here and elsewhere you assume that vcpu_nestedhvm() is legitimate to use
even in the non-nested case. I think that's heading in the wrong direction;
I think that a hypothetical mode with CONFIG_NESTED=n and the entire
struct nestedvcpu wrapped in #ifdef CONFIG_NESTED should still be possible
to put in place, without meaningful rearrangements or renaming besides the
adding of the respective #if{,n}def.
This assumption already exists, e.g. see svm_create_vmcb(), svm_destroy_vmcb(),
svm_dr_access().
If you would prefer not to introduce any new cases like this, I could introduce
a new macro, e.g.
#define vcpu_n1vmcx(v) (vcpu_nestedhvm((v)).nv_n1vmcb)
and then for the hypothetical CONFIG_NESTED=n, it would resolve to:
#define vcpu_n1vmcx(v) ((v)->arch.hvm.svm.vmcb)
Does that work for you?
Ross
|
