linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Ankit Agrawal <ankita@nvidia.com>
Cc: Will Deacon <will@kernel.org>, "maz@kernel.org" <maz@kernel.org>,
	"oliver.upton@linux.dev" <oliver.upton@linux.dev>,
	"joey.gouly@arm.com" <joey.gouly@arm.com>,
	"suzuki.poulose@arm.com" <suzuki.poulose@arm.com>,
	"yuzenghui@huawei.com" <yuzenghui@huawei.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"ryan.roberts@arm.com" <ryan.roberts@arm.com>,
	"shahuang@redhat.com" <shahuang@redhat.com>,
	"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
	"david@redhat.com" <david@redhat.com>,
	"ddutile@redhat.com" <ddutile@redhat.com>,
	"seanjc@google.com" <seanjc@google.com>,
	Aniket Agashe <aniketa@nvidia.com>, Neo Jia <cjia@nvidia.com>,
	Kirti Wankhede <kwankhede@nvidia.com>,
	Krishnakant Jaju <kjaju@nvidia.com>,
	"Tarun Gupta (SW-GPU)" <targupta@nvidia.com>,
	Vikram Sethi <vsethi@nvidia.com>,
	Andy Currid <acurrid@nvidia.com>,
	Alistair Popple <apopple@nvidia.com>,
	John Hubbard <jhubbard@nvidia.com>,
	Dan Williams <danw@nvidia.com>, Zhi Wang <zhiw@nvidia.com>,
	Matt Ochs <mochs@nvidia.com>, Uday Dhoke <udhoke@nvidia.com>,
	Dheeraj Nigam <dnigam@nvidia.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"sebastianene@google.com" <sebastianene@google.com>,
	"coltonlewis@google.com" <coltonlewis@google.com>,
	"kevin.tian@intel.com" <kevin.tian@intel.com>,
	"yi.l.liu@intel.com" <yi.l.liu@intel.com>,
	"ardb@kernel.org" <ardb@kernel.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"gshan@redhat.com" <gshan@redhat.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"tabba@google.com" <tabba@google.com>,
	"qperret@google.com" <qperret@google.com>,
	"kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"maobibo@loongson.cn" <maobibo@loongson.cn>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: [PATCH v9 3/6] KVM: arm64: Block cacheable PFNMAP mapping
Date: Mon, 30 Jun 2025 09:25:01 -0300	[thread overview]
Message-ID: <20250630122501.GQ167785@nvidia.com> (raw)
In-Reply-To: <SA1PR12MB7199144BBDA23C9A06DA12F9B046A@SA1PR12MB7199.namprd12.prod.outlook.com>

