RE: [PATCH 0/2] PCI/P2PDMA: Allow P2PDMA in VMware and Hyper-V guests on Intel hosts

["Popov, Pavel E" <pavel.e.popov@intel.com>]

> Please read all of my responses. I was explicit about why the check
> inside the guest VM produces random results. However, your responses
> continue to focus on the guest, which is not the problem.

Fair, my earlier replies were about the guest. Taking the host-side
points in turn:

1. Host topology decides P2P, the guest cannot see it, and the patch
   says "yes" for every pair regardless.

   The topology is accounted for where the knowledge is: on the host.
   Which devices land in one VM is decided by the admin, from devices
   VMware has certified for passthrough in the Compatibility Guide,
   and on vSphere 8+ by Device Groups, which hands devices sharing a
   switch or interconnect to a VM as a topology-aware group. Hyper-V
   has no equivalent grouping; DDA is plain passthrough, each device
   assigned to the VM explicitly by the admin.

   The blanket "yes" is not new either. On bare metal the flags = 0
   whitelist entries say "yes" for any pair of Xeon Scalable root
   buses, across sockets, with no knowledge of BIOS P2P settings. And
   cpu_supports_p2pdma() already bypasses the host bridge check for
   AMD Zen on CPUID alone, in guests included. This series gives Intel
   hosts what the tree already does for AMD; if that is unacceptable
   in principle, it is unacceptable for AMD guests today.

2. Regression: consumers that work today via a system-memory fallback
   will take the P2P path and break on hosts that cannot route it.

   A wrong "yes" fails safely: without host-side P2P the request is
   stopped at the host IOMMU, nothing is corrupted, the same exposure
   an AMD guest has today. An unconditional "no" is worse: it blocks
   P2P on every host that does route it, and the guest's answer
   changes nothing about whether the host routes it.

   Xeon Scalable routes P2P between any two root ports, which the
   whitelist already encodes. The only hypervisor-side requirement is
   mapping the peer's MMIO into the VM's IOMMU domain, and that is
   what passthrough P2P support means: on ESXi it was an explicit
   per-VM setting for years and is the default since 9.0; Hyper-V does
   it for devices assigned to the same VM, as tested on Windows Server
   2025. The decision is made on the host; the guest only has to stop
   vetoing it.

3. The hypervisor must describe it, HMAT is the way, NAK to anything
   that does not fix the hypervisor first.

   Agreed HMAT is the right source and should take precedence: consult
   it first, this check only where no HMAT exists. The disagreement is
   on "first". Guests on already shipped ESXi and Hyper-V releases
   will never get HMAT, and those stay in production for years; the
   cover letter's note on the adoption timeline was written with
   VMware's input, and Jim can speak to it. Until a hypervisor emits
   HMAT, this fallback is the only path that works.

Thanks,
Pavel