Re: [Qemu-devel] [RFC][PATCH 0/2] uq/master: Basic MSI support for in-kernel irqchip mode

[Jan Kiszka]

On 2012-03-28 11:45, Michael S. Tsirkin wrote:
> On Wed, Mar 28, 2012 at 09:13:22AM +0200, Jan Kiszka wrote:
>> On 2012-03-22 00:17, Jan Kiszka wrote:
>>> Some half a year ago when I posted my first attempt to refactor MSI
>>> for KVM support, we came to the conclusion that it might suffice to do
>>> transparent dynamic routing for user-space injected MSI messages. These
>>> two patches now implement such an approach for upstream.
>>>
>>> As QEMU does not yet include irqfd support (for vhost) or pci device
>>> assignment, this is already enough to enable MSI over the in-kernel
>>> irqchip. Still, this is only RFC as it is just lightly tested and should
>>> primarily collect feedback regarding the direction. If it's fine, I'd
>>> like to base further qemu-kvm refactorings and upstream preparations on
>>> top of such a series.
>>>
>>> Also, I'd like to reanimate my KVM patch to provide direct MSI injection
>>> in future kernels so that we do not need to take this long path here
>>> forever.
>>>
>>> Jan Kiszka (2):
>>>   kvm: Introduce basic MSI support in-kernel irqchips
>>>   KVM: x86: Wire up MSI support for in-kernel irqchip
>>>
>>>  hw/apic.c     |    3 +
>>>  hw/kvm/apic.c |   33 ++++++++++-
>>>  hw/pc.c       |    5 --
>>>  kvm-all.c     |  171 
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>>>  kvm.h         |    1 +
>>>  5 files changed, 205 insertions(+), 8 deletions(-)
>>>
>>
>> Anyone any comments? I think this series could open the door for
>> kernel_irqchip=on as default in QEMU 1.1.
>>
>> Jan
>>
> 
> For what this patch is trying to do, would adding a simple ioctl for
> injecting a given message into guest be cleaner?

For sure, and I already proposed this in the past. I think we were only
discussing the extensibility of such an IOCTL.

Anyway, that won't help with existing kernels. That's why I'm proposing
this userspace approach as an interim solution.

> Also, how would this support irqfd in the future? Will we have to
> rip it all out and replace with per-device tracking that we
> have today?

Irqfd and kvm device assignment will require additional interfaces (of
the kvm core in QEMU) via which you will be able to request stable
routes from such sources to specified MSIs. That will be widely
orthogonal to what is done in these patches here. Upstream is not
affected yet as it neither supports device assignment nor irqfds up to now.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux