[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Avoid dom0/HVM performance penalty from MSR access tightening
- To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Wed, 23 Feb 2022 17:31:53 +0100
- 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=+Tg4BZHzs8/tGsoflF5x3K6sr4inZ33dxpzy5J8Eeyc=; b=kuhTAoAIpnDcEdh62qiARK3Qg0RE9EJpD2Zw4Vb3ZadG3sqGhDD/ijEnKE1oC56XGMMAKurVUuckik719tWj8bi6hphJLg73AopQ/xY8tsSCPgv5XrIIOqQXdA9q3WnhyR7HUj1Zhx97GIwUsfH6ElYifju7BwMef+lS2IM0wa+85b41/y84Nt3klv3aN8bCa665uaUR4fdVl6KD6IsLjdiiTWdIdJ/OS8TxQRuKb2HZL4eE3If3Ck3016epbplglrIKyKhn4y0ZPI4K516SM5t5C8r0+YLu7bWw1079BIKwJVsuHEyDWnihO5CPmrrFpUyiAq2eUnZg5S6JRx+7QQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XsdEFtuuUWHdRZ2rRDw9qPEjqhQ1qMA38Rq/A/h/GUZH5CKqOiDQw2//69HKncESFSGqRYyMGQdJ+m4b52qdCaSOEs0DU02WJ5hjimt2NUI2C8aKwLaPZJOWamMR9Vnj1EtkwGeyOXowv4pvuuCdHBK8ALaczDUXgF1AKxZbeY91EftfnWwMl8Jn0/hasEvB0STrUQ1HKWbPEh0MknNJK8G03L8bG76yAG6e1P76jzMMEmXhw3HIRufE69u5u7yu2EnzNnflmjziNJIerQj2rg1vQZJdSHgi40mduAvsB2mKvQgZXFDoZ5Ad7/36lbJyEfgNV8qvwSto64qAhgkuug==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Alex Olson <this.is.a0lson@xxxxxxxxx>
- Delivery-date: Wed, 23 Feb 2022 16:32:02 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 23.02.2022 17:11, Roger Pau Monné wrote:
> On Wed, Feb 23, 2022 at 09:38:56AM -0600, Alex Olson wrote:
>> 1) For conditions in which MSR registers are writeable from PV guests (such
>> as
>> dom0), they should probably be readable well, looks like
>> MSR_IA32_THERM_CONTROL
>> is currently one of a small number of "unreadable" but writeable
>> MSRs. Otherwise seemingly valid read-(check/modify)-write operations will
>> behave incorrectly under Xen.
>
> So it's one of those MSRs that's only writable when dom0 has it's
> vCPUs pinned. We could allow dom0 to read from it in that case (that's
> an oversight of the MSR handling rework), but it would seem better to
> just remove access to it altogether: it's bogus to allow dom0 to play
> with the MSR in the first place IMO, and it won't really solve issues
> like the one reported here unless dom0 vCPUs == pCPUs and all are
> pinned, so that dom0 can fix the MSR in all CPUs.
Dropping this is imo only legitimate if we decide to do away with
"cpufreq=dom0-kernel" and alike. This limited access permission to
certain MSRs was largely if not exclusively to make this extended
Dom0 control work (which as a prereq took pinning Dom0's vCPU-s).
Jan
|
