All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	ankita@nvidia.com, maz@kernel.org, suzuki.poulose@arm.com,
	yuzenghui@huawei.com, will@kernel.org,
	alex.williamson@redhat.com, kevin.tian@intel.com,
	yi.l.liu@intel.com, ardb@kernel.org, akpm@linux-foundation.org,
	gshan@redhat.com, linux-mm@kvack.org, lpieralisi@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,
	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 v3 2/2] kvm: arm64: set io memory s2 pte as normalnc for vfio pci devices
Date: Wed, 13 Dec 2023 20:05:29 +0000	[thread overview]
Message-ID: <ZXoOieQN7rBiLL4A@linux.dev> (raw)
In-Reply-To: <20231212181156.GO3014157@nvidia.com>

Hi,

Sorry, a bit late to the discussion :)

On Tue, Dec 12, 2023 at 02:11:56PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 12, 2023 at 05:46:34PM +0000, Catalin Marinas wrote:
> > should know the implications. There's also an expectation that the
> > actual driver (KVM guests) or maybe later DPDK can choose the safe
> > non-cacheable or write-combine (Linux terminology) attributes for the
> > BAR.
> 
> DPDK won't rely on this interface

Wait, so what's the expected interface for determining the memory
attributes at stage-1? I'm somewhat concerned that we're conflating two
things here:

 1) KVM needs to know the memory attributes to use at stage-2, which
    isn't fundamentally different from what's needed for userspace
    stage-1 mappings.

 2) KVM additionally needs a hint that the device / VFIO can handle
    mismatched aliases w/o the machine exploding. This goes beyond
    supporting Normal-NC mappings at stage-2 and is really a bug
    with our current scheme (nGnRnE at stage-1, nGnRE at stage-2).

I was hoping that (1) could be some 'common' plumbing for both userspace
and KVM mappings. And for (2), any case where a device is intolerant of
mismatches && KVM cannot force the memory attributes should be rejected.

AFAICT, the only reason PCI devices can get the blanket treatment of
Normal-NC at stage-2 is because userspace has a Device-* mapping and can't
speculatively load from the alias. This feels a bit hacky, and maybe we
should prioritize an interface for mapping a device into a VM w/o a
valid userspace mapping.

I very much understand that this has been going on for a while, and we
need to do *something* to get passthrough working well for devices that
like 'WC'. I just want to make sure we don't paint ourselves into a corner
that's hard to get out of in the future.

-- 
Thanks,
Oliver

WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oliver.upton@linux.dev>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	ankita@nvidia.com, maz@kernel.org, suzuki.poulose@arm.com,
	yuzenghui@huawei.com, will@kernel.org,
	alex.williamson@redhat.com, kevin.tian@intel.com,
	yi.l.liu@intel.com, ardb@kernel.org, akpm@linux-foundation.org,
	gshan@redhat.com, linux-mm@kvack.org, lpieralisi@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,
	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 v3 2/2] kvm: arm64: set io memory s2 pte as normalnc for vfio pci devices
Date: Wed, 13 Dec 2023 20:05:29 +0000	[thread overview]
Message-ID: <ZXoOieQN7rBiLL4A@linux.dev> (raw)
In-Reply-To: <20231212181156.GO3014157@nvidia.com>

Hi,

Sorry, a bit late to the discussion :)

On Tue, Dec 12, 2023 at 02:11:56PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 12, 2023 at 05:46:34PM +0000, Catalin Marinas wrote:
> > should know the implications. There's also an expectation that the
> > actual driver (KVM guests) or maybe later DPDK can choose the safe
> > non-cacheable or write-combine (Linux terminology) attributes for the
> > BAR.
> 
> DPDK won't rely on this interface

