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
