qemu-devel
[Top][All Lists]
Advanced

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

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


From: Jan Kiszka
Subject: Re: [Qemu-devel] [RFC][PATCH 0/2] uq/master: Basic MSI support for in-kernel irqchip mode
Date: Wed, 28 Mar 2012 13:07:42 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-03-28 12:47, Michael S. Tsirkin wrote:
> On Wed, Mar 28, 2012 at 11:50:27AM +0200, Jan Kiszka wrote:
>> 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.
> 
> Yes. And the conclusion I think was that it's not very extensible
> but a very good fit for what we want to do, right?
> See Message-ID: <address@hidden>

Cannot match this ID, but I guess the best is now to just leave a flags
and some padding fields in the struct for whatever may or may not come
in the future.

> 
>> Anyway, that won't help with existing kernels. That's why I'm proposing
>> this userspace approach as an interim solution.
> 
> I guess we can just keep the userspace irqchip around?

This is about the kernel IRQ chip support. We want to support it over
current kernels, not only 3.4 or even later.

> 
>>> 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.
> 
> Yes but not exactly as they will conflict for resources, right?
> How do you plan to solve this?

As done in my original series: If a static route requires a pseudo GSI
and there are none free, we simply flush the dynamic MSI routes.

> 
>> Upstream is not
>> affected yet as it neither supports device assignment nor irqfds up to now.
>>
>> Jan
> 
> Just to clarify: so in the end, we will need
> to basically do what qemu-kvm does, as well?

Basically yes, but with refactored interfaces. E.g. all pseudo GSI
management will be privatized in the KVM layer. And MSI[-X] interfaces
will be refactored to reduce the code you need in virtio and pci-assign
for propagating vector changes to the routing subsystem. Details
regarding this aren't settled yet, but it will be just an add-on to the
MSI injection path for fully emulated devices, ie. the topic of this series.

Jan

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



reply via email to

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