[RFC][PATCH v2 0/4] uq/master: Basic MSI support for in-kernel irqchip mode
This is v2 of the RFC, fixing a memory leak in kvm_flush_dynamic_msi_routes and adding support for the proposed KVM_SIGNAL_MSI IOCTL. This series depends on kvm: set gsi_bits and max_gsi correctly (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/88906). Jan Kiszka (4): kvm: Refactor KVMState::max_gsi to gsi_count kvm: Introduce basic MSI support for in-kernel irqchips KVM: x86: Wire up MSI support for in-kernel irqchip kvm: Add support for direct MSI injections hw/apic.c |3 + hw/kvm/apic.c | 33 +- hw/pc.c |5 -- kvm-all.c | 195 +++-- kvm.h |1 + 5 files changed, 225 insertions(+), 12 deletions(-) -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH v2 4/4] kvm: Add support for direct MSI injections
From: Jan Kiszka jan.kis...@siemens.com
If the kernel supports KVM_SIGNAL_MSI, we can avoid the route-based
MSI injection mechanism.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kvm-all.c | 22 +++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 5256511..6225bab 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -95,6 +95,7 @@ struct KVMState
uint32_t *used_gsi_bitmap;
unsigned int gsi_count;
QTAILQ_HEAD(msi_hashtab, KVMMSIRoute) msi_hashtab[KVM_MSI_HASHTAB_SIZE];
+bool direct_msi;
#endif
};
@@ -895,8 +896,10 @@ static void kvm_init_irq_routing(KVMState *s)
s-irq_routes = g_malloc0(sizeof(*s-irq_routes));
s-nr_allocated_irq_routes = 0;
-for (i = 0; i KVM_MSI_HASHTAB_SIZE; i++) {
-QTAILQ_INIT(s-msi_hashtab[i]);
+if (!s-direct_msi) {
+for (i = 0; i KVM_MSI_HASHTAB_SIZE; i++) {
+QTAILQ_INIT(s-msi_hashtab[i]);
+}
}
kvm_arch_init_irq_routing(s);
@@ -1035,7 +1038,7 @@ again:
return bit - 1 + i * 32;
}
-if (retry) {
+if (!s-direct_msi retry) {
retry = false;
kvm_flush_dynamic_msi_routes(s);
goto again;
@@ -1062,8 +1065,19 @@ static KVMMSIRoute *kvm_lookup_msi_route(KVMState *s,
uint64_t addr,
int kvm_irqchip_send_msi(KVMState *s, uint64_t addr, uint32_t data)
{
+struct kvm_msi msi;
KVMMSIRoute *route;
+if (s-direct_msi) {
+msi.address_lo = (uint32_t)addr;
+msi.address_hi = addr 32;
+msi.data = data;
+msi.flags = 0;
+memset(msi.pad, 0, sizeof(msi.pad));
+
+return kvm_vm_ioctl(s, KVM_SIGNAL_MSI, msi);
+}
+
route = kvm_lookup_msi_route(s, addr, data);
if (!route) {
int gsi, ret;
@@ -1231,6 +1245,8 @@ int kvm_init(void)
s-pit_state2 = kvm_check_extension(s, KVM_CAP_PIT_STATE2);
#endif
+s-direct_msi = (kvm_check_extension(s, KVM_CAP_SIGNAL_MSI) 0);
+
ret = kvm_arch_init(s);
if (ret 0) {
goto err;
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH v2 2/4] kvm: Introduce basic MSI support for in-kernel irqchips
From: Jan Kiszka jan.kis...@siemens.com
This patch basically adds kvm_irqchip_send_msi, a service for sending
arbitrary MSI messages to KVM's in-kernel irqchip models.
As the current KVI API requires us to establish a static route from a
pseudo GSI to the target MSI message and inject the MSI via toggling
that GSI, we need to play some tricks to make this unfortunately
interface transparent. We create those routes on demand and keep them
in a hash table. Succeeding messages can then search for an existing
route in the table first and reuse it whenever possible. If we should
run out of limited GSIs, we simply flush the table and rebuild it as
messages are sent.
This approach is rather simple and could be optimized further. However,
future kernels will contain a more efficient MSI injection interface
that will obsolete the GSI-based dynamic injection.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kvm-all.c | 171 -
kvm.h |1 +
2 files changed, 171 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index eb0b4c0..5256511 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -48,6 +48,8 @@
do { } while (0)
#endif
+#define KVM_MSI_HASHTAB_SIZE256
+
typedef struct KVMSlot
{
target_phys_addr_t start_addr;
@@ -59,6 +61,11 @@ typedef struct KVMSlot
typedef struct kvm_dirty_log KVMDirtyLog;
+typedef struct KVMMSIRoute {
+struct kvm_irq_routing_entry kroute;
+QTAILQ_ENTRY(KVMMSIRoute) entry;
+} KVMMSIRoute;
+
struct KVMState
{
KVMSlot slots[32];
@@ -87,6 +94,7 @@ struct KVMState
int nr_allocated_irq_routes;
uint32_t *used_gsi_bitmap;
unsigned int gsi_count;
+QTAILQ_HEAD(msi_hashtab, KVMMSIRoute) msi_hashtab[KVM_MSI_HASHTAB_SIZE];
#endif
};
@@ -860,9 +868,14 @@ static void set_gsi(KVMState *s, unsigned int gsi)
s-used_gsi_bitmap[gsi / 32] |= 1U (gsi % 32);
}
+static void clear_gsi(KVMState *s, unsigned int gsi)
+{
+s-used_gsi_bitmap[gsi / 32] = ~(1U (gsi % 32));
+}
+
static void kvm_init_irq_routing(KVMState *s)
{
-int gsi_count;
+int gsi_count, i;
gsi_count = kvm_check_extension(s, KVM_CAP_IRQ_ROUTING);
if (gsi_count 0) {
@@ -882,6 +895,10 @@ static void kvm_init_irq_routing(KVMState *s)
s-irq_routes = g_malloc0(sizeof(*s-irq_routes));
s-nr_allocated_irq_routes = 0;
+for (i = 0; i KVM_MSI_HASHTAB_SIZE; i++) {
+QTAILQ_INIT(s-msi_hashtab[i]);
+}
+
kvm_arch_init_irq_routing(s);
}
@@ -912,6 +929,54 @@ static void kvm_add_routing_entry(KVMState *s,
set_gsi(s, entry-gsi);
}
+static void kvm_remove_routing_entry(KVMState *s,
+ struct kvm_irq_routing_entry *entry)
+{
+struct kvm_irq_routing_entry *e;
+int gsi = entry-gsi;
+int i;
+
+for (i = 0; i s-irq_routes-nr; ++i) {
+e = s-irq_routes-entries[i];
+if (e-type == entry-type e-gsi == gsi) {
+switch (e-type) {
+case KVM_IRQ_ROUTING_IRQCHIP:
+if (e-u.irqchip.irqchip == entry-u.irqchip.irqchip
+e-u.irqchip.pin == entry-u.irqchip.pin) {
+goto found;
+}
+break;
+case KVM_IRQ_ROUTING_MSI:
+if (e-u.msi.address_lo == entry-u.msi.address_lo
+e-u.msi.address_hi == entry-u.msi.address_hi
+e-u.msi.data == entry-u.msi.data) {
+goto found;
+}
+break;
+default:
+break;
+}
+}
+}
+/* route not found */
+return;
+
+found:
+s-irq_routes-nr--;
+*e = s-irq_routes-entries[s-irq_routes-nr];
+
+/* If there are no other users of this GSI, release it. */
+for (i = 0; i s-irq_routes-nr; i++) {
+e = s-irq_routes-entries[i];
+if (e-gsi == gsi) {
+break;
+}
+}
+if (i == s-irq_routes-nr) {
+clear_gsi(s, gsi);
+}
+}
+
void kvm_irqchip_add_route(KVMState *s, int irq, int irqchip, int pin)
{
struct kvm_irq_routing_entry e;
@@ -932,11 +997,115 @@ int kvm_irqchip_commit_routes(KVMState *s)
return kvm_vm_ioctl(s, KVM_SET_GSI_ROUTING, s-irq_routes);
}
+static unsigned int kvm_hash_msi(uint32_t data)
+{
+/* This is optimized for IA32 MSI layout. However, no other arch shall
+ * repeat the mistake of not providing a direct MSI injection API. */
+return data 0xff;
+}
+
+static void kvm_flush_dynamic_msi_routes(KVMState *s)
+{
+KVMMSIRoute *route, *next;
+unsigned int hash;
+
+for (hash = 0; hash KVM_MSI_HASHTAB_SIZE; hash++) {
+QTAILQ_FOREACH_SAFE(route, s-msi_hashtab[hash], entry, next) {
+kvm_remove_routing_entry(s, route-kroute);
+QTAILQ_REMOVE(s-msi_hashtab[hash], route, entry);
+g_free(route);
+}
+}
+}
+
+static int kvm_get_pseudo_gsi(KVMState *s)
+{
+
[RFC][PATCH v2 1/4] kvm: Refactor KVMState::max_gsi to gsi_count
From: Jan Kiszka jan.kis...@siemens.com
Instead of the bitmap size, store the maximum of GSIs the kernel
support. Move the GSI limit assertion to the API function
kvm_irqchip_add_route and make it stricter.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kvm-all.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index b8e9dc6..eb0b4c0 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -86,7 +86,7 @@ struct KVMState
struct kvm_irq_routing *irq_routes;
int nr_allocated_irq_routes;
uint32_t *used_gsi_bitmap;
-unsigned int max_gsi;
+unsigned int gsi_count;
#endif
};
@@ -857,8 +857,6 @@ int kvm_irqchip_set_irq(KVMState *s, int irq, int level)
#ifdef KVM_CAP_IRQ_ROUTING
static void set_gsi(KVMState *s, unsigned int gsi)
{
-assert(gsi s-max_gsi);
-
s-used_gsi_bitmap[gsi / 32] |= 1U (gsi % 32);
}
@@ -873,7 +871,7 @@ static void kvm_init_irq_routing(KVMState *s)
/* Round up so we can search ints using ffs */
gsi_bits = ALIGN(gsi_count, 32);
s-used_gsi_bitmap = g_malloc0(gsi_bits / 8);
-s-max_gsi = gsi_bits;
+s-gsi_count = gsi_count;
/* Mark any over-allocated bits as already in use */
for (i = gsi_count; i gsi_bits; i++) {
@@ -918,6 +916,8 @@ void kvm_irqchip_add_route(KVMState *s, int irq, int
irqchip, int pin)
{
struct kvm_irq_routing_entry e;
+assert(pin s-gsi_count);
+
e.gsi = irq;
e.type = KVM_IRQ_ROUTING_IRQCHIP;
e.flags = 0;
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH v2 3/4] KVM: x86: Wire up MSI support for in-kernel irqchip
From: Jan Kiszka jan.kis...@siemens.com
Catch writes to the MSI MMIO region in the KVM APIC and forward them to
the kernel. Provide the kernel support GSI routing, this allows to
enable MSI support also for in-kernel irqchip mode.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/apic.c |3 +++
hw/kvm/apic.c | 33 +++--
hw/pc.c |5 -
3 files changed, 34 insertions(+), 7 deletions(-)
diff --git a/hw/apic.c b/hw/apic.c
index 4eeaf88..5fbf01c 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -19,6 +19,7 @@
#include apic_internal.h
#include apic.h
#include ioapic.h
+#include msi.h
#include host-utils.h
#include trace.h
#include pc.h
@@ -862,6 +863,8 @@ static void apic_init(APICCommonState *s)
s-timer = qemu_new_timer_ns(vm_clock, apic_timer, s);
local_apics[s-idx] = s;
+
+msi_supported = true;
}
static void apic_class_init(ObjectClass *klass, void *data)
diff --git a/hw/kvm/apic.c b/hw/kvm/apic.c
index ffe7a52..7d83b1a 100644
--- a/hw/kvm/apic.c
+++ b/hw/kvm/apic.c
@@ -10,6 +10,7 @@
* See the COPYING file in the top-level directory.
*/
#include hw/apic_internal.h
+#include hw/msi.h
#include kvm.h
static inline void kvm_apic_set_reg(struct kvm_lapic_state *kapic,
@@ -145,10 +146,38 @@ static void kvm_apic_external_nmi(APICCommonState *s)
run_on_cpu(s-cpu_env, do_inject_external_nmi, s);
}
+static uint64_t kvm_apic_mem_read(void *opaque, target_phys_addr_t addr,
+ unsigned size)
+{
+return -1U;
+}
+
+static void kvm_apic_mem_write(void *opaque, target_phys_addr_t addr,
+ uint64_t data, unsigned size)
+{
+int ret;
+
+ret = kvm_irqchip_send_msi(kvm_state, addr, data);
+if (ret 0) {
+fprintf(stderr, KVM: injection failed, MSI lost (%s)\n,
+strerror(-ret));
+}
+}
+
+static const MemoryRegionOps kvm_apic_io_ops = {
+.read = kvm_apic_mem_read,
+.write = kvm_apic_mem_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
static void kvm_apic_init(APICCommonState *s)
{
-memory_region_init_reservation(s-io_memory, kvm-apic-msi,
- MSI_SPACE_SIZE);
+memory_region_init_io(s-io_memory, kvm_apic_io_ops, s, kvm-apic-msi,
+ MSI_SPACE_SIZE);
+
+if (kvm_has_gsi_routing()) {
+msi_supported = true;
+}
}
static void kvm_apic_class_init(ObjectClass *klass, void *data)
diff --git a/hw/pc.c b/hw/pc.c
index 83a1b5b..fab620a 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -907,11 +907,6 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
apic_mapped = 1;
}
-/* KVM does not support MSI yet. */
-if (!kvm_irqchip_in_kernel()) {
-msi_supported = true;
-}
-
return dev;
}
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 42635] PCIe passthrough broken with AMD iommu after s2disk / resume
https://bugzilla.kernel.org/show_bug.cgi?id=42635 --- Comment #3 from Klaus Mueller kmuel...@justmail.de 2012-04-03 07:27:43 --- Meanwhile I detected, that using the boot option iommu=pt (or additional iommu=1) shows the same problem (regardless of suspend/resume). If the VM is started after the first virsh start / virsh shutdown cycle with virsh start again, the device is dead in the VM. Host must be rebooted to get it working again. If the options iommu=pt (or additional iommu=1) are not used at all, the VM can be restarted without any problem coming up. 1. Host booted w/ iommu=pt iommu=1 2. virsh start 3. virsh shutdown 4. virsh start 5. - Passed through device in VM is dead. 1. Host booted w/o iommu=pt iommu=1 2. virsh start 3. virsh shutdown 4. virsh start 5. - Passed through device in VM is fine. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm: RCU warning in async pf
On Mon, Apr 02, 2012 at 08:54:32PM -0400, Sasha Levin wrote:
Hi all,
I got the spew at the bottom of the mail in a KVM guest using the KVM tools
and running trinity.
I'm not quite sure how default_idle managed to trigger a pagefault, so that
part looks odd to me.
This is not regular page fault. This is async page fault that tells the
guest that a page, previously swapped out by hypervisor, is now swapped
back in and it can happen while vcpu is idle. The code does not leave
idle state properly though. We probably need to call rcu_irq_enter()
there. Will look into it.
[12140.220507] ===
[12140.220507] [ INFO: suspicious RCU usage. ]
[12140.220507] 3.4.0-rc1-next-20120402-sasha #46 Tainted: GW
[12140.220507] ---
[12140.220507] include/linux/rcupdate.h:729 rcu_read_lock() used illegally
while idle!
[12140.220507]
[12140.220507] other info that might help us debug this:
[12140.220507]
[12140.220507]
[12140.220507] RCU used illegally from idle CPU!
[12140.220507] rcu_scheduler_active = 1, debug_locks = 1
[12140.220507] RCU used illegally from extended quiescent state!
[12140.220507] 4 locks held by swapper/1/0:
[12140.253991] #0: ((async_pf_sleepers[i].lock)-rlock){..-...}, at:
[8107cdc8] kvm_async_pf_task_wake+0x48/0x130
[12140.253991] #1: (n.wq){..}, at: [810e200d]
__wake_up+0x2d/0x70
[12140.253991] #2: (p-pi_lock){-.-.-.}, at: [810ec404]
try_to_wake_up+0x34/0x290
[12140.253991] #3: (rcu_read_lock){.+.+..}, at: [810f3c80]
select_task_rq_fair+0xb0/0x5c0
[12140.253991]
[12140.253991] stack backtrace:
[12140.253991] Pid: 0, comm: swapper/1 Tainted: GW
3.4.0-rc1-next-20120402-sasha #46
[12140.253991] Call Trace:
[12140.253991] [81114173] lockdep_rcu_suspicious+0x113/0x130
[12140.253991] [810f3ce5] select_task_rq_fair+0x115/0x5c0
[12140.253991] [810f3c80] ? select_task_rq_fair+0xb0/0x5c0
[12140.253991] [810ec404] ? try_to_wake_up+0x34/0x290
[12140.253991] [810ec404] ? try_to_wake_up+0x34/0x290
[12140.253991] [810ec561] try_to_wake_up+0x191/0x290
[12140.253991] [81114850] ? __lock_acquired+0x1c0/0x210
[12140.253991] [810ec66d] default_wake_function+0xd/0x10
[12140.253991] [810d7208] autoremove_wake_function+0x18/0x40
[12140.253991] [810e11e2] __wake_up_common+0x52/0x90
[12140.253991] [810e200d] ? __wake_up+0x2d/0x70
[12140.253991] [810e2023] __wake_up+0x43/0x70
[12140.253991] [8107cb07] apf_task_wake_one+0x87/0x90
[12140.253991] [8107cdf5] kvm_async_pf_task_wake+0x75/0x130
[12140.253991] [8107d1e6] do_async_page_fault+0x86/0xa0
[12140.253991] [82657a55] async_page_fault+0x25/0x30
[12140.253991] [8107d626] ? native_safe_halt+0x6/0x10
[12140.253991] [81116fed] ? trace_hardirqs_on+0xd/0x10
[12140.253991] [8105857d] default_idle+0x4d/0xa0
[12140.253991] [810582af] cpu_idle+0x11f/0x180
[12140.253991] [8264b9e0] ? setup_APIC_timer+0x88/0x8c
[12140.253991] [8264b004] start_secondary+0xe1/0xe8
[12140.253991]
[12140.253991] ===
[12140.253991] [ INFO: suspicious RCU usage. ]
[12140.253991] 3.4.0-rc1-next-20120402-sasha #46 Tainted: GW
[12140.253991] ---
[12140.253991] kernel/sched/fair.c:2716 suspicious rcu_dereference_check()
usage!
[12140.253991]
[12140.253991] other info that might help us debug this:
[12140.253991]
[12140.253991]
[12140.253991] RCU used illegally from idle CPU!
[12140.253991] rcu_scheduler_active = 1, debug_locks = 1
[12140.253991] RCU used illegally from extended quiescent state!
[12140.253991] 4 locks held by swapper/1/0:
[12140.253991] #0: ((async_pf_sleepers[i].lock)-rlock){..-...}, at:
[8107cdc8] kvm_async_pf_task_wake+0x48/0x130
[12140.253991] #1: (n.wq){..}, at: [810e200d]
__wake_up+0x2d/0x70
[12140.253991] #2: (p-pi_lock){-.-.-.}, at: [810ec404]
try_to_wake_up+0x34/0x290
[12140.253991] #3: (rcu_read_lock){.+.+..}, at: [810f3c80]
select_task_rq_fair+0xb0/0x5c0
[12140.253991]
[12140.253991] stack backtrace:
[12140.253991] Pid: 0, comm: swapper/1 Tainted: GW
3.4.0-rc1-next-20120402-sasha #46
[12140.253991] Call Trace:
[12140.253991] [81114173] lockdep_rcu_suspicious+0x113/0x130
[12140.253991] [810f3d4c] select_task_rq_fair+0x17c/0x5c0
[12140.253991] [810f3c80] ? select_task_rq_fair+0xb0/0x5c0
[12140.253991] [810ec404] ? try_to_wake_up+0x34/0x290
[12140.253991] [810ec404] ? try_to_wake_up+0x34/0x290
[12140.253991] [810ec561] try_to_wake_up+0x191/0x290
[12140.253991] [81114850] ? __lock_acquired+0x1c0/0x210
[12140.253991] [810ec66d] default_wake_function+0xd/0x10
[12140.253991]
[GIT PULL] Please pull powerpc KVM fixes
Avi, The following changes since commit 592f5d87b3feee9d60411f19d583038c0c7670ad: KVM: PPC: Book3S: PR: Fix preemption (2012-04-03 16:42:39 +1000) are available in the git repository at: git://github.com/paulusmack/linux tags/powerpc-fixes for you to fetch changes up to 592f5d87b3feee9d60411f19d583038c0c7670ad: KVM: PPC: Book3S: PR: Fix preemption (2012-04-03 16:42:39 +1000) Five fixes for bugs that have crept in to the powerpc KVM implementations. These are all small simple patches that only affect arch/powerpc/kvm. They come from the series that Alex Graf put together but which was too late for the 3.4 merge window. Please pull these and send them to Linus for inclusion in 3.4. The powerpc-fixes tag is a signed tag, signed with my signing key with ID 05F66CE9. Thanks, Paul. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] virt: Repairs aexpect expect.read_nonblocking infinite read.
Signed-off-by: Jiří Župka jzu...@redhat.com --- client/tests/kvm/tests/ksm_overcommit.py |2 +- client/tests/kvm/tests/virtio_console.py |2 +- client/virt/aexpect.py | 28 ++-- client/virt/deps/test_cpu_flags/stress.c |2 +- 4 files changed, 21 insertions(+), 13 deletions(-) diff --git a/client/tests/kvm/tests/ksm_overcommit.py b/client/tests/kvm/tests/ksm_overcommit.py index 3614aea..8511818 100644 --- a/client/tests/kvm/tests/ksm_overcommit.py +++ b/client/tests/kvm/tests/ksm_overcommit.py @@ -200,7 +200,7 @@ def run_ksm_overcommit(test, params, env): free_mem, (i - 1)) last_vm = i break -out = session.read_nonblocking(0.1) +out = session.read_nonblocking(0.1, 1) time.sleep(2) except OSError: logging.debug(Only %s host free memory, killing %d guests, diff --git a/client/tests/kvm/tests/virtio_console.py b/client/tests/kvm/tests/virtio_console.py index a52b9e1..c3395e8 100644 --- a/client/tests/kvm/tests/virtio_console.py +++ b/client/tests/kvm/tests/virtio_console.py @@ -598,7 +598,7 @@ def run_virtio_console(test, params, env): @return: Kernel crash log or None. -data = vm_port.read_nonblocking() +data = vm_port.read_nonblocking(0.1, timeout) match = re.search(BUG:, data, re.MULTILINE) if match is None: return None diff --git a/client/virt/aexpect.py b/client/virt/aexpect.py index d75bbe1..25ec62d 100755 --- a/client/virt/aexpect.py +++ b/client/virt/aexpect.py @@ -901,20 +901,25 @@ class Expect(Tail): return Tail.__getinitargs__(self) -def read_nonblocking(self, timeout=None): +def read_nonblocking(self, internal_timeout=None, timeout=None): Read from child until there is nothing to read for timeout seconds. -@param timeout: Time (seconds) to wait before we give up reading from -the child process, or None to use the default value. +@param internal_timeout: Time (seconds) to wait before we give up + reading from the child process, or None to + use the default value. +@param timeout: Timeout for reading child process output. -if timeout is None: -timeout = 0.1 +if internal_timeout is None: +internal_timeout = 0.1 +end_time = None +if timeout: +end_time = time.time() + timeout fd = self._get_fd(expect) data = while True: try: -r, w, x = select.select([fd], [], [], timeout) +r, w, x = select.select([fd], [], [], internal_timeout) except Exception: return data if fd in r: @@ -924,6 +929,8 @@ class Expect(Tail): data += new_data else: return data +if end_time and time.time() end_time: +return data def match_patterns(self, str, patterns): @@ -980,7 +987,8 @@ class Expect(Tail): if not r: raise ExpectTimeoutError(patterns, o) # Read data from child -data = self.read_nonblocking(internal_timeout) +data = self.read_nonblocking(internal_timeout, + end_time - time.time()) if not data: break # Print it if necessary @@ -1157,14 +1165,14 @@ class ShellSession(Expect): # Read all output that's waiting to be read, to make sure the output # we read next is in response to the newline sent -self.read_nonblocking(timeout=0) +self.read_nonblocking(internal_timeout=0, timeout=timeout) # Send a newline self.sendline() # Wait up to timeout seconds for some output from the child end_time = time.time() + timeout while time.time() end_time: time.sleep(0.5) -if self.read_nonblocking(timeout=0).strip(): +if self.read_nonblocking(0, end_time-time.time()).strip(): return True # No output -- report unresponsive return False @@ -1224,7 +1232,7 @@ class ShellSession(Expect): return .join(str.rstrip().splitlines(True)[:-1]) logging.debug(Sending command: %s % cmd) -self.read_nonblocking(timeout=0) +self.read_nonblocking(0, timeout) self.sendline(cmd) try: o = self.read_up_to_prompt(timeout, internal_timeout, print_func) diff --git a/client/virt/deps/test_cpu_flags/stress.c b/client/virt/deps/test_cpu_flags/stress.c index 3c35e59..ae424c2 100644 --- a/client/virt/deps/test_cpu_flags/stress.c +++ b/client/virt/deps/test_cpu_flags/stress.c @@
Re: [GIT PULL] Please pull powerpc KVM fixes
On Tue, Apr 03, 2012 at 10:03:05PM +1000, Paul Mackerras wrote: The following changes since commit 592f5d87b3feee9d60411f19d583038c0c7670ad: OK, I messed up the git request-pull command. The request should have looked like this: The following changes since commit b1a808ff436343956a6ae63178ea1810c5e5a3a1: Merge branch 'for-next' of git://gitorious.org/kernel-hsi/kernel-hsi (2012-04-02 09:50:40 -0700) are available in the git repository at: git://github.com/paulusmack/linux tags/powerpc-fixes for you to fetch changes up to 592f5d87b3feee9d60411f19d583038c0c7670ad: KVM: PPC: Book3S: PR: Fix preemption (2012-04-03 16:42:39 +1000) Five fixes for bugs that have crept in to the powerpc KVM implementations. These are all small simple patches that only affect arch/powerpc/kvm. They come from the series that Alex Graf put together but which was too late for the 3.4 merge window. Alexander Graf (3): KVM: PPC: Book3S: Compile fix for ppc32 in HIOR access code KVM: PPC: Save/Restore CR over vcpu_run KVM: PPC: Book3S: PR: Fix preemption Paul Mackerras (2): KVM: PPC: Book3S HV: Fix kvm_alloc_linear in case where no linears exist KVM: PPC: Book3S HV: Save and restore CR in __kvmppc_vcore_entry arch/powerpc/kvm/book3s_hv_builtin.c|9 + arch/powerpc/kvm/book3s_hv_interrupts.S |8 ++-- arch/powerpc/kvm/book3s_interrupts.S|7 +++ arch/powerpc/kvm/book3s_pr.c|9 + arch/powerpc/kvm/booke_interrupts.S |7 ++- 5 files changed, 29 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/13] KVM: MMU: fast path of handling guest page fault
On 04/01/2012 07:23 PM, Avi Kivity wrote:
On 03/29/2012 11:27 AM, Xiao Guangrong wrote:
If the the present bit of page fault error code is set, it indicates
the shadow page is populated on all levels, it means what we do is only
modify the access bit which can be done out of mmu-lock
The tricks in this patch is avoiding the race between fast page fault
path and write-protect path, write-protect path is a read-check-modify
path:
read spte, check W bit, then clear W bit. What we do is populating a
identification in spte, if write-protect meets it, it modify the spte
even if the spte is readonly. See the comment in the code to get more
information
+
+static bool page_fault_can_be_fast(struct kvm_vcpu *vcpu, gfn_t gfn,
+ u32 error_code)
+{
+ unsigned long *rmap;
+ bool write = error_code PFERR_WRITE_MASK;
+
+ /*
+* #PF can be fast only if the shadow page table is present, that
+* means we just need change the access bits (e.g: R/W, U/S...)
+* which can be done out of mmu-lock.
+*/
+ if (!(error_code PFERR_PRESENT_MASK))
+ return false;
+
+ if (unlikely(vcpu-vcpu_id max_vcpu_spte()))
+ return false;
+
+ rmap = gfn_to_rmap(vcpu-kvm, gfn, PT_PAGE_TABLE_LEVEL);
What prevents sp-gfns from being freed while this is going on? Did I
miss the patch that makes mmu pages freed by rcu? Also need barriers in
kvm_mmu_get_page() to make sure sp-gfns is made visible before the page
is hashed in.
Ah, it's call_rcu in kvm_mmu_commit_zap_page().
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 0/4] uq/master: Basic MSI support for in-kernel irqchip mode
On Tue, Apr 03, 2012 at 09:23:12AM +0200, Jan Kiszka wrote: This is v2 of the RFC, fixing a memory leak in kvm_flush_dynamic_msi_routes and adding support for the proposed KVM_SIGNAL_MSI IOCTL. This series depends on kvm: set gsi_bits and max_gsi correctly (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/88906). Looks good to me. How hard would it be to add irqfd support? Jan Kiszka (4): kvm: Refactor KVMState::max_gsi to gsi_count kvm: Introduce basic MSI support for in-kernel irqchips KVM: x86: Wire up MSI support for in-kernel irqchip kvm: Add support for direct MSI injections hw/apic.c |3 + hw/kvm/apic.c | 33 +- hw/pc.c |5 -- kvm-all.c | 195 +++-- kvm.h |1 + 5 files changed, 225 insertions(+), 12 deletions(-) -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm: RCU warning in async pf
On Mon, Apr 02, 2012 at 08:54:32PM -0400, Sasha Levin wrote:
Hi all,
I got the spew at the bottom of the mail in a KVM guest using the KVM tools
and running trinity.
I'm not quite sure how default_idle managed to trigger a pagefault, so that
part looks odd to me.
Wrapping the offending RCU read-side critical section in RCU_NONIDLE()
is the intended solution -- though that assumes that you can tell where
the page fault will occur.
Thanx, Paul
[12140.220507] ===
[12140.220507] [ INFO: suspicious RCU usage. ]
[12140.220507] 3.4.0-rc1-next-20120402-sasha #46 Tainted: GW
[12140.220507] ---
[12140.220507] include/linux/rcupdate.h:729 rcu_read_lock() used illegally
while idle!
[12140.220507]
[12140.220507] other info that might help us debug this:
[12140.220507]
[12140.220507]
[12140.220507] RCU used illegally from idle CPU!
[12140.220507] rcu_scheduler_active = 1, debug_locks = 1
[12140.220507] RCU used illegally from extended quiescent state!
[12140.220507] 4 locks held by swapper/1/0:
[12140.253991] #0: ((async_pf_sleepers[i].lock)-rlock){..-...}, at:
[8107cdc8] kvm_async_pf_task_wake+0x48/0x130
[12140.253991] #1: (n.wq){..}, at: [810e200d]
__wake_up+0x2d/0x70
[12140.253991] #2: (p-pi_lock){-.-.-.}, at: [810ec404]
try_to_wake_up+0x34/0x290
[12140.253991] #3: (rcu_read_lock){.+.+..}, at: [810f3c80]
select_task_rq_fair+0xb0/0x5c0
[12140.253991]
[12140.253991] stack backtrace:
[12140.253991] Pid: 0, comm: swapper/1 Tainted: GW
3.4.0-rc1-next-20120402-sasha #46
[12140.253991] Call Trace:
[12140.253991] [81114173] lockdep_rcu_suspicious+0x113/0x130
[12140.253991] [810f3ce5] select_task_rq_fair+0x115/0x5c0
[12140.253991] [810f3c80] ? select_task_rq_fair+0xb0/0x5c0
[12140.253991] [810ec404] ? try_to_wake_up+0x34/0x290
[12140.253991] [810ec404] ? try_to_wake_up+0x34/0x290
[12140.253991] [810ec561] try_to_wake_up+0x191/0x290
[12140.253991] [81114850] ? __lock_acquired+0x1c0/0x210
[12140.253991] [810ec66d] default_wake_function+0xd/0x10
[12140.253991] [810d7208] autoremove_wake_function+0x18/0x40
[12140.253991] [810e11e2] __wake_up_common+0x52/0x90
[12140.253991] [810e200d] ? __wake_up+0x2d/0x70
[12140.253991] [810e2023] __wake_up+0x43/0x70
[12140.253991] [8107cb07] apf_task_wake_one+0x87/0x90
[12140.253991] [8107cdf5] kvm_async_pf_task_wake+0x75/0x130
[12140.253991] [8107d1e6] do_async_page_fault+0x86/0xa0
[12140.253991] [82657a55] async_page_fault+0x25/0x30
[12140.253991] [8107d626] ? native_safe_halt+0x6/0x10
[12140.253991] [81116fed] ? trace_hardirqs_on+0xd/0x10
[12140.253991] [8105857d] default_idle+0x4d/0xa0
[12140.253991] [810582af] cpu_idle+0x11f/0x180
[12140.253991] [8264b9e0] ? setup_APIC_timer+0x88/0x8c
[12140.253991] [8264b004] start_secondary+0xe1/0xe8
[12140.253991]
[12140.253991] ===
[12140.253991] [ INFO: suspicious RCU usage. ]
[12140.253991] 3.4.0-rc1-next-20120402-sasha #46 Tainted: GW
[12140.253991] ---
[12140.253991] kernel/sched/fair.c:2716 suspicious rcu_dereference_check()
usage!
[12140.253991]
[12140.253991] other info that might help us debug this:
[12140.253991]
[12140.253991]
[12140.253991] RCU used illegally from idle CPU!
[12140.253991] rcu_scheduler_active = 1, debug_locks = 1
[12140.253991] RCU used illegally from extended quiescent state!
[12140.253991] 4 locks held by swapper/1/0:
[12140.253991] #0: ((async_pf_sleepers[i].lock)-rlock){..-...}, at:
[8107cdc8] kvm_async_pf_task_wake+0x48/0x130
[12140.253991] #1: (n.wq){..}, at: [810e200d]
__wake_up+0x2d/0x70
[12140.253991] #2: (p-pi_lock){-.-.-.}, at: [810ec404]
try_to_wake_up+0x34/0x290
[12140.253991] #3: (rcu_read_lock){.+.+..}, at: [810f3c80]
select_task_rq_fair+0xb0/0x5c0
[12140.253991]
[12140.253991] stack backtrace:
[12140.253991] Pid: 0, comm: swapper/1 Tainted: GW
3.4.0-rc1-next-20120402-sasha #46
[12140.253991] Call Trace:
[12140.253991] [81114173] lockdep_rcu_suspicious+0x113/0x130
[12140.253991] [810f3d4c] select_task_rq_fair+0x17c/0x5c0
[12140.253991] [810f3c80] ? select_task_rq_fair+0xb0/0x5c0
[12140.253991] [810ec404] ? try_to_wake_up+0x34/0x290
[12140.253991] [810ec404] ? try_to_wake_up+0x34/0x290
[12140.253991] [810ec561] try_to_wake_up+0x191/0x290
[12140.253991] [81114850] ? __lock_acquired+0x1c0/0x210
[12140.253991] [810ec66d] default_wake_function+0xd/0x10
[12140.253991] [810d7208] autoremove_wake_function+0x18/0x40
[12140.253991]
Re: Questing regarding KVM Guest PMU
On Mon, Mar 19, 2012 at 12:37 PM, Gleb Natapov g...@redhat.com wrote: On Mon, Mar 19, 2012 at 12:20:30PM +0530, shashank rachamalla wrote: On Sun, Mar 18, 2012 at 10:21 PM, Gleb Natapov g...@redhat.com wrote: On Sun, Mar 18, 2012 at 09:47:55PM +0530, shashank rachamalla wrote: I guess things are working fine with perf. But why not with oprofile ? Looks like it. I never tried oprofile. Will try to reproduce your problem and see what oprofile is doing. I am using ubuntu 10.04 with 2.6.32-21-generic kernel as guest and oprofile 0.9.6. Also, I have tried to capture kvm-events ( perf patch ) in host while running oprofile and perf in guest. Please see the attachment. I have run the tests in three cases for the around 5 secs. There are more number of MSR reads and writes in case of perf which I think is normal. However, there are very few MSR reads and writes with oprofile. Also, the number of NMI exceptions are too high in case of oprofile. Which host kernel are you using? Try latest kvm.git and check if you see something unusual in dmesg. Currenly running 3.3.0-rc5. will try with the latest source from kvm git and let you know. Thanks, there were some fixes that didn't make it into 3.3. rdpmc instruction emulation fix is one of them. If oprofile uses it this can explain the problem. I have tried with latest kvm source from git and also with 3.0 guest kernel but oprofile fails to collect any samples on guest. I am using a core2duo processor which is considered by oprofile as pentium pro model. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Please pull powerpc KVM fixes
On 04/03/2012 03:22 PM, Paul Mackerras wrote: On Tue, Apr 03, 2012 at 10:03:05PM +1000, Paul Mackerras wrote: The following changes since commit 592f5d87b3feee9d60411f19d583038c0c7670ad: OK, I messed up the git request-pull command. The request should have looked like this: The following changes since commit b1a808ff436343956a6ae63178ea1810c5e5a3a1: Merge branch 'for-next' of git://gitorious.org/kernel-hsi/kernel-hsi (2012-04-02 09:50:40 -0700) are available in the git repository at: git://github.com/paulusmack/linux tags/powerpc-fixes for you to fetch changes up to 592f5d87b3feee9d60411f19d583038c0c7670ad: KVM: PPC: Book3S: PR: Fix preemption (2012-04-03 16:42:39 +1000) Five fixes for bugs that have crept in to the powerpc KVM implementations. These are all small simple patches that only affect arch/powerpc/kvm. They come from the series that Alex Graf put together but which was too late for the 3.4 merge window. Thanks, pulled into kvm-updates/3.4. Will post upstream after adding x86 fixes. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM call minutes April 3
I'm afraid my notes are rather rough... * 1.1 soft freeze apr 15th (less than two weeks) hard freeze may 1 three months cycle for 1.2 stable machine types only every few releases? pc-next * Maintainers, got distracted and my notes make no sense, sorry * MSI injection to KVM irqchips from userspace devices models * qemu-kvm tree: working towards upstream merge not much left, mostly device assignment * Migration: vmstate and visitors, decoupling the wire format why not ASN.1 * qtest: test cases wanted -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] KVM: Introduce direct MSI message injection for in-kernel irqchips
On 03/29/2012 09:14 PM, Jan Kiszka wrote:
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated on the fly by user space,
IRQ routes are a limited resource that user space has to manage
carefully.
By providing a direct injection path, we can both avoid using up limited
resources and simplify the necessary steps for user land.
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 81ff39f..ed27d1b 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1482,6 +1482,27 @@ See KVM_ASSIGN_DEV_IRQ for the data structure. The
target device is specified
by assigned_dev_id. In the flags field, only KVM_DEV_ASSIGN_MASK_INTX is
evaluated.
+4.61 KVM_SIGNAL_MSI
+
+Capability: KVM_CAP_SIGNAL_MSI
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_msi (in)
+Returns: 0 on delivery, 0 if guest blocked the MSI, and -1 on error
+
+Directly inject a MSI message. Only valid with in-kernel irqchip that handles
+MSI messages.
+
+struct kvm_msi {
+ __u32 address_lo;
+ __u32 address_hi;
+ __u32 data;
+ __u32 flags;
+ __u8 pad[16];
+};
+
+No flags are defined so far. The corresponding field must be 0.
There are two ways in which this can be generalized:
struct kvm_general_irq {
__u32 type; // line | MSI
__u32 op; // raise/lower/trigger
union {
... line;
struct kvm_msi msi;
}
};
so we have a single ioctl for all interrupt handling. This allows
eventual removal of the line-oriented ioctls.
The other alternative is to have a dma interface, similar to the kvm_run
mmio interface but with the kernel acting as destination. The advantage
here is that we can handle dma from a device to any kernel-emulated
device, not just the APIC MSI range. A downside is that we can't return
values related to interrupt coalescing.
A performance note: delivering an interrupt needs to search all vcpus
for an APIC ID match. The previous plan was to cache (or pre-calculate)
this lookup in the irq routing table. Now it looks like we'll need a
separate cache for this.
(yes, I said on the call I don't anticipate objections but preparing to
apply a patch always triggers more critical thinking)
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] KVM: Introduce direct MSI message injection for in-kernel irqchips
On 2012-04-03 18:27, Avi Kivity wrote:
On 03/29/2012 09:14 PM, Jan Kiszka wrote:
Currently, MSI messages can only be injected to in-kernel irqchips by
defining a corresponding IRQ route for each message. This is not only
unhandy if the MSI messages are generated on the fly by user space,
IRQ routes are a limited resource that user space has to manage
carefully.
By providing a direct injection path, we can both avoid using up limited
resources and simplify the necessary steps for user land.
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 81ff39f..ed27d1b 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1482,6 +1482,27 @@ See KVM_ASSIGN_DEV_IRQ for the data structure. The
target device is specified
by assigned_dev_id. In the flags field, only KVM_DEV_ASSIGN_MASK_INTX is
evaluated.
+4.61 KVM_SIGNAL_MSI
+
+Capability: KVM_CAP_SIGNAL_MSI
+Architectures: x86
+Type: vm ioctl
+Parameters: struct kvm_msi (in)
+Returns: 0 on delivery, 0 if guest blocked the MSI, and -1 on error
+
+Directly inject a MSI message. Only valid with in-kernel irqchip that
handles
+MSI messages.
+
+struct kvm_msi {
+__u32 address_lo;
+__u32 address_hi;
+__u32 data;
+__u32 flags;
+__u8 pad[16];
+};
+
+No flags are defined so far. The corresponding field must be 0.
There are two ways in which this can be generalized:
struct kvm_general_irq {
__u32 type; // line | MSI
__u32 op; // raise/lower/trigger
union {
... line;
struct kvm_msi msi;
}
};
so we have a single ioctl for all interrupt handling. This allows
eventual removal of the line-oriented ioctls.
The other alternative is to have a dma interface, similar to the kvm_run
mmio interface but with the kernel acting as destination. The advantage
here is that we can handle dma from a device to any kernel-emulated
device, not just the APIC MSI range. A downside is that we can't return
values related to interrupt coalescing.
Due to lacking injection feedback, I'm in favor of option 1. Will have a
look.
A performance note: delivering an interrupt needs to search all vcpus
for an APIC ID match. The previous plan was to cache (or pre-calculate)
this lookup in the irq routing table. Now it looks like we'll need a
separate cache for this.
As this is non-existent until today, we don't regress here. And it can
still be added on top later on, transparently.
(yes, I said on the call I don't anticipate objections but preparing to
apply a patch always triggers more critical thinking)
Well, we make progress, though slower than I was hoping. :)
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] KVM: Introduce direct MSI message injection for in-kernel irqchips
On 04/03/2012 07:47 PM, Jan Kiszka wrote: so we have a single ioctl for all interrupt handling. This allows eventual removal of the line-oriented ioctls. The other alternative is to have a dma interface, similar to the kvm_run mmio interface but with the kernel acting as destination. The advantage here is that we can handle dma from a device to any kernel-emulated device, not just the APIC MSI range. A downside is that we can't return values related to interrupt coalescing. Due to lacking injection feedback, I'm in favor of option 1. Will have a look. I wonder if we can create a side channel for it. Lack of a kernel DMA API is a hole in the current code, though we haven't been bitten by it yet. An example is a guest that is swapping its own page tables; right now the shadow mmu doesn't notice those writes (when the page tables are swapped in) and will deliver incorrect results. Of course no guest does that, so it doesn't happen in practice. A performance note: delivering an interrupt needs to search all vcpus for an APIC ID match. The previous plan was to cache (or pre-calculate) this lookup in the irq routing table. Now it looks like we'll need a separate cache for this. As this is non-existent until today, we don't regress here. And it can still be added on top later on, transparently. Yes, it's just a note, not an objection. The cache lookup will be slower than the gsi lookup (hash table vs. array) but still O(1) vs. the current O(n). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questing regarding KVM Guest PMU
On Tue, Apr 03, 2012 at 07:20:04PM +0530, shashank rachamalla wrote: On Mon, Mar 19, 2012 at 12:37 PM, Gleb Natapov g...@redhat.com wrote: On Mon, Mar 19, 2012 at 12:20:30PM +0530, shashank rachamalla wrote: On Sun, Mar 18, 2012 at 10:21 PM, Gleb Natapov g...@redhat.com wrote: On Sun, Mar 18, 2012 at 09:47:55PM +0530, shashank rachamalla wrote: I guess things are working fine with perf. But why not with oprofile ? Looks like it. I never tried oprofile. Will try to reproduce your problem and see what oprofile is doing. I am using ubuntu 10.04 with 2.6.32-21-generic kernel as guest and oprofile 0.9.6. Also, I have tried to capture kvm-events ( perf patch ) in host while running oprofile and perf in guest. Please see the attachment. I have run the tests in three cases for the around 5 secs. There are more number of MSR reads and writes in case of perf which I think is normal. However, there are very few MSR reads and writes with oprofile. Also, the number of NMI exceptions are too high in case of oprofile. Which host kernel are you using? Try latest kvm.git and check if you see something unusual in dmesg. Currenly running 3.3.0-rc5. will try with the latest source from kvm git and let you know. Thanks, there were some fixes that didn't make it into 3.3. rdpmc instruction emulation fix is one of them. If oprofile uses it this can explain the problem. I have tried with latest kvm source from git and also with 3.0 guest kernel but oprofile fails to collect any samples on guest. I am using a core2duo processor which is considered by oprofile as pentium pro model. core2duo on the host or the guest? What is your qemu command line? -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] KVM: Introduce direct MSI message injection for in-kernel irqchips
On 2012-04-03 18:54, Avi Kivity wrote: On 04/03/2012 07:47 PM, Jan Kiszka wrote: so we have a single ioctl for all interrupt handling. This allows eventual removal of the line-oriented ioctls. The other alternative is to have a dma interface, similar to the kvm_run mmio interface but with the kernel acting as destination. The advantage here is that we can handle dma from a device to any kernel-emulated device, not just the APIC MSI range. A downside is that we can't return values related to interrupt coalescing. Due to lacking injection feedback, I'm in favor of option 1. Will have a look. I wonder if we can create a side channel for it. Lack of a kernel DMA API is a hole in the current code, though we haven't been bitten by it yet. An example is a guest that is swapping its own page tables; right now the shadow mmu doesn't notice those writes (when the page tables are swapped in) and will deliver incorrect results. Of course no guest does that, so it doesn't happen in practice. A performance note: delivering an interrupt needs to search all vcpus for an APIC ID match. The previous plan was to cache (or pre-calculate) this lookup in the irq routing table. Now it looks like we'll need a separate cache for this. As this is non-existent until today, we don't regress here. And it can still be added on top later on, transparently. Yes, it's just a note, not an objection. The cache lookup will be slower than the gsi lookup (hash table vs. array) but still O(1) vs. the current O(n). If you are concerned about performance in this path, wouldn't a DMA interface for MSI injection be counterproductive? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v2 0/4] uq/master: Basic MSI support for in-kernel irqchip mode
On 2012-04-03 15:06, Michael S. Tsirkin wrote: On Tue, Apr 03, 2012 at 09:23:12AM +0200, Jan Kiszka wrote: This is v2 of the RFC, fixing a memory leak in kvm_flush_dynamic_msi_routes and adding support for the proposed KVM_SIGNAL_MSI IOCTL. This series depends on kvm: set gsi_bits and max_gsi correctly (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/88906). Looks good to me. How hard would it be to add irqfd support? Shouldn't be, but the changes will be a bit bigger. I'm thinking about a revamped interface between the MSI core and affected devices for a while. Will try to put down in some lines of code what I have in mind - once the dynamic MSI injection topic has settled. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questing regarding KVM Guest PMU
On Tue, Apr 3, 2012 at 10:28 PM, Gleb Natapov g...@redhat.com wrote: On Tue, Apr 03, 2012 at 07:20:04PM +0530, shashank rachamalla wrote: On Mon, Mar 19, 2012 at 12:37 PM, Gleb Natapov g...@redhat.com wrote: On Mon, Mar 19, 2012 at 12:20:30PM +0530, shashank rachamalla wrote: On Sun, Mar 18, 2012 at 10:21 PM, Gleb Natapov g...@redhat.com wrote: On Sun, Mar 18, 2012 at 09:47:55PM +0530, shashank rachamalla wrote: I guess things are working fine with perf. But why not with oprofile ? Looks like it. I never tried oprofile. Will try to reproduce your problem and see what oprofile is doing. I am using ubuntu 10.04 with 2.6.32-21-generic kernel as guest and oprofile 0.9.6. Also, I have tried to capture kvm-events ( perf patch ) in host while running oprofile and perf in guest. Please see the attachment. I have run the tests in three cases for the around 5 secs. There are more number of MSR reads and writes in case of perf which I think is normal. However, there are very few MSR reads and writes with oprofile. Also, the number of NMI exceptions are too high in case of oprofile. Which host kernel are you using? Try latest kvm.git and check if you see something unusual in dmesg. Currenly running 3.3.0-rc5. will try with the latest source from kvm git and let you know. Thanks, there were some fixes that didn't make it into 3.3. rdpmc instruction emulation fix is one of them. If oprofile uses it this can explain the problem. I have tried with latest kvm source from git and also with 3.0 guest kernel but oprofile fails to collect any samples on guest. I am using a core2duo processor which is considered by oprofile as pentium pro model. core2duo on the host or the guest? What is your qemu command line? both. qemu command line below. sudo /usr/local/bin/qemu-system-x86_64 -drive file=vdisk1.img,if=virtio -cpu host -m 2000 -net nic,model=virtio -net user -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questing regarding KVM Guest PMU
On Wed, Apr 4, 2012 at 12:13 AM, shashank rachamalla shashank.rachama...@gmail.com wrote: On Tue, Apr 3, 2012 at 10:28 PM, Gleb Natapov g...@redhat.com wrote: On Tue, Apr 03, 2012 at 07:20:04PM +0530, shashank rachamalla wrote: On Mon, Mar 19, 2012 at 12:37 PM, Gleb Natapov g...@redhat.com wrote: On Mon, Mar 19, 2012 at 12:20:30PM +0530, shashank rachamalla wrote: On Sun, Mar 18, 2012 at 10:21 PM, Gleb Natapov g...@redhat.com wrote: On Sun, Mar 18, 2012 at 09:47:55PM +0530, shashank rachamalla wrote: I guess things are working fine with perf. But why not with oprofile ? Looks like it. I never tried oprofile. Will try to reproduce your problem and see what oprofile is doing. I am using ubuntu 10.04 with 2.6.32-21-generic kernel as guest and oprofile 0.9.6. Also, I have tried to capture kvm-events ( perf patch ) in host while running oprofile and perf in guest. Please see the attachment. I have run the tests in three cases for the around 5 secs. There are more number of MSR reads and writes in case of perf which I think is normal. However, there are very few MSR reads and writes with oprofile. Also, the number of NMI exceptions are too high in case of oprofile. Which host kernel are you using? Try latest kvm.git and check if you see something unusual in dmesg. Currenly running 3.3.0-rc5. will try with the latest source from kvm git and let you know. Thanks, there were some fixes that didn't make it into 3.3. rdpmc instruction emulation fix is one of them. If oprofile uses it this can explain the problem. I have tried with latest kvm source from git and also with 3.0 guest kernel but oprofile fails to collect any samples on guest. I am using a core2duo processor which is considered by oprofile as pentium pro model. core2duo on the host or the guest? What is your qemu command line? both. qemu command line below. sudo /usr/local/bin/qemu-system-x86_64 -drive file=vdisk1.img,if=virtio -cpu host -m 2000 -net nic,model=virtio -net user please find more info ( /proc/cpuinfo and uname of both host and guest ) in attached files. -- Gleb. processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping: 11 microcode : 0xb3 cpu MHz : 800.000 cache size : 4096 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida dts tpr_shadow vnmi flexpriority bogomips: 4399.99 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping: 11 microcode : 0xb3 cpu MHz : 800.000 cache size : 4096 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida dts tpr_shadow vnmi flexpriority bogomips: 4399.99 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: Linux shashank-Aspire-5920 3.3.0-rc5+ #3 SMP Tue Apr 3 22:42:29 IST 2012 i686 i686 i386 GNU/Linux processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping: 11 cpu MHz : 2199.996 cache size : 4096 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss constant_tsc up arch_perfmon pni ssse3 cx16 hypervisor lahf_lm bogomips: 4399.99 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 0 bits virtual power management: Linux
Re: [RFC][PATCH v2 0/4] uq/master: Basic MSI support for in-kernel irqchip mode
On 2012-04-03 09:23, Jan Kiszka wrote: This is v2 of the RFC, fixing a memory leak in kvm_flush_dynamic_msi_routes and adding support for the proposed KVM_SIGNAL_MSI IOCTL. This series depends on kvm: set gsi_bits and max_gsi correctly (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/88906). Jan Kiszka (4): kvm: Refactor KVMState::max_gsi to gsi_count kvm: Introduce basic MSI support for in-kernel irqchips KVM: x86: Wire up MSI support for in-kernel irqchip kvm: Add support for direct MSI injections hw/apic.c |3 + hw/kvm/apic.c | 33 +- hw/pc.c |5 -- kvm-all.c | 195 +++-- kvm.h |1 + 5 files changed, 225 insertions(+), 12 deletions(-) As we obviously agreed on the general direction regarding an MSI injection interface, I think patches 1-3 can lose their RFC tags and are ready for uq/master (provided there are no further review comments). Patch 4 will be reworked once the kernel interface is finalized. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes April 3
On 04/03/2012 05:43 PM, Markus Armbruster wrote: I'm afraid my notes are rather rough... * 1.1 soft freeze apr 15th (less than two weeks) hard freeze may 1 three months cycle for 1.2 stable machine types only every few releases? pc-next * Maintainers, got distracted and my notes make no sense, sorry * MSI injection to KVM irqchips from userspace devices models * qemu-kvm tree: working towards upstream merge not much left, mostly device assignment * Migration: vmstate and visitors, decoupling the wire format why not ASN.1 Curiosity kills me of waiting for next week's meeting to get the answer * qtest: test cases wanted -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes April 3
On Tue, Apr 03, 2012 at 11:43:57PM +0300, Dor Laor wrote: On 04/03/2012 05:43 PM, Markus Armbruster wrote: I'm afraid my notes are rather rough... * 1.1 soft freeze apr 15th (less than two weeks) hard freeze may 1 three months cycle for 1.2 stable machine types only every few releases? pc-next * Maintainers, got distracted and my notes make no sense, sorry * MSI injection to KVM irqchips from userspace devices models * qemu-kvm tree: working towards upstream merge not much left, mostly device assignment * Migration: vmstate and visitors, decoupling the wire format why not ASN.1 Curiosity kills me of waiting for next week's meeting to get the answer I believe when this had come up in the past the plan was to use ASN.1 for the wire protocol, but not to address the decoupling problem. Theoretically it could handle both, but I believe that requires defining device structures using ASN.1 definitions, which probably isn't suitable for devices since it results in high level structures which require special accessors (at least for the libraries I've looked at) An IDL compiler that generates visitors based on a simple device code annotations still seems to be the leading option. Previously I'd jumped the gun a bit by piggy-backing off vmstate to get at the protocol side, but that permanently baked QEMUFile markers into the wire protocol which was the wrong approach. Attacking the IDL/schema side first is the more rationale approach. From there we can potentially generate ASN.1 BER/DER visitors for the protocol side, or potentially even just vmstate bindings as a start. I've recently started looking into the latter... it's completely feasible, the only downside is it complicates the IDL due requiring support for a lot of what are very much vmstate-specific items, but it should be possible to do this in a manner where those annotations are self-contained and ignorable if we opted to replace vmstate-style declarations. * qtest: test cases wanted -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] Please pull powerpc KVM fixes
Avi, The following changes since commit 592f5d87b3feee9d60411f19d583038c0c7670ad: KVM: PPC: Book3S: PR: Fix preemption (2012-04-03 16:42:39 +1000) are available in the git repository at: git://github.com/paulusmack/linux tags/powerpc-fixes for you to fetch changes up to 592f5d87b3feee9d60411f19d583038c0c7670ad: KVM: PPC: Book3S: PR: Fix preemption (2012-04-03 16:42:39 +1000) Five fixes for bugs that have crept in to the powerpc KVM implementations. These are all small simple patches that only affect arch/powerpc/kvm. They come from the series that Alex Graf put together but which was too late for the 3.4 merge window. Please pull these and send them to Linus for inclusion in 3.4. The powerpc-fixes tag is a signed tag, signed with my signing key with ID 05F66CE9. Thanks, Paul. -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Please pull powerpc KVM fixes
On Tue, Apr 03, 2012 at 10:03:05PM +1000, Paul Mackerras wrote: The following changes since commit 592f5d87b3feee9d60411f19d583038c0c7670ad: OK, I messed up the git request-pull command. The request should have looked like this: The following changes since commit b1a808ff436343956a6ae63178ea1810c5e5a3a1: Merge branch 'for-next' of git://gitorious.org/kernel-hsi/kernel-hsi (2012-04-02 09:50:40 -0700) are available in the git repository at: git://github.com/paulusmack/linux tags/powerpc-fixes for you to fetch changes up to 592f5d87b3feee9d60411f19d583038c0c7670ad: KVM: PPC: Book3S: PR: Fix preemption (2012-04-03 16:42:39 +1000) Five fixes for bugs that have crept in to the powerpc KVM implementations. These are all small simple patches that only affect arch/powerpc/kvm. They come from the series that Alex Graf put together but which was too late for the 3.4 merge window. Alexander Graf (3): KVM: PPC: Book3S: Compile fix for ppc32 in HIOR access code KVM: PPC: Save/Restore CR over vcpu_run KVM: PPC: Book3S: PR: Fix preemption Paul Mackerras (2): KVM: PPC: Book3S HV: Fix kvm_alloc_linear in case where no linears exist KVM: PPC: Book3S HV: Save and restore CR in __kvmppc_vcore_entry arch/powerpc/kvm/book3s_hv_builtin.c|9 + arch/powerpc/kvm/book3s_hv_interrupts.S |8 ++-- arch/powerpc/kvm/book3s_interrupts.S|7 +++ arch/powerpc/kvm/book3s_pr.c|9 + arch/powerpc/kvm/booke_interrupts.S |7 ++- 5 files changed, 29 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Please pull powerpc KVM fixes
On 04/03/2012 03:22 PM, Paul Mackerras wrote: On Tue, Apr 03, 2012 at 10:03:05PM +1000, Paul Mackerras wrote: The following changes since commit 592f5d87b3feee9d60411f19d583038c0c7670ad: OK, I messed up the git request-pull command. The request should have looked like this: The following changes since commit b1a808ff436343956a6ae63178ea1810c5e5a3a1: Merge branch 'for-next' of git://gitorious.org/kernel-hsi/kernel-hsi (2012-04-02 09:50:40 -0700) are available in the git repository at: git://github.com/paulusmack/linux tags/powerpc-fixes for you to fetch changes up to 592f5d87b3feee9d60411f19d583038c0c7670ad: KVM: PPC: Book3S: PR: Fix preemption (2012-04-03 16:42:39 +1000) Five fixes for bugs that have crept in to the powerpc KVM implementations. These are all small simple patches that only affect arch/powerpc/kvm. They come from the series that Alex Graf put together but which was too late for the 3.4 merge window. Thanks, pulled into kvm-updates/3.4. Will post upstream after adding x86 fixes. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
