Re: [qemu-s390x] [PATCH v1 0/5][RFC] Refactoring of AIS support

[Halil Pasic]

On 10/30/2017 02:48 PM, Christian Borntraeger wrote:
> 
> 
> On 10/30/2017 02:44 PM, Pierre Morel wrote:
>> On 30/10/2017 13:44, Christian Borntraeger wrote:
>>>
>>>
>>> On 10/30/2017 01:42 PM, Cornelia Huck wrote:
>>>> On Mon, 30 Oct 2017 09:28:09 +0100
>>>> Christian Borntraeger <address@hidden> wrote:
>>>>
>>>>> Now I thought about that for a while and I start to think that we cannot 
>>>>> implement ais
>>>>> in QEMU and cover all cases.
>>>>> One aspect was certainly passthrough (like you handled in patch 4).
>>>>> Another aspect is that some interrupts might be injected from the kernel 
>>>>> - even for
>>>>> emulated devices. e.g. virtio-pci together with vhost-net, will inject 
>>>>> interrupts via
>>>>> the set_irq callback. I think disabling irqfd for these cases is not a 
>>>>> good idea.
>>>>
>>>> Is there still a fallback for irqfd emulation?
>>>
>>> it might disable dataplane or other things. (it once did). So I think we 
>>> should not
>>> go down this path.
>>>
>>>>
>>>>>
>>>>> So what about adding a new KVM capability (for 4.14), fixup the other 
>>>>> things in
>>>>> QEMU and then bind it to the new capability?
>>>>
>>>> For 4.15, surely?
>>>>
>>>> Probably the only way we can make this work correctly...
>>>>
>>
>> I may have not understand.
>>
>> Why do we need a new capability, we already have the KVM_CAP_S390_AIS 
>> capability?
> 
> To mark a kernel that supports AIS+migration without having to instantiate a 
> flic device.
> 

It's about libvirt probing AFAIU. Right now, to tell if we have migration for
AIS we need a flic device instantiated in the kernel (we need the fd to tell
if the flic attributes are supported by the kernel).

> 
>> The PCI device has a netdev property pointing to a netdev, if this netdev 
>> sets the vhost property, can't we test this to know if we can realize this 
>> device or not?
>>
>> Using virtio-pci instead of virtio-ccw is not the first choice for S390. The 
>> use case I see for S390 using virtio-pci is as a fallback in case for the 
>> migration of a PCI device the target host does not support AIS or do not 
>> have VFIO device and one do not want to modify the guest.
> 
> This was just one example. Having the interrupt controller in the kernel, 
> implementing AIS in
> qemu is very prone to break something that we have forgotten about.
> 

I tend to agree with Christian. While doing emulation AIS in QEMU
for scenarios where all adapter interrupts (subject to AIS) are
guaranteed to go through QEMU is possible, it is also bound to
introduce a whole lot of added complexity.

Frankly, I doubt the gain outweighs the pain in this case.

Regards,
Halil