To be clear about what is at stake: this series is what enables P2PDMA in VMware and Hyper-V guests on Intel hosts. The assumption that the hypervisor can simply be fixed to emit HMAT is Linux-centric. It holds for KVM/QEMU, which is open source and where anyone can add HMAT support. ESXi and Hyper-V are proprietary, so only VMware and Microsoft can add it, and until they do, this series is the only path for guests on those hypervisors.
> This does not change the fact that the patch causes unpredictable > behavior for P2P devices in the guest. Sometimes it works; other times, > devices that previously worked may be classified as P2P-capable and > will stop. Nothing "previously worked" here. Before this patch, P2PDMA was refused for every passthrough device pair in VMware and Hyper-V guests on Intel hosts, except Intel QAT/DSA/IAA, whose own Device IDs happen to be in the allowlist. Those keep working unchanged, so there is no working configuration that could regress. And the check is deterministic: it depends on the CPU model and the hypervisor type, nothing else. The same guest on the same host gets the same answer every time. > Help Lukas and Mahesh succeed in their work. I'd like to, but the blocker for guests is on the hypervisor side. A guest only benefits from HMAT once ESXi or Hyper-V emits it, and that is VMware's and Microsoft's code, outside the control of Intel or the kernel community. The kernel cannot make them ship it; what it can do is provide this fallback. When your HMAT-based detection lands, it should be consulted first and this check only when no HMAT is present, so on any hypervisor that emits HMAT your code is what runs and this one is never reached. > -----Original Message----- > From: Leon Romanovsky <[email protected]> > Sent: Saturday, October 10, 2026 10:47 PM > To: Popov, Pavel E <[email protected]> > Cc: Bjorn Helgaas <[email protected]>; Jim Chow <[email protected]>; > Bjorn Helgaas <[email protected]>; Logan Gunthorpe > <[email protected]>; Radu Rugina <[email protected]>; Alexey > Makhalov <[email protected]>; Wei Liu <[email protected]>; > Michael Kelley <[email protected]>; Lukas Wunner <[email protected]>; > Nathan Ciobanu <[email protected]>; bcm-kernel-feedback- > [email protected]; [email protected]; > [email protected]; > [email protected]; [email protected] > Subject: Re: [PATCH 0/2] PCI/P2PDMA: Allow P2PDMA in VMware and Hyper-V > guests on Intel hosts > > On Fri, Oct 09, 2026 at 07:13:31PM +0000, Popov, Pavel E wrote: > > Leon, > > > > Understood on all points, and I agree HMAT is the proper fix. We > > discussed it with Lukas Wunner as well. Exposing HMAT is on the > > hypervisor side; Jim Chow from VMware can speak to their plans. Even > > once HMAT lands in Linux, it only helps guests after the hypervisors add > > support > for it. > > > > The key point for us is that today there is no path at all for > > passthrough devices on VMware or Hyper-V, and that is what this patch > > addresses. We reviewed it with VMware and aligned on this approach for > > the guest in the meantime. > > This does not change the fact that the patch causes unpredictable behavior for > P2P devices in the guest. Sometimes it works; other times, devices that > previously > worked may be classified as P2P-capable and will stop. > > > > > Is there anything you would recommend to make the series acceptable as > > an interim? > > Help Lukas and Mahesh succeed in their work. > > Thanks
