From: Jason Gunthorpe <jgg@nvidia.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Marc Zyngier <maz@kernel.org>,
ankita@nvidia.com,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
oliver.upton@linux.dev, suzuki.poulose@arm.com,
yuzenghui@huawei.com, will@kernel.org, ardb@kernel.org,
akpm@linux-foundation.org, gshan@redhat.com, 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, mochs@nvidia.com,
kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory
Date: Wed, 6 Dec 2023 11:38:09 -0400 [thread overview]
Message-ID: <20231206153809.GS2692119@nvidia.com> (raw)
In-Reply-To: <ZXCQrTbf6q0BIhSw@lpieralisi>
On Wed, Dec 06, 2023 at 04:18:05PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Dec 06, 2023 at 11:05:56AM -0400, Jason Gunthorpe wrote:
> > On Wed, Dec 06, 2023 at 02:49:02PM +0000, Catalin Marinas wrote:
> > > On Tue, Dec 05, 2023 at 03:48:22PM -0400, Jason Gunthorpe wrote:
> > > > On Tue, Dec 05, 2023 at 07:24:37PM +0000, Catalin Marinas wrote:
> > > > > On Tue, Dec 05, 2023 at 12:43:18PM -0400, Jason Gunthorpe wrote:
> > > > > > What if we change vfio-pci to use pgprot_device() like it already
> > > > > > really should and say the pgprot_noncached() is enforced as
> > > > > > DEVICE_nGnRnE and pgprot_device() may be DEVICE_nGnRE or NORMAL_NC?
> > > > > > Would that be acceptable?
> > > > >
> > > > > pgprot_device() needs to stay as Device, otherwise you'd get speculative
> > > > > reads with potential side-effects.
> > > >
> > > > I do not mean to change pgprot_device() I mean to detect the
> > > > difference via pgprot_device() vs pgprot_noncached(). They put a
> > > > different value in the PTE that we can sense. It is very hacky.
> > >
> > > Ah, ok, it does look hacky though (as is the alternative of coming up
> > > with a new specific pgprot_*() that KVM can treat differently).
> > >
> > > BTW, on those Mellanox devices that require different attributes within
> > > a BAR, do they have a problem with speculative reads causing
> > > side-effects?
> >
> > Yes. We definitely have had that problem in the past on older
> > devices. VFIO must map the BAR using pgprot_device/noncached() into
> > the VMM, no other choice is functionally OK.
>
> Were those BARs tagged as prefetchable or non-prefetchable ? I assume the
> latter but please let me know if I am guessing wrong.
I don't know it was quite old HW. Probably.
Just because a BAR is not marked as prefetchable doesn't mean that the
device can't use NORMAL_NC on subsets of it.
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Marc Zyngier <maz@kernel.org>,
ankita@nvidia.com,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
oliver.upton@linux.dev, suzuki.poulose@arm.com,
yuzenghui@huawei.com, will@kernel.org, ardb@kernel.org,
akpm@linux-foundation.org, gshan@redhat.com, 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, mochs@nvidia.com,
kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory
Date: Wed, 6 Dec 2023 11:38:09 -0400 [thread overview]
Message-ID: <20231206153809.GS2692119@nvidia.com> (raw)
In-Reply-To: <ZXCQrTbf6q0BIhSw@lpieralisi>
On Wed, Dec 06, 2023 at 04:18:05PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Dec 06, 2023 at 11:05:56AM -0400, Jason Gunthorpe wrote:
> > On Wed, Dec 06, 2023 at 02:49:02PM +0000, Catalin Marinas wrote:
> > > On Tue, Dec 05, 2023 at 03:48:22PM -0400, Jason Gunthorpe wrote:
> > > > On Tue, Dec 05, 2023 at 07:24:37PM +0000, Catalin Marinas wrote:
> > > > > On Tue, Dec 05, 2023 at 12:43:18PM -0400, Jason Gunthorpe wrote:
> > > > > > What if we change vfio-pci to use pgprot_device() like it already
> > > > > > really should and say the pgprot_noncached() is enforced as
> > > > > > DEVICE_nGnRnE and pgprot_device() may be DEVICE_nGnRE or NORMAL_NC?
> > > > > > Would that be acceptable?
> > > > >
> > > > > pgprot_device() needs to stay as Device, otherwise you'd get speculative
> > > > > reads with potential side-effects.
> > > >
> > > > I do not mean to change pgprot_device() I mean to detect the
> > > > difference via pgprot_device() vs pgprot_noncached(). They put a
> > > > different value in the PTE that we can sense. It is very hacky.
> > >
> > > Ah, ok, it does look hacky though (as is the alternative of coming up
> > > with a new specific pgprot_*() that KVM can treat differently).
> > >
> > > BTW, on those Mellanox devices that require different attributes within
> > > a BAR, do they have a problem with speculative reads causing
> > > side-effects?
> >
> > Yes. We definitely have had that problem in the past on older
> > devices. VFIO must map the BAR using pgprot_device/noncached() into
> > the VMM, no other choice is functionally OK.
>
> Were those BARs tagged as prefetchable or non-prefetchable ? I assume the
> latter but please let me know if I am guessing wrong.
I don't know it was quite old HW. Probably.
Just because a BAR is not marked as prefetchable doesn't mean that the
device can't use NORMAL_NC on subsets of it.
Jason
_______________________________________________
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-12-06 15:38 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-05 3:30 [PATCH v2 1/1] KVM: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory ankita
2023-12-05 3:30 ` ankita
2023-12-05 9:21 ` Marc Zyngier
2023-12-05 9:21 ` Marc Zyngier
2023-12-05 11:40 ` Catalin Marinas
2023-12-05 11:40 ` Catalin Marinas
2023-12-05 13:05 ` Jason Gunthorpe
2023-12-05 13:05 ` Jason Gunthorpe
2023-12-05 14:37 ` Lorenzo Pieralisi
2023-12-05 14:37 ` Lorenzo Pieralisi
2023-12-05 14:44 ` Jason Gunthorpe
2023-12-05 14:44 ` Jason Gunthorpe
2023-12-05 16:24 ` Catalin Marinas
2023-12-05 16:24 ` Catalin Marinas
2023-12-05 17:10 ` Jason Gunthorpe
2023-12-05 17:10 ` Jason Gunthorpe
2023-12-05 16:22 ` Catalin Marinas
2023-12-05 16:22 ` Catalin Marinas
2023-12-05 16:43 ` Jason Gunthorpe
2023-12-05 16:43 ` Jason Gunthorpe
2023-12-05 17:01 ` Marc Zyngier
2023-12-05 17:01 ` Marc Zyngier
2023-12-05 17:33 ` Catalin Marinas
2023-12-05 17:33 ` Catalin Marinas
2023-12-05 17:50 ` Marc Zyngier
2023-12-05 17:50 ` Marc Zyngier
2023-12-05 18:40 ` Catalin Marinas
2023-12-05 18:40 ` Catalin Marinas
2023-12-06 11:39 ` Marc Zyngier
2023-12-06 11:39 ` Marc Zyngier
2023-12-06 12:14 ` Catalin Marinas
2023-12-06 12:14 ` Catalin Marinas
2023-12-06 15:16 ` Jason Gunthorpe
2023-12-06 15:16 ` Jason Gunthorpe
2023-12-06 16:31 ` Catalin Marinas
2023-12-06 16:31 ` Catalin Marinas
2023-12-06 17:20 ` Jason Gunthorpe
2023-12-06 17:20 ` Jason Gunthorpe
2023-12-06 18:58 ` Catalin Marinas
2023-12-06 18:58 ` Catalin Marinas
2023-12-06 19:03 ` Jason Gunthorpe
2023-12-06 19:03 ` Jason Gunthorpe
2023-12-06 19:06 ` Catalin Marinas
2023-12-06 19:06 ` Catalin Marinas
2023-12-07 2:53 ` Ankit Agrawal
2023-12-07 2:53 ` Ankit Agrawal
2023-12-06 11:52 ` Lorenzo Pieralisi
2023-12-06 11:52 ` Lorenzo Pieralisi
2023-12-05 19:24 ` Catalin Marinas
2023-12-05 19:24 ` Catalin Marinas
2023-12-05 19:48 ` Jason Gunthorpe
2023-12-05 19:48 ` Jason Gunthorpe
2023-12-06 14:49 ` Catalin Marinas
2023-12-06 14:49 ` Catalin Marinas
2023-12-06 15:05 ` Jason Gunthorpe
2023-12-06 15:05 ` Jason Gunthorpe
2023-12-06 15:18 ` Lorenzo Pieralisi
2023-12-06 15:18 ` Lorenzo Pieralisi
2023-12-06 15:38 ` Jason Gunthorpe [this message]
2023-12-06 15:38 ` Jason Gunthorpe
2023-12-06 16:23 ` Catalin Marinas
2023-12-06 16:23 ` Catalin Marinas
2023-12-06 16:48 ` Jason Gunthorpe
2023-12-06 16:48 ` Jason Gunthorpe
2023-12-07 10:13 ` Lorenzo Pieralisi
2023-12-07 10:13 ` Lorenzo Pieralisi
2023-12-07 13:38 ` Jason Gunthorpe
2023-12-07 13:38 ` Jason Gunthorpe
2023-12-07 14:50 ` Lorenzo Pieralisi
2023-12-07 14:50 ` Lorenzo Pieralisi
2023-12-05 13:28 ` Lorenzo Pieralisi
2023-12-05 13:28 ` Lorenzo Pieralisi
2023-12-05 14:16 ` Shameerali Kolothum Thodi
2023-12-05 14:16 ` Shameerali Kolothum Thodi
2023-12-06 8:17 ` Shameerali Kolothum Thodi
2023-12-06 8:17 ` Shameerali Kolothum Thodi
2023-12-05 11:48 ` Catalin Marinas
2023-12-05 11:48 ` Catalin Marinas
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=20231206153809.GS2692119@nvidia.com \
--to=jgg@nvidia.com \
--cc=acurrid@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=aniketa@nvidia.com \
--cc=ankita@nvidia.com \
--cc=apopple@nvidia.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=cjia@nvidia.com \
--cc=danw@nvidia.com \
--cc=gshan@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=kwankhede@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=maz@kernel.org \
--cc=mochs@nvidia.com \
--cc=oliver.upton@linux.dev \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=suzuki.poulose@arm.com \
--cc=targupta@nvidia.com \
--cc=vsethi@nvidia.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/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.