On Mon, Jun 30, 2025 at 01:56:43AM +0000, Ankit Agrawal wrote:
> > Sorry for the drive-by comment, but I was looking at this old series from
> > Paolo (look at the cover letter and patch 5):
> >
> > https://lore.kernel.org/r/20250109133817.314401-1-pbonzini@redhat.com
> >
> > in which he points out that the arm64 get_vma_page_shift() function
> > incorrectly assumes that a VM_PFNMAP VMA is physically contiguous, which
> > may not be the case if a driver calls remap_pfn_range() to mess around
> > with mappings within the VMA. I think that implies that the optimisation
> > in 2aa53d68cee6 ("KVM: arm64: Try stage2 block mapping for host device
> > MMIO") is unsound.
> 
> Hm yeah, that does seem problematic. Perhaps we need a new
> vma flag that could help the driver communicate to the KVM that the
> mapping is contiguous and it can go ahead with the optimization?
> E.g. something similar to VM_ALLOW_ANY_UNCACHED.

I think Paolo has the right direction - remove any attempts by KVM to
expand contiguity, it should only copy the primary's PTEs and rely on
the primary to discover contiguity. No new flags.

Instead we need to keep pushing forward with Peter Xu's work to have
PFNMAPs use large PTEs. I believe ARM still has some missing parts for
full support bot overall it is a far better direction.

> > But it got me thinking -- given that remap_pfn_range() also takes a 'prot'
> > argument, how do we ensure that this is reflected in the guest? It feels
> > a bit dodgy to rely on drivers always passing 'vma->vm_page_prot'.

But broadly, if you take that perspective KVM as a misdesign..  KVM
should be getting the VMA's PTE so that the S2 PTE can duplicate the
page-by-page flags, instead of only copying the writable bit.

So, let's call this out of scope for this series. ARM64 KVM does not
support page-by-page cachability, it never has, and there is no known
use case right now.. The only user of VMA_CACHED PFNMAPs is being
consistent.

Jason


  reply	other threads:[~2025-06-30 12:25 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-21  4:21 [PATCH v9 0/6] KVM: arm64: Map GPU device memory as cacheable ankita
2025-06-21  4:21 ` [PATCH v9 1/6] KVM: arm64: Rename the device variable to s2_force_noncacheable ankita
2025-07-04 13:41   ` Jason Gunthorpe
2025-07-04 13:57   ` David Hildenbrand
2025-06-21  4:21 ` [PATCH v9 2/6] KVM: arm64: Update the check to detect device memory ankita
2025-07-04 13:43   ` Jason Gunthorpe
2025-07-04 14:02   ` David Hildenbrand
2025-06-21  4:21 ` [PATCH v9 3/6] KVM: arm64: Block cacheable PFNMAP mapping ankita
2025-06-27 13:49   ` Will Deacon
2025-06-30  1:56     ` Ankit Agrawal
2025-06-30 12:25       ` Jason Gunthorpe [this message]
2025-07-04 12:21         ` David Hildenbrand
2025-07-04 16:04           ` Will Deacon
2025-07-04 16:47             ` Jason Gunthorpe
2025-07-08 12:47               ` Will Deacon
2025-07-04 13:45   ` Jason Gunthorpe
2025-07-04 14:09   ` David Hildenbrand
2025-06-21  4:21 ` [PATCH v9 4/6] KVM: arm64: New function to determine hardware cache management support ankita
2025-07-04 13:47   ` Jason Gunthorpe
2025-07-04 14:10   ` David Hildenbrand
2025-06-21  4:21 ` [PATCH v9 5/6] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags ankita
2025-07-04 14:04   ` Jason Gunthorpe
2025-07-04 14:13     ` David Hildenbrand
2025-07-04 16:51       ` Ankit Agrawal
2025-06-21  4:21 ` [PATCH v9 6/6] KVM: arm64: Expose new KVM cap for cacheable PFNMAP ankita
2025-07-04 13:44   ` Jason Gunthorpe
2025-07-04 14:15     ` David Hildenbrand
2025-07-04 15:04       ` Jason Gunthorpe
2025-07-04 16:20         ` Ankit Agrawal
2025-07-04 16:56           ` Jason Gunthorpe
2025-06-27  5:03 ` [PATCH v9 0/6] KVM: arm64: Map GPU device memory as cacheable Ankit Agrawal
2025-07-02  9:33 ` Ankit Agrawal
2025-07-02 16:51   ` Donald Dutile

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=20250630122501.GQ167785@nvidia.com \
    --to=jgg@nvidia.com \
    --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=coltonlewis@google.com \
    --cc=danw@nvidia.com \
    --cc=david@redhat.com \
    --cc=ddutile@redhat.com \
    --cc=dnigam@nvidia.com \
    --cc=gshan@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=joey.gouly@arm.com \
    --cc=kevin.tian@intel.com \
    --cc=kjaju@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=linux-mm@kvack.org \
    --cc=lpieralisi@kernel.org \
    --cc=maobibo@loongson.cn \
    --cc=maz@kernel.org \
    --cc=mochs@nvidia.com \
    --cc=oliver.upton@linux.dev \
    --cc=pbonzini@redhat.com \
    --cc=qperret@google.com \
    --cc=ryan.roberts@arm.com \
    --cc=seanjc@google.com \
    --cc=sebastianene@google.com \
    --cc=shahuang@redhat.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=targupta@nvidia.com \
    --cc=udhoke@nvidia.com \
    --cc=vsethi@nvidia.com \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    --cc=yuzenghui@huawei.com \
    --cc=zhiw@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox