qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC][PATCH 00/45] qemu-kvm: MSI layer rework for in-ke


From: Jan Kiszka
Subject: Re: [Qemu-devel] [RFC][PATCH 00/45] qemu-kvm: MSI layer rework for in-kernel irqchip support
Date: Mon, 17 Oct 2011 21:35:05 +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 2011-10-17 17:57, Michael S. Tsirkin wrote:
> On Mon, Oct 17, 2011 at 11:27:34AM +0200, Jan Kiszka wrote:
>> As previously indicated, I was working for quite a while on a major
>> refactoring of the MSI "additions" we have in qemu-kvm to support
>> in-kernel irqchip, vhost and device assignment. This is now the outcome.
>>
>> I'm quite happy with it, things are still working (apparently), and the
>> invasiveness of KVM hooks into the MSI layer is significantly reduced.
>> Moreover, I was able to port the device assignment code over generic MSI
>> support, reducing the size of that file a bit further.
>>
>> Some further highlights:
>>  - fix for HPET MSI support with in-kernel irqchip
>>  - fully configurable MSI-X (allows 1:1 mapping for assigned devices)
>>  - refactored KVM core API for device assignment and IRQ routing
>>
>> I'm sending the whole series in one chunk so that you can see what the
>> result will be. It's RFC as I bet that there are regressions included
>> and maybe still room left for improvements. Once all is fine (can be
>> broken up into multiple chunks for the merge), I would suggest patching
>> qemu-kvm first and then start with porting things over to upstream.
>>
>> Comments & review welcome.
>>
>> CC: Alexander Graf <address@hidden>
>> CC: Gerd Hoffmann <address@hidden>
>> CC: Isaku Yamahata <address@hidden>
> 
> 
> So the scheme where we lazily update kvm gsi table
> on interrupts is interesting. There seems to be
> very little point in it for virtio, and it does
> seem to make it impossible to detect lack or resources
> (at the moment we let guest know if we run out of GSIs
> and linux guests can fall back to regular interrupts).

Are we really at that limit already? Then I think it's rather time to
lift it at the kernel side.

> 
> I am guessing the idea is to use it for device assignment
> where it does make sense as there is no standard way
> to track which vectors are actually used?
> But how does it work there? kvm does not
> propage unmapped interrupts from an assigned device to qemu, does it?

No, device assignment and irqfd (vhost, vfio, whatever-will-come) belong
to the static group. They need to hand out a static gsi to the irq
source, thus they cannot participate in lazy updating.

But they can benefit from the generic config notifiers: whenever the
guest changes some route (or disables it), they just need to inform the
core about this. So there is no need to track used vectors separately
anymore.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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