Received-SPF: pass (google.com: domain of linux-kernel+bounces-176400-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Sat, 11 May 2024 11:03:20 +0800
From: Chao Gao <chao.gao@intel.com>
To: "Li, Xin3" <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: <Zj7f+JWbVfIBIK8h@chao-email>
References: <20240207172646.3981-1-xin3.li@intel.com>
 <20240207172646.3981-13-xin3.li@intel.com>
 <ZjBiLDJ4SdQ0p5xm@chao-email>
 <SA1PR11MB6734740F9B6085E0997A4179A8E72@SA1PR11MB6734.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <SA1PR11MB6734740F9B6085E0997A4179A8E72@SA1PR11MB6734.namprd11.prod.outlook.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?AURRhxvqiFQOes+Ow/n/IoalxFlF38nYWSE2X2pRYmOIS2JWuVxfNkWO6nob?=
 =?us-ascii?Q?ZM+QXtOipQ5b17765gHAwwgJz4D85nIzXcLUdSpB8zHBJ+E8NP9dbG9my/FB?=
 =?us-ascii?Q?Sl6oU41574Wpe+ZsJpP/tdm5HIMI+V7oLPQ3mvus8kgh9eI6mms+KCyjrpnZ?=
 =?us-ascii?Q?UlPWnfuVE8WJWPsGQ7hVzbyJ7eFmfSrmf2PP2yjDKxOAATPk6hevH4mwdtyL?=
 =?us-ascii?Q?jHHTWoYzdWkUt4+6hMEuCe7Jli1mepzsjYR3Vul16rFOb6+dd5XkB9Dm5XN6?=
 =?us-ascii?Q?+C0/pT8DM2y+VBYXABPVfAj9rLwGF91nSXXD/g0yw3XpuVfBcEOySN41c65x?=
 =?us-ascii?Q?ewCvO9gWJMp76svOtA+LGgdBtxf36Ysu9z0w9Qos9cbpXGwKUnqGMUOkfyYu?=
 =?us-ascii?Q?wy2YhTXQ+g18VRiwoVqmMrSESvLtxyk8x0GODrJjiOm45hYXmy6xrmdbFuw0?=
 =?us-ascii?Q?V+Sdty9wnYIHkwME2Gp0wPLdrIxUreOrPzu/iaffR9IfGF00rgwuufHhCCpJ?=
 =?us-ascii?Q?sdxmB60+ne4aUq199C2P2Z8FUdmM8DZ4l3M73nG86ROzLpDUbcHa7VX1+uBA?=
 =?us-ascii?Q?TZXfVNhT8EkIlCWrcafzJQPLuftJApQ2BirnRaQfLUKeNV4dNDLqSZ/ocWu3?=
 =?us-ascii?Q?fKtxS1Of9bB1Mq8hFZqwR6twYg3UebSh6IlkAynhoZnXa5R/hy24cUveBUt0?=
 =?us-ascii?Q?gQaowR6+USdXlk+aWWYkm0bdAtE4qEqNi5/atmnd1bqH8o6+6iBFDrbAa5+S?=
 =?us-ascii?Q?QtYQRK9vvDSqNoqYzFJy+T5/DVivsqBAnRCgafiuRZvnSOXX8xkQpx+M5yYp?=
 =?us-ascii?Q?iWUkloo2EX+9GF/UiBEBxJABmECFSYFTUdmx583NEDdnaWPyYCBjEjBsA6WC?=
 =?us-ascii?Q?HG2uQdu2wP9YYyYvRZZYB2uPrXZHxRnVQK6J3XyySB0eUhe1tOsf0BPbOHqK?=
 =?us-ascii?Q?aTHZ3b3EqqDzsD2CRIaYQ3ZtC2KcRE0GgIhQgcVBG9p5uddTC3W9DsVlW57K?=
 =?us-ascii?Q?xkAjyWZoniDg8ixAjPIFL+GbNcB4vMQKV4p2YHNOSPIMTotkMZSgZFIY9lQ5?=
 =?us-ascii?Q?DbZuBq/MQwLFG14f8Tv6oKygZoFePKKmuE0uA6BWe7eEUaHtTwZMcxYkXcMu?=
 =?us-ascii?Q?mNzFKChc9tMq/SuS14h1IkxOPsSEz7Scf2Sh4d76AIdDGNOBQ+R6luS7VyI8?=
 =?us-ascii?Q?R8+QiJUn2WMU3Lzv1NugrvDolcfiAw1X47ovZnW9BBmI7jLC33Vdzw86GlZc?=
 =?us-ascii?Q?VkyHjq1jeWwQR7728CH8En6k9FhnYsuQae3AKEb3sl0hAGQbQvJYBokuCgQ+?=
 =?us-ascii?Q?ukqBBT8pRQ3kO7JJiiyh7NCOaLUkn00CunSXdDzL45AfXj+NDwBzRJAwruI8?=
 =?us-ascii?Q?PP/twalpL4VLq1iE7aBIVHn02yZA/9UyzYQzqvOcFEid6SJXeTh9+71GxNmA?=
 =?us-ascii?Q?lzaP3UVRrkJK2hFZuQjwUwLFznWXoVMYeX6o1FrUmC5zeGGE9EpQnPbCD/3n?=
 =?us-ascii?Q?GMy2KB55Nr1s6LQ7rl4Eme/SVJh9FNwI477cuF2stglxt6PRvbFjtf25K3LS?=
 =?us-ascii?Q?PEY/+FVB5nlKxhPcRmmh8zHpb8YpxHWunMFPFi/X?=
X-MS-Exchange-CrossTenant-Network-Message-Id: f6ccdc53-9d5d-4d37-685b-08dc7166f109
X-MS-Exchange-CrossTenant-AuthSource: CH3PR11MB8660.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2024 03:03:32.6382
 (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: ///kLhseuTSQ0RPy/moUnXDJ6iRiKrBnqVOAohLQnGAgxcKdBWLWU3cbKGtfyQH2UiShUe8yQOWK3ueZ1D+1Mw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6093
X-OriginatorOrg: intel.com

On Fri, May 10, 2024 at 05:36:03PM +0800, Li, Xin3 wrote:
>> >+               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.
>
>VMM should guarantee a FRED guest _sees_ consistent values in CR6/DR6
>and event data. If not it's just a VMM bug that we need to fix.

I don't get why VMM should.

I know the hardware will guarantee this. And likely KVM will also do this.
but I don't think it is necessary for KVM to assume L1 VMM will guarantee
this. because as long as L2 guest is enlightened to read event_data from stack
only, the ABI between L1 VMM and L2 guest can be: CR2/DR6 may be out of sync
with the event_data. I am not saying it is good that L1 VMM deviates from the
real hardware behavior. But how L1 VMM defines this ABI with L2 has nothing to
do with KVM as L0. KVM shouldn't make assumptions on that.