[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 16 May 2023 16:53:35 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=daInJN88i+p1YQGyc6eg9rrply3P7vvIgfvu63l1Sos=; b=dZZYwrVXfmVUpUFnhALZeOztQr5Fdo80ebdIbZweHW4xFBuwBXMXE0Bn/r4kwh+UtUw04Q1TS3hZEQ6RlRqH7QjIDSxegBZCB6zBYSXXlMpFTGNM5kf9RfOeBcp9jTNrASX6DzM79qK8otzB/Y0/vdxNXFJYN2OthcDOzNZ216KjM6UHq0Qk/jFP4sOCRHoK4vfyGyzaquc22IPo64IA5ghbyDMkiT1tOJ9P/GaIjISjywaZsdA5i6Ywk8+xvhoTUev+tvqKPsqsd+TFGjBZw3QK265MOqSALEI6H6WLSaBLZEps3k9cuvqpeoZmETn7IGPvKa40uk1NBM3w7UT2Pw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S+u7KO4cXrHRU5kX4NKHs+4rdAaIeYwJvAbEti/vi+gTcJrmrYq2Kb1FwHETnKEnWJOopSVnfM9t1yUimuTkKBCgH9+UP35oSO+6ia1D+DdUpezxWK+tcWFckZluEeb3zRamaQB1kWhhlXm0eXIWpwRaVSHa+Ws88zPKUj8LRBvchZAW9F4Jmp7rlE2SuP5fqcCKpMUpDFcCpDDEldaD7HJ1TEvNCQZa7/hUvbBMMC+Wbgh/ifGR/BRZYlK6CYsQDp0g7nxbvoAnG0sr3fosQ4Udy4n/6PU3nLGD7XMiKFOPXvIjArWj+2kORgxXvLrOyzDIPcyK5EsnlLZwgtXETg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 16 May 2023 14:53:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.