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 2012-10-25 11:22, Xiao Guangrong wrote:
In isapc, no i440x device exists in guest that means seabios can not
make 0xc to 0x100 writable
It works fine in current code since the guest can happily write readonly
memory. In order to support readonly slot in Qemu, we do not make the
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
Debugging crash, panics, stack trace WARN_ONs, etc., from both virtual and
bare-metal boots can get difficult very quickly. While there are ways to
decipher the output and determine if the output is from a virtual guest,
the in-kernel hypervisors now have a single registration point
and set
* Prarit Bhargava pra...@redhat.com wrote:
Debugging crash, panics, stack trace WARN_ONs, etc., from both virtual and
bare-metal boots can get difficult very quickly. While there are ways to
decipher the output and determine if the output is from a virtual guest,
the in-kernel hypervisors
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Remove duplicated include.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
tools/kvm/builtin-setup.c | 4
1 file changed, 4 deletions(-)
diff
On Fri, 26 Oct 2012, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Remove duplicated include.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
On Thu, 25 Oct 2012, Sasha Levin wrote:
On Thu, Oct 25, 2012 at 3:03 AM, Pekka Enberg penb...@kernel.org wrote:
On Wed, 24 Oct 2012, William Dauchy wrote:
when registering the config interrupt, the later is registered in
vcpi-config_vector and not in vpci-vq_vector
introduced in:
On Thu, 25 Oct 2012, Sasha Levin wrote:
I think we're seeing that because we don't handle VIRTIO_MSI_NO_VECTOR
properly.
We need to deal with the ability to remove GSI friends as well. I've
added it to my workqueue (unless someone deals with it first).
Any reason I shouldn't apply
On Fri, Oct 26, 2012 at 06:31:00PM +0300, Pekka Enberg wrote:
On Thu, 25 Oct 2012, Sasha Levin wrote:
I think we're seeing that because we don't handle VIRTIO_MSI_NO_VECTOR
properly.
We need to deal with the ability to remove GSI friends as well. I've
added it to my workqueue (unless
On Tue, Oct 09, 2012 at 08:08:47PM +0200, Andreas Färber wrote:
Hello Marcelo,
Here's a couple of backports for your stable-0.15 branch.
Except for one (marked as backported) these were all clean cherry-picks.
My proposal is to merge these KVM-only patches before qemu-stable-0.15.git,
On Thu, Oct 04, 2012 at 05:48:52PM -0300, Eduardo Habkost wrote:
Most of this series are just cleanups that will help when making -cpu
check/enforce work properly, with some fixes.
In addition to code movements, the main changes are:
- x2apic won't be enabled if in-kernel irqchip is
On Tue, Oct 09, 2012 at 12:43:52PM -0400, Don Slutz wrote:
On 10/09/12 10:03, Eduardo Habkost wrote:
This makes QEMU recognize the following CPU flag names:
Flags| Corresponding KVM kernel commit
-+
FSGSBASE |
On Tue, Oct 16, 2012 at 10:54:59AM +0200, Erik Brakkee wrote:
OS: Centos 6.2
KVM version: qemu-kvm-tools-0.12.1.2-2.209.el6_2.4.x86_64
qemu-kvm-0.12.1.2-2.209.el6_2.4.x86_64
uname -a:
Linux myhost 2.6.32-220.7.1.el6.x86_64 #1 SMP Wed Mar 7 00:52:02 GMT 2012
x86_64 x86_64 x86_64
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 Tue, Oct 23, 2012 at 07:56:54PM +, Auld, Will wrote:
Having looked closer at the tacked of changing out the index and data fields
in some
function calls for a struct parameter with these and a originator field (host
or guest)
it is less attractive than I thought it would be. The only
On Wed, Oct 17, 2012 at 11:03:42PM +0800, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
The variable base_gfn is initialized but never used
otherwise, so remove the unused variable.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
On Fri, Oct 12, 2012 at 03:43:23PM -0400, Don Slutz wrote:
Currently -cpu host,-kvmclock,-kvm_nopiodelay,-kvm_mmu does not
turn off all bits in CPUID 0x4001 EAX.
The missing ones are KVM_FEATURE_STEAL_TIME and
KVM_FEATURE_CLOCKSOURCE_STABLE_BIT.
This adds the names kvm_steal_time and
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
49 matches
Mail list logo
