On 03/06/2013 05:41 AM, Marcelo Tosatti wrote:
On Tue, Mar 05, 2013 at 02:22:08PM -0600, Michael Wolf wrote:
Sorry for the delay in the response. I did not see the email
right away.
On Mon, 2013-02-18 at 22:11 -0300, Marcelo Tosatti wrote:
On Mon, Feb 18, 2013 at 05:43:47PM +0100, Frederic
On Sun, Mar 03, 2013 at 11:17:38AM +0200, Gleb Natapov wrote:
On Thu, Feb 28, 2013 at 08:13:10PM +0800, Hu Tao wrote:
This series implements a new interface, kvm pv event, to notify host when
some events happen in guest. Right now there is one supported event: guest
panic.
What other
Hi,
On Mon, Mar 04, 2013 at 11:05:37AM +0100, Paolo Bonzini wrote:
Il 03/03/2013 10:17, Gleb Natapov ha scritto:
On Thu, Feb 28, 2013 at 08:13:10PM +0800, Hu Tao wrote:
This series implements a new interface, kvm pv event, to notify host when
some events happen in guest. Right now there is
On Tue, Mar 05, 2013 at 09:26:18AM +0100, Paolo Bonzini wrote:
Il 05/03/2013 04:17, Hu Tao ha scritto:
Will
if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
runstate_check(RUN_STATE_SHUTDOWN) ||
runstate_check(RUN_STATE_GUEST_PANICKED)) {
On Wed, Mar 06, 2013 at 02:16:27PM +0800, Asias He wrote:
This helper is useful to check if a feature is supported.
Signed-off-by: Asias He as...@redhat.com
---
drivers/vhost/tcm_vhost.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/vhost/tcm_vhost.c
Il 06/03/2013 09:56, Hu Tao ha scritto:
Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):
Device(PEVT) {
Name(_HID, EisaId(QEMU0001))
OperationRegion(PEOR, SystemIO, 0x505, 0x01)
Field(PEOR, ByteAcc, NoLock, Preserve) {
On Tue, Mar 05, 2013 at 11:14:31PM -0800, H. Peter Anvin wrote:
On 03/05/2013 04:05 PM, H. Peter Anvin wrote:
On 02/28/2013 07:24 AM, Michael S. Tsirkin wrote:
3. hypervisor assigned IO address
qemu can reserve IO addresses and assign to virtio devices.
2 bytes per device (for
在 2013-03-06三的 10:07 +0100，Paolo Bonzini写道：
Il 06/03/2013 09:56, Hu Tao ha scritto:
Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):
Device(PEVT) {
Name(_HID, EisaId(QEMU0001))
OperationRegion(PEOR, SystemIO, 0x505, 0x01)
On Wed, Mar 06, 2013 at 04:46:58PM +0800, Hu Tao wrote:
On Sun, Mar 03, 2013 at 11:17:38AM +0200, Gleb Natapov wrote:
On Thu, Feb 28, 2013 at 08:13:10PM +0800, Hu Tao wrote:
This series implements a new interface, kvm pv event, to notify host when
some events happen in guest. Right now
On Wed, Mar 06, 2013 at 10:07:31AM +0100, Paolo Bonzini wrote:
Il 06/03/2013 09:56, Hu Tao ha scritto:
Something like this should work (in SeaBIOS's src/acpi-dsdt-isa.dsl):
Device(PEVT) {
Name(_HID, EisaId(QEMU0001))
OperationRegion(PEOR, SystemIO, 0x505,
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:07:31AM +0100, Paolo Bonzini wrote:
Il 06/03/2013 09:56, Hu Tao ha scritto:
Something like this should work (in SeaBIOS's
src/acpi-dsdt-isa.dsl):
Device(PEVT) {
Name(_HID, EisaId(QEMU0001))
OperationRegion(PEOR,
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
On Wed, Mar 06, 2013 at 04:48:17AM -0500, Paolo Bonzini wrote:
On Wed, Mar 06, 2013 at 10:07:31AM +0100, Paolo Bonzini wrote:
Il 06/03/2013 09:56, Hu Tao ha scritto:
Something like this should work (in SeaBIOS's
src/acpi-dsdt-isa.dsl):
Device(PEVT) {
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
On Wed, Mar 06, 2013 at 01:48:33PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2013-02-13 at 23:49 -0600, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given architecture
only has one way to do it. If
- Messaggio originale -
Da: Gleb Natapov g...@redhat.com
A: Paolo Bonzini pbonz...@redhat.com
Cc: Alexander Graf ag...@suse.de, kvm@vger.kernel.org,
kvm-...@vger.kernel.org, Stuart Yoder
stuart.yo...@freescale.com, Scott Wood scottw...@freescale.com, Paul
Mackerras
- Messaggio originale -
Da: Gleb Natapov g...@redhat.com
A: Paolo Bonzini pbonz...@redhat.com
Cc: Alexander Graf ag...@suse.de, kvm@vger.kernel.org,
kvm-...@vger.kernel.org, Stuart Yoder
stuart.yo...@freescale.com, Scott Wood scottw...@freescale.com, Paul
Mackerras
On 03/06/2013 01:21 AM, Michael S. Tsirkin wrote:
Right. Though even with better granularify bridge windows
would still be a (smaller) problem causing fragmentation.
If we were to extend the PCI spec I would go for a bridge without
windows at all: a bridge can snoop on configuration
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, kvm@vger.kernel.org,
kvm-...@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, kvm@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.
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 Wed, Mar 06, 2013 at 03:15:16AM -0800, H. Peter Anvin wrote:
On 03/06/2013 01:21 AM, Michael S. Tsirkin wrote:
Right. Though even with better granularify bridge windows
would still be a (smaller) problem causing fragmentation.
If we were to extend the PCI spec I would go for a
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
2013/2/19 Marcelo Tosatti mtosa...@redhat.com:
On Mon, Feb 18, 2013 at 05:43:47PM +0100, Frederic Weisbecker wrote:
2013/2/5 Michael Wolf m...@linux.vnet.ibm.com:
In the case of where you have a system that is running in a
capped or overcommitted environment the user may see steal time
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
2013/3/5 Michael Wolf m...@linux.vnet.ibm.com:
Sorry for the delay in the response. I did not see the email
right away.
On Mon, 2013-02-18 at 22:11 -0300, Marcelo Tosatti wrote:
On Mon, Feb 18, 2013 at 05:43:47PM +0100, Frederic Weisbecker wrote:
2013/2/5 Michael Wolf
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
Il 05/03/2013 23:51, Nicholas A. Bellinger ha scritto:
For making progress with Paolo's vhost-scsi branch on my side, this was
still being blocked by bios boot hangs:
http://www.spinics.net/lists/target-devel/msg03830.html
Paolo Co, any ideas on the latter..?
Nope. Asias, do you have
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:
Properly set those bits to 1 that the spec demands in case bit 55 of
VMX_BASIC is 0 - like in our case.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Changes in v3:
- rebase over queue
arch/x86/include/asm/vmx.h |4
arch/x86/kvm/vmx.c | 13 ++---
2 files
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:
On Tue, 2013-03-05 at 22:41 -0300, Marcelo Tosatti wrote:
On Tue, Mar 05, 2013 at 02:22:08PM -0600, Michael Wolf wrote:
Sorry for the delay in the response. I did not see the email
right away.
On Mon, 2013-02-18 at 22:11 -0300, Marcelo Tosatti wrote:
On Mon, Feb 18, 2013 at
On Wed, 2013-03-06 at 12:13 +0400, Glauber Costa wrote:
On 03/06/2013 05:41 AM, Marcelo Tosatti wrote:
On Tue, Mar 05, 2013 at 02:22:08PM -0600, Michael Wolf wrote:
Sorry for the delay in the response. I did not see the email
right away.
On Mon, 2013-02-18 at 22:11 -0300, Marcelo
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 Wed, 2013-03-06 at 14:34 +0100, Frederic Weisbecker wrote:
2013/3/5 Michael Wolf m...@linux.vnet.ibm.com:
Sorry for the delay in the response. I did not see the email
right away.
On Mon, 2013-02-18 at 22:11 -0300, Marcelo Tosatti wrote:
On Mon, Feb 18, 2013 at 05:43:47PM +0100,
Il 06/03/2013 02:28, Asias He ha scritto:
This can queue up quite a bit of memory if the handler thread
is delayed, no? Can we limit the # of outstanding events?
Will guest recover from a missed event?
Hmm, good point. Will limit the number. The size of 'struct
tcm_vhost_evt' is around 20
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 Tue, Feb 26, 2013 at 05:40:10PM +, Peter Maydell wrote:
KVM ARM support has just hit Linus' kernel tree, so we can
finally commit this series to QEMU. Since all the patches got
reviewed last time round this should be ready to commit.
I plan to commit this via arm-devs.next.
NB: the
On Mar 2, 2013, at 7:45 AM, Peter Maydell wrote:
On 2 March 2013 15:18, Sanjay Lal sanj...@kymasys.com wrote:
+/* If we have an interrupt but the guest is not ready to receive an
+ * interrupt, request an interrupt window exit. This will
+ * cause a return to userspace as soon
On Mar 2, 2013, at 12:03 PM, Peter Maydell wrote:
On 2 March 2013 15:18, Sanjay Lal sanj...@kymasys.com wrote:
--- /dev/null
+++ b/hw/mips_cps_bootcode.h
@@ -0,0 +1,310 @@
+/* Sample boot code for 1004K CPS (Coherent Processing System.)
+ * Not Generic for all Release 2 or higher MIPS32 or
On Mar 2, 2013, at 7:27 AM, Peter Maydell wrote:
2013/3/2 Sanjay Lal sanj...@kymasys.com:
+static void gt64xxx_save(QEMUFile *f, void *opaque)
+{
+GT64120State *s = opaque;
+
+/* CPU Configuration */
+qemu_put_be32s(f, s-regs[GT_CPU]);
+qemu_put_be32s(f,
On Wed, Mar 06, 2013 at 01:12:52AM -0500, Paolo Bonzini wrote:
On Tue, Mar 05, 2013 at 08:16:41PM -0300, Marcelo Tosatti wrote:
On Mon, Mar 04, 2013 at 10:41:43PM +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
A VCPU sending INIT or SIPI to some other VCPU
On Wed, Mar 06, 2013 at 08:57:54AM +0100, Jan Kiszka wrote:
On 2013-03-06 07:12, Paolo Bonzini wrote:
On Tue, Mar 05, 2013 at 08:16:41PM -0300, Marcelo Tosatti wrote:
On Mon, Mar 04, 2013 at 10:41:43PM +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
A VCPU sending
On 2013-03-06 22:30, Marcelo Tosatti wrote:
On Wed, Mar 06, 2013 at 08:57:54AM +0100, Jan Kiszka wrote:
On 2013-03-06 07:12, Paolo Bonzini wrote:
On Tue, Mar 05, 2013 at 08:16:41PM -0300, Marcelo Tosatti wrote:
On Mon, Mar 04, 2013 at 10:41:43PM +0100, Jan Kiszka wrote:
From: Jan Kiszka
On Wed, Mar 06, 2013 at 10:39:27PM +0100, Jan Kiszka wrote:
On 2013-03-06 22:30, Marcelo Tosatti wrote:
On Wed, Mar 06, 2013 at 08:57:54AM +0100, Jan Kiszka wrote:
On 2013-03-06 07:12, Paolo Bonzini wrote:
On Tue, Mar 05, 2013 at 08:16:41PM -0300, Marcelo Tosatti wrote:
On Mon, Mar 04,
On 2013-03-06 22:50, Marcelo Tosatti wrote:
On Wed, Mar 06, 2013 at 10:39:27PM +0100, Jan Kiszka wrote:
On 2013-03-06 22:30, Marcelo Tosatti wrote:
On Wed, Mar 06, 2013 at 08:57:54AM +0100, Jan Kiszka wrote:
On 2013-03-06 07:12, Paolo Bonzini wrote:
On Tue, Mar 05, 2013 at 08:16:41PM -0300,
Il 06/03/2013 22:19, Marcelo Tosatti ha scritto:
Vcpu should only invoke kvm_emulate_halt if it has been through a
KVM_MP_STATE_UNINITIALIZED - KVM_MP_STATE_INIT_RECEIVED -
KVM_MP_STATE_SIPI_RECEIVED - KVM_MP_STATE_RUNNABLE transition.
If it has been through that, how can a
On Wed, Mar 06, 2013 at 11:43:30PM +0100, Paolo Bonzini wrote:
Il 06/03/2013 22:19, Marcelo Tosatti ha scritto:
Vcpu should only invoke kvm_emulate_halt if it has been through a
KVM_MP_STATE_UNINITIALIZED - KVM_MP_STATE_INIT_RECEIVED -
KVM_MP_STATE_SIPI_RECEIVED - KVM_MP_STATE_RUNNABLE
On Tue, Mar 05, 2013 at 02:42:54AM +, Marc Zyngier wrote:
This patch series is reworking KVM/arm in order to prepare the code
to be shared with the upcoming KVM/arm64.
Nothing major here, just a lot of accessors, small cleanups and fixes
to make the code useable on arm64.
This code
On Wed, Mar 06, 2013 at 10:21:09AM +0100, Stefan Hajnoczi wrote:
On Wed, Mar 06, 2013 at 02:16:30PM +0800, Asias He wrote:
+static struct tcm_vhost_evt *tcm_vhost_allocate_evt(struct vhost_scsi *vs,
+ u32 event, u32 reason)
+{
+ struct tcm_vhost_evt *evt;
+
+ if
(Re-sending this, since my Gmail interface decided to compose the
previous one in rich format and the kvm list rejected it - no changes
to the content)
Hi Marcelo / Gleb,
Please pull these KVM/ARM fixes mostly centered around preparation for
Marc's ARMv8 KVM work.
Thanks,
-Christoffer
The
On Wed, Mar 06, 2013 at 10:06:20AM +0100, Stefan Hajnoczi wrote:
On Wed, Mar 06, 2013 at 02:16:27PM +0800, Asias He wrote:
This helper is useful to check if a feature is supported.
Signed-off-by: Asias He as...@redhat.com
---
drivers/vhost/tcm_vhost.c | 14 ++
1 file
On Wed, Mar 06, 2013 at 06:41:47PM +0100, Paolo Bonzini wrote:
Il 06/03/2013 02:28, Asias He ha scritto:
This can queue up quite a bit of memory if the handler thread
is delayed, no? Can we limit the # of outstanding events?
Will guest recover from a missed event?
Hmm, good point. Will
On Mon, Mar 04, 2013 at 08:40:29PM +0100, Jan Kiszka wrote:
The logic for calculating the value with which we call kvm_set_cr0/4 was
broken (will definitely be visible with nested unrestricted guest mode
support). Also, we performed the check regarding CR0_ALWAYSON too early
when in guest
On Wed, Mar 06, 2013 at 03:44:03PM +0100, Jan Kiszka wrote:
Properly set those bits to 1 that the spec demands in case bit 55 of
VMX_BASIC is 0 - like in our case.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Changes in v3:
- rebase over queue
arch/x86/include/asm/vmx.h |
On Tue, Mar 05, 2013 at 03:18:00AM +, Marc Zyngier wrote:
In order to be able to correctly profile what is happening on the
host, we need to be able to identify when we're running on the guest,
and log these events differently.
Perf offers a simple way to register callbacks into KVM.
On Wed, Mar 06, 2013 at 03:28:00PM +0100, Paolo Bonzini wrote:
Il 05/03/2013 23:51, Nicholas A. Bellinger ha scritto:
For making progress with Paolo's vhost-scsi branch on my side, this was
still being blocked by bios boot hangs:
http://www.spinics.net/lists/target-devel/msg03830.html
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 10:29:12AM -0600, Michael Wolf wrote:
On Wed, 2013-03-06 at 12:13 +0400, Glauber Costa wrote:
On 03/06/2013 05:41 AM, Marcelo Tosatti wrote:
On Tue, Mar 05, 2013 at 02:22:08PM -0600, Michael Wolf wrote:
Sorry for the delay in the response. I did not see the email
On Wed, Mar 06, 2013 at 10:27:13AM -0600, Michael Wolf wrote:
On Tue, 2013-03-05 at 22:41 -0300, Marcelo Tosatti wrote:
On Tue, Mar 05, 2013 at 02:22:08PM -0600, Michael Wolf wrote:
Sorry for the delay in the response. I did not see the email
right away.
On Mon, 2013-02-18 at
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 09:52:16PM -0300, Marcelo Tosatti wrote:
On Wed, Mar 06, 2013 at 10:29:12AM -0600, Michael Wolf wrote:
I looked at doing that once but was told that I was changing the
interface in an unacceptable way, because now I was not reporting all of
the elapsed time. I agree
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, 6 Mar 2013 16:31:48 -0800, Christoffer Dall
cd...@cs.columbia.edu
wrote:
Hi Christoffer,
Please pull these KVM/ARM fixes mostly centered around preparation for
Marc's ARMv8 KVM work.
Can we please hold on that for a while? asm-offset.c is usually a
candidate for merge conflicts as
On Wed, Mar 6, 2013 at 7:54 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On Wed, 6 Mar 2013 16:31:48 -0800, Christoffer Dall
cd...@cs.columbia.edu
wrote:
Hi Christoffer,
Please pull these KVM/ARM fixes mostly centered around preparation for
Marc's ARMv8 KVM work.
Can we please hold on
After commit 2b8b328b61c799957a456a5a8dab8cc7dea68575 (vhost_net: handle polling
errors when setting backend), we in fact track the polling state through
poll-wqh, so there's no need to duplicate the work with an extra
vhost_net_polling_state. So this patch removes this and make the code simpler.
On Wed, 6 Mar 2013 20:40:00 -0800, Christoffer Dall
cd...@cs.columbia.edu
wrote:
On Wed, Mar 6, 2013 at 7:54 PM, Marc Zyngier marc.zyng...@arm.com
wrote:
On Wed, 6 Mar 2013 16:31:48 -0800, Christoffer Dall
cd...@cs.columbia.edu
wrote:
Hi Christoffer,
Please pull these KVM/ARM fixes mostly
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 08:40:29PM +0100, Jan Kiszka wrote:
The logic for calculating the value with which we call kvm_set_cr0/4 was
broken (will definitely be visible with nested unrestricted guest mode
support). Also, we performed the check regarding CR0_ALWAYSON too early
when in guest
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
On Wed, Mar 06, 2013 at 01:48:33PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2013-02-13 at 23:49 -0600, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given architecture
only has one way to do it. If
- 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
1 - 100 of 133 matches
Mail list logo
