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 18:00:03 +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 17:43, Michael S. Tsirkin wrote:
> On Wed, Mar 28, 2012 at 01:36:15PM +0200, Jan Kiszka wrote:
>> On 2012-03-28 13:31, Michael S. Tsirkin wrote:
>>>>>>> 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.
>>>
>>> Right. So static routes take precedence. This means that in effect
>>> we will have two APIs in qemu: for fast MSIs and for slow ones,
>>> the advantage of the slow APIs being that they are easier to use,
>>> right?
>>
>> We will have two APIs depending on the source of the MSI. Special
>> sources are the exception while emulated ones are the majority. And for
>> the latter we should try very hard to keep things simple and clean.
>>
>> Jan
> 
> I assume this means yes :) So how about we replace the hash table with a
> single GSI reserved for this purpose, and use that for each interrupt?
> This will work fine for slow paths such as hotplug controller, yes it
> will be slow but *predictably* slow.

AHCI, HDA, virtio-block, and every other userspace MSI user will suffer
- I can't imagine you really want this. :)

> 
> Fast path will use static GSIs like qemu-kvm does.

Nope, qemu-kvm hooks deeply into the MSI layer to track vectors. I don't
believe we want this upstream. It also doesn't work for non-PCI MSI
(HPET on x86, try -global hpet.timers=4 -global hpet.msi=on with Linux
guests).

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]