On Sat, 2012-10-27 at 11:01 +0100, Peter Maydell wrote:
> This is more or less how ARM has done it (though our specific encoding
> of interrupt numbers is different, obviously).
>
> If I were designing an interface for this kind of thing from scratch
> I'd probably want it to look like "create a
On 26 October 2012 23:03, Benjamin Herrenschmidt
wrote:
> So the GSI bit. We can assume that GSIs in that context are basically
> our "global interrupt number". This would apply to pretty much every
> platform indeed.
>
> The routing here, if I understand things correctly, consists of
> associatin
On 2012-10-27 00:03, Benjamin Herrenschmidt wrote:
> On Sat, 2012-10-27 at 07:45 +1100, Benjamin Herrenschmidt wrote:
>> On Fri, 2012-10-26 at 14:39 +0200, Jan Kiszka wrote:
>>
>>> But we are just talking about sending messages from A to B or soldering
>>> an input to an output pin. That's pretty g
On Sat, 2012-10-27 at 07:45 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2012-10-26 at 14:39 +0200, Jan Kiszka wrote:
>
> > But we are just talking about sending messages from A to B or soldering
> > an input to an output pin. That's pretty generic. Give each output event
> > a virtual IRQ numbe
On Fri, 2012-10-26 at 14:39 +0200, Jan Kiszka wrote:
> But we are just talking about sending messages from A to B or soldering
> an input to an output pin. That's pretty generic. Give each output event
> a virtual IRQ number and define where its output "line" should be linked
> to (input pin of ta
On Fri, 2012-10-26 at 13:57 +0200, Paolo Bonzini wrote:
> Il 26/10/2012 13:09, Benjamin Herrenschmidt ha scritto:
> > The only cases I can think of are the association between a virtual
> > interrupt (ie, an interrupt in the guest interrupt number space) and an
> > in-kernel source for that interru
On 2012-10-26 14:08, Peter Maydell wrote:
> On 26 October 2012 12:57, Paolo Bonzini wrote:
>> If you exclude old-style PCI pass-through and limit yourself to vhost
>> and VFIO, you can treat irqfd as "the" in-kernel source of the
>> interrupt. Then you need a mapping between MSIs and numbers used
On 2012-10-26 13:39, Benjamin Herrenschmidt wrote:
> On Fri, 2012-10-26 at 12:17 +0100, Peter Maydell wrote:
>>> Well, that's the thing, I haven't managed to figure that out so far,
>> it
>>> looks very x86-specific to me. To begin with there's no such thing
>> as a
>>> "GSI" in our world.
>>
>> Th
On 26 October 2012 12:57, Paolo Bonzini wrote:
> If you exclude old-style PCI pass-through and limit yourself to vhost
> and VFIO, you can treat irqfd as "the" in-kernel source of the
> interrupt. Then you need a mapping between MSIs and numbers used in
> KVM_IRQFD ("GSIs").
>
> This is what KVM_
Il 26/10/2012 13:09, Benjamin Herrenschmidt ha scritto:
> The only cases I can think of are the association between a virtual
> interrupt (ie, an interrupt in the guest interrupt number space) and an
> in-kernel source for that interrupt, ie, vhost and PCI pass-through
> essentially.
If you exclud
[snipping some parts that Jan answered about already]
Il 26/10/2012 12:47, Benjamin Herrenschmidt ha scritto:
> Or do you mean the routing configured by the user ? IE. Affinity ? If
> yes, then that's indeed what the 64-bit per source is. Each interrupt
> source has some state including the config
On Fri, 2012-10-26 at 12:17 +0100, Peter Maydell wrote:
> > Well, that's the thing, I haven't managed to figure that out so far,
> it
> > looks very x86-specific to me. To begin with there's no such thing
> as a
> > "GSI" in our world.
>
> This was roughly the feeling I had looking at these APIs.
On 26 October 2012 11:44, Benjamin Herrenschmidt
wrote:
> On Fri, 2012-10-26 at 12:15 +0200, Paolo Bonzini wrote:
>> QEMU's MSI-X routing is not x86-specific, so it should use the same
>> KVM_SET_GSI_ROUTING ioctl that x86 uses.
>
> Well, that's the thing, I haven't managed to figure that out so f
On Fri, 2012-10-26 at 12:40 +0200, Paolo Bonzini wrote:
> Il 26/10/2012 12:37, Benjamin Herrenschmidt ha scritto:
> >> > Wiring which MSI-X interrupts go to which source controllers. If you
> >> > have one source controller per PCI bridge, you need to tell the kernel
> >> > the mapping between MSI
On Fri, 2012-10-26 at 13:00 +0200, Jan Kiszka wrote:
> And at latest there you will need the IRQ routing infrastructure of KVM.
> It tells KVM which "virtual IRQ" (badly named "GSI") triggers which
> event at which input, e.g. a physical IRQ line at some IRQ controller or
> a specific message at s
On 2012-10-26 12:44, Benjamin Herrenschmidt wrote:
> On Fri, 2012-10-26 at 12:15 +0200, Paolo Bonzini wrote:
>>> Whether you want to do startup configuration and board wiring via
>>> the same ioctl that handles runtime state save/load/migration is
>>> a different question, of course.
>>
>> QEMU's M
On Fri, 2012-10-26 at 12:15 +0200, Paolo Bonzini wrote:
> > Whether you want to do startup configuration and board wiring via
> > the same ioctl that handles runtime state save/load/migration is
> > a different question, of course.
>
> QEMU's MSI-X routing is not x86-specific, so it should use the
Il 26/10/2012 12:37, Benjamin Herrenschmidt ha scritto:
>> > Wiring which MSI-X interrupts go to which source controllers. If you
>> > have one source controller per PCI bridge, you need to tell the kernel
>> > the mapping between MSI messages interrupts and PCI bridges, and update
>> > it wheneve
On Fri, 2012-10-26 at 11:58 +0200, Paolo Bonzini wrote:
> Il 25/10/2012 21:40, Benjamin Herrenschmidt ha scritto:
> >> > Probably you do need a variant of KVM_CREATE_IRQCHIP to create the
> >> > IOAPICs/source controllers (Paul's proposal at
> >> > http://permalink.gmane.org/gmane.comp.emulators.kv
On 2012-10-26 12:15, Paolo Bonzini wrote:
> Il 26/10/2012 12:09, Peter Maydell ha scritto:
The other problem is configuring the redirection table. If you need >64
sources you need ioctls like KVM_GET/SET_IRQCHIP_ONE_REG.
>> Why would you want an extra ONE_REG-like ioctl? The existin
Il 26/10/2012 12:09, Peter Maydell ha scritto:
>> >
>> > The other problem is configuring the redirection table. If you need >64
>> > sources you need ioctls like KVM_GET/SET_IRQCHIP_ONE_REG.
> Why would you want an extra ONE_REG-like ioctl? The existing ONE_REG
> ioctls have plenty of space in th
On 26 October 2012 10:58, Paolo Bonzini wrote:
> Wiring which MSI-X interrupts go to which source controllers. If you
> have one source controller per PCI bridge, you need to tell the kernel
> the mapping between MSI messages interrupts and PCI bridges, and update
> it whenever the MSI masking ch
Il 25/10/2012 21:40, Benjamin Herrenschmidt ha scritto:
>> > Probably you do need a variant of KVM_CREATE_IRQCHIP to create the
>> > IOAPICs/source controllers (Paul's proposal at
>> > http://permalink.gmane.org/gmane.comp.emulators.kvm.powerpc.devel/5674
>> > for example), assign chip ids to them,
On Thu, 2012-10-25 at 20:27 +0200, Paolo Bonzini wrote:
> Probably you do need a variant of KVM_CREATE_IRQCHIP to create the
> IOAPICs/source controllers (Paul's proposal at
> http://permalink.gmane.org/gmane.comp.emulators.kvm.powerpc.devel/5674
> for example), assign chip ids to them, set the num
On Thu, 2012-10-25 at 18:14 +0200, Paolo Bonzini wrote:
> As Jan said, there's more than a few similarities between the x86 and
> PPC model.
>
> Taking inspiration from the x86 API, configuring the source controller
> seems to be more of a task for KVM_SET_GSI_ROUTING (a very x86-centric
> name, I
Il 25/10/2012 18:32, Jan Kiszka ha scritto:
> For wiring things together, I agree. But the IOAPIC has a fixed number
> of input lines per chip, Power needs to configure them. I don't think
> deriving this from addressed lines is the best solution. Some lines may
> be configured (too) late, when the
On 2012-10-25 18:14, Paolo Bonzini wrote:
> Il 24/10/2012 02:50, Paul Mackerras ha scritto:
>> So we could indeed use the existing KVM_CREATE_IRQCHIP to tell KVM to
>> create a presentation controller per vcpu. But then how do we tell
>> KVM how many source controllers we want and how many interru
Il 24/10/2012 02:50, Paul Mackerras ha scritto:
> So we could indeed use the existing KVM_CREATE_IRQCHIP to tell KVM to
> create a presentation controller per vcpu. But then how do we tell
> KVM how many source controllers we want and how many interrupts each
> source controller should handle? Th
On 2012-10-24 02:50, Paul Mackerras wrote:
> On Tue, Oct 23, 2012 at 12:48:28PM +0200, Jan Kiszka wrote:
>
>> The current irqchip API is like this:
>>
>> KVM_CREATE_IRQCHIP (without any parameters)
>> ...
>> KVM_CREATE_VCPU
>> KVM_SET_IRQCHIP (or the other way around)
>> ...
>> KVM_RUN
>>
>> The a
On Tue, Oct 23, 2012 at 12:48:28PM +0200, Jan Kiszka wrote:
> The current irqchip API is like this:
>
> KVM_CREATE_IRQCHIP (without any parameters)
> ...
> KVM_CREATE_VCPU
> KVM_SET_IRQCHIP (or the other way around)
> ...
> KVM_RUN
>
> The arguments you cannot pass via KVM_CREATE_IRQCHIP - which
On 2012-10-23 13:04, Peter Maydell wrote:
> On 23 October 2012 12:00, Jan Kiszka wrote:
>> BTW, I guess we will regret that one-reg ABI one day and have to
>> introduce a multi-reg version again for hot-standby, i.e. continuous
>> state migration. I know we also do this for c86 MSRs - that interfa
On 23 October 2012 12:00, Jan Kiszka wrote:
> BTW, I guess we will regret that one-reg ABI one day and have to
> introduce a multi-reg version again for hot-standby, i.e. continuous
> state migration. I know we also do this for c86 MSRs - that interface
> has the same limitation.
The multi-reg AB
On 2012-10-23 12:52, Peter Maydell wrote:
> On 23 October 2012 11:48, Jan Kiszka wrote:
>> The current irqchip API is like this:
>>
>> KVM_CREATE_IRQCHIP (without any parameters)
>> ...
>> KVM_CREATE_VCPU
>> KVM_SET_IRQCHIP (or the other way around)
>> ...
>> KVM_RUN
>>
>> The arguments you cannot
On 23 October 2012 11:48, Jan Kiszka wrote:
> The current irqchip API is like this:
>
> KVM_CREATE_IRQCHIP (without any parameters)
> ...
> KVM_CREATE_VCPU
> KVM_SET_IRQCHIP (or the other way around)
> ...
> KVM_RUN
>
> The arguments you cannot pass via KVM_CREATE_IRQCHIP - which is more
> like a
On 2012-10-18 15:48, Christoffer Dall wrote:
> On Wed, Oct 17, 2012 at 7:58 PM, Benjamin Herrenschmidt
> wrote:
>> On Thu, 2012-10-18 at 09:10 +1100, Paul Mackerras wrote:
>>>
>>> With the XICS, there are two types of irqchip: a source controller and
>>> a presentation controller. There is one pr
On 10/18/2012 03:49 PM, Alexander Graf wrote:
>
> On 18.10.2012, at 15:48, Christoffer Dall wrote:
>
>> On Wed, Oct 17, 2012 at 7:58 PM, Benjamin Herrenschmidt
>> wrote:
>>> On Thu, 2012-10-18 at 09:10 +1100, Paul Mackerras wrote:
With the XICS, there are two types of irqchip: a sourc
On 18.10.2012, at 15:48, Christoffer Dall wrote:
> On Wed, Oct 17, 2012 at 7:58 PM, Benjamin Herrenschmidt
> wrote:
>> On Thu, 2012-10-18 at 09:10 +1100, Paul Mackerras wrote:
>>>
>>> With the XICS, there are two types of irqchip: a source controller and
>>> a presentation controller. There is
On Wed, Oct 17, 2012 at 7:58 PM, Benjamin Herrenschmidt
wrote:
> On Thu, 2012-10-18 at 09:10 +1100, Paul Mackerras wrote:
>>
>> With the XICS, there are two types of irqchip: a source controller and
>> a presentation controller. There is one presentation controller per
>> vcpu and typically one s
On Thu, 2012-10-18 at 09:10 +1100, Paul Mackerras wrote:
>
> With the XICS, there are two types of irqchip: a source controller and
> a presentation controller. There is one presentation controller per
> vcpu and typically one source controller per PCI host bridge (a source
> controller can manag
On Wed, Oct 17, 2012 at 04:39:57PM -0400, Christoffer Dall wrote:
> On Wed, Oct 17, 2012 at 4:38 PM, Alexander Graf wrote:
> > On 10/14/2012 02:04 AM, Christoffer Dall wrote:
> >>
> >> *** warning: this RFC patch series is only compile-tested ***
> >>
> >> We need a way to specify the address at w
On Wed, 2012-10-17 at 16:39 -0400, Christoffer Dall wrote:
> > Have you talked to Ben about this one? He wanted to design a new, more
> > flexible irqchip API that would work for XICS & MPIC. Maybe there's some
> > room for cooperation here?
> >
> I have not - Ben, what do you have in mind?
I've
On Wed, Oct 17, 2012 at 4:38 PM, Alexander Graf wrote:
> On 10/14/2012 02:04 AM, Christoffer Dall wrote:
>>
>> *** warning: this RFC patch series is only compile-tested ***
>>
>> We need a way to specify the address at which we expect VMs to access
>> the interrupt controller (both the emulated di
On 10/14/2012 02:04 AM, Christoffer Dall wrote:
*** warning: this RFC patch series is only compile-tested ***
We need a way to specify the address at which we expect VMs to access
the interrupt controller (both the emulated distributor and the hardware
interface supporting virtualization). User
43 matches
Mail list logo
