Received-SPF: pass (google.com: domain of linux-kernel+bounces-163283-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Tue, 30 Apr 2024 11:14:52 +0800
From: Chao Gao <chao.gao@intel.com>
To: Xin Li <xin3.li@intel.com>
CC: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, "linux-doc@vger.kernel.org"
	<linux-doc@vger.kernel.org>, "linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>, "seanjc@google.com" <seanjc@google.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>, "corbet@lwn.net"
	<corbet@lwn.net>, "tglx@linutronix.de" <tglx@linutronix.de>,
	"mingo@redhat.com" <mingo@redhat.com>, "bp@alien8.de" <bp@alien8.de>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>, "x86@kernel.org"
	<x86@kernel.org>, "hpa@zytor.com" <hpa@zytor.com>, "shuah@kernel.org"
	<shuah@kernel.org>, "vkuznets@redhat.com" <vkuznets@redhat.com>,
	"peterz@infradead.org" <peterz@infradead.org>, "Shankar, Ravi V"
	<ravi.v.shankar@intel.com>, "xin@zytor.com" <xin@zytor.com>
Subject: Re: [PATCH v2 12/25] KVM: VMX: Handle FRED event data
Message-ID: <ZjBiLDJ4SdQ0p5xm@chao-email>
References: <20240207172646.3981-1-xin3.li@intel.com>
 <20240207172646.3981-13-xin3.li@intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20240207172646.3981-13-xin3.li@intel.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?FySwc5MZKFZuUxKzdAg927sPmKy5IoCeHbUoGvZFzctwC9+y12soB0g+VDly?=
 =?us-ascii?Q?8twFey7VTkygZNu3/yl7dIYeyac9fdNf/qr+uBnNE/RpupT8bE3kGRYdzroh?=
 =?us-ascii?Q?NR41/W18o1xOr/hrrxZAU+9GECbSwg1j9fihOdS3RGQWELiPojm9cyDzr39p?=
 =?us-ascii?Q?Kbv0DfZtPMWlH3602eEN2SCPO+oCiI/nPcgP5ExxHAjbCmC24wJ/1w8MP/Qm?=
 =?us-ascii?Q?OasvHp2+/cxmACPO3tt+I8BE6AZBlvDGcohCpLg6/W4RrSW+izEz9XNaWl3J?=
 =?us-ascii?Q?Dedd8m/hNe4j/cKoz4jnx90jqg8hNRNAmx3mW1JmEC7hHxZtHjmJYa+qNW2h?=
 =?us-ascii?Q?YIp9W8kCiUR1Xu/GK1Aa2J5Pvw/uHrXyHk2WjrnZHgYlNx5vuFHDll8ZP7Kn?=
 =?us-ascii?Q?17oKQUUZdRjDT9/lmdH3YwmXU9yre1gjDnCfz8Vgy50xjhDEa6moF1AfbCGO?=
 =?us-ascii?Q?6xmRkE5NcrjxF9oqqaey4p5XpzXEm2coVOP+rUclb60HiXDHwE434EFXsclQ?=
 =?us-ascii?Q?AvGeDhih+ODSOOFUa8D5Mifhnhfo7GN/MRWtLRQ+l+fdt+LHLMBcKjAz7oCu?=
 =?us-ascii?Q?wogmbM3sub/pobAKKHYuRlFDQ67Tmg4iJwOGCeuE82GLj5roHTH/sOhGpX1/?=
 =?us-ascii?Q?ft/brn9dFNmXe3mYbx/5fLkXGFb/bCf2nZHwKN1RtVBeUAVtFoDYpja0Shw7?=
 =?us-ascii?Q?cOWFj5vd+RlNWVqgjb/wtjRYsiGYhS2N64lh7u85du6MJxOwtuQwjgqktnQ4?=
 =?us-ascii?Q?xNzDj0qIEmqQxp+D4MsNgeFzoyZ5hT0NWTldBHPfD7zZ5ZLALQbRxpal20Hc?=
 =?us-ascii?Q?4sUHzGe46OkDiNFe2fRgPjxRUST/NMwgdlovnSj7jMpXac5Q26h36B7hlhrQ?=
 =?us-ascii?Q?GjhbnMjaj++kREkbQuosEAliP5KVadr2f5IosqFaKQhxIXZcZmeq9ymDb0LI?=
 =?us-ascii?Q?0SvVyMgTbZpNdutFHNsCp6YXQcOHteIlwSACcC+k4aX0nsXqMZBITK60Q4mF?=
 =?us-ascii?Q?0DbOtH0uMVjh4o50MKaoE+NYayqdO48M1TwXaBKaWLY9RTC/mPBpbcRqzNL8?=
 =?us-ascii?Q?OwXB/64Z6Kd40k4Rl5IhdmqwqhJIznYdyHQFZFej4JVHRJWewqSdqLB+vpwO?=
 =?us-ascii?Q?d7494TmRpNvyIy5HpQbt2VTqT7fISVq1R8cDHR0okPg+d527dN9t5WRNNTmr?=
 =?us-ascii?Q?9pJ+r9WCVFDYipCdVTHZjS4vPWxlognbAwh1mVfF2MQnJ8TtbGsO8uokd6kA?=
 =?us-ascii?Q?mLdFICYdJysNB5H8UoDmNCynjy/jGnAKVAB2GZdg14WvPq9YDaFH6sR6DCay?=
 =?us-ascii?Q?02fC9UySgGnkuZZBS9rwgpuDqw1FxnZxuyYIVTCYw1bqWdEHKloQ8TSNawh5?=
 =?us-ascii?Q?WvY+e0KzxGXhz2rNlZrKKo8ZOY6NWaoIOxH2vYiF6XWG5AX3Zm3hxSGcw65T?=
 =?us-ascii?Q?EdFpGPC8oU0hl+fG+JleG784s0oxIJWxwjngWl/ts3my2dpik6X9UHeeedxU?=
 =?us-ascii?Q?1LEkvFZa7zaXS9z1f5bhdV56ANF0QM5d1lMI5ESB6R9Pi6yOSCzDw7kYYLQa?=
 =?us-ascii?Q?w/xepAETXrh930MzPzS/4SdCMqIZZb3/Za7lpHAg?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 9a884045-5967-4e6b-7bf4-08dc68c3ba46
X-MS-Exchange-CrossTenant-AuthSource: CH3PR11MB8660.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Apr 2024 03:15:03.6263
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: U9XjoENFgonPOf5NPjn2kYsjbVG6uqWAxO6ol04fOGln5KbNaZmR9ga9iUmI8/1u63w8f6kuk1jfRy9mhmKUlQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4681
X-OriginatorOrg: intel.com

>index ee61d2c25cb0..f622fb90a098 100644
>--- a/arch/x86/kvm/vmx/vmx.c
>+++ b/arch/x86/kvm/vmx/vmx.c
>@@ -1871,9 +1871,29 @@ static void vmx_inject_exception(struct kvm_vcpu *vcpu)
>                vmcs_write32(VM_ENTRY_INSTRUCTION_LEN,
>                             vmx->vcpu.arch.event_exit_inst_len);
>                intr_info |= INTR_TYPE_SOFT_EXCEPTION;
>-       } else
>+       } else {
>                intr_info |= INTR_TYPE_HARD_EXCEPTION;
>
>+               if (kvm_is_fred_enabled(vcpu)) {
>+                       u64 event_data = 0;
>+
>+                       if (is_debug(intr_info))
>+                               /*
>+                                * Compared to DR6, FRED #DB event data saved on
>+                                * the stack frame have bits 4 ~ 11 and 16 ~ 31
>+                                * inverted, i.e.,
>+                                *   fred_db_event_data = dr6 ^ 0xFFFF0FF0UL
>+                                */
>+                               event_data = vcpu->arch.dr6 ^ DR6_RESERVED;
>+                       else if (is_page_fault(intr_info))
>+                               event_data = vcpu->arch.cr2;
>+                       else if (is_nm_fault(intr_info))
>+                               event_data = to_vmx(vcpu)->fred_xfd_event_data;
>+

IMO, deriving an event_data from CR2/DR6 is a little short-sighted because the
event_data and CR2/DR6 __can__ be different, e.g., L1 VMM __can__ set CR2 to A
and event_data field to B (!=A) when injecting #PF.

And this approach cannot be extended to handle a (future) exception whose
event_data isn't tied to a dedicated register like CR2/DR6.

Adding a new field fred_xfd_event_data in struct vcpu has problems too:
fred_xfd_event_data gets lost during migration; strickly speaking, event_data
is tied to an exception rather than a CPU. e.g., the CPU may detect a nested
exception when delivering one and both have their own event_data.

I think we can make event_data a property of exceptions. i.e., add a payload2
to struct kvm_queued_exception. and add new APIs to kvm_queue_exception* family
to accept a payload2 and in VMX code, just program payload2 to the VMCS
event_data field if FRED is enabled. KVM ABI should be extended as well to pass
payload2 to userspace like how the payload is handled in
kvm_vcpu_ioctl_x86_get/put_vcpu_events.