qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/8] s390x/pci: Fixing s390 vfio-pci ISM support


From: Niklas Schnelle
Subject: Re: [PATCH 0/8] s390x/pci: Fixing s390 vfio-pci ISM support
Date: Thu, 21 Jan 2021 10:58:09 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0


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

One other point for me is that all these special requirements seem
to stem from the fact that ISM is not a physical PCIe device but
a special s390 only thing. That also implies that unlike with real
PCI devices we are not going to find an existing Linux driver
and infrastructure that just works. I'd bet if it's anywhere
as special as ISM we will also need a QEMU change either way
and if that change is only to change the PFT check then
great, won't have trouble getting that backported...
So the PFT check ensures we're definitely trying the standard path
first and only change it to a special case if we understand that
it is required as we do for ISM.

That said it's also important to note that we are not searching
for a be all end all solution here. The standard path's to-MIO
translation, even though it is working, is weird enough and also
not ideal for performance so we might look at that again
in separate work and yes that could change things for
this case too but that too will require QEMU and Kernel
changes either way.
Furthermore we will be looking into handling more PCI
without leaving SIE at which point we will also re-evaluate
if that works for ISM. Again that needs QEMU and likely Kernel
changes. I'm a great fan of general solutions that
don't unnecessarily exclude something, so I do understand your
concern but let's focus on what we know and want to fix now
instead of trying to solve future theoretical issues that
we have no strong reason to believe will ever appear.

If we stick with the PFT check I think we do need to
change some wording especially for the Kernel changes.


> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]