[COMMIT master] Update source link
From: Avi Kivity a...@redhat.com Signed-off-by: Avi Kivity a...@redhat.com diff --git a/linux-2.6 b/linux-2.6 index 66b0aed..545c64b 16 --- a/linux-2.6 +++ b/linux-2.6 @@ -1 +1 @@ -Subproject commit 66b0aed4a9e15a2ea3a00763f362b6ee0b28d538 +Subproject commit 545c64b25fc62cc74fcc8933e2f95d1bb25a4934 -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] bios: dynamically track available rsdt entries
From: Avi Kivity a...@redhat.com
Instead of using hardcoded offsets into the rsdt table, keep a count of
used entries.
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/kvm/bios/rombios32.c b/kvm/bios/rombios32.c
index f4c58b9..cbd5f15 100755
--- a/kvm/bios/rombios32.c
+++ b/kvm/bios/rombios32.c
@@ -1293,18 +1293,15 @@ struct rsdp_descriptor /* Root System
Descriptor Pointer */
uint8_treserved [3]; /* Reserved
field must be 0 */
} __attribute__((__packed__));
+#define MAX_RSDT_ENTRIES 100
+
/*
* ACPI 1.0 Root System Description Table (RSDT)
*/
struct rsdt_descriptor_rev1
{
ACPI_TABLE_HEADER_DEF /* ACPI common table
header */
-#ifdef BX_QEMU
- uint32_t table_offset_entry [3]; /* Array
of pointers to other */
-// uint32_t table_offset_entry [5]; /* Array
of pointers to other */
-#else
- uint32_t table_offset_entry [3]; /* Array
of pointers to other */
-#endif
+ uint32_t table_offset_entry
[MAX_RSDT_ENTRIES]; /* Array of pointers to other */
/* ACPI tables */
} __attribute__((__packed__));
@@ -1607,6 +1604,7 @@ void acpi_bios_init(void)
uint32_t srat_addr,srat_size;
uint16_t i, external_tables;
int nb_numa_nodes;
+int nb_rsdt_entries = 0;
/* reserve memory space for tables */
#ifdef BX_USE_EBDA_TABLES
@@ -1876,7 +1874,7 @@ void acpi_bios_init(void)
uint16_t len;
if(acpi_load_table(i, addr, len) 0)
BX_PANIC(Failed to load ACPI table from QEMU\n);
-rsdt-table_offset_entry[i+2] = cpu_to_le32(addr);
+rsdt-table_offset_entry[nb_rsdt_entries++] = cpu_to_le32(addr);
addr += len;
if(addr = ram_size)
BX_PANIC(ACPI table overflow\n);
@@ -1884,18 +1882,20 @@ void acpi_bios_init(void)
#endif
/* RSDT */
-rsdt-table_offset_entry[0] = cpu_to_le32(fadt_addr);
-rsdt-table_offset_entry[1] = cpu_to_le32(madt_addr);
+rsdt-table_offset_entry[nb_rsdt_entries++] = cpu_to_le32(fadt_addr);
+rsdt-table_offset_entry[nb_rsdt_entries++] = cpu_to_le32(madt_addr);
/* kvm has no ssdt (processors are in dsdt) */
-// rsdt-table_offset_entry[2] = cpu_to_le32(ssdt_addr);
+// rsdt-table_offset_entry[nb_rsdt_entries++] = cpu_to_le32(ssdt_addr);
#ifdef BX_QEMU
/* No HPET (yet) */
-// rsdt-table_offset_entry[3] = cpu_to_le32(hpet_addr);
+// rsdt-table_offset_entry[nb_rsdt_entries++] = cpu_to_le32(hpet_addr);
if (nb_numa_nodes 0)
-rsdt-table_offset_entry[3] = cpu_to_le32(srat_addr);
+rsdt-table_offset_entry[nb_rsdt_entries++] = cpu_to_le32(srat_addr);
#endif
+rsdt_size -= MAX_RSDT_ENTRIES * 4;
+rsdt_size += nb_rsdt_entries * 4;
acpi_build_table_header((struct acpi_table_header *)rsdt, RSDT,
-rsdt_size - (nb_numa_nodes 0? 0: sizeof(uint32_t)), 1);
+rsdt_size, 1);
acpi_tables_size = addr - base_addr;
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Regenerate bios for latest merge
From: Avi Kivity a...@redhat.com - dynamic acpi tables - dynamic SMBIOS tables - SRAT (NUMA) - make rsdt entry tracking saner Signed-off-by: Avi Kivity a...@redhat.com diff --git a/pc-bios/bios.bin b/pc-bios/bios.bin index d5d42f3..70bd7ad 100644 Binary files a/pc-bios/bios.bin and b/pc-bios/bios.bin differ -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] bios: Load SMBIOS entries and files from qemu (Alex Williamson)
From: Alex Williamson alex.william...@hp.com
Allow SMBIOS fields to be overridden and entries replaced by those
read from qemu.
Signed-off-by: Alex Williamson alex.william...@hp.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/kvm/bios/rombios32.c b/kvm/bios/rombios32.c
index 70a26c7..6c7d376 100755
--- a/kvm/bios/rombios32.c
+++ b/kvm/bios/rombios32.c
@@ -444,7 +444,6 @@ uint32_t cpuid_features;
uint32_t cpuid_ext_features;
unsigned long ram_size;
uint64_t ram_end;
-uint8_t bios_uuid[16];
#ifdef BX_USE_EBDA_TABLES
unsigned long ebda_cur_addr;
#endif
@@ -479,6 +478,7 @@ void wrmsr_smp(uint32_t index, uint64_t val)
#define QEMU_CFG_UUID 0x02
#define QEMU_CFG_ARCH_LOCAL 0x8000
#define QEMU_CFG_ACPI_TABLES (QEMU_CFG_ARCH_LOCAL + 0)
+#define QEMU_CFG_SMBIOS_ENTRIES (QEMU_CFG_ARCH_LOCAL + 1)
int qemu_cfg_port;
@@ -527,19 +527,17 @@ static int acpi_load_table(int i, uint32_t addr, uint16_t
*len)
qemu_cfg_read((uint8_t*)addr, *len);
return 0;
}
-#endif
-void uuid_probe(void)
+static uint16_t smbios_entries(void)
{
-#ifdef BX_QEMU
-if(qemu_cfg_port) {
-qemu_cfg_select(QEMU_CFG_UUID);
-qemu_cfg_read(bios_uuid, 16);
-return;
-}
-#endif
-memset(bios_uuid, 0, 16);
+uint16_t cnt;
+
+qemu_cfg_select(QEMU_CFG_SMBIOS_ENTRIES);
+qemu_cfg_read((uint8_t*)cnt, sizeof(cnt));
+
+return cnt;
}
+#endif
void cpu_probe(void)
{
@@ -1951,21 +1949,105 @@ smbios_entry_point_init(void *start,
ep-intermediate_checksum = -sum;
}
+struct smbios_header {
+uint16_t length;
+uint8_t type;
+} __attribute__((__packed__));
+
+struct smbios_field {
+struct smbios_header header;
+uint8_t type;
+uint16_t offset;
+uint8_t data[];
+} __attribute__((__packed__));
+
+struct smbios_table {
+struct smbios_header header;
+uint8_t data[];
+} __attribute__((__packed__));
+
+#define SMBIOS_FIELD_ENTRY 0
+#define SMBIOS_TABLE_ENTRY 1
+
+static size_t
+smbios_load_field(int type, size_t offset, void *addr)
+{
+#ifdef BX_QEMU
+int i;
+
+for (i = smbios_entries(); i 0; i--) {
+struct smbios_field field;
+
+qemu_cfg_read((uint8_t *)field, sizeof(struct smbios_header));
+field.header.length -= sizeof(struct smbios_header);
+
+if (field.header.type != SMBIOS_FIELD_ENTRY) {
+while (field.header.length--)
+inb(QEMU_CFG_DATA_PORT);
+continue;
+}
+
+qemu_cfg_read((uint8_t *)field.type,
+ sizeof(field) - sizeof(struct smbios_header));
+field.header.length -= sizeof(field) - sizeof(struct smbios_header);
+
+if (field.type != type || field.offset != offset) {
+while (field.header.length--)
+inb(QEMU_CFG_DATA_PORT);
+continue;
+}
+
+qemu_cfg_read(addr, field.header.length);
+return (size_t)field.header.length;
+}
+#endif
+return 0;
+}
+
+#define load_str_field_with_default(type, field, def) do { \
+size = smbios_load_field(type, offsetof(struct smbios_type_##type, \
+field), end); \
+if (size 0) {\
+end += size; \
+} else { \
+memcpy(end, def, sizeof(def)); \
+end += sizeof(def);\
+} \
+p-field = ++str_index;\
+} while (0)
+
+#define load_str_field_or_skip(type, field) do { \
+size = smbios_load_field(type, offsetof(struct smbios_type_##type, \
+field), end); \
+if (size 0) {\
+end += size; \
+p-field = ++str_index;\
+} else { \
+p-field = 0; \
+} \
+} while (0)
+
/* Type 0 -- BIOS Information */
#define RELEASE_DATE_STR 01/01/2007
static void *
-smbios_type_0_init(void *start)
+smbios_init_type_0(void *start)
{
struct smbios_type_0 *p = (struct smbios_type_0 *)start;
+char *end = (char *)start + sizeof(struct smbios_type_0);
+size_t size;
+int str_index = 0;
p-header.type = 0;
p-header.length = sizeof(struct smbios_type_0);
p-header.handle = 0;
-p-vendor_str = 1;
-p-bios_version_str = 1;
+load_str_field_with_default(0, vendor_str,
[COMMIT master] KVM: use smp_send_reschedule in kvm_vcpu_kick
From: Marcelo Tosatti mtosa...@redhat.com
KVM uses a function call IPI to cause the exit of a guest running on a
physical cpu. For virtual interrupt notification there is no need to
wait on IPI receival, or to execute any function.
This is exactly what the reschedule IPI does, without the overhead
of function IPI. So use it instead of smp_call_function_single in
kvm_vcpu_kick.
Also change the guest_mode variable to a bit in vcpu-requests, and
use that to collapse multiple IPI's that would be issued between the
first one and zeroing of guest mode.
This allows kvm_vcpu_kick to called with interrupts disabled.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/ia64/kernel/irq_ia64.c b/arch/ia64/kernel/irq_ia64.c
index acc4d19..b448197 100644
--- a/arch/ia64/kernel/irq_ia64.c
+++ b/arch/ia64/kernel/irq_ia64.c
@@ -610,6 +610,9 @@ static struct irqaction ipi_irqaction = {
.name = IPI
};
+/*
+ * KVM uses this interrupt to force a cpu out of guest mode
+ */
static struct irqaction resched_irqaction = {
.handler = dummy_handler,
.flags =IRQF_DISABLED,
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index be4413e..80c57b0 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -668,7 +668,7 @@ again:
host_ctx = kvm_get_host_context(vcpu);
guest_ctx = kvm_get_guest_context(vcpu);
- vcpu-guest_mode = 1;
+ clear_bit(KVM_REQ_KICK, vcpu-requests);
r = kvm_vcpu_pre_transition(vcpu);
if (r 0)
@@ -685,7 +685,7 @@ again:
kvm_vcpu_post_transition(vcpu);
vcpu-arch.launched = 1;
- vcpu-guest_mode = 0;
+ set_bit(KVM_REQ_KICK, vcpu-requests);
local_irq_enable();
/*
@@ -1879,24 +1879,18 @@ void kvm_arch_hardware_unsetup(void)
{
}
-static void vcpu_kick_intr(void *info)
-{
-#ifdef DEBUG
- struct kvm_vcpu *vcpu = (struct kvm_vcpu *)info;
- printk(KERN_DEBUGvcpu_kick_intr %p \n, vcpu);
-#endif
-}
-
void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
{
- int ipi_pcpu = vcpu-cpu;
- int cpu = get_cpu();
+ int me;
+ int cpu = vcpu-cpu;
if (waitqueue_active(vcpu-wq))
wake_up_interruptible(vcpu-wq);
- if (vcpu-guest_mode cpu != ipi_pcpu)
- smp_call_function_single(ipi_pcpu, vcpu_kick_intr, vcpu, 0);
+ me = get_cpu();
+ if (cpu != me (unsigned) cpu nr_cpu_ids cpu_online(cpu))
+ if (!test_and_set_bit(KVM_REQ_KICK, vcpu-requests))
+ smp_send_reschedule(cpu);
put_cpu();
}
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index 13f33ea..3b2e55e 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -172,6 +172,9 @@ void smp_reschedule_interrupt(struct pt_regs *regs)
{
ack_APIC_irq();
inc_irq_stat(irq_resched_count);
+ /*
+* KVM uses this interrupt to force a cpu out of guest mode
+*/
}
void smp_call_function_interrupt(struct pt_regs *regs)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 23c0d56..c6d3ff3 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3226,6 +3226,9 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu, struct
kvm_run *kvm_run)
local_irq_disable();
+ clear_bit(KVM_REQ_KICK, vcpu-requests);
+ smp_mb__after_clear_bit();
+
if (vcpu-requests || need_resched() || signal_pending(current)) {
local_irq_enable();
preempt_enable();
@@ -3233,13 +3236,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
goto out;
}
- vcpu-guest_mode = 1;
- /*
-* Make sure that guest_mode assignment won't happen after
-* testing the pending IRQ vector bitmap.
-*/
- smp_wmb();
-
if (vcpu-arch.exception.pending)
__queue_exception(vcpu);
else
@@ -3284,7 +3280,7 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu, struct
kvm_run *kvm_run)
set_debugreg(vcpu-arch.host_dr6, 6);
set_debugreg(vcpu-arch.host_dr7, 7);
- vcpu-guest_mode = 0;
+ set_bit(KVM_REQ_KICK, vcpu-requests);
local_irq_enable();
++vcpu-stat.exits;
@@ -4567,30 +4563,20 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
|| vcpu-arch.nmi_pending;
}
-static void vcpu_kick_intr(void *info)
-{
-#ifdef DEBUG
- struct kvm_vcpu *vcpu = (struct kvm_vcpu *)info;
- printk(KERN_DEBUG vcpu_kick_intr %p \n, vcpu);
-#endif
-}
-
void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
{
- int ipi_pcpu = vcpu-cpu;
- int cpu;
+ int me;
+ int cpu = vcpu-cpu;
if (waitqueue_active(vcpu-wq)) {
wake_up_interruptible(vcpu-wq);
++vcpu-stat.halt_wakeup;
}
- /*
-* We may be called synchronously with irqs disabled in
[COMMIT master] nr_cpu_ids compat
From: Marcelo Tosatti mtosa...@redhat.com Signed-off-by: Marcelo Tosatti mtosa...@redhat.com Signed-off-by: Avi Kivity a...@redhat.com diff --git a/external-module-compat-comm.h b/external-module-compat-comm.h index 8cb5440..d7fec25 100644 --- a/external-module-compat-comm.h +++ b/external-module-compat-comm.h @@ -116,6 +116,10 @@ int kvm_smp_call_function_single(int cpu, void (*func)(void *info), #endif +#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,28) +#define nr_cpu_ids NR_CPUS +#endif + #include linux/miscdevice.h #ifndef KVM_MINOR #define KVM_MINOR 232 -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] smp_send_reschedule compat
From: Marcelo Tosatti mtosa...@redhat.com
smp_send_reschedule was exported (via smp_ops) in v2.6.24.
Create a compat function which schedules the IPI to keventd context,
in case interrupts are disabled, for kernels 2.6.24.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/external-module-compat-comm.h b/external-module-compat-comm.h
index d7fec25..88d2314 100644
--- a/external-module-compat-comm.h
+++ b/external-module-compat-comm.h
@@ -224,6 +224,12 @@ int kvm_smp_call_function_mask(cpumask_t mask, void
(*func) (void *info),
#define smp_call_function_mask kvm_smp_call_function_mask
+void kvm_smp_send_reschedule(int cpu);
+
+#else
+
+#define kvm_smp_send_reschedule smp_send_reschedule
+
#endif
/* empty_zero_page isn't exported in all kernels */
diff --git a/external-module-compat.c b/external-module-compat.c
index 0d858be..ca269cc 100644
--- a/external-module-compat.c
+++ b/external-module-compat.c
@@ -221,6 +221,58 @@ out:
return 0;
}
+#include linux/workqueue.h
+
+static void vcpu_kick_intr(void *info)
+{
+}
+
+struct kvm_kick {
+ int cpu;
+ struct work_struct work;
+};
+
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
+static void kvm_do_smp_call_function(void *data)
+{
+ int me;
+ struct kvm_kick *kvm_kick = data;
+#else
+static void kvm_do_smp_call_function(struct work_struct *work)
+{
+ int me;
+ struct kvm_kick *kvm_kick = container_of(work, struct kvm_kick, work);
+#endif
+ me = get_cpu();
+
+ if (kvm_kick-cpu != me)
+ smp_call_function_single(kvm_kick-cpu, vcpu_kick_intr,
+NULL, 0);
+ kfree(kvm_kick);
+ put_cpu();
+}
+
+void kvm_queue_smp_call_function(int cpu)
+{
+ struct kvm_kick *kvm_kick = kmalloc(sizeof(struct kvm_kick),
GFP_ATOMIC);
+
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,20)
+ INIT_WORK(kvm_kick-work, kvm_do_smp_call_function, kvm_kick);
+#else
+ INIT_WORK(kvm_kick-work, kvm_do_smp_call_function);
+#endif
+
+ schedule_work(kvm_kick-work);
+}
+
+void kvm_smp_send_reschedule(int cpu)
+{
+ if (irqs_disabled()) {
+ kvm_queue_smp_call_function(cpu);
+ return;
+ }
+ smp_call_function_single(cpu, vcpu_kick_intr, NULL, 0);
+}
#endif
/* manually export hrtimer_init/start/cancel */
diff --git a/ia64/hack-module.awk b/ia64/hack-module.awk
index dda3347..e768343 100644
--- a/ia64/hack-module.awk
+++ b/ia64/hack-module.awk
@@ -1,4 +1,4 @@
-BEGIN { split(INIT_WORK on_each_cpu smp_call_function \
+BEGIN { split(INIT_WORK on_each_cpu smp_call_function smp_send_reschedule \
hrtimer_add_expires_ns hrtimer_get_expires \
hrtimer_get_expires_ns hrtimer_start_expires \
hrtimer_expires_remaining \
diff --git a/x86/hack-module.awk b/x86/hack-module.awk
index bdb873a..143aa52 100644
--- a/x86/hack-module.awk
+++ b/x86/hack-module.awk
@@ -1,7 +1,7 @@
BEGIN { split(INIT_WORK desc_struct ldttss_desc64 desc_ptr \
hrtimer_add_expires_ns hrtimer_get_expires \
hrtimer_get_expires_ns hrtimer_start_expires \
- hrtimer_expires_remaining \
+ hrtimer_expires_remaining smp_send_reschedule \
on_each_cpu relay_open request_irq free_irq , compat_apis); }
/^int kvm_init\(/ { anon_inodes = 1 }
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] virtio: find_vqs/del_vqs virtio operations
On Sun, May 10, 2009 at 01:37:06PM +0930, Rusty Russell wrote: Yes, and in fact a rough look at your patch reveals that we don't actually need del_vq: now we track them, we can just do that as part of vdev destruction, right? Let's assume that a driver encounters an error in probe after it calls find_vq. It would need a way to revert find_vq, won't it? It seems to me that bus-remove does not get called on probe failure. Isn't that right? -- MST -- 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 0/2] Deal with shadow interrupts after emulated instructions
On Fri, May 08, 2009 at 04:23:05PM -0400, Glauber Costa wrote: Hi, This is the same patch you're all used to by now, but split in two per Avi request. Acked-by: Gleb Natapov g...@redhat.com -- 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: boot=on option fails on win 2k/xp double boot
Gleb Natapov, il 10/05/2009 07:21, ha scritto: On Sat, May 09, 2009 at 07:53:50PM +0200, Federico Fissore wrote: I've a windows (virtual) box with windows xp originally installed and a windows 2k lately installed Are they both installed on the same disk? yes they are If I run kvm from the command line for testing purposes everything is fine. If I run it with libvirt on the host, I does not boot, complaining with an I/O error the problem arises since libvirt adds boot=on on the first disk without that option, everything works fine do you have any hint on this? libvirt should not add boot=on if interface type is IDE and if disk type is not IDE then boot is supported only from one disk (the one that has boot=on). attached is the xml the current non-working version uses disk images. but it fails the same way when using LVM volumes other info: libvirt version is 0.4.6-10 and kvm is 72. these are what is currenntly available with debian lenny domain type='kvm' namenord_recuperi/name uuidac298be5-4c11-e7cd-4093-36c951445d3f/uuid memory1048576/memory currentMemory1048576/currentMemory vcpu1/vcpu os type arch='x86_64' machine='pc'hvm/type boot dev='hd'/ /os features pae/ /features clock offset='localtime'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/bin/kvm/emulator disk type='file' device='disk' source file='/DATA/virtual.machines/nr/nr_c.qcow2'/ target dev='hda' bus='ide'/ /disk disk type='file' device='disk' source file='/DATA/virtual.machines/nr/nr_e.qcow2'/ target dev='hdb' bus='ide'/ /disk disk type='block' device='cdrom' source dev='/dev/cdrom'/ target dev='hdc' bus='ide'/ readonly/ /disk interface type='bridge' mac address='54:a4:7e:c0:0b:24'/ source bridge='br2'/ /interface input type='mouse' bus='ps2'/ graphics type='vnc' port='5903' autoport='no' listen='192.168.46.20' keymap='it'/ /devices /domain smime.p7s Description: S/MIME Cryptographic Signature
Re: boot=on option fails on win 2k/xp double boot
On Sun, May 10, 2009 at 10:38:18AM +0200, Federico Fissore wrote: Gleb Natapov, il 10/05/2009 07:21, ha scritto: On Sat, May 09, 2009 at 07:53:50PM +0200, Federico Fissore wrote: I've a windows (virtual) box with windows xp originally installed and a windows 2k lately installed Are they both installed on the same disk? yes they are If I run kvm from the command line for testing purposes everything is fine. If I run it with libvirt on the host, I does not boot, complaining with an I/O error the problem arises since libvirt adds boot=on on the first disk without that option, everything works fine do you have any hint on this? libvirt should not add boot=on if interface type is IDE and if disk type is not IDE then boot is supported only from one disk (the one that has boot=on). attached is the xml the current non-working version uses disk images. but it fails the same way when using LVM volumes other info: libvirt version is 0.4.6-10 and kvm is 72. these are what is currenntly available with debian lenny Can you please try non ancient version of KVM? kvm-85? -- 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: [RFC PATCH 0/3] generic hypercall support
Gregory Haskins wrote: That only works if the device exposes a pio port, and the hypervisor exposes HC_PIO. If the device exposes the hypercall, things break once you assign it. Well, true. But normally I would think you would resurface the device from G1 to G2 anyway, so any relevant transform would also be reflected in the resurfaced device config. We do, but the G1 hypervisor cannot be expected to understand the config option that exposes the hypercall. I suppose if you had a hard requirement that, say, even the pci-config space was pass-through, this would be a problem. I am not sure if that is a realistic environment, though. You must pass through the config space, as some of it is device specific. The hypervisor will trap config space accesses, but unless it understands them, it cannot modify them. -- 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
[PATCH] Work around misreported kvm cpuid features
kvm misreports MCA, MCE, MTRR, and PAT as unsupported. This causes Vista to
fail. Since QEMU does not support any version of kvm that does not actually
support these features, it is safe to enable them unconditionally.
These features are needed by Vista x64 to boot.
Signed-off-by: Avi Kivity a...@redhat.com
---
target-i386/kvm.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index fe67eed..a7b7ae3 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -88,6 +88,13 @@ uint32_t kvm_arch_get_supported_cpuid(CPUState *env,
uint32_t function, int reg)
break;
case R_EDX:
ret = cpuid-entries[i].edx;
+if (function == 1) {
+/* kvm misreports the following features: */
+ret |= 1 12; /* MTRR */
+ret |= 1 16; /* PAT */
+ret |= 1 7; /* MCE */
+ret |= 1 14; /* MCA */
+}
if (function == 0x8001) {
/* On Intel, kvm returns cpuid according to the Intel spec,
* so add missing bits according to the AMD spec:
--
1.6.1.1
--
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] make migration work again
Glauber Costa wrote: Due to a small messup in version checking, migration was not working. fix it. Signed-off-by: Glauber Costa glom...@redhat.com --- migration-tcp.c |1 + savevm.c |1 + target-i386/helper.c |1 + target-i386/machine.c |8 4 files changed, 7 insertions(+), 4 deletions(-) Strange diffstat. diff --git a/target-i386/machine.c b/target-i386/machine.c index 7f75d31..c1e05c5 100644 --- a/target-i386/machine.c +++ b/target-i386/machine.c @@ -194,11 +194,11 @@ int cpu_load(QEMUFile *f, void *opaque, int version_id) int32_t a20_mask; if (version_id != 3 version_id != 4 version_id != 5 - version_id != 6 version_id != 7 version_id != 8) -return -EINVAL; -/* KVM cannot accept migrations from QEMU today */ -if (version_id != 9) + version_id != 6 version_id != 7 version_id != 8 +/* KVM cannot accept migrations from QEMU today */ + version_id != 9) return -EINVAL; I think you want to remove the first line as well? Only accept version_id == 9? And keep the comment. -- 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 1/2] replace drop_interrupt_shadow by set_interrupt_shadow
Glauber Costa wrote:
This patch replaces drop_interrupt_shadow with the more
general set_interrupt_shadow, that can either drop or raise
it, depending on its parameter.
void (*skip_emulated_instruction)(struct kvm_vcpu *vcpu);
+ void (*set_interrupt_shadow)(struct kvm_vcpu *vcpu, int mask);
+ u32 (*get_interrupt_shadow)(struct kvm_vcpu *vcpu);
Would be better to make these symmetric in their mask types.
+++ b/arch/x86/kvm/svm.c
@@ -202,6 +202,27 @@ static int is_external_interrupt(u32 info)
return info == (SVM_EVTINJ_VALID | SVM_EVTINJ_TYPE_INTR);
}
+static u32 svm_get_interrupt_shadow(struct kvm_vcpu *vcpu)
+{
+ struct vcpu_svm *svm = to_svm(vcpu);
+ u32 ret = 0;
+
+ if (svm-vmcb-control.int_state SVM_INTERRUPT_SHADOW_MASK)
+ ret |= (X86_SHADOW_INT_STI X86_SHADOW_INT_MOV_SS);
- |. Parentheses unnecessary.
{
struct vcpu_svm *svm = to_svm(vcpu);
@@ -2637,6 +2652,8 @@ static struct kvm_x86_ops svm_x86_ops = {
.run = svm_vcpu_run,
.handle_exit = handle_exit,
.skip_emulated_instruction = skip_emulated_instruction,
+ .set_interrupt_shadow= svm_set_interrupt_shadow,
Missing space.
+static void vmx_set_interrupt_shadow(struct kvm_vcpu *vcpu, int mask)
+{
+ u32 interruptibility_old = vmcs_read32(GUEST_INTERRUPTIBILITY_INFO);
+ u32 interruptibility = interruptibility_old;
+
+ switch (mask) {
+ case 0:
+ interruptibility = ~((GUEST_INTR_STATE_STI |
GUEST_INTR_STATE_MOV_SS));
+ break;
Need to clear this unconditionally, otherwise 'sti; mov ss' will set
both flags.
+ case X86_SHADOW_INT_MOV_SS:
+ interruptibility |= GUEST_INTR_STATE_MOV_SS;
+ break;
+ case X86_SHADOW_INT_STI:
+ interruptibility |= GUEST_INTR_STATE_STI;
+ break;
+ default:
+ printk(KERN_ERR Bogus mask for interrupt shadow!\n);
+ }
I suggest we deal with the case where both are set. One day we'll live
migrate this state, and if we come from an AMD host, we might get this
state.
--
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 2/2] deal with interrupt shadow state for emulated instruction
Glauber Costa wrote:
we currently unblock shadow interrupt state when we skip an instruction,
but failing to do so when we actually emulate one. This blocks interrupts
in key instruction blocks, in particular sti; hlt; sequences
If the instruction emulated is an sti, we have to block shadow interrupts.
The same goes for mov ss. pop ss also needs it, but we don't currently
emulate it.
Without this patch, I cannot boot gpxe option roms at vmx machines.
This is described at https://bugzilla.redhat.com/show_bug.cgi?id=494469
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 3d8fcc5..c456aa5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2362,7 +2362,7 @@ int emulate_instruction(struct kvm_vcpu *vcpu,
u16 error_code,
int emulation_type)
{
- int r;
+ int r, shadow_mask;
struct decode_cache *c;
kvm_clear_exception_queue(vcpu);
@@ -2415,7 +2415,12 @@ int emulate_instruction(struct kvm_vcpu *vcpu,
return EMULATE_DONE;
}
+ vcpu-arch.emulate_ctxt.interruptibility = 0;
If the instruction is sti or mov ss, this is ouput only. Otherwise, it
is an input/output parameter.
To reduce confusion suggest moving this statement to x86_emulate_insn,
so it can be an output-only parameter.
--
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
[PATCH v2] Work around misreported kvm cpuid features
kvm misreports MCA, MCE, MTRR, and PAT as unsupported. This causes Vista to
fail. Since QEMU does not support any version of kvm that does not actually
support these features, it is safe to enable them unconditionally.
These features are needed by Vista x64 to boot.
Signed-off-by: Avi Kivity a...@redhat.com
---
Changes from v1:
- use CPUID_* instead of open coding constants
target-i386/kvm.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index fe67eed..86da72d 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -88,6 +88,10 @@ uint32_t kvm_arch_get_supported_cpuid(CPUState *env,
uint32_t function, int reg)
break;
case R_EDX:
ret = cpuid-entries[i].edx;
+if (function == 1) {
+/* kvm misreports the following features: */
+ret |= CPUID_MTRR | CPUID_PAT | CPUID_MCA | CPUID_MCE;
+}
if (function == 0x8001) {
/* On Intel, kvm returns cpuid according to the Intel spec,
* so add missing bits according to the AMD spec:
--
1.6.0.6
--
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-Bugs-2789729 ] Destination guest will reboot when Migration
Bugs item #2789729, was opened at 2009-05-10 08:09 Message generated for change (Tracker Item Submitted) made by jiajun You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2789729group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: qemu Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) Summary: Destination guest will reboot when Migration Initial Comment: With kvm.git commit:66b0aed4a9e15a2ea3a00763f362b6ee0b28d538 and qemu-kvm.git commit:6e57bb9a636cefdaba7decbd5ac10f1508ff64c0, when doing live migration, the destination guest will reboot. Reproduce steps: (1)qemu-img create -b /share/xvs/img/app/ia32e_SMP.img -f qcow2 /share/xvs/var/tmp-img_CPL_LM_40_1228273473_1 (2)qemu -m 256 -net nic,macaddr=00:16:3e:39:78:1c,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/tmp-img_CPL_LM_40_1228273473_1 -incoming tcp:localhost: (3) Press Ctrl+Alt+2 to switch to qemu monitor (4) Run migrate tcp:localhost: -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2789729group_id=180599 -- 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
Biweekly KVM Test report, kvm.git 66b0ae... qemu-kvm.git 6e57bb...
Hi All, This is our Weekly KVM Testing Report against lastest kvm.git 66b0aed4a9e15a2ea3a00763f362b6ee0b28d538 and qemu-kvm.git 6e57bb9a636cefdaba7decbd5ac10f1508ff64c0. There is a Live Migration bug found in this two weeks. One New Issue: 1. Destination guest will reboot when Migration https://sourceforge.net/tracker/?func=detailaid=2789729group_id=180599atid=893831 Old Issue List: 1. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 2. 64-bit smp RHEL5.3 call trace after Live Migration https://sourceforge.net/tracker/?func=detailaid=2761920group_id=180599atid=893831 3. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 4. failure to migrate guests with more than 4GB of RAM https://sourceforge.net/tracker/index.php?func=detailaid=1971512group_id=180599atid=893831 5. OpenSuse10.2 can not be installed http://sourceforge.net/tracker/index.php?func=detailaid=2088475group_id=180599atid=893831 6. Fail to Save Restore Guest https://sourceforge.net/tracker/?func=detailatid=893831aid=2175042group_id=180599 7. hotplug inexistent device will kill guest https://sourceforge.net/tracker/index.php?func=detailaid=2432316group_id=180599atid=893831 8. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detailaid=2721640group_id=180599atid=893831 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G' Report Summary on IA32-pae Summary Test Report of Last Session = Total Pass Fail NoResult Crash = control_panel 8 6 2 0 0 gtest 16 16 0 0 0 = control_panel 8 6 2 0 0 :KVM_256M_guest_PAE_gPAE 1 1 0 0 0 :KVM_linux_win_PAE_gPAE 1 1 0 0 0 :KVM_two_winxp_PAE_gPAE 1 1 0 0 0 :KVM_four_sguest_PAE_gPA 1 1 0 0 0 :KVM_1500M_guest_PAE_gPA 1 1 0 0 0 :KVM_LM_Continuity_PAE_g 1 0 1 0 0 :KVM_LM_SMP_PAE_gPAE 1 1 0 0 0 :KVM_SR_Continuity_PAE_g 1 0 1 0 0 gtest 16 16 0 0 0 :ltp_nightly_PAE_gPAE 1 1 0 0 0 :boot_up_acpi_PAE_gPAE 1 1 0 0 0 :boot_up_acpi_xp_PAE_gPA 1 1 0 0 0 :boot_up_vista_PAE_gPAE 1 1 0 0 0 :reboot_xp_PAE_gPAE 1 1 0 0 0 :boot_base_kernel_PAE_gP 1 1 0 0 0 :boot_up_acpi_win2k3_PAE 1 1 0 0 0 :boot_smp_acpi_win2k3_PA 1 1 0 0 0 :boot_smp_acpi_win2k_PAE 1 1 0 0 0 :boot_up_win2008_PAE_gPA 1 1 0 0 0 :boot_up_acpi_win2k_PAE_ 1 1 0 0 0 :boot_smp_acpi_xp_PAE_gP 1 1 0 0 0 :boot_up_noacpi_win2k_PA 1 1 0 0 0 :boot_smp_vista_PAE_gPAE 1 1 0 0 0 :boot_smp_win2008_PAE_gP 1 1 0 0 0 :kb_nightly_PAE_gPAE 1 1 0 0 0 = Total 24 22 2 0 0 Report Summary on IA32e Summary Test Report of Last Session = Total Pass Fail NoResult Crash = control_panel 17 12 5 0 0 gtest 23 23 0 0 0 = control_panel 17 12 5 0 0 :KVM_4G_guest_64_g32e 1 1 0 0 0 :KVM_four_sguest_64_gPAE 1 1 0 0 0 :KVM_LM_SMP_64_g32e 1 1 0 0 0 :KVM_linux_win_64_gPAE 1 1 0 0 0 :KVM_LM_SMP_64_gPAE 1 1 0 0 0 :KVM_SR_Continuity_64_gP 1 0 1 0 0 :KVM_four_sguest_64_g32e 1 1
Re: Biweekly KVM Test report, kvm.git 66b0ae... qemu-kvm.git 6e57bb...
Xu, Jiajun wrote: Hi All, This is our Weekly KVM Testing Report against lastest kvm.git 66b0aed4a9e15a2ea3a00763f362b6ee0b28d538 and qemu-kvm.git 6e57bb9a636cefdaba7decbd5ac10f1508ff64c0. There is a Live Migration bug found in this two weeks. One New Issue: 1. Destination guest will reboot when Migration https://sourceforge.net/tracker/?func=detailaid=2789729group_id=180599atid=893831 There's a patch pending for this, should be applied in a day or too. Old Issue List: 1. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detailaid=2723366group_id=180599atid=893831 This test is not very meaningful on qcow2. It should be run on an LVM parition, with cache=none: -drive file=/dev/volgroup/image,cache=none -- 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 0/4] smp_send_reschedule / assigned dev host intx race v2
mtosa...@redhat.com wrote: Addressing comments. Applied, thanks. -- 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 3/4] KVM: introduce kvm_arch_can_free_memslot, disallow slot deletion if cached cr3
mtosa...@redhat.com wrote:
Disallow the deletion of memory slots (and aliases, for x86 case), if a
vcpu contains a cr3 that points to such slot/alias.
This complements commit 6c20e1442bb1c62914bb85b7f4a38973d2a423ba.
v2:
- set KVM_REQ_TRIPLE_FAULT
- use __KVM_HAVE_ARCH_CAN_FREE_MEMSLOT to avoid duplication of stub
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: kvm-pending/arch/x86/kvm/x86.c
===
--- kvm-pending.orig/arch/x86/kvm/x86.c
+++ kvm-pending/arch/x86/kvm/x86.c
@@ -1636,6 +1636,29 @@ gfn_t unalias_gfn(struct kvm *kvm, gfn_t
return gfn;
}
+static int kvm_root_gfn_in_range(struct kvm *kvm, gfn_t base_gfn,
+gfn_t end_gfn, bool unalias)
+{
+ struct kvm_vcpu *vcpu;
+ gfn_t root_gfn;
+ int i;
+
+ for (i = 0; i KVM_MAX_VCPUS; ++i) {
+ vcpu = kvm-vcpus[i];
+ if (!vcpu)
+ continue;
+ root_gfn = vcpu-arch.cr3 PAGE_SHIFT;
The guest may have changed this by now.
+ if (unalias)
+ root_gfn = unalias_gfn(kvm, root_gfn);
+ if (root_gfn = base_gfn root_gfn = end_gfn) {
+ set_bit(KVM_REQ_TRIPLE_FAULT, vcpu-requests);
+ return 1;
+ }
+ }
+
+ return 0;
+}
+
The naming is bad, a function named as a predicate shouldn't have side
effects.
Also, we should allow deleting the slot. There's no reason to deny
userspace something just because the guest is playing around
I think this should be enough:
- take mmu lock
- request an mmu reload from all vcpus
- drop the slot
- release mmu lock
The reload will inject a #GP if cr3 is now out of bounds, should be
changed to triple fault, but everything is in place (set_cr3 already
checks).
--
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 0/3] generic hypercall support
Gregory Haskins wrote: Anthony Liguori wrote: I'm surprised so much effort is going into this, is there any indication that this is even close to a bottleneck in any circumstance? Yes. Each 1us of overhead is a 4% regression in something as trivial as a 25us UDP/ICMP rtt ping.m It wasn't 1us, it was 350ns or something around there (i.e ~1%). for request-response, this is generally for *every* packet since you cannot exploit buffering/deferring. Can you back up your claim that PPC has no difference in performance with an MMIO exit and a hypercall (yes, I understand PPC has no VT like instructions, but clearly there are ways to cause a trap, so presumably we can measure the difference between a PF exit and something more explicit). First, the PPC that KVM supports performs very poorly relatively speaking because it receives no hardware assistance this is not the right place to focus wrt optimizations. And because there's no hardware assistance, there simply isn't a hypercall instruction. Are PFs the fastest type of exits? Probably not but I honestly have no idea. I'm sure Hollis does though. Page faults are going to have tremendously different performance characteristics on PPC too because it's a software managed TLB. There's no page table lookup like there is on x86. As a more general observation, we need numbers to justify an optimization, not to justify not including an optimization. In other words, the burden is on you to present a scenario where this optimization would result in a measurable improvement in a real world work load. Regards, Anthony Liguori We need numbers before we can really decide to abandon this optimization. If PPC mmio has no penalty over hypercall, I am not sure the 350ns on x86 is worth this effort (especially if I can shrink this with some RCU fixes). Otherwise, the margin is quite a bit larger. -Greg -- 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 1/3] virtio: find_vqs/del_vqs virtio operations
Am Sunday 10 May 2009 06:07:06 schrieb Rusty Russell: Yes, and in fact a rough look at your patch reveals that we don't actually need del_vq: now we track them, we can just do that as part of vdev destruction, right? Some of my students are working on a test module for virtio. Its a driver that matches all virtio IDs which can be used via bind/unbind. We currently use del_vq/find_vq in non device_release code. I will recheck but my feeling is that I want to keep del_vq. Christian -- 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 hardlocks on hp dv9010us
Hello, kvm-85 with vanilla kernel 2.6.29.3 (kvm modules from kernel) hard locks for me: - sometimes at the very beginning, just after the QEMU window opens, but nothing is displayed before the hardlock. - sometimes during runtime with various guests: e.g. Windows XP 64bit and Exherbo 64bit [1]. The latter one seems to trigger it very often, so I should be able to test any fixes quickly. It has been also happening with other guest OSes and older versions of kvm and older kernels. This is how i run kvm: kvm \ -hda /home/data/guests/exherbo-kvm-amd64-20090504.img \ -localtime \ -net nic -net tap,script=no,downscript=no,ifname=tap0 Also tried taskset 1 kvm ... I have a hp dv9010us laptop (one of those that hard locked before CONFIG_IO_DELAY_* options were introduced in kernel - not sure if it may be related at all). Is there anything I could do to debug it and provide more info? my hw (uname -a and lscpi): Linux phoebe 2.6.29.3 #1 SMP Sun May 10 20:33:09 CEST 2009 x86_64 AMD Turion(tm) 64 X2 Mobile Technology TL-56 AuthenticAMD GNU/Linux 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2) 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2) 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2) 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2) 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2) 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2) 00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2) 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3) 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3) 00:0a.3 Co-processor: nVidia Corporation MCP51 PMU (rev a3) 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) 00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev f1) 00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev f1) 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2) 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 03:00.0 Network controller: Broadcom Corporation BCM4311 802.11b/g WLAN (rev 01) 05:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce Go 7600] (rev a1) 07:05.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller 07:05.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) 07:05.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 01) 07:05.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a) 07:05.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05) [1] - http://dev.exherbo.org/images/exherbo-kvm-amd64-20090504.tar.xz -- Best Regards, Piotr Jaroszyński -- 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 hardlocks on hp dv9010us
I have tried debugging with netconsole but I am not getting anything directly preceding the hardlock, only: kvm: 4682: cpu0 unhandled wrmsr: 0xc0010117 data 0 on every startup (also manages to be logged when kvm hangs at the very beginning). -- Best Regards, Piotr Jaroszyński -- 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: Implement generic double fault generation mechanism
There is not point referring to current code. Current code does not handle serial exceptions properly. So fix it in your patch otherwise I propose to use my patch that fixes current code (http://patchwork.kernel.org/patch/21829/). I would like Avi to decide. As comments to the difference of 2 patches, my undrestanding is that I am addressing the problem base on SDM 5-4 with the answer to serial injection as first in first service. Your patch doesn;t solve generic double fault case for example exception 11 on 11, or GP on GP which needs to be converted to #DF per SDM, rather you only handle the case the secondary exception is PF, and servicing PF. I can check with internal architecture to see what does handle exceptions serially mean in really. For me serial means first in first out, and thus we should remain 1st exception. Eddie.-- 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: Luvalley-2 has been released: running KVM below any operating system
Xiaodong Yi wrote: It is not a typo. I copied from UnixBench output directly. Howver, it must be a bug of Luvalley because even the native Linux benchmark on Double-Precision Whetstone is not that high. I also noticed that other benchmarks are all lower than native Linux. About timing, Luvalley does nothing more than KVM except that Luvalley implemented the VLAPIC timer using TSC while KVM uses the services of Linux kernel. The other timers of both Luvalley and KVM, I think, are all implemented in Qemu. Moreover, I could not explain why Luvalley's benchmarks on process creation, execl throughput, file copy and shell script are 20% ~ 40% higher than KVM, while other benchmarks on pipe throughput, context switching and syscall overhead are almost the same as KVM. A typical issue in VMM benchmarking using OS benchmark such as what you used is time inaccurate issue. Benchmarks using guest time won't be able to get a right time or right duration due to scheduler etc, and thus VMM benchmarks is using network time for measuring such as vConsolidate. Spec.org is definning their benchmark for VMM, and I believe they will use network time too. For simplicity, you may continue use OS benchmark to measure VMM, but then you need to calibrate guest time accuracy first such as using stop watch etc. In both Xen KVM, we benchmark using OS benchmark too, but it is usually only to see improvement of a performance patch. Formal benchmark data needs to consult wall clock or stop watch. Thx, eddie-- 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 -v3 1/2] QEMU-KVM: MCE: Add MCE simulation to qemu/tcg
On Sat, 2009-05-09 at 05:08 +0800, Anthony Liguori wrote:
Huang Ying wrote:
- MCE features are initialized when VCPU is intialized according to CPUID.
- A monitor command mce is added to inject a MCE.
- A new interrupt mask: CPU_INTERRUPT_MCE is added to inject the MCE.
Signed-off-by: Huang Ying ying.hu...@intel.com
---
cpu-all.h |4 ++
cpu-exec.c |4 ++
monitor.c | 49 +
target-i386/cpu.h | 22 +++
target-i386/helper.c| 70
target-i386/op_helper.c | 34 +++
6 files changed, 183 insertions(+)
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -202,6 +202,7 @@
#define CR4_DE_MASK (1 3)
#define CR4_PSE_MASK (1 4)
#define CR4_PAE_MASK (1 5)
+#define CR4_MCE_MASK (1 6)
#define CR4_PGE_MASK (1 7)
#define CR4_PCE_MASK (1 8)
#define CR4_OSFXSR_SHIFT 9
@@ -248,6 +249,17 @@
#define PG_ERROR_RSVD_MASK 0x08
#define PG_ERROR_I_D_MASK 0x10
+#define MCE_CAP_DEF0x100
+#define MCE_BANKS_DEF 4
+
+#define MCG_CTL_P (1UL8)
+
+#define MCG_STATUS_MCIP(1UL2)
+
+#define MCI_STATUS_VAL (1UL63)
+#define MCI_STATUS_OVER(1UL62)
+#define MCI_STATUS_UC (1UL61)
+
#define MSR_IA32_TSC0x10
#define MSR_IA32_APICBASE 0x1b
#define MSR_IA32_APICBASE_BSP (18)
@@ -288,6 +300,11 @@
#define MSR_MTRRdefType0x2ff
+#define MSR_MC0_CTL0x400
+#define MSR_MC0_STATUS 0x401
+#define MSR_MC0_ADDR 0x402
+#define MSR_MC0_MISC 0x403
+
#define MSR_EFER0xc080
#define MSR_EFER_SCE (1 0)
@@ -674,6 +691,11 @@ typedef struct CPUX86State {
user */
struct APICState *apic_state;
uint32_t mp_state;
+
+uint64 mcg_cap;
+uint64 mcg_status;
+uint64 mcg_ctl;
+uint64 *mce_banks;
} CPUX86State;
Doesn't this need to be added to the savevm/loadvm state?
Yes. I will add it.
Best Regards,
Huang Ying
signature.asc
Description: This is a digitally signed message part
problems with pci passthrough of nic and a DL380G6
Are the instructions for passing a device at: http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM supposed to work for passing one of four onboard nics to a guest? I ask because not only did it not work, it made my server a very unhappy camper. Server: HP DL380 G6, 1 E5540, 6 GB RAM (3x2), latest BIOS SMT enabled, VT-d2 enabled Host OS: Fedora core 9 OS, kvm.git 66b0aed4a9e15..., pxe booted Device is last of the four on-board nics (the host is using the first one). Commands: modprobe pci-stub echo 14e4 1639 /sys/bus/pci/drivers/pci-stub/new_id echo :03:00.1 '/sys/bus/pci/devices/:03:00.1/driver/unbind' echo :03:00.1 /sys/bus/pci/drivers/pci-stub/bind Those commands worked fine. At this point I tried to mount the 4th logical disk (host OS is run via pxe and automounting of drives is not setup) and it failed. Since that disk holds the guest I wanted to run, I decided to reboot and start fresh. During reboot the server hung after a few BIOS initialization screens but before the PXE attempt. There was a 1 line message on the screen about an unknown NMI. The IML for the server shows a couple of critical errors - description is Unknown Event (Class 6, Code 4). A second reboot attempt hung at the same place. I had to disable VT-d2 in the BIOS to get it to come back. Any ideas? david -- 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: Luvalley-2 has been released: running KVM below any operating system
Thanks for your advice and hope your continue attention on Luvalley. Regards, Xiaodong 2009/5/11 Dong, Eddie eddie.d...@intel.com: Xiaodong Yi wrote: It is not a typo. I copied from UnixBench output directly. Howver, it must be a bug of Luvalley because even the native Linux benchmark on Double-Precision Whetstone is not that high. I also noticed that other benchmarks are all lower than native Linux. About timing, Luvalley does nothing more than KVM except that Luvalley implemented the VLAPIC timer using TSC while KVM uses the services of Linux kernel. The other timers of both Luvalley and KVM, I think, are all implemented in Qemu. Moreover, I could not explain why Luvalley's benchmarks on process creation, execl throughput, file copy and shell script are 20% ~ 40% higher than KVM, while other benchmarks on pipe throughput, context switching and syscall overhead are almost the same as KVM. A typical issue in VMM benchmarking using OS benchmark such as what you used is time inaccurate issue. Benchmarks using guest time won't be able to get a right time or right duration due to scheduler etc, and thus VMM benchmarks is using network time for measuring such as vConsolidate. Spec.org is definning their benchmark for VMM, and I believe they will use network time too. For simplicity, you may continue use OS benchmark to measure VMM, but then you need to calibrate guest time accuracy first such as using stop watch etc. In both Xen KVM, we benchmark using OS benchmark too, but it is usually only to see improvement of a performance patch. Formal benchmark data needs to consult wall clock or stop watch. Thx, eddie -- 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
