From: Lorenzo Pieralisi <lpieralisi@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>, Jason Gunthorpe <jgg@nvidia.com>,
ankita@nvidia.com, maz@kernel.org, oliver.upton@linux.dev,
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
Date: Fri, 13 Oct 2023 17:28:10 +0200 [thread overview]
Message-ID: <ZSliChc3poZNM4f9@lpieralisi> (raw)
In-Reply-To: <ZSlBOiebenPKXBY4@arm.com>
On Fri, Oct 13, 2023 at 02:08:10PM +0100, Catalin Marinas wrote:
[...]
> Yes, we end up with mismatched aliases but they only matter if the VMM
> also accesses the I/O range via its own mapping. So far I haven't seen
> case that suggests this.
>
> > > Things can go wrong but that's not because Device does anything better.
> > > Given the RAS implementation, external aborts caused on Device memory
> > > (e.g. wrong size access) is uncontainable. For Normal NC it can be
> > > contained (I can dig out the reasoning behind this if you want, IIUC
> > > something to do with not being able to cancel an already issued Device
> > > access since such accesses don't allow speculation due to side-effects;
> > > for Normal NC, it's just about the software not getting the data).
> >
> > I really think these details belong in the commit message.
>
> I guess another task for Lorenzo ;).
I will do, I start wondering though whether this documentation belongs
in this commit log only or at Documentation/arch/arm64 level (or both),
I am pretty sure this thread can turn out quite useful as a reference
(it is for me) if we manage to summarize it that would benefit
everyone.
Lorenzo
WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lpieralisi@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>, Jason Gunthorpe <jgg@nvidia.com>,
ankita@nvidia.com, maz@kernel.org, oliver.upton@linux.dev,
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
Date: Fri, 13 Oct 2023 17:28:10 +0200 [thread overview]
Message-ID: <ZSliChc3poZNM4f9@lpieralisi> (raw)
In-Reply-To: <ZSlBOiebenPKXBY4@arm.com>
On Fri, Oct 13, 2023 at 02:08:10PM +0100, Catalin Marinas wrote:
[...]
> Yes, we end up with mismatched aliases but they only matter if the VMM
> also accesses the I/O range via its own mapping. So far I haven't seen
> case that suggests this.
>
> > > Things can go wrong but that's not because Device does anything better.
> > > Given the RAS implementation, external aborts caused on Device memory
> > > (e.g. wrong size access) is uncontainable. For Normal NC it can be
> > > contained (I can dig out the reasoning behind this if you want, IIUC
> > > something to do with not being able to cancel an already issued Device
> > > access since such accesses don't allow speculation due to side-effects;
> > > for Normal NC, it's just about the software not getting the data).
> >
> > I really think these details belong in the commit message.
>
> I guess another task for Lorenzo ;).
I will do, I start wondering though whether this documentation belongs
in this commit log only or at Documentation/arch/arm64 level (or both),
I am pretty sure this thread can turn out quite useful as a reference
(it is for me) if we manage to summarize it that would benefit
everyone.
Lorenzo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-10-13 15:28 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-07 18:14 [PATCH v1 0/2] KVM: arm64: support write combining and cachable IO memory in VMs ankita
2023-09-07 18:14 ` ankita
2023-09-07 18:14 ` [PATCH v1 1/2] KVM: arm64: determine memory type from VMA ankita
2023-09-07 18:14 ` ankita
2023-09-07 19:12 ` Jason Gunthorpe
2023-09-07 19:12 ` Jason Gunthorpe
2023-10-05 16:15 ` Catalin Marinas
2023-10-05 16:15 ` Catalin Marinas
2023-10-05 16:54 ` Jason Gunthorpe
2023-10-05 16:54 ` Jason Gunthorpe
2023-10-10 14:25 ` Catalin Marinas
2023-10-10 14:25 ` Catalin Marinas
2023-10-10 15:05 ` Jason Gunthorpe
2023-10-10 15:05 ` Jason Gunthorpe
2023-10-10 17:19 ` Catalin Marinas
2023-10-10 17:19 ` Catalin Marinas
2023-10-10 18:23 ` Jason Gunthorpe
2023-10-10 18:23 ` Jason Gunthorpe
2023-10-11 17:45 ` Catalin Marinas
2023-10-11 17:45 ` Catalin Marinas
2023-10-11 18:38 ` Jason Gunthorpe
2023-10-11 18:38 ` Jason Gunthorpe
2023-10-12 16:16 ` Catalin Marinas
2023-10-12 16:16 ` Catalin Marinas
2024-03-10 3:49 ` Ankit Agrawal
2024-03-10 3:49 ` Ankit Agrawal
2024-03-19 13:38 ` Jason Gunthorpe
2024-03-19 13:38 ` Jason Gunthorpe
2023-10-23 13:20 ` Shameerali Kolothum Thodi
2023-10-23 13:20 ` Shameerali Kolothum Thodi
2023-09-07 18:14 ` [PATCH v1 2/2] KVM: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory ankita
2023-09-07 18:14 ` ankita
2023-09-08 16:40 ` Catalin Marinas
2023-09-08 16:40 ` Catalin Marinas
2023-09-11 14:57 ` Lorenzo Pieralisi
2023-09-11 14:57 ` Lorenzo Pieralisi
2023-09-11 17:20 ` Jason Gunthorpe
2023-09-11 17:20 ` Jason Gunthorpe
2023-09-13 15:26 ` Lorenzo Pieralisi
2023-09-13 15:26 ` Lorenzo Pieralisi
2023-09-13 18:54 ` Jason Gunthorpe
2023-09-13 18:54 ` Jason Gunthorpe
2023-09-26 8:31 ` Lorenzo Pieralisi
2023-09-26 8:31 ` Lorenzo Pieralisi
2023-09-26 12:25 ` Jason Gunthorpe
2023-09-26 12:25 ` Jason Gunthorpe
2023-09-26 13:52 ` Catalin Marinas
2023-09-26 13:52 ` Catalin Marinas
2023-09-26 16:12 ` Lorenzo Pieralisi
2023-09-26 16:12 ` Lorenzo Pieralisi
2023-10-05 9:56 ` Lorenzo Pieralisi
2023-10-05 9:56 ` Lorenzo Pieralisi
2023-10-05 11:56 ` Jason Gunthorpe
2023-10-05 11:56 ` Jason Gunthorpe
2023-10-05 14:08 ` Lorenzo Pieralisi
2023-10-05 14:08 ` Lorenzo Pieralisi
2023-10-12 12:35 ` Will Deacon
2023-10-12 12:35 ` Will Deacon
2023-10-12 13:20 ` Jason Gunthorpe
2023-10-12 13:20 ` Jason Gunthorpe
2023-10-12 14:29 ` Lorenzo Pieralisi
2023-10-12 14:29 ` Lorenzo Pieralisi
2023-10-12 13:53 ` Catalin Marinas
2023-10-12 13:53 ` Catalin Marinas
2023-10-12 14:48 ` Will Deacon
2023-10-12 14:48 ` Will Deacon
2023-10-12 15:44 ` Jason Gunthorpe
2023-10-12 15:44 ` Jason Gunthorpe
2023-10-12 16:39 ` Will Deacon
2023-10-12 16:39 ` Will Deacon
2023-10-12 18:36 ` Jason Gunthorpe
2023-10-12 18:36 ` Jason Gunthorpe
2023-10-13 9:29 ` Will Deacon
2023-10-13 9:29 ` Will Deacon
2023-10-12 17:26 ` Catalin Marinas
2023-10-12 17:26 ` Catalin Marinas
2023-10-13 9:29 ` Will Deacon
2023-10-13 9:29 ` Will Deacon
2023-10-13 13:08 ` Catalin Marinas
2023-10-13 13:08 ` Catalin Marinas
2023-10-13 13:45 ` Jason Gunthorpe
2023-10-13 13:45 ` Jason Gunthorpe
2023-10-19 11:07 ` Catalin Marinas
2023-10-19 11:07 ` Catalin Marinas
2023-10-19 11:51 ` Jason Gunthorpe
2023-10-19 11:51 ` Jason Gunthorpe
2023-10-20 11:21 ` Catalin Marinas
2023-10-20 11:21 ` Catalin Marinas
2023-10-20 11:47 ` Jason Gunthorpe
2023-10-20 11:47 ` Jason Gunthorpe
2023-10-20 14:03 ` Lorenzo Pieralisi
2023-10-20 14:03 ` Lorenzo Pieralisi
2023-10-20 14:28 ` Jason Gunthorpe
2023-10-20 14:28 ` Jason Gunthorpe
2023-10-19 13:35 ` Lorenzo Pieralisi
2023-10-19 13:35 ` Lorenzo Pieralisi
2023-10-13 15:28 ` Lorenzo Pieralisi [this message]
2023-10-13 15:28 ` Lorenzo Pieralisi
2023-10-19 11:12 ` Catalin Marinas
2023-10-19 11:12 ` Catalin Marinas
2023-11-09 15:34 ` Lorenzo Pieralisi
2023-11-09 15:34 ` Lorenzo Pieralisi
2023-11-10 14:26 ` Jason Gunthorpe
2023-11-10 14:26 ` Jason Gunthorpe
2023-11-13 0:42 ` Lorenzo Pieralisi
2023-11-13 0:42 ` Lorenzo Pieralisi
2023-11-13 17:41 ` Catalin Marinas
2023-11-13 17:41 ` Catalin Marinas
2023-10-12 12:27 ` Will Deacon
2023-10-12 12:27 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZSliChc3poZNM4f9@lpieralisi \
--to=lpieralisi@kernel.org \
--cc=acurrid@nvidia.com \
--cc=aniketa@nvidia.com \
--cc=ankita@nvidia.com \
--cc=apopple@nvidia.com \
--cc=catalin.marinas@arm.com \
--cc=cjia@nvidia.com \
--cc=danw@nvidia.com \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=kvmarm@lists.linux.dev \
--cc=kwankhede@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=targupta@nvidia.com \
--cc=vsethi@nvidia.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.