Re: [Qemu-devel] [PATCH v1 0/5][RFC] Refactoring of AIS support

[Pierre Morel]

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?
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.

Pierre


--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany