Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Wed, 13 Sep 2023 15:54:54 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc:     ankita@nvidia.com, maz@kernel.org, oliver.upton@linux.dev,
        catalin.marinas@arm.com, will@kernel.org, aniketa@nvidia.com,
        cjia@nvidia.com, kwankhede@nvidia.com, targupta@nvidia.com,
        vsethi@nvidia.com, acurrid@nvidia.com, apopple@nvidia.com,
        jhubbard@nvidia.com, danw@nvidia.com,
        linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/2] KVM: arm64: allow the VM to select DEVICE_* and
 NORMAL_NC for IO memory
Message-ID: <ZQIFfqgR5zcidRR3@nvidia.com>
References: <20230907181459.18145-1-ankita@nvidia.com>
 <20230907181459.18145-3-ankita@nvidia.com>
 <ZP8q71+YXoU6O9uh@lpieralisi>
 <ZP9MQdRYmlawNsbC@nvidia.com>
 <ZQHUifAfJ+lZikAn@lpieralisi>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZQHUifAfJ+lZikAn@lpieralisi>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?235szihIBF41HvT6aij6PFcMjXvYBQjsx157UIeahSPVvZYOz1yfRYS+GERJ?=
 =?us-ascii?Q?2uS6xpkVGd6CRXROfys6V5Qlf6TUJFs8gTKtdCaNHMEoN/HFge76Crxo97Pa?=
 =?us-ascii?Q?RVQi3L6sH2KyJsFt4GTXUPKAJNEEKAigByVHN0HM/AXFYa7OTPHAcaYndUPQ?=
 =?us-ascii?Q?WaXpCWI09S3h8d5V5PoQrxiAZoygfrVHmNA1NFG5Rz0nFP+20U12EsIj3U65?=
 =?us-ascii?Q?WDuz+e7xIcCyER9HWD0NksuK1HJAOr4Yl8+J+EfFXOGcgS4yry832NMWs97r?=
 =?us-ascii?Q?fKvLWyjaCBSTkU+fPjxXthwvizL1ESayjaHwyZXe93mLvVnVjJo4dI5OehVS?=
 =?us-ascii?Q?31ACr5xDgjbqA8qIQMfvLF9ihxQxd/Tip4BYACRNGSj4OoC9Pa+5QVKXXjwK?=
 =?us-ascii?Q?vwVWmiiUuV7NXpz9etRCxPR12IwvptJ90FVXBpesP2b4IaZ9HOsRYxe1c7gl?=
 =?us-ascii?Q?D8TCg52KbvozZeM2ujpUgg7aGf3qimnr6ehdPTEbK3SFO979yonV1IUeL0pL?=
 =?us-ascii?Q?HEMt7M3bb/QC2wg5whoKiZGoBz6DwgJq+uGBZ2k5PAINd6ObUmOUBq6wMeqB?=
 =?us-ascii?Q?KO1+/LowILId9DN9e92urqxK9QgYLb+yVoNFQ5ugrzloAGEUGAGK8rBOLcrD?=
 =?us-ascii?Q?/PwAZlYD8r3995MvIGNnHTfK6bnE7S7sGwQfbnNNN0a0k3sih7mrJPkMsSat?=
 =?us-ascii?Q?teRRMLndlLVoaI1oH85RtgCaug3Iwk0hSaOr1vuuZ85NC24LWfwxoWU2Cny6?=
 =?us-ascii?Q?s8echst2BoL2Z3cyQoSsIwa47tyOIZZ4cICberluXI2JIfsy288FPcRgp4Sb?=
 =?us-ascii?Q?hKdOVpjNsZcFaK4/owgTT4sL/oZbJvaqo6tKHo0hjxMnfUZIKmlcZ1FQOs9T?=
 =?us-ascii?Q?wznGpg9wrOxXunE5aNgDbrGADMn6BqCmxkIquJzb+wMUUJT4LWXmsL48agTC?=
 =?us-ascii?Q?EXEcqzpE15FBpF6tPCo3pAUazwqwef4t81ANHfXm39GnUdZHoiMszl6cqRiP?=
 =?us-ascii?Q?9IgmE7RCDK6QqkBY6P+bPM22YjgsdrykJ37no5d3LFD4yXiw4gxyO1lZiyOf?=
 =?us-ascii?Q?+qgo1CEbImen6U0mvW9RhLY/WO4vdiQ/90jfrr9MKpJzkMbBzR7O3B7tw/B6?=
 =?us-ascii?Q?MnsL/UQlLSUczHWzdQUHeuQFuAYy6dCPw8hldv8TNfMD/bqtSpNA6f6SsD42?=
 =?us-ascii?Q?B7DM+cf5Au3NPHfza29s/hcCdg2dZF2sq8kZaauuOXaUR53yOpeVJKG+msQg?=
 =?us-ascii?Q?pLyyxgRcoS17Ktqbu3RmgQ3IjvljErddrMpntGkxqnjINeSDeicoBJ1+NDX3?=
 =?us-ascii?Q?KTSLseXU/OFuB/UExZtH9OiZnKe/9dQLqKnjlesGq2JeiUHqoaY0IZflWLYC?=
 =?us-ascii?Q?fxYGd8MSjqxsBg6cRWlcT2qblZMoIWBAQTxvIljg+I6LQdQBNEelkq6qUj7p?=
 =?us-ascii?Q?P9iAteZREKdltxftw/8s/PNXnEupMzMoezZ360oVMIWJvXWEaRRdBTJQcHRd?=
 =?us-ascii?Q?tNilw5IN01jRk9vdJgMwg+TaXDD2KWcQOJDIGkl/u/FK3ewyRQbXkxs+uvAp?=
 =?us-ascii?Q?tS4NM8TrkKmS41O00KAEX853bT25piJCrCpmLOlD?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 472c9b6f-d452-4392-8e39-08dbb48aebfa
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2023 18:54:56.3383
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: KgiS6lquW3gxnk3wWi7Se1tmkmUMYicC9Y+u9JNX1AqdLPfroypQ2XYPRhLOJHtx
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB7005
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Wed, 13 Sep 2023 11:55:07 -0700 (PDT)
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email

On Wed, Sep 13, 2023 at 05:26:01PM +0200, Lorenzo Pieralisi wrote:
> > > I understand that's the use case you are after but this change is
> > > targeting all VMs, it must be clear.
> > > 
> > > Then WC and mapping to PCI TLPs, either you describe that in details
> > > (NormalNC vs device-nGnRE and resulting SystemBus<->PCI transactions) or
> > > you don't describe it at all, as it stands I don't know how to use
> > > this information.
> > 
> > How about another pargraph:
> > 
> >  KVM prevents all VMs (including Linux) from accessing NORMAL_NC
> >  mappings, which is how Linux implements pgprot_writecombine(). This
> >  prevents using this performance optimization within VMs.
> > 
> > I don't think we need to go into details how it works beyond that it
> > requires NORMAL_NC.
> 
> I think it is worth summarizing the discussion that led to this change,
> I can write something up.

We tried here, in short the reason we all understood it was like this
today is because there was a belief that DEVICE_nGnRE allowed
fewer/none uncontained failures than NORMAL_NC.

AFIACT it turns out the specs are unclear and actual real world IP
from ARM does not behave this way. We learned that at best they are
equally unsafe, even perhaps NORMAL_NC is bit safer.

What makes it safe in real chips is not the unclear specification, or
the behavior of the ARM IP to generate uncontained failures, but
because the combination of all IP in the platform never triggers an
uncontained error anyhow.

For instance PCIe integration IP does not transform PCIe TLP failures
into uncontained errors. They generate all ones data on the bus
instead.

There is no spec that says this should happen, it is just what people
do - c&p from Intel.

On top of that we see that server focused designs built to run VMs
have put in the RAS work to ensure uncontained errors can't exist and
truely plug this hole.

Thus, at the end of the day the safety of KVM and VFIO is effectively
an unknowable platform specific property no matter what choice we make
in SW here. Thus let's make the choice that enables the broadest VM
functionality.

> > > > Fortunately real platforms do tend to implement this.
> 
> Is it possible please to describe what "this" is in details ?

"prevent uncontained errors for DEVICE_* and NORMAL_NC access"
 
> What does "real platforms" mean ?

Actual real world deployments of VFIO and KVM in production that
expect to be safe from uncontained errors.

> Let's describe what HW/SW should be implemented to make this
> safe.

The platform must not generate uncontained errors :)

> I can write up the commit log and post it if I manage to summarize
> it any better - more important the review on the code (that was already
> provided), I will try to write something up asap.

Thank you!

Jason