Wait, so what's the expected interface for determining the memory
attributes at stage-1? I'm somewhat concerned that we're conflating two
things here:

 1) KVM needs to know the memory attributes to use at stage-2, which
    isn't fundamentally different from what's needed for userspace
    stage-1 mappings.

 2) KVM additionally needs a hint that the device / VFIO can handle
    mismatched aliases w/o the machine exploding. This goes beyond
    supporting Normal-NC mappings at stage-2 and is really a bug
    with our current scheme (nGnRnE at stage-1, nGnRE at stage-2).

I was hoping that (1) could be some 'common' plumbing for both userspace
and KVM mappings. And for (2), any case where a device is intolerant of
mismatches && KVM cannot force the memory attributes should be rejected.

AFAICT, the only reason PCI devices can get the blanket treatment of
Normal-NC at stage-2 is because userspace has a Device-* mapping and can't
speculatively load from the alias. This feels a bit hacky, and maybe we
should prioritize an interface for mapping a device into a VM w/o a
valid userspace mapping.

I very much understand that this has been going on for a while, and we
need to do *something* to get passthrough working well for devices that
like 'WC'. I just want to make sure we don't paint ourselves into a corner
that's hard to get out of in the future.

-- 
Thanks,
Oliver

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-12-13 20:05 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-08 16:47 [PATCH v3 0/2] kvm: arm64: allow vm to select DEVICE_* and ankita
2023-12-08 16:47 ` ankita
2023-12-08 16:47 ` [PATCH v3 1/2] kvm: arm64: introduce new flag for non-cacheable IO memory ankita
2023-12-08 16:47   ` ankita
2023-12-12 12:17   ` Will Deacon
2023-12-12 12:17     ` Will Deacon
2023-12-12 17:31   ` Catalin Marinas
2023-12-12 17:31     ` Catalin Marinas
2024-01-03 11:43   ` Suzuki K Poulose
2024-01-03 11:43     ` Suzuki K Poulose
2024-01-03 13:25     ` Ankit Agrawal
2024-01-03 13:25       ` Ankit Agrawal
2023-12-08 16:47 ` [PATCH v3 2/2] kvm: arm64: set io memory s2 pte as normalnc for vfio pci devices ankita
2023-12-08 16:47   ` ankita
2023-12-12 17:46   ` Catalin Marinas
2023-12-12 17:46     ` Catalin Marinas
2023-12-12 18:11     ` Jason Gunthorpe
2023-12-12 18:11       ` Jason Gunthorpe
2023-12-13 20:05       ` Oliver Upton [this message]
2023-12-13 20:05         ` Oliver Upton
2023-12-14 15:48         ` Lorenzo Pieralisi
2023-12-14 15:48           ` Lorenzo Pieralisi
2023-12-14 16:56           ` Oliver Upton
2023-12-14 16:56             ` Oliver Upton
2023-12-21 13:19             ` Catalin Marinas
2023-12-21 13:19               ` Catalin Marinas
2024-01-02 17:09               ` Jason Gunthorpe
2024-01-02 17:09                 ` Jason Gunthorpe
2024-01-03 13:33                 ` Catalin Marinas
2024-01-03 13:33                   ` Catalin Marinas
2024-01-05 20:42               ` Oliver Upton
2024-01-05 20:42                 ` Oliver Upton
2024-01-08 11:04                 ` Catalin Marinas
2024-01-08 11:04                   ` Catalin Marinas
2024-01-08 13:18                   ` Jason Gunthorpe
2024-01-08 13:18                     ` Jason Gunthorpe
2024-01-02 17:26         ` Jason Gunthorpe
2024-01-02 17:26           ` Jason Gunthorpe

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=ZXoOieQN7rBiLL4A@linux.dev \
    --to=oliver.upton@linux.dev \
    --cc=acurrid@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.williamson@redhat.com \
    --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=jgg@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=kevin.tian@intel.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=linux-mm@kvack.org \
    --cc=lpieralisi@kernel.org \
    --cc=maz@kernel.org \
    --cc=mochs@nvidia.com \
    --cc=suzuki.poulose@arm.com \
    --cc=targupta@nvidia.com \
    --cc=vsethi@nvidia.com \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    --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.