Re: [PATCH 6/6] x86/boot: Expose MSR_ARCH_CAPS data in guest max policies

From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 6/6] x86/boot: Expose MSR_ARCH_CAPS data in guest max policies
Date: Tue, 16 May 2023 16:53:35 +0200	[thread overview]
Message-ID: <22a6bd70-887e-da72-ccff-16b3627463c3@suse.com> (raw)
In-Reply-To: <b1c56e56-90cc-0f37-4c8a-df1217339e59@citrix.com>

On 16.05.2023 16:16, Andrew Cooper wrote:
> On 16/05/2023 3:06 pm, Jan Beulich wrote:
>> On 16.05.2023 15:51, Andrew Cooper wrote:
>>> On 16/05/2023 2:06 pm, Jan Beulich wrote:
>>>> On 15.05.2023 16:42, Andrew Cooper wrote:
>>>> Further is even just non-default exposure of all the various bits okay
>>>> to other than Dom0? IOW is there indeed no further adjustment necessary
>>>> to guest_rdmsr()?
>> With your reply further down also sufficiently clarifying things for
>> me (in particular pointing the one oversight of mine), the question
>> above is the sole part remaining before I'd be okay giving my R-b here.
> 
> Oh sorry.  Yes, it is sufficient.  Because VMs (other than dom0) don't
> get the ARCH_CAPS CPUID bit, reads of MSR_ARCH_CAPS will #GP.
> 
> Right now, you can set cpuid = "host:arch-caps" in an xl.cfg file.  If
> you do this, you get to keep both pieces, as you'll end up advertising
> the MSR but with a value of 0 because of the note in patch 4.  libxl
> still only understand the xend CPUID format and can't express any MSR
> data at all.

Hmm, so the CPUID bit being max only results in all the ARCH_CAPS bits
getting turned off in the default policy. That is, to enable anything
you need to not only enable the CPUID bit, but also the ARCH_CAPS bits
you want enabled (with no presents means to do so). I guess that's no
different from other max-only features with dependents, but I wonder
whether that's good behavior. Wouldn't it make more sense for the
individual bits' exposure qualifiers to become meaningful one to
qualifying feature is enabled? I.e. here this would then mean that
some ARCH_CAPS bits may become available, while others may require
explicit turning on (assuming they weren't all 'A').

But irrespective of that (which is kind of orthogonal) my question was
rather with already considering the point in time when the CPUID bit
would become 'A'. IOW I was wondering whether at that point having all
the individual bits be 'A' is actually going to be correct.

Jan