[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kvm-ppc
Subject:    Re: [RFC PATCH 0/9] KVM: PPC: In-kernel PAPR interrupt controller emulation
From:       Benjamin Herrenschmidt <benh () kernel ! crashing ! org>
Date:       2012-12-15 2:06:13
Message-ID: 1355537173.19932.151.camel () pasglop
[Download RAW message or body]

On Sat, 2012-12-15 at 01:46 +0100, Alexander Graf wrote:
> On 05.11.2012, at 04:18, Paul Mackerras wrote:
> 
> > This series implements in-kernel emulation of the XICS interrupt
> > controller specified in the PAPR specification and used by pseries
> > guests.  Since the XICS is organized a bit differently to the
> > interrupt controllers used on x86 machines, I have defined some new
> > ioctls for setting up the XICS and for saving and restoring its
> > state.  It may be possible to use some of the currently x86-specific
> > ioctls instead.
> 
> Is this one already following the new world order that we discussed during KVM Forum? :)

The "new world order" .... (sorry, looks like nobody took notes and
people expect me to do a write up from memory now ... :-)

Well, mostly we agreed that the x86 stuff wasn't going to work for us.

So basically what we discussed boils down to:

 - Move the existing "generic" KVM ioctl to create the kernel APIC to
x86 since it's no as-is useful for other archs who, among other things,
might need to pass argument based on the machine type (type of interrupt
subsystem for example, etc...)

 - Once that's done, well, instanciating interrupt controller objects
becomes pretty much an arch specific matter. We could try to keep some
ioctls somewhat common though it's not *that* useful because the various
types & arguments are going to be fairly arch specific, so goes for
configuration. Examples of what could be kept common are:

   * Create irq chip, takes at least a "type" argument, possibly a few
more type-specific args (or a union, but then let's keep space in there
since we can't change the size of the struct later as it would impact
the ioctl number afaik).

  * Assigning the address of an irq chip when it can change (see ARM
patches)

 - The existing business with irqfd etc... is mostly ok, except the
interfaces messing around with MSIs (see virtio-pci use of kvm functions
directly). The assignment of an irq number for an MSI must be a hook,
probably a PCI controller hook, so x86 can get it done via its existing
kernel interfaces and sane architectures can keep the assignment in qemu
where it belongs.

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]