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

["Michael S. Tsirkin" <mst@redhat.com>]

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 <agraf@suse.de>
> CC: Gerd Hoffmann <kraxel@redhat.com>
> CC: Isaku Yamahata <yamahata@valinux.co.jp>


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

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?
 

-- 
MST