[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 02/11] x86: Reject CPU policies with vendors other than the host's
- To: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Thu, 27 Nov 2025 20:15:46 +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=X1/Cch735HsmSXp1A6klo1Ajd+EVV4F3T+aLHoCWSJg=; b=ZTTUhrcY3KSNN+leGYinRWhVVkzFf08YFCkU2Fl832TSFz0aHBdW0h6lGsf41D01nmri9EapRAIMJqTNAmy+0QhuD9vBnuTXqI6J2SoD58nvfksl5o3B5USedLqIbcXs3G90Q1e1W+zjVxkNjl36cypckZnm90JS2KC0E34bTKcbHy6YhZuT6jkXkvH1BdZyoylnrr3IjGjGo6t5LkcdGbR6Vvqskm/u6WHH+hn1Ncx/wT8sxJWSJWBqxkULMuOMKyrrpYFOOMfnY5/3wwj5nQ8CdprHQE8JQVeePzHe9SvqkZ7RMnkT40CRRlfnxXosfT+eHjCWekOCrKxfLiDdew==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ItJZUW/zrhJzxKhyATOy+Rk52awa6fArRSyhD/QHwjfzpeB5JbN6s7r5o3STRi1kSZqA6PI7pdO722jCwHOZKaXH13OVVjRBS9XHS3aCfGCT7BN9JnuKvIE0Ntx0Tm82VnBgHAeCzhemah2m2vLesGS0XcsI+DFO7qfVRltGP6wOJ6BenBR+EVyrMaAl42qzFv9NqigQ1as4ONHyNgecVqLlFfBVGBY77XqL3M39b28YfLaBPuId8vBwAKHprQM87RFoBM1+Y6qZJX6VwrS8i9IVIFUCHVB67YUkeAfuJH1cB3rGNxSFUD1zlm8B1gQaDA1MhoRKXe6tsw4oI+ebVQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: andrew.cooper3@xxxxxxxxxx, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Jason Andryuk <jason.andryuk@xxxxxxx>, Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
- Delivery-date: Thu, 27 Nov 2025 20:16:06 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 26/11/2025 4:44 pm, Alejandro Vallejo wrote:
> While in principle it's possible to have a vendor virtualising another,
> this is fairly tricky in practice. Not doing so enables certain
> optimisations with regards to vendor checks in later patches.
>
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>
> ---
> I originally had a Kconfig option to allow cross-vendor virt and
> conditionally disable the check on policy compatibility. In practice,
> I suspect there's 0% of people that would want that, so I decided to
> simply remove it altogether. Happy to put it back if there's anyone
> interested.
We've debated dropping cross-vendor support several times.
Prior to speculation, it was actually the case that PV guests worked
fairly well (Xen abstracts away the details surprisingly well), and HVM
functioned to a first approximation (emulating the SYS* instructions is
horrible).
After speculation, there's no hope in hell of getting a viable VM in a
cross-vendor environment, so we should drop it.
In addition to this hunk, you'll want to drop is_cross_vendor(),
should_emulate logic in hvm_ud_intercept(), and the cross-vendor aspect
of determining #UD interception in {svm,vmx}_cpuid_policy_changed().
Also, I think you can clean up MSR_IA32_PLATFORM_ID / MSR_AMD_PATCHLEVEL
in guest_rdmsr() which have some pretty well hidden is-cross-vendor checks.
Also you'll want a note in CHANGELOG.md.
I'd also suggest splitting it out of this series. It's quite different
to the rest of the series.
~Andrew
|
