On 1/21/21 10:58 AM, Niklas Schnelle wrote:
On 1/21/21 9:27 AM, Pierre Morel wrote:
On 1/20/21 9:29 PM, Matthew Rosato wrote:
On 1/20/21 2:18 PM, Pierre Morel wrote:
...snip...
So, I mean I can change the code to be more permissive in that way (allow any
device that doesn't have MSI-X capability to at least attempt to use the
region). But the reality is that ISM specifically needs the region for
successful pass through, so I don't see a reason to create a different bit for
that vs just checking for the PFT in QEMU and using that value to decide
whether or not region availability is a requirement for allowing the device to
pass through.
There is no need for a new bit to know if a device support MIO or not, as I
said before, there is already one in the CLP query PCI function response and it
is already used in the kernel zPCI architecture.
It is not a big think to do and does not change the general architecture of the
patch, only the detection of which device is impacted to make it generic
instead of device dedicated.
Regards,
Pierre
Just wanted to say that we've had a very similar discussion with
Cornelia end of last year and came to the conclusion that explicitly
matching the PFT is likely the safest bet:
https://lkml.org/lkml/2020/12/22/479
What I see there is a discussion on the relation between relaxed access
and MIO without explaining to Connie that we have in the kernel the
possibility to know if a device support MIO or not independently of it
supports the relaxed access.
The all point here is about taking decisions for the right reasons.
We have the possibility to take the decision based on functionalities
and not on a specific PCI function.
If we keep the PFT check, and we can do this of course, but is it a good
solution if it appears we have other PFT with the same functionalities?
Please note that this is a minor code change, keeping track of the MIO
support just as we keep track of the PFT and check on this instead of on
the PFT.
It does not modify the general architecture of the patch series neither
in kernel nor in QEMU at all.
Pierre
--
Pierre Morel
IBM Lab Boeblingen
