Hello Michael,
I agree with your concerns regarding a device been able to access memory
that doesn't belong to it. That exposure we have today with 2MB TCEs.
With 2MB TCEs, DMA window size will be big enough, for dedicated
adapters, that whole memory is going to be mapped "direct". Which
essentially means, that a "rogue" device/driver has the potential to
corrupt LPAR wide memory.
I have sent you v3.
Thanks,
Gaurav
On 5/4/23 12:10 AM, Michael Ellerman wrote:
Gaurav Batra <gba...@linux.vnet.ibm.com> writes:
Hello Michael,
I was looking into the Bug: 199106
(https://bugzilla.linux.ibm.com/show_bug.cgi?id=199106).
In the Bug, Mellanox driver was timing out when enabling SRIOV device.
I tested, Alexey's patch and it fixes the issue with Mellanox driver.
The down side
to Alexey's fix is that even a small memory request by the driver will
be aligned up
to 2MB. In my test, the Mellanox driver is issuing multiple requests of
64K size.
All these will get aligned up to 2MB, which is quite a waste of resources.
OK. I guess we should use your patch then.
It's not ideal as it means the device can potentially read/write to
memory it shouldn't, but 2MB is a lot to waste for a 64K alloc.
In any case, both the patches work. Let me know which approach you
prefer. In case
we decide to go with my patch, I just realized that I need to fix
nio_pages in
iommu_free_coherent() as well.
Can you send a v3 with that fixed please.
cheers
