Re: [Qemu-devel] [PATCH] kvm: Move kvm_allows_irq0_override() to target-i386

[Jan Kiszka]

On 2012-07-21 14:17, Peter Maydell wrote:
> On 21 July 2012 12:08, Jan Kiszka <address@hidden> wrote:
>> On 2012-07-21 12:53, Peter Maydell wrote:
>>> This is still sounding like "there is an extra feature which you should
>>> probably implement at some point and should certainly design with the
>>> intention of supporting", not "you cannot have an irqchip without irqfds".
>>>
>>> Therefore QEMU code which cares about irqfds should be doing
>>> checks for irqfd functionality, not "is there an in kernel
>>> irqchip".
>>
>> Defining some kvm_irqfd_available() is one thing. Ignoring irqfd "for
>> now" while introducing in-kernel irqchip is another, less wise decision.
> 
> You still haven't really explained why we can't just ignore irqfd
> for now. I don't see how it would particularly affect the design
> of the kernel implementation very much, and the userspace interface
> seems to just be an extra ioctl.

I bet you ignored MSI so far. Physical IRQ lines are just a part of the
whole picture. How are MSIs delivered on the systems you want to add?

> 
>> Once you support the backend (KVM_SET_GSI_ROUTING + KVM_IRQ_LINE),
>> adding irqfd is in fact simple.
> 
> I don't really understand where KVM_SET_GSI_ROUTING comes into
> this -- the documentation is a bit opaque. It says "Sets the GSI
> routing table entries" but it doesn't define what a GSI is or
> what we're routing to where. Googling suggests GSI is an APIC
> specific term so it doesn't sound like it's relevant for non-x86.

As I said before: "GSI" needs to be read as "physical or virtual IRQ
line". The virtual ones can be of any source you define, irqfd is just one.

> 
> I'm not sure what KVM_IRQ_LINE has to do with it either -- this
> is just the standard interrupt injection ioctl. KVM ARM supports
> this whether there's an in-kernel irqchip or not.

KVM_IRQ_LINE injects according to the routing defined via
KVM_SET_GSI_ROUTING, at least on x86 (and ia64). If you define your own
KVM_IRQ_LINE semantics, you may have problems later on when you need to
redefine it after adding IRQ routing support.

Even if you don't want to add full irqchip support now, plan for it.
Define the so far used interfaces in a way that they will work
seamlessly when adding the missing bits and pieces. However, I still
think it's better to skip the intermediate steps in order to avoid
planning mistakes.

Jan

signature.asc
Description: OpenPGP digital signature