From: Logan Gunthorpe <logang@deltatee.com>
To: "Popov, Pavel E" <pavel.e.popov@intel.com>,
Bjorn Helgaas <helgaas@kernel.org>
Cc: Leon Romanovsky <leon@kernel.org>,
Jim Chow <jim.chow@broadcom.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Radu Rugina <radu.rugina@broadcom.com>,
Alexey Makhalov <alexey.makhalov@broadcom.com>,
Wei Liu <wei.liu@kernel.org>,
Michael Kelley <mhklinux@outlook.com>,
Lukas Wunner <lukas@wunner.de>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com>,
"bcm-kernel-feedback-list@broadcom.com"
<bcm-kernel-feedback-list@broadcom.com>,
"virtualization@lists.linux.dev" <virtualization@lists.linux.dev>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] PCI/P2PDMA: Allow P2PDMA in VMware and Hyper-V guests on Intel hosts
Date: Fri, 16 Oct 2026 12:18:20 -0600 [thread overview]
Message-ID: <006effed-576f-4aed-b3ac-c335d8d51106@deltatee.com> (raw)
In-Reply-To: <LV2PR11MB6070D328D5E6A538DB6370B2B29B2@LV2PR11MB6070.namprd11.prod.outlook.com>
On 2026-10-16 10:05, Popov, Pavel E wrote:
> Bjorn, Logan,
>
> Leon's position is clear: "NAK to anything that does not fix the
> hypervisor first". No concrete failure was described, and no change in
> this series can address it. That leaves the decision with you. Two
> facts: AMD guests get P2PDMA today and Intel guests do not, and HMAT
> does not exist in Linux yet.
Yikes, ok, I've followed some of that long discussion.
My first thought was this didn't seem as big an issue as it seemed
because if someone explicitly tries to do a P2PDMA transaction inside a
VM and it fails because the IOMMU blocks it, then they just get a noisy
error and they shouldn't enable P2PDMA. Except...
It looks like the dma-buf paths will enable P2PDMA unconditionally if
the test in question allows it, without anything the user needs to do to
enable it. I think that was probably a huge mistake but I guess we have
to live with that now. It means enabling new hardware with rules like
this is risky. It means even adding a global rule for Intel like AMD is
risky too. (Although, *maybe* eight years after I first added this code,
we can say that the vast majority of Intel CPUs support it, in which
case the dangers here are overblown -- but can we say that? What about
atoms and the like? Would the rule need to be complicated by a big model
list? These questions are why this has never happened.)
So I'm inclined to agree with Leon now that accepting this patch as is
may introduce some problematic risks. For now, maybe we need a kernel
command line argument that can explicitly enable an endpoint or
something like that so users that want to try it on VMware or wherever
can do so without needing to build a custom patched kernel.
I wish we could revisit the decision for dma-buf to use it without any
users explicitly asking for it. But I don't know what the correct path
forward is. If we can agree on a bulk rule for enabling Intel CPUs that
might be a good compromise, but I'm uncertain if that is even possible.
Logan
next prev parent reply other threads:[~2026-10-16 18:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 15:40 Pavel Popov
2026-10-09 15:40 ` [PATCH 1/2] PCI/P2PDMA: Allow P2PDMA in VMware " Pavel Popov
2026-10-09 16:38 ` Logan Gunthorpe
2026-10-09 16:49 ` Popov, Pavel E
2026-10-09 15:40 ` [PATCH 2/2] PCI/P2PDMA: Allow P2PDMA in Hyper-V " Pavel Popov
2026-10-09 16:58 ` [PATCH 0/2] PCI/P2PDMA: Allow P2PDMA in VMware and " Bjorn Helgaas
2026-10-09 18:08 ` Leon Romanovsky
2026-10-09 18:21 ` Popov, Pavel E
2026-10-09 18:49 ` Leon Romanovsky
2026-10-09 19:13 ` Popov, Pavel E
2026-10-11 5:47 ` Leon Romanovsky
2026-10-12 14:26 ` Popov, Pavel E
2026-10-12 16:24 ` Leon Romanovsky
2026-10-12 16:45 ` Popov, Pavel E
2026-10-12 18:21 ` Leon Romanovsky
2026-10-12 20:01 ` Popov, Pavel E
2026-10-13 12:20 ` Leon Romanovsky
2026-10-16 14:55 ` Popov, Pavel E
2026-10-16 15:31 ` Leon Romanovsky
2026-10-16 16:05 ` Popov, Pavel E
2026-10-16 18:18 ` Logan Gunthorpe [this message]
2026-10-16 19:45 ` Popov, Pavel E
2026-10-16 20:12 ` Logan Gunthorpe
2026-10-16 22:01 ` Popov, Pavel E
2026-10-09 19:12 ` Bjorn Helgaas
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=006effed-576f-4aed-b3ac-c335d8d51106@deltatee.com \
--to=logang@deltatee.com \
--cc=alexey.makhalov@broadcom.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=jim.chow@broadcom.com \
--cc=leon@kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mhklinux@outlook.com \
--cc=nathan.d.ciobanu@linux.intel.com \
--cc=pavel.e.popov@intel.com \
--cc=radu.rugina@broadcom.com \
--cc=rafael@kernel.org \
--cc=virtualization@lists.linux.dev \
--cc=wei.liu@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®