- Messaggio originale -
Da: Gleb Natapov g...@redhat.com
A: Paolo Bonzini pbonz...@redhat.com
Cc: Alexander Graf ag...@suse.de, k...@vger.kernel.org,
kvm-ppc@vger.kernel.org, Stuart Yoder
stuart.yo...@freescale.com, Scott Wood scottw...@freescale.com, Paul
Mackerras
On Wed, Mar 06, 2013 at 05:38:33AM -0500, Paolo Bonzini wrote:
- Messaggio originale -
Da: Gleb Natapov g...@redhat.com
A: Paolo Bonzini pbonz...@redhat.com
Cc: Alexander Graf ag...@suse.de, k...@vger.kernel.org,
kvm-ppc@vger.kernel.org, Stuart Yoder
On 06.03.2013, at 12:26, Gleb Natapov wrote:
On Wed, Mar 06, 2013 at 05:38:33AM -0500, Paolo Bonzini wrote:
- Messaggio originale -
Da: Gleb Natapov g...@redhat.com
A: Paolo Bonzini pbonz...@redhat.com
Cc: Alexander Graf ag...@suse.de, k...@vger.kernel.org,
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
Commit 523f0e5421c12610527c620b983b443f329e3a32 (KVM: PPC: E500:
Explicitly mark shadow maps invalid) began using E500_TLB_VALID
for guest TLB1 entries, and skipping invalidations if it's not set.
However, when E500_TLB_VALID was set for such entries, it was on a
fake local ref, and so the
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
This adds a new ioctl, KVM_SET_IRQ_ARCHITECTURE, which is intended to
be called by userspace to specify that it wishes the kernel to emulate
a specific interrupt controller architecture. This doesn't imply the
creation of any specific device, but does indicate that when vcpus are
created, space
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
101 - 133 of 133 matches
Mail list logo
