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 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 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 generic.
On 26 October 2012 23:03, Benjamin Herrenschmidt
b...@kernel.crashing.org 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,
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 generic.
On 26 October 2012 23:03, Benjamin Herrenschmidt
b...@kernel.crashing.org 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,
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, set the
On 26 October 2012 10:58, Paolo Bonzini pbonz...@redhat.com 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
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 the ID range
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 existing ONE_REG
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
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 whenever the MSI
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 same
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 MSI-X routing
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 some MSI
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 messages
On 26 October 2012 11:44, Benjamin Herrenschmidt
b...@kernel.crashing.org 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
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. There
[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
On 26 October 2012 12:57, Paolo Bonzini pbonz...@redhat.com 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
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.
This was roughly the
On 2012-10-26 14:08, Peter Maydell wrote:
On 26 October 2012 12:57, Paolo Bonzini pbonz...@redhat.com 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
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 interrupt,
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 number and
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, set the
On 26 October 2012 10:58, Paolo Bonzini pbonz...@redhat.com 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
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 the ID range
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 existing ONE_REG
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
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 whenever the MSI
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 same
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 some MSI
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. There
[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
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 exclude
On 26 October 2012 12:57, Paolo Bonzini pbonz...@redhat.com 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
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.
This was roughly the
On 2012-10-26 14:08, Peter Maydell wrote:
On 26 October 2012 12:57, Paolo Bonzini pbonz...@redhat.com 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
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 target
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 number and
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 arguments you cannot
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? 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 interrupts
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 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 must
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 number
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 arguments you cannot
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? 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 interrupts
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 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 number
On 2012-10-18 15:48, Christoffer Dall wrote:
On Wed, Oct 17, 2012 at 7:58 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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.
On 23 October 2012 11:48, Jan Kiszka jan.kis...@siemens.com 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
On 2012-10-23 12:52, Peter Maydell wrote:
On 23 October 2012 11:48, Jan Kiszka jan.kis...@siemens.com 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
On 23 October 2012 12:00, Jan Kiszka jan.kis...@siemens.com 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
On 2012-10-23 13:04, Peter Maydell wrote:
On 23 October 2012 12:00, Jan Kiszka jan.kis...@siemens.com 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
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 is more
On 2012-10-18 15:48, Christoffer Dall wrote:
On Wed, Oct 17, 2012 at 7:58 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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.
On 23 October 2012 11:48, Jan Kiszka jan.kis...@siemens.com 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
On 2012-10-23 12:52, Peter Maydell wrote:
On 23 October 2012 11:48, Jan Kiszka jan.kis...@siemens.com 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
On 23 October 2012 12:00, Jan Kiszka jan.kis...@siemens.com 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
On 2012-10-23 13:04, Peter Maydell wrote:
On 23 October 2012 12:00, Jan Kiszka jan.kis...@siemens.com 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
On Wed, Oct 17, 2012 at 7:58 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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
On 18.10.2012, at 15:48, Christoffer Dall wrote:
On Wed, Oct 17, 2012 at 7:58 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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
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
b...@kernel.crashing.org wrote:
On Thu, 2012-10-18 at 09:10 +1100, Paul Mackerras wrote:
With the XICS, there are two types of irqchip:
On Wed, Oct 17, 2012 at 7:58 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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
On 18.10.2012, at 15:48, Christoffer Dall wrote:
On Wed, Oct 17, 2012 at 7:58 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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
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
b...@kernel.crashing.org wrote:
On Thu, 2012-10-18 at 09:10 +1100, Paul Mackerras wrote:
With the XICS, there are two types of irqchip:
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).
On Wed, Oct 17, 2012 at 4:38 PM, Alexander Graf ag...@suse.de 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
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 been
On Wed, Oct 17, 2012 at 04:39:57PM -0400, Christoffer Dall wrote:
On Wed, Oct 17, 2012 at 4:38 PM, Alexander Graf ag...@suse.de 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
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 manage
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).
On Wed, Oct 17, 2012 at 4:38 PM, Alexander Graf ag...@suse.de 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
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 been
On Wed, Oct 17, 2012 at 04:39:57PM -0400, Christoffer Dall wrote:
On Wed, Oct 17, 2012 at 4:38 PM, Alexander Graf ag...@suse.de 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
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 manage
*** 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 space should decide on this
address as user
79 matches
Mail list logo
