[Top][All Lists]

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

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

From: Pierre Morel
Subject: Re: [qemu-s390x] [PATCH v1 0/5][RFC] Refactoring of AIS support
Date: Mon, 30 Oct 2017 14:44:47 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

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

Is there still a fallback for irqfd emulation?

it might disable dataplane or other things. (it once did). So I think we should 
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 Morel
Linux/KVM/QEMU in Böblingen - Germany

reply via email to

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