Il 05/03/2013 16:25, Gleb Natapov ha scritto:
1) We need to set the generic interrupt type of the system before we create
vcpus.
This is a new ioctl that sets the overall system interrupt controller type
to a specific model. This used so that when we create vcpus, we can create
the
On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
Il 05/03/2013 16:25, Gleb Natapov ha scritto:
1) We need to set the generic interrupt type of the system before we
create vcpus.
This is a new ioctl that sets the overall system interrupt controller type
to a specific
Am 06.03.2013 um 10:58 schrieb Gleb Natapov g...@redhat.com:
On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
Il 05/03/2013 16:25, Gleb Natapov ha scritto:
1) We need to set the generic interrupt type of the system before we
create vcpus.
This is a new ioctl that sets the
On Wed, Mar 06, 2013 at 11:04:21AM +0100, Alexander Graf wrote:
Am 06.03.2013 um 10:58 schrieb Gleb Natapov g...@redhat.com:
On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
Il 05/03/2013 16:25, Gleb Natapov ha scritto:
1) We need to set the generic interrupt type of the
...@samba.org, Peter
Maydell peter.mayd...@linaro.org
Inviato: Mercoledì, 6 marzo 2013 10:58:35
Oggetto: Re: in-kernel interrupt controller steering
On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
Il 05/03/2013 16:25, Gleb Natapov ha scritto:
1) We need to set the generic interrupt
...@samba.org, Peter
Maydell peter.mayd...@linaro.org
Inviato: Mercoledì, 6 marzo 2013 10:58:35
Oggetto: Re: in-kernel interrupt controller steering
On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
Il 05/03/2013 16:25, Gleb Natapov ha scritto:
1) We need to set the generic interrupt
...@freescale.com, Scott Wood scottw...@freescale.com, Paul
Mackerras pau...@samba.org, Peter
Maydell peter.mayd...@linaro.org
Inviato: Mercoledì, 6 marzo 2013 10:58:35
Oggetto: Re: in-kernel interrupt controller steering
On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
Il 05/03/2013
-...@vger.kernel.org, Stuart Yoder
stuart.yo...@freescale.com, Scott Wood scottw...@freescale.com, Paul
Mackerras pau...@samba.org, Peter
Maydell peter.mayd...@linaro.org
Inviato: Mercoledì, 6 marzo 2013 10:58:35
Oggetto: Re: in-kernel interrupt controller steering
On Wed, Mar 06, 2013 at 10:40:18AM +0100
So what is the difference between calling this special ioctl before
creating vcpus and calling create device ioctl instead and create
QEMU proxy device at whatever point in time QEMU wants to create
it?
Because you'd have to stash the handle that KVM_CREATE_DEVICE
returns
On 06.03.2013, at 12:44, Paolo Bonzini wrote:
So what is the difference between calling this special ioctl before
creating vcpus and calling create device ioctl instead and create
QEMU proxy device at whatever point in time QEMU wants to create
it?
Because you'd have to stash the handle
Please go ahead and try to describe an interface the way you envision
it. It needs to fulfill the following criteria:
* different machine models have different interrupt controller
types
* we need to be able to fetch information from interrupt
controllers, this should be as
On 06.03.2013, at 12:46, Paolo Bonzini wrote:
Please go ahead and try to describe an interface the way you envision
it. It needs to fulfill the following criteria:
* different machine models have different interrupt controller
types
* we need to be able to fetch information from
I agree. But is the device really being created at CREATE_DEVICE
time? What happens if you create N CPUs and N-1 irqchips?
irqchip in CREATE_DEVICE is the IOAPIC, not the LAPIC. The LAPIC gets
spawned at vcpu creation.
On x86, the LAPIC is created magically together with the VCPU.
On 06.03.2013, at 12:57, Paolo Bonzini wrote:
I agree. But is the device really being created at CREATE_DEVICE
time? What happens if you create N CPUs and N-1 irqchips?
irqchip in CREATE_DEVICE is the IOAPIC, not the LAPIC. The LAPIC gets
spawned at vcpu creation.
On x86, the LAPIC is
On 06.03.2013, at 12:59, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 12:46:52PM +0100, Alexander Graf wrote:
On 06.03.2013, at 12:44, Paolo Bonzini wrote:
So what is the difference between calling this special ioctl before
creating vcpus and calling create device ioctl instead and
So what is the difference between calling this special ioctl
before
creating vcpus and calling create device ioctl instead and
create
QEMU proxy device at whatever point in time QEMU wants to
create
it?
Because you'd have to stash the handle that KVM_CREATE_DEVICE
On 06.03.2013, at 13:14, Paolo Bonzini wrote:
So what is the difference between calling this special ioctl
before
creating vcpus and calling create device ioctl instead and
create
QEMU proxy device at whatever point in time QEMU wants to
create
it?
Because you'd have to stash the
Alex, would the PPC patches let you run with in-kernel LAPICs
and userspace IOAPICs? If so, the new model would not be a
problem with QEMU at all.
The split on PPC isn't that clean. The MPIC doesn't split it at all
for example. There we only have an IOAPIC without a LAPIC. So
setting
On Wed, Mar 06, 2013 at 12:46:52PM +0100, Alexander Graf wrote:
On 06.03.2013, at 12:44, Paolo Bonzini wrote:
So what is the difference between calling this special ioctl before
creating vcpus and calling create device ioctl instead and create
QEMU proxy device at whatever point in
On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alexander Graf wrote:
The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREATE_DEVICE.
Ah, I see. I don't see why it would. The fact that there is a LAPIC doesn't
mean that the
On Wed, Mar 06, 2013 at 12:58:39PM +0100, Alexander Graf wrote:
On 06.03.2013, at 12:57, Paolo Bonzini wrote:
I agree. But is the device really being created at CREATE_DEVICE
time? What happens if you create N CPUs and N-1 irqchips?
irqchip in CREATE_DEVICE is the IOAPIC, not the
On 06.03.2013, at 14:14, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alexander Graf wrote:
The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREATE_DEVICE.
Ah, I see. I don't see why it would. The fact
Il 06/03/2013 14:14, Gleb Natapov ha scritto:
The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREATE_DEVICE.
Ah, I see. I don't see why it would. The fact that there is a
LAPIC doesn't mean that the per-vcpu
On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:14, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alexander Graf wrote:
The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
KVM_CREATE_IRQCHIP_ARGS) forced you to later
On 06.03.2013, at 14:56, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:14, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alexander Graf wrote:
The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
On Wed, Mar 06, 2013 at 02:41:04PM +0100, Paolo Bonzini wrote:
Il 06/03/2013 14:14, Gleb Natapov ha scritto:
The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREATE_DEVICE.
Ah, I see. I don't see why it would. The
Il 06/03/2013 15:03, Alexander Graf ha scritto:
KVM_IRQ_LINE is basically an IOAPIC interrupt line assert. That's
fine. That ioctl should get an ioapic device handle to work on.
It would be a KVM_SET_DEVICE_ATTR in your case, right?
Whether we call the IOAPIC PINs GSIs or something different
On 06.03.2013, at 15:12, Paolo Bonzini wrote:
Il 06/03/2013 15:03, Alexander Graf ha scritto:
KVM_IRQ_LINE is basically an IOAPIC interrupt line assert. That's
fine. That ioctl should get an ioapic device handle to work on.
It would be a KVM_SET_DEVICE_ATTR in your case, right?
No, it
On 06.03.2013, at 15:11, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 02:41:04PM +0100, Paolo Bonzini wrote:
Il 06/03/2013 14:14, Gleb Natapov ha scritto:
The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREATE_DEVICE.
Il 06/03/2013 15:30, Alexander Graf ha scritto:
KVM_IRQ_LINE is basically an IOAPIC interrupt line assert. That's
fine. That ioctl should get an ioapic device handle to work on.
It would be a KVM_SET_DEVICE_ATTR in your case, right?
No, it would be KVM_IRQ_LINE. It's basically a command
On 06.03.2013, at 15:37, Paolo Bonzini wrote:
Il 06/03/2013 15:30, Alexander Graf ha scritto:
KVM_IRQ_LINE is basically an IOAPIC interrupt line assert. That's
fine. That ioctl should get an ioapic device handle to work on.
It would be a KVM_SET_DEVICE_ATTR in your case, right?
No, it
On Wed, Mar 06, 2013 at 03:03:53PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:56, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:14, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alexander Graf wrote:
On 06.03.2013, at 15:41, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 03:03:53PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:56, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:14, Gleb Natapov wrote:
On Wed, Mar 06, 2013
On 06.03.2013, at 15:48, Alexander Graf wrote:
On 06.03.2013, at 15:41, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 03:03:53PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:56, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
On 06.03.2013,
Il 06/03/2013 15:59, Alexander Graf ha scritto:
Then we don't care about any ordering at all anymore from KVM's
perspective. Alternatively, the above code could live inside kvm as
well of course. create_vcpu() would have to register itself with the
interrupt controller then to allow for
On Wed, Mar 06, 2013 at 03:48:54PM +0100, Alexander Graf wrote:
On 06.03.2013, at 15:41, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 03:03:53PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:56, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
Am 06.03.2013 um 16:30 schrieb Gleb Natapov g...@redhat.com:
On Wed, Mar 06, 2013 at 03:48:54PM +0100, Alexander Graf wrote:
On 06.03.2013, at 15:41, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 03:03:53PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:56, Gleb Natapov wrote:
On
On 6 March 2013 22:31, Alexander Graf ag...@suse.de wrote:
On 06.03.2013, at 15:11, Gleb Natapov wrote:
KVM_INTERRUPT is synchronous.
Ah, I think that's where my thinko is. On PPC, KVM_INTERRUPT is
asynchronous.
As an aside, would it be worth moving PPC into line with other
archs by
Am 06.03.2013 um 19:46 schrieb Peter Maydell peter.mayd...@linaro.org:
On 6 March 2013 22:31, Alexander Graf ag...@suse.de wrote:
On 06.03.2013, at 15:11, Gleb Natapov wrote:
KVM_INTERRUPT is synchronous.
Ah, I think that's where my thinko is. On PPC, KVM_INTERRUPT is
asynchronous.
As
On Wed, Mar 06, 2013 at 03:48:54PM +0100, Alexander Graf wrote:
Paul, Scott, do you think we can move the this CPU can receive
interrupts from MPIC / XICS part into an ENABLE_CAP that gets set
dynamically? That ENABLE_CAP would allocate the structures in the vcpu
and register the vcpu with
On Wed, Mar 06, 2013 at 03:48:54PM +0100, Alexander Graf wrote:
Paul, Scott, do you think we can move the this CPU can receive
interrupts from MPIC / XICS part into an ENABLE_CAP that gets set
dynamically? That ENABLE_CAP would allocate the structures in the
vcpu and register the vcpu
Il 05/03/2013 16:25, Gleb Natapov ha scritto:
1) We need to set the generic interrupt type of the system before we create
vcpus.
This is a new ioctl that sets the overall system interrupt controller type
to a specific model. This used so that when we create vcpus, we can create
the
On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
Il 05/03/2013 16:25, Gleb Natapov ha scritto:
1) We need to set the generic interrupt type of the system before we
create vcpus.
This is a new ioctl that sets the overall system interrupt controller type
to a specific
Am 06.03.2013 um 10:58 schrieb Gleb Natapov g...@redhat.com:
On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
Il 05/03/2013 16:25, Gleb Natapov ha scritto:
1) We need to set the generic interrupt type of the system before we
create vcpus.
This is a new ioctl that sets the
On Wed, Mar 06, 2013 at 11:04:21AM +0100, Alexander Graf wrote:
Am 06.03.2013 um 10:58 schrieb Gleb Natapov g...@redhat.com:
On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
Il 05/03/2013 16:25, Gleb Natapov ha scritto:
1) We need to set the generic interrupt type of the
...@samba.org, Peter
Maydell peter.mayd...@linaro.org
Inviato: Mercoledì, 6 marzo 2013 10:58:35
Oggetto: Re: in-kernel interrupt controller steering
On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
Il 05/03/2013 16:25, Gleb Natapov ha scritto:
1) We need to set the generic interrupt
...@samba.org, Peter
Maydell peter.mayd...@linaro.org
Inviato: Mercoledì, 6 marzo 2013 10:58:35
Oggetto: Re: in-kernel interrupt controller steering
On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
Il 05/03/2013 16:25, Gleb Natapov ha scritto:
1) We need to set the generic interrupt
...@freescale.com, Scott Wood scottw...@freescale.com, Paul
Mackerras pau...@samba.org, Peter
Maydell peter.mayd...@linaro.org
Inviato: Mercoledì, 6 marzo 2013 10:58:35
Oggetto: Re: in-kernel interrupt controller steering
On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote:
Il 05/03
@vger.kernel.org, Stuart Yoder
stuart.yo...@freescale.com, Scott Wood scottw...@freescale.com, Paul
Mackerras pau...@samba.org, Peter
Maydell peter.mayd...@linaro.org
Inviato: Mercoledì, 6 marzo 2013 10:58:35
Oggetto: Re: in-kernel interrupt controller steering
On Wed, Mar 06, 2013 at 10:40:18AM +0100
So what is the difference between calling this special ioctl before
creating vcpus and calling create device ioctl instead and create
QEMU proxy device at whatever point in time QEMU wants to create
it?
Because you'd have to stash the handle that KVM_CREATE_DEVICE
returns
On 06.03.2013, at 12:44, Paolo Bonzini wrote:
So what is the difference between calling this special ioctl before
creating vcpus and calling create device ioctl instead and create
QEMU proxy device at whatever point in time QEMU wants to create
it?
Because you'd have to stash the handle
Please go ahead and try to describe an interface the way you envision
it. It needs to fulfill the following criteria:
* different machine models have different interrupt controller
types
* we need to be able to fetch information from interrupt
controllers, this should be as
On 06.03.2013, at 12:46, Paolo Bonzini wrote:
Please go ahead and try to describe an interface the way you envision
it. It needs to fulfill the following criteria:
* different machine models have different interrupt controller
types
* we need to be able to fetch information from
I agree. But is the device really being created at CREATE_DEVICE
time? What happens if you create N CPUs and N-1 irqchips?
irqchip in CREATE_DEVICE is the IOAPIC, not the LAPIC. The LAPIC gets
spawned at vcpu creation.
On x86, the LAPIC is created magically together with the VCPU.
So what is the difference between calling this special ioctl
before
creating vcpus and calling create device ioctl instead and
create
QEMU proxy device at whatever point in time QEMU wants to
create
it?
Because you'd have to stash the handle that KVM_CREATE_DEVICE
On 06.03.2013, at 13:14, Paolo Bonzini wrote:
So what is the difference between calling this special ioctl
before
creating vcpus and calling create device ioctl instead and
create
QEMU proxy device at whatever point in time QEMU wants to
create
it?
Because you'd have to stash the
On Wed, Mar 06, 2013 at 12:46:52PM +0100, Alexander Graf wrote:
On 06.03.2013, at 12:44, Paolo Bonzini wrote:
So what is the difference between calling this special ioctl before
creating vcpus and calling create device ioctl instead and create
QEMU proxy device at whatever point in
On 06.03.2013, at 14:14, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alexander Graf wrote:
The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREATE_DEVICE.
Ah, I see. I don't see why it would. The fact
Il 06/03/2013 14:14, Gleb Natapov ha scritto:
The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREATE_DEVICE.
Ah, I see. I don't see why it would. The fact that there is a
LAPIC doesn't mean that the per-vcpu
On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:14, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alexander Graf wrote:
The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
KVM_CREATE_IRQCHIP_ARGS) forced you to later
On 06.03.2013, at 14:56, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:14, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alexander Graf wrote:
The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
On Wed, Mar 06, 2013 at 02:41:04PM +0100, Paolo Bonzini wrote:
Il 06/03/2013 14:14, Gleb Natapov ha scritto:
The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREATE_DEVICE.
Ah, I see. I don't see why it would. The
Il 06/03/2013 15:03, Alexander Graf ha scritto:
KVM_IRQ_LINE is basically an IOAPIC interrupt line assert. That's
fine. That ioctl should get an ioapic device handle to work on.
It would be a KVM_SET_DEVICE_ATTR in your case, right?
Whether we call the IOAPIC PINs GSIs or something different
On 06.03.2013, at 15:12, Paolo Bonzini wrote:
Il 06/03/2013 15:03, Alexander Graf ha scritto:
KVM_IRQ_LINE is basically an IOAPIC interrupt line assert. That's
fine. That ioctl should get an ioapic device handle to work on.
It would be a KVM_SET_DEVICE_ATTR in your case, right?
No, it
On 06.03.2013, at 15:11, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 02:41:04PM +0100, Paolo Bonzini wrote:
Il 06/03/2013 14:14, Gleb Natapov ha scritto:
The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of
KVM_CREATE_IRQCHIP_ARGS) forced you to later call KVM_CREATE_DEVICE.
Il 06/03/2013 15:30, Alexander Graf ha scritto:
KVM_IRQ_LINE is basically an IOAPIC interrupt line assert. That's
fine. That ioctl should get an ioapic device handle to work on.
It would be a KVM_SET_DEVICE_ATTR in your case, right?
No, it would be KVM_IRQ_LINE. It's basically a command
On 06.03.2013, at 15:37, Paolo Bonzini wrote:
Il 06/03/2013 15:30, Alexander Graf ha scritto:
KVM_IRQ_LINE is basically an IOAPIC interrupt line assert. That's
fine. That ioctl should get an ioapic device handle to work on.
It would be a KVM_SET_DEVICE_ATTR in your case, right?
No, it
On Wed, Mar 06, 2013 at 03:03:53PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:56, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:14, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 01:20:39PM +0100, Alexander Graf wrote:
On 06.03.2013, at 15:41, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 03:03:53PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:56, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:14, Gleb Natapov wrote:
On Wed, Mar 06, 2013
On 06.03.2013, at 15:48, Alexander Graf wrote:
On 06.03.2013, at 15:41, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 03:03:53PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:56, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
On 06.03.2013,
Il 06/03/2013 15:59, Alexander Graf ha scritto:
Then we don't care about any ordering at all anymore from KVM's
perspective. Alternatively, the above code could live inside kvm as
well of course. create_vcpu() would have to register itself with the
interrupt controller then to allow for
On Wed, Mar 06, 2013 at 03:48:54PM +0100, Alexander Graf wrote:
On 06.03.2013, at 15:41, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 03:03:53PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:56, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 02:22:15PM +0100, Alexander Graf wrote:
Am 06.03.2013 um 16:30 schrieb Gleb Natapov g...@redhat.com:
On Wed, Mar 06, 2013 at 03:48:54PM +0100, Alexander Graf wrote:
On 06.03.2013, at 15:41, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 03:03:53PM +0100, Alexander Graf wrote:
On 06.03.2013, at 14:56, Gleb Natapov wrote:
On
On 6 March 2013 22:31, Alexander Graf ag...@suse.de wrote:
On 06.03.2013, at 15:11, Gleb Natapov wrote:
KVM_INTERRUPT is synchronous.
Ah, I think that's where my thinko is. On PPC, KVM_INTERRUPT is
asynchronous.
As an aside, would it be worth moving PPC into line with other
archs by
Am 06.03.2013 um 19:46 schrieb Peter Maydell peter.mayd...@linaro.org:
On 6 March 2013 22:31, Alexander Graf ag...@suse.de wrote:
On 06.03.2013, at 15:11, Gleb Natapov wrote:
KVM_INTERRUPT is synchronous.
Ah, I think that's where my thinko is. On PPC, KVM_INTERRUPT is
asynchronous.
As
On Wed, Mar 06, 2013 at 03:48:54PM +0100, Alexander Graf wrote:
Paul, Scott, do you think we can move the this CPU can receive
interrupts from MPIC / XICS part into an ENABLE_CAP that gets set
dynamically? That ENABLE_CAP would allocate the structures in the vcpu
and register the vcpu with
On Wed, Mar 06, 2013 at 03:48:54PM +0100, Alexander Graf wrote:
Paul, Scott, do you think we can move the this CPU can receive
interrupts from MPIC / XICS part into an ENABLE_CAP that gets set
dynamically? That ENABLE_CAP would allocate the structures in the
vcpu and register the vcpu
On Mon, Mar 04, 2013 at 11:20:47PM +0100, Alexander Graf wrote:
Howdy,
We just sat down to discuss the proposed XICS and MPIC interfaces and how we
can take bits of each and create an interface that works for everyone. In
this, it feels like we came to some conclusions. Some of which we
On Mon, 2013-03-04 at 23:20 +0100, Alexander Graf wrote:
7) Interrupt line connections to vcpus are implicit
We don't explicitly mark which in-kernel irqchip interrupt line goes
to which vcpu. This is done implicitly. If we see a need for it, we
create a new irqchip device type that allows
On 06.03.2013, at 01:23, Benjamin Herrenschmidt wrote:
On Mon, 2013-03-04 at 23:20 +0100, Alexander Graf wrote:
7) Interrupt line connections to vcpus are implicit
We don't explicitly mark which in-kernel irqchip interrupt line goes
to which vcpu. This is done implicitly. If we see a need
On Mon, 2013-03-04 at 23:20 +0100, Alexander Graf wrote:
7) Interrupt line connections to vcpus are implicit
We don't explicitly mark which in-kernel irqchip interrupt line goes
to which vcpu. This is done implicitly. If we see a need for it, we
create a new irqchip device type that allows
On 03/04/2013 04:20:47 PM, Alexander Graf wrote:
Howdy,
We just sat down to discuss the proposed XICS and MPIC interfaces and
how we can take bits of each and create an interface that works for
everyone. In this, it feels like we came to some conclusions. Some of
which we already reached
On Mon, Mar 04, 2013 at 06:59:16PM -0600, Scott Wood wrote:
On 03/04/2013 04:20:47 PM, Alexander Graf wrote:
1) We need to set the generic interrupt type of the system before
we create vcpus.
This is a new ioctl that sets the overall system interrupt
controller type to a specific model.
On 03/04/2013 04:20:47 PM, Alexander Graf wrote:
Howdy,
We just sat down to discuss the proposed XICS and MPIC interfaces and
how we can take bits of each and create an interface that works for
everyone. In this, it feels like we came to some conclusions. Some of
which we already reached
On Mon, Mar 04, 2013 at 06:59:16PM -0600, Scott Wood wrote:
On 03/04/2013 04:20:47 PM, Alexander Graf wrote:
1) We need to set the generic interrupt type of the system before
we create vcpus.
This is a new ioctl that sets the overall system interrupt
controller type to a specific model.
85 matches
Mail list logo
