[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/ept: limit calls to memory_type_changed()
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Tue, 27 Sep 2022 10:40:41 +0200
- 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=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=yrXc5pGA7NhHOUZaCl5GAaR0WyhyFfALLRJZrswc+1g=; b=kpJ4QImhAh54u+w8x1lKHzeKa7bEXsuCXVoHt9uGV7DU1DAslacHft8u2gxoD29id06e3LoblmE84uHAnF8WxCK5TzHETK6oXvScjnCSWunjYHBYBmXZJ4cAgJcCkNCaot7Kg/x93KI4Psd21/x2aIu4SFs9WKubStBeEKGyUZohljDnJit/RDkhWaf8aQsJ9FW1KJNWPGzOcaM/QGTOIfsWFB3nzEk3zHEkwQ33eA9mUi1xAqHodRgBePbKbIrJ7ipZmHgl3B8UW0dPX0F9QBaCz191v9DW3YCs1UUPrYgyg/UM4J+hM9d9SHEWGJBi6YOVQ9RbdmB5wyOOK8UIMQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GyjHC4v+P76LQgddVtRbD2oteMZwGWOnK82SRgJKwhSH4mseeKczISUQ63aipEaxOzrkIn2PtQhI3Zv/2UHl8CS7TO/kLb5qFyRdF+fJ85R2TM14ODxvLO4kWQ5lwH2QDmCJFHsByQsTJgOwrDXk0tgVa0Kb4MAdA31dmMT5ISx2g0pF9NZvNUWp+QEAiwRY0ZED1AZbdxplu0M7+rtUVerRSZNdX3HII9SKftuRFCYyTybQkrnjm1zCTsIAjbRsV8JQKav/W7cg4kvlIrz+vHzRWkVhheOht4IQXBoA2SB8VgvRblQzpIXPjRaouA1+h4WjvBaHYh2AaX+zeh2Iww==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Tue, 27 Sep 2022 08:41:08 +0000
- Ironport-data: A9a23:ijRasK2GQIE+Su5hB/bD5RBwkn2cJEfYwER7XKvMYLTBsI5bpzMBn GsYWm2OOK2LY2SkedwiOdvk8EkBupPcm9FqSwtlpC1hF35El5HIVI+TRqvS04F+DeWYFR46s J9OAjXkBJppJpMJjk71atANlVEliefSAOKU5NfsYkhZXRVjRDoqlSVtkus4hp8AqdWiCkaGt MiaT/f3YTdJ4BYpdDNPg06/gEk35q6q6WlH5gVWic1j5zcyqVFEVPrzGonpR5fIatE8NvK3Q e/F0Ia48gvxl/v6Ior4+lpTWhRiro/6ZWBiuFIPM0SRqkEqShgJ+rQ6LJIhhXJ/0F1lqTzTJ OJl7vRcQS9xVkHFdX90vxNwS0mSNoUekFPLzOTWXWV+ACQqflO1q8iCAn3aMqUJ1t5pWj9Dy MZbEx41QBKxldiK2IikH7wEasQLdKEHPas5k1Q5lXT8MqxjRprOBaLX+dVfwTE8wNhUGurTb NYYbjwpawncZxpIOREcD5dWcOWA3yGjNWEH7g/I4/NvvgA/zyQouFTpGMDSddGQA91cg26Tp 37c/nS/CRYfXDCa4Wreoyn217SX9c/9cKUOL52n99tguWewx0cwNR86b1SD/fbs3yZSXPoac ST44BEGr6I/6UiqRdnVRACjrTiPuRt0c8VUO/037keK0KW8ywSEAmkJSBZRZdpgs9U5LRQxz UOAld7tAT1psZWWRGib+7PSqim9UQAFIGlHaSIaQA8t59j4vJp1nh/JVsxkEqO+kpvyAz6Y/ tyRhC03hrFWiNFR0ay+pAjDm2j1/sWPSRMp7ALKWG7j9hl+eIOue42v7x7c8OpEK4GaCFKGu RDohvSj0QzHNrnV/ATlfQnHNOjBCyqtWNEEvWNSIg==
- Ironport-hdrordr: A9a23:m87UTqlNk9ZuPM8bt7NqCxrodi3pDfO3imdD5ihNYBxZY6Wkfp +V8cjzhCWftN9OYhodcLC7V5Voj0mskKKdxbNhRYtKOzOWw1dATbsSlLcKpgeNJ8SQzI5gPM tbAstD4ZjLfCJHZKXBkXaF+rQbsb66GcmT7I+xrkuFDzsaDZ2Ihz0JdjpzeXcGIDWua6BJdq Z1saF81kedkDksH7KGL0hAe9KGi8zAlZrgbxJDLxk76DOWhTftzLLhCRCX0joXTjsKmN4ZgC D4uj28wp/mn+Cwyxfa2WOWx5NKmOH5wt8GIMCXkMAaJhjllw7tToV8XL+puiwzvYiUmR8Xue iJhy1lE9V46nvXcG3wiRzx2zP42DJr0HPmwU/wuwqXneXJABYBT+ZRj4NQdRXUr2A6ustn7a 5N12WF87JKEBLphk3GlpT1fiAvsnDxjWspkOYVgXAae5AZcqVtoYsW+14QOIscHRj99JssHI BVfYzhDc5tAB2nhk3izyhSKITGZAVyIv7GeDlJhiWt6UkYoJgjpHFoh/D2nR87heAAotd/lq b5259T5cFzp/8tHNxA7dg6MLqK40z2MGbx2TGpUCPaPZBCHU7xgLjKx5hwzN2WWfUzvegPcd L6IRhliVI=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Tue, Sep 27, 2022 at 08:35:20AM +0200, Jan Beulich wrote:
> On 26.09.2022 17:58, Roger Pau Monné wrote:
> > On Mon, Sep 26, 2022 at 05:36:41PM +0200, Jan Beulich wrote:
> >> On 26.09.2022 17:25, Roger Pau Monné wrote:
> >>> Correction: the Arm memory_type_changed() needs to stay, as
> >>> iomem_{permit,deny}_access() is common code.
> >>
> >> Right, or we'd need some other arch abstraction. (I wonder whether
> >> long term Arm can actually get away without this. Even on the AMD side
> >> of x86 I don't think it's quite right that adding/removing of MMIO
> >> ranges has no effect on the memory type of accesses.)
> >
> > IIRC there's no way for the hypervisor to infer cache attributes on
> > AMD SVM for NPT entries, but maybe I'm missing something. Guest MTRRs
> > settings are completely ignored for AMD guests.
>
> Right, as documented: "Note that there is no hardware support for guest
> MTRRs; the VMM can simulate their effect by altering the memory types
> in the nested page tables." That's something we imo should do, but which
> I don't think we actually do (see p2m_type_to_flags()). We respect the
> PAT bit when splitting large pages, but I don't think we ever set the
> bit when making new / updated entries.
>
> > I'm not able ATM
> > however to find in the AMD PM how effective cache attributes are
> > calculated when using NPT however. I would guess host MTRR + guest
> > PAT?
>
> First guest and host PAT are combined, then the result is combined with
> (host) MTRR. See the tables in the "Nested Paging" sub-section "Combining
> Memory Types, MTRRs". Of course things are quite a bit more limited (but
> also simpler) in shadow mode.
Thanks, so we could indeed do something similar as to what we do for
Intel and set a cache attribute in the nested page tables, at which
point we would need epte_get_entry_emt() to be not EPT specific
anymore.
I've created:
https://gitlab.com/xen-project/xen/-/issues/88
To have some reminder of this pending work, or else I would forget.
Thanks, Roger.
|
