[Autotest PATCH] KVM-test: Simple stop/continue test
Change guest state by monitor cmd, verify guest status,
and try to login guest by network.
Signed-off-by: Jason Wang jasow...@redhat.com
Signed-off-by: Amos Kong ak...@redhat.com
---
client/tests/kvm/tests/stop_continue.py | 52 +++
client/tests/kvm/tests_base.cfg.sample |4 ++
2 files changed, 56 insertions(+), 0 deletions(-)
create mode 100644 client/tests/kvm/tests/stop_continue.py
diff --git a/client/tests/kvm/tests/stop_continue.py
b/client/tests/kvm/tests/stop_continue.py
new file mode 100644
index 000..c7d8025
--- /dev/null
+++ b/client/tests/kvm/tests/stop_continue.py
@@ -0,0 +1,52 @@
+import logging
+from autotest_lib.client.common_lib import error
+
+
+def run_stop_continue(test, params, env):
+
+Suspend a running Virtual Machine and verify its state.
+
+1) Boot the vm
+2) Suspend the vm through stop command
+3) Verify the state through info status command
+4) Check is the ssh session to guest is still responsive,
+ if succeed, fail the test.
+
+@param test: Kvm test object
+@param params: Dictionary with the test parameters
+@param env: Dictionary with test environment.
+
+vm = env.get_vm(params[main_vm])
+vm.verify_alive()
+timeout = float(params.get(login_timeout, 240))
+session = vm.wait_for_login(timeout=timeout)
+
+try:
+logging.info(Suspend the virtual machine)
+vm.monitor.cmd(stop)
+
+logging.info(Verifying the status of virtual machine through monitor)
+o = vm.monitor.info(status)
+if 'paused' not in o and ( u'running': False not in str(o)):
+logging.error(o)
+raise error.TestFail(Fail to suspend through monitor command
line)
+
+logging.info(Check the session responsiveness)
+if session.is_responsive():
+raise error.TestFail(Session is still responsive after stop)
+
+logging.info(Try to resume the guest)
+vm.monitor.cmd(cont)
+
+o = vm.monitor.info(status)
+m_type = params.get(monitor_type, human)
+if ('human' in m_type and 'running' not in o) or\
+ ('qmp' in m_type and u'running': True not in str(o)):
+logging.error(o)
+raise error.TestFail(Could not continue the execution)
+
+logging.info(Try to re-log into guest)
+session = vm.wait_for_login(timeout=timeout)
+
+finally:
+session.close()
diff --git a/client/tests/kvm/tests_base.cfg.sample
b/client/tests/kvm/tests_base.cfg.sample
index 5d274f8..7333ed0 100644
--- a/client/tests/kvm/tests_base.cfg.sample
+++ b/client/tests/kvm/tests_base.cfg.sample
@@ -260,6 +260,10 @@ variants:
- systemtap:
test_control_file = systemtap.control
+- stop_continue:
+type = stop_continue
+kill_vm_on_error = yes
+
- linux_s3: install setup unattended_install.cdrom
only Linux
type = linux_s3
--
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
[Autotest PATCH] KVM-test: Check if guest bootable after reseting several times
This test comes from a regression bug: Guest can not found bootable device after reseting several times by monitor command. Signed-off-by: Amos Kong ak...@redhat.com --- client/tests/kvm/tests/system_reset_bootable.py | 29 +++ client/tests/kvm/tests_base.cfg.sample |7 ++ 2 files changed, 36 insertions(+), 0 deletions(-) create mode 100755 client/tests/kvm/tests/system_reset_bootable.py diff --git a/client/tests/kvm/tests/system_reset_bootable.py b/client/tests/kvm/tests/system_reset_bootable.py new file mode 100755 index 000..ca9fb70 --- /dev/null +++ b/client/tests/kvm/tests/system_reset_bootable.py @@ -0,0 +1,29 @@ +import logging, time +from autotest_lib.client.common_lib import error +import kvm_test_utils + + +def run_system_reset_bootable(test, params, env): + +KVM reset test: +1) Boot guest. +2) Send some times system_reset monitor command. +3) Log into the guest to verify it could normally boot. + +@param test: kvm test object +@param params: Dictionary with the test parameters +@param env: Dictionary with test environment. + +vm = env.get_vm(params[main_vm]) +vm.verify_alive() +timeout = float(params.get(login_timeout, 240)) +reset_times = int(params.get(reset_times,20)) +interval = int(params.get(reset_interval,10)) +wait_time = int(params.get(wait_time_for_reset,60)) +time.sleep(wait_time) + +for i in range(reset_times): +vm.monitor.cmd(system_reset) +time.sleep(interval) + +session = vm.wait_for_login(timeout=timeout) diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample index 7333ed0..ceafebe 100644 --- a/client/tests/kvm/tests_base.cfg.sample +++ b/client/tests/kvm/tests_base.cfg.sample @@ -961,6 +961,13 @@ variants: sleep_before_reset = 20 kill_vm_on_error = yes +- system_reset_bootable: +type = system_reset_bootable +interval = 1 +reset_times = 20 +wait_time_for_reset = 120 +kill_vm_on_error = yes + - shutdown: install setup unattended_install.cdrom type = shutdown shutdown_method = shell -- 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] [qemu-iotests][PATCH] Update rbd support
On Tue, Apr 12, 2011 at 10:42:00PM -0700, Josh Durgin wrote: I suspect we only support the weird writing past size for the file protocol, so we should only run the test for it. Or does sheepdog do anything special about it? Sheepdog supports it by truncating to the right size if a write would be past the end. I'm not sure if other protocols support it. I've changed 016 to require the file or sheepdog protocols, and then applied the rest of your patch. Thanks a lot! -- 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] kvm, ioapic: Fix an error field reference
From: Liu Yuan tailai...@taobao.com Function ioapic_debug() in the ioapic_deliver() misnames one filed by reference. This patch correct it. Signed-off-by: Liu Yuan tailai...@taobao.com --- virt/kvm/ioapic.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c index 0b9df83..8df1ca1 100644 --- a/virt/kvm/ioapic.c +++ b/virt/kvm/ioapic.c @@ -167,7 +167,7 @@ static int ioapic_deliver(struct kvm_ioapic *ioapic, int irq) ioapic_debug(dest=%x dest_mode=%x delivery_mode=%x vector=%x trig_mode=%x\n, -entry-fields.dest, entry-fields.dest_mode, +entry-fields.dest_id, entry-fields.dest_mode, entry-fields.delivery_mode, entry-fields.vector, entry-fields.trig_mode); -- 1.7.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
[Autotest PATCH] KVM-test: TSC drift test
This case is used to test the drift between host and guest.
Use taskset to make tsc program execute in a single cpu.
If the drift ratio bigger than 10%, then fail this case.
Signed-off-by: Amos Kong ak...@redhat.com
---
client/tests/kvm/deps/get_tsc.c| 27 ++
client/tests/kvm/tests/tsc_drift.py| 88
client/tests/kvm/tests_base.cfg.sample |5 ++
3 files changed, 120 insertions(+), 0 deletions(-)
create mode 100644 client/tests/kvm/deps/get_tsc.c
create mode 100644 client/tests/kvm/tests/tsc_drift.py
diff --git a/client/tests/kvm/deps/get_tsc.c b/client/tests/kvm/deps/get_tsc.c
new file mode 100644
index 000..e91a41f
--- /dev/null
+++ b/client/tests/kvm/deps/get_tsc.c
@@ -0,0 +1,27 @@
+/*
+ * Programme to get cpu's TSC(time stamp counter)
+ * Copyright(C) 2009 Redhat, Inc.
+ * Amos Kong ak...@redhat.com
+ * Dec 9, 2009
+ *
+ */
+
+#define _GNU_SOURCE
+#include stdio.h
+#include stdint.h
+
+typedef unsigned long long u64;
+
+u64 rdtsc(void)
+{
+ unsigned tsc_lo, tsc_hi;
+
+ asm volatile(rdtsc : =a(tsc_lo), =d(tsc_hi));
+ return tsc_lo | (u64)tsc_hi 32;
+}
+
+int main(void)
+{
+ printf(%lld\n, rdtsc());
+ return 0;
+}
diff --git a/client/tests/kvm/tests/tsc_drift.py
b/client/tests/kvm/tests/tsc_drift.py
new file mode 100644
index 000..de2fb76
--- /dev/null
+++ b/client/tests/kvm/tests/tsc_drift.py
@@ -0,0 +1,88 @@
+import time, os, logging, commands, re
+from autotest_lib.client.common_lib import error
+from autotest_lib.client.bin import local_host
+import kvm_test_utils
+
+
+def run_tsc_drift(test, params, env):
+
+Check the TSC(time stamp counter) frequency of guest and host whether match
+or not
+
+1) Computer average tsc frequency of host's cpus by C the program
+2) Copy the C code to the guest, complie and run it to get tsc
+ frequency of guest's vcpus
+3) Sleep sometimes and get the TSC of host and guest again
+4) Compute the TSC frequency of host and guest
+5) Compare the frequency deviation between host and guest with standard
+
+@param test: Kvm test object
+@param params: Dictionary with the test parameters.
+@param env: Dictionary with test environment.
+
+drift_threshold = float(params.get(drift_threshold))
+interval = float(params.get(interval))
+cpu_chk_cmd = params.get(cpu_chk_cmd)
+tsc_freq_path = os.path.join(test.bindir, 'deps/get_tsc.c')
+host_freq = 0
+
+def get_tsc(machine=host, i=0):
+cmd = taskset -c %s /tmp/get_tsc % i
+if machine == host:
+s, o = commands.getstatusoutput(cmd)
+else:
+s, o = session.cmd_status_output(cmd)
+if s != 0:
+logging.debug(o)
+raise error.TestError(Fail to get tsc of host, ncpu: %d % i)
+return float(re.findall((\d+),o)[0])
+
+vm = env.get_vm(params[main_vm])
+vm.verify_alive()
+timeout = float(params.get(login_timeout, 240))
+session = vm.wait_for_login(timeout=timeout)
+
+commands.getoutput(gcc %s -o /tmp/get_tsc % tsc_freq_path)
+ncpu = local_host.LocalHost().get_num_cpu()
+
+logging.info(Interval is %s % interval)
+logging.info(Determine the TSC frequency in the host)
+for i in range(ncpu):
+tsc1 = get_tsc(host, i)
+time.sleep(interval)
+tsc2 = get_tsc(host, i)
+
+delta = tsc2 - tsc1
+logging.info(Host TSC delta for cpu %s is %s % (i, delta))
+if delta 0:
+raise error.TestError(Host TSC for cpu %s warps %s % (i, delta))
+
+host_freq += delta / ncpu
+logging.info(Average frequency of host's cpus: %s % host_freq)
+
+vm.copy_files_to(tsc_freq_path,'/tmp/get_tsc.c')
+session.cmd(gcc /tmp/get_tsc.c -o /tmp/get_tsc)
+
+s, guest_ncpu = session.cmd_status_output(cpu_chk_cmd)
+
+success = True
+for i in range(int(guest_ncpu)):
+tsc1 = get_tsc(guest, i)
+time.sleep(interval)
+tsc2 = get_tsc(guest, i)
+
+delta = tsc2 - tsc1
+logging.info(Guest TSC delta for vcpu %s is %s % (i, delta))
+if delta 0:
+logging.error(Guest TSC for vcpu %s warps %s % (i, delta))
+
+ratio = 100 * (delta - host_freq) / host_freq
+logging.info(TSC drift ratio for vcpu %s is %s % (i, ratio))
+if abs(ratio) drift_threshold:
+logging.error(TSC drift found for vcpu %s ratio %s % (i, ratio))
+success = False
+
+if not success:
+raise error.TestFail(TSC drift found for the guest, please check the
+ log for details)
+session.close()
diff --git a/client/tests/kvm/tests_base.cfg.sample
b/client/tests/kvm/tests_base.cfg.sample
index ceafebe..8e70746 100644
--- a/client/tests/kvm/tests_base.cfg.sample
+++ b/client/tests/kvm/tests_base.cfg.sample
@@ -331,6 +331,11 @@ variants:
drift_threshold = 10
Re: How to use qemu-kvm with Fedora15-beta gnome3 (better vga driver ?)
On 04/21/2011 05:40 AM, Cheng Renquan wrote: I'm trying to use qemu-kvm to run Fedora15-beta with gnome3, but it told me graphics hardware failed to run gnome3 specific features and it fallback to gnome2; Sorry, none of the cards provided by KVM (including the SPICE-specific QXL card) currently provide the 3D acceleration abilities required by GNOME 3. Paolo -- 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: performance of virtual functions compared to virtio
On 04/21/2011 05:35 AM, Alex Williamson wrote: Device assignment via a VF provides the lowest latency and most bandwidth for *getting data off the host system*, though virtio/vhost is getting better. If all you care about is VM-VM on the same host or VM-host, then virtio is only limited by memory bandwidth/latency and host processor cycles. Your processor has 25GB/s of memory bandwidth. On the other hand, the VF has to send data all the way out to the wire and all the way back up through the NIC to get to the other VM/host. You're using a 1Gb/s NIC. Your results actually seem to indicate you're getting better than wire rate, so maybe you're only passing through an internal switch on the NIC, in any case, VFs are not optimal for communication within the same physical system. They are optimal for off host communication. Thanks, Note I think in both cases we can make significant improvements: - for VFs, steer device interrupts to the cpus which run the vcpus that will receive the interrupts eventually (ISTR some work about this, but not sure) - for virtio, use a DMA engine to copy data (I think there exists code in upstream which does this, but has this been enabled/tuned?) -- 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] KVM: MMU: Make cmpxchg_gpte aware of nesting too
On 04/21/2011 04:02 AM, Takuya Yoshikawa wrote:
On Wed, 20 Apr 2011 15:33:16 +0200
Roedel, Joergjoerg.roe...@amd.com wrote:
@@ -245,13 +257,17 @@ walk:
goto error;
if (write_fault !is_dirty_gpte(pte)) {
- bool ret;
+ int ret;
trace_kvm_mmu_set_dirty_bit(table_gfn, index, sizeof(pte));
- ret = FNAME(cmpxchg_gpte)(vcpu-kvm, table_gfn, index, pte,
+ ret = FNAME(cmpxchg_gpte)(vcpu, mmu, table_gfn, index, pte,
pte|PT_DIRTY_MASK);
- if (ret)
+ if (ret 0) {
+ present = false;
+ goto error;
+ } if (ret)
goto walk;
Preferably else if or another line ? :)
Yes, I added an 'else' and 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] kvm, ioapic: Fix an error field reference
On 04/21/2011 09:53 AM, Liu Yuan wrote: From: Liu Yuantailai...@taobao.com Function ioapic_debug() in the ioapic_deliver() misnames one filed by reference. This patch correct it. 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: How to use qemu-kvm with Fedora15-beta gnome3 (better vga driver ?)
On Thu, Apr 21, 2011 at 12:57 AM, Paolo Bonzini pbonz...@redhat.com wrote: On 04/21/2011 05:40 AM, Cheng Renquan wrote: I'm trying to use qemu-kvm to run Fedora15-beta with gnome3, but it told me graphics hardware failed to run gnome3 specific features and it fallback to gnome2; Sorry, none of the cards provided by KVM (including the SPICE-specific QXL card) currently provide the 3D acceleration abilities required by GNOME 3. Later when I tried VirtualBox I found VB video driver has such 3D acceleration abilities, but I just don't like VB style slow performance; Then are there some plans / possibilities to add more virtual graphics hardware drivers for qemu kvm ? Any specification to follow? Pointers for me to explore this way? cheng@cheng-tux ~ $ ls -lh /usr/share/qemu/vgabios* -rw-r--r-- 1 root root 35K Oct 14 2010 /usr/share/qemu/vgabios-cirrus.bin -rw-r--r-- 1 root root 39K Oct 14 2010 /usr/share/qemu/vgabios.bin cheng@cheng-tux ~ $ file /usr/share/qemu/vgabios* /usr/share/qemu/vgabios-cirrus.bin: BIOS (ia32) ROM Ext. IBM comp. Video (70*512) /usr/share/qemu/vgabios.bin:BIOS (ia32) ROM Ext. IBM comp. Video (78*512) -- 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 v3 0/3] Store and load PCI device saved state across function resets
On 04/20/2011 11:31 PM, Alex Williamson wrote: v2 - v3: Saved structure has variable contents. Avi, see if this adds any credibility to the pci-core allocated opaque buffer. It was wrong in the previous versions to distill the variable device capability save list into a fixed struct. This should also eliminate any future maintenance specific to this storing and loading of state as capability save changes. Haha, nice trick. Yes, it does. -- 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 v3 3/3] KVM: Use pci_store/load_saved_state() around VM device usage
On 04/20/2011 11:31 PM, Alex Williamson wrote: Store the device saved state so that we can reload the device back to the original state when it's unassigned. This has the benefit that the state survives across pci_reset_function() calls via the PCI sysfs reset interface while the VM is using the device. Acked-by: Avi Kivity a...@redhat.com -- 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 0/3] Convert 0F 01 opcodes to opcode::execute
A little step towards removing the big switch (). Avi Kivity (3): KVM: x86 emulator: move 0F 01 sub-opcodes into their own functions KVM: x86 emulator: Don't force #UD for 0F 01 /5 KVM: x86 emulator: Use opcode::execute for 0F 01 opcode arch/x86/kvm/emulate.c | 169 +++- 1 files changed, 94 insertions(+), 75 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
[PATCH 1/3] KVM: x86 emulator: move 0F 01 sub-opcodes into their own functions
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/emulate.c | 146 ---
1 files changed, 99 insertions(+), 47 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index f683ce1..bf4284d 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2589,6 +2589,95 @@ static int em_clts(struct x86_emulate_ctxt *ctxt)
return X86EMUL_CONTINUE;
}
+static int em_vmcall(struct x86_emulate_ctxt *ctxt)
+{
+ struct decode_cache *c = ctxt-decode;
+ int rc;
+
+ if (c-modrm_mod != 3 || c-modrm_rm != 1)
+ return X86EMUL_UNHANDLEABLE;
+
+ rc = ctxt-ops-fix_hypercall(ctxt);
+ if (rc != X86EMUL_CONTINUE)
+ return rc;
+
+ /* Let the processor re-execute the fixed hypercall */
+ c-eip = ctxt-eip;
+ /* Disable writeback. */
+ c-dst.type = OP_NONE;
+ return X86EMUL_CONTINUE;
+}
+
+static int em_lgdt(struct x86_emulate_ctxt *ctxt)
+{
+ struct decode_cache *c = ctxt-decode;
+ struct desc_ptr desc_ptr;
+ int rc;
+
+ rc = read_descriptor(ctxt, ctxt-ops, c-src.addr.mem,
+desc_ptr.size, desc_ptr.address,
+c-op_bytes);
+ if (rc != X86EMUL_CONTINUE)
+ return rc;
+ ctxt-ops-set_gdt(ctxt, desc_ptr);
+ /* Disable writeback. */
+ c-dst.type = OP_NONE;
+ return X86EMUL_CONTINUE;
+}
+
+static int em_svm(struct x86_emulate_ctxt *ctxt)
+{
+ struct decode_cache *c = ctxt-decode;
+ int rc;
+
+ switch (c-modrm_rm) {
+ case 1:
+ rc = ctxt-ops-fix_hypercall(ctxt);
+ break;
+ default:
+ return X86EMUL_UNHANDLEABLE;
+ }
+ /* Disable writeback. */
+ c-dst.type = OP_NONE;
+ return rc;
+}
+
+static int em_lidt(struct x86_emulate_ctxt *ctxt)
+{
+ struct decode_cache *c = ctxt-decode;
+ struct desc_ptr desc_ptr;
+ int rc;
+
+ rc = read_descriptor(ctxt, ctxt-ops, c-src.addr.mem,
+desc_ptr.size,
+desc_ptr.address,
+c-op_bytes);
+ if (rc != X86EMUL_CONTINUE)
+ return rc;
+ ctxt-ops-set_idt(ctxt, desc_ptr);
+ /* Disable writeback. */
+ c-dst.type = OP_NONE;
+ return X86EMUL_CONTINUE;
+}
+
+static int em_smsw(struct x86_emulate_ctxt *ctxt)
+{
+ struct decode_cache *c = ctxt-decode;
+
+ c-dst.bytes = 2;
+ c-dst.val = ctxt-ops-get_cr(ctxt, 0);
+ return X86EMUL_CONTINUE;
+}
+
+static int em_lmsw(struct x86_emulate_ctxt *ctxt)
+{
+ struct decode_cache *c = ctxt-decode;
+ ctxt-ops-set_cr(ctxt, 0, (ctxt-ops-get_cr(ctxt, 0) ~0x0eul)
+ | (c-src.val 0x0f));
+ c-dst.type = OP_NONE;
+ return X86EMUL_CONTINUE;
+}
+
static bool valid_cr(int nr)
{
switch (nr) {
@@ -3509,7 +3598,6 @@ x86_emulate_insn(struct x86_emulate_ctxt *ctxt)
int rc = X86EMUL_CONTINUE;
int saved_dst_type = c-dst.type;
int irq; /* Used for int 3, int, and into */
- struct desc_ptr desc_ptr;
ctxt-decode.mem_read.pos = 0;
@@ -4022,62 +4110,26 @@ twobyte_insn:
case 0x01: /* lgdt, lidt, lmsw */
switch (c-modrm_reg) {
case 0: /* vmcall */
- if (c-modrm_mod != 3 || c-modrm_rm != 1)
- goto cannot_emulate;
-
- rc = ctxt-ops-fix_hypercall(ctxt);
- if (rc != X86EMUL_CONTINUE)
- goto done;
-
- /* Let the processor re-execute the fixed hypercall */
- c-eip = ctxt-eip;
- /* Disable writeback. */
- c-dst.type = OP_NONE;
+ rc = em_vmcall(ctxt);
break;
case 2: /* lgdt */
- rc = read_descriptor(ctxt, ops, c-src.addr.mem,
-desc_ptr.size, desc_ptr.address,
-c-op_bytes);
- if (rc != X86EMUL_CONTINUE)
- goto done;
- ctxt-ops-set_gdt(ctxt, desc_ptr);
- /* Disable writeback. */
- c-dst.type = OP_NONE;
+ rc = em_lgdt(ctxt);
break;
case 3: /* lidt/vmmcall */
- if (c-modrm_mod == 3) {
- switch (c-modrm_rm) {
- case 1:
- rc = ctxt-ops-fix_hypercall(ctxt);
- break;
- default:
- goto cannot_emulate;
- }
-
[PATCH 2/3] KVM: x86 emulator: Don't force #UD for 0F 01 /5
While it isn't defined, no need to force a #UD. If it becomes defined in the future this can cause wierd problems for the guest. Signed-off-by: Avi Kivity a...@redhat.com --- arch/x86/kvm/emulate.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index bf4284d..e8f146d 100644 --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -4127,9 +4127,6 @@ twobyte_insn: case 6: /* lmsw */ rc = em_lmsw(ctxt); break; - case 5: /* not defined */ - rc = emulate_ud(ctxt); - break; case 7: /* invlpg*/ rc = em_invlpg(ctxt); break; -- 1.7.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
[PATCH 3/3] KVM: x86 emulator: Use opcode::execute for 0F 01 opcode
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/emulate.c | 56 +++
1 files changed, 13 insertions(+), 43 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index e8f146d..522b4a5 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2625,18 +2625,13 @@ static int em_lgdt(struct x86_emulate_ctxt *ctxt)
return X86EMUL_CONTINUE;
}
-static int em_svm(struct x86_emulate_ctxt *ctxt)
+static int em_vmmcall(struct x86_emulate_ctxt *ctxt)
{
struct decode_cache *c = ctxt-decode;
int rc;
- switch (c-modrm_rm) {
- case 1:
- rc = ctxt-ops-fix_hypercall(ctxt);
- break;
- default:
- return X86EMUL_UNHANDLEABLE;
- }
+ rc = ctxt-ops-fix_hypercall(ctxt);
+
/* Disable writeback. */
c-dst.type = OP_NONE;
return rc;
@@ -2909,7 +2904,7 @@ static struct opcode group7_rm1[] = {
static struct opcode group7_rm3[] = {
DIP(SrcNone | ModRM | Prot | Priv, vmrun, check_svme_pa),
- DI(SrcNone | ModRM | Prot | VendorSpecific, vmmcall),
+ II(SrcNone | ModRM | Prot | VendorSpecific, em_vmmcall, vmmcall),
DIP(SrcNone | ModRM | Prot | Priv, vmload, check_svme_pa),
DIP(SrcNone | ModRM | Prot | Priv, vmsave, check_svme_pa),
DIP(SrcNone | ModRM | Prot | Priv, stgi,check_svme),
@@ -2961,15 +2956,17 @@ static struct opcode group6[] = {
static struct group_dual group7 = { {
DI(ModRM | Mov | DstMem | Priv, sgdt),
DI(ModRM | Mov | DstMem | Priv, sidt),
- DI(ModRM | SrcMem | Priv, lgdt), DI(ModRM | SrcMem | Priv, lidt),
- DI(SrcNone | ModRM | DstMem | Mov, smsw), N,
- DI(SrcMem16 | ModRM | Mov | Priv, lmsw),
- DI(SrcMem | ModRM | ByteOp | Priv | NoAccess, invlpg),
+ II(ModRM | SrcMem | Priv, em_lgdt, lgdt),
+ II(ModRM | SrcMem | Priv, em_lidt, lidt),
+ II(SrcNone | ModRM | DstMem | Mov, em_smsw, smsw), N,
+ II(SrcMem16 | ModRM | Mov | Priv, em_lmsw, lmsw),
+ II(SrcMem | ModRM | ByteOp | Priv | NoAccess, em_invlpg, invlpg),
}, {
- D(SrcNone | ModRM | Priv | VendorSpecific), EXT(0, group7_rm1),
+ I(SrcNone | ModRM | Priv | VendorSpecific, em_vmcall),
+ EXT(0, group7_rm1),
N, EXT(0, group7_rm3),
- DI(SrcNone | ModRM | DstMem | Mov, smsw), N,
- DI(SrcMem16 | ModRM | Mov | Priv, lmsw), EXT(0, group7_rm7),
+ II(SrcNone | ModRM | DstMem | Mov, em_smsw, smsw), N,
+ II(SrcMem16 | ModRM | Mov | Priv, em_lmsw, lmsw), EXT(0, group7_rm7),
} };
static struct opcode group8[] = {
@@ -4107,33 +4104,6 @@ done:
twobyte_insn:
switch (c-b) {
- case 0x01: /* lgdt, lidt, lmsw */
- switch (c-modrm_reg) {
- case 0: /* vmcall */
- rc = em_vmcall(ctxt);
- break;
- case 2: /* lgdt */
- rc = em_lgdt(ctxt);
- break;
- case 3: /* lidt/vmmcall */
- if (c-modrm_mod == 3)
- return em_svm(ctxt);
- else
- return em_lidt(ctxt);
- break;
- case 4: /* smsw */
- rc = em_smsw(ctxt);
- break;
- case 6: /* lmsw */
- rc = em_lmsw(ctxt);
- break;
- case 7: /* invlpg*/
- rc = em_invlpg(ctxt);
- break;
- default:
- goto cannot_emulate;
- }
- break;
case 0x05: /* syscall */
rc = emulate_syscall(ctxt, ops);
break;
--
1.7.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
[PATCH] KVM: SVM: Get rid of x86_intercept_map::valid
By reserving 0 as an invalid x86_intercept_stage, we no longer
need to store a valid flag in x86_intercept_map.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/include/asm/kvm_emulate.h |1 +
arch/x86/kvm/svm.c | 12
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/kvm_emulate.h
b/arch/x86/include/asm/kvm_emulate.h
index 127ea3e..28114f5 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -304,6 +304,7 @@ struct x86_emulate_ctxt {
X86EMUL_MODE_PROT64)
enum x86_intercept_stage {
+ X86_ICTP_NONE = 0, /* Allow zero-init to not match anything */
X86_ICPT_PRE_EXCEPT,
X86_ICPT_POST_EXCEPT,
X86_ICPT_POST_MEMACCESS,
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index de4bba9..9cff036 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3959,19 +3959,15 @@ static void svm_fpu_deactivate(struct kvm_vcpu *vcpu)
}
#define PRE_EX(exit) { .exit_code = (exit), \
- .stage = X86_ICPT_PRE_EXCEPT, \
- .valid = true }
+ .stage = X86_ICPT_PRE_EXCEPT, }
#define POST_EX(exit) { .exit_code = (exit), \
- .stage = X86_ICPT_POST_EXCEPT, \
- .valid = true }
+ .stage = X86_ICPT_POST_EXCEPT, }
#define POST_MEM(exit) { .exit_code = (exit), \
-.stage = X86_ICPT_POST_MEMACCESS, \
-.valid = true }
+ .stage = X86_ICPT_POST_MEMACCESS, }
static struct __x86_intercept {
u32 exit_code;
enum x86_intercept_stage stage;
- bool valid;
} x86_intercept_map[] = {
[x86_intercept_cr_read] = POST_EX(SVM_EXIT_READ_CR0),
[x86_intercept_cr_write]= POST_EX(SVM_EXIT_WRITE_CR0),
@@ -4039,7 +4035,7 @@ static int svm_check_intercept(struct kvm_vcpu *vcpu,
icpt_info = x86_intercept_map[info-intercept];
- if (!icpt_info.valid || stage != icpt_info.stage)
+ if (stage != icpt_info.stage)
goto out;
switch (icpt_info.exit_code) {
--
1.7.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] KVM: Add CPUID support for VIA CPU
Hi, Avi I'm sorry to reply you a little late. I spent some time on finding information to fix the EFLAGS[30] issue, and I have got it now. Here is some comment from Centaur.: EFLAGS:30 was used on C7 but not by Nano. EFLAGS:30 is undefined for Intel. C7 used it as a way of improving performance by remembering when keyram was valid but it required users to clear the bit (say by PUSHF/POPF) when changing keys for an encryption. There was a whole lot of ucode to make sure that EFLAGS:30 would always be zero on a task switch, to avoid leaking key material (or simply making an error in calculation). In a rational fit of paranoia, we decided that it was safer to always reset the internal keyram at the start of every XCRYPT instruction, which made use of EFLAGS:30 irrelevant. The current docs make no reference to EFLAGS, and they specifically indicate that they supercede all previous documentation. So,the conclusion is: Only VIA C7 CPUs have dependency on EFLAGS[30], but they do not support VT-X technology, so kvm can not run on it and the issue about EFLAGS[30] will not occur. VIA Nano CPUs support VT-X technology and can run kvm, but they have no dependency on EFLAGS[30] (EFLAGS[30] is kept cleared), so the issue about EFLAGS[30] will not appear, too. I'll send you the current document about nano cpu. Brilly 2011-04-21 On 04/14/2011 12:54 PM, brill...@viatech.com.cn wrote: Thank you very much for telling me where the EFLAGS[30] might be set and cleared. In fact, adding the CPUID support into kvm kernel code is just to provide correct result for the calling of the kvm_arch_get_supported_cpuid function in Qemu-kvm application. That may not be sufficient for correct operation. Consider: - guest executes a padlock instruction - cpu sets EFLAGS[30] - external interrupt - VMEXIT (saves EFLAGS in GUEST_RFLAGS with EFLAGS[30] set) - external interrupt is processed, causes a task switch - EFLAGS[30] is cleared - some other process uses padlock instructions, which causes a reload of key information - switch back to kvm - VM entry (loads EFLAGS from GUEST_RFLAGS; still has EFLAGS[30] set) - guest executes following padlock instruction, doesn't reload key information so I think the code as is causes data corruption. Yes, I agree. But VIA Nano is no longer associated with EFLAGS[30], so the data corruption will not appear. There is no dependency on EFLAGS when calling VIA CPUID instruction. Before using padlock engine functions, the application first need detect is the features exist through cpuid instruction, then use ACE and other instructions such as PHE/RNG/PMM. And as previously said, only the ACE instructions required that the EFLAGS[30] should be set to 0, It is recommanded that execute instruction sequence pushf;popf to clear this bit before using ACE instructions. The problem is that VM entry reloads eflags from saved state and is not affected by popf. I have re-submitted this patch, please check it. Thanks! wrt cpuid it seems reasonable but that's we need to clear the EFLAGS[30] issue first. I think the EFLAGS[30] issue is fixed now. -- 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 -- 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 33762] Qemu-kvm infinite loop on hardened (Grsecurity/PaX) kernel
https://bugzilla.kernel.org/show_bug.cgi?id=33762 Anton Kochkov anton.koch...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- 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
[Bug 27052] Module KVM : unable to handle kernel NULL pointer dereference at
https://bugzilla.kernel.org/show_bug.cgi?id=27052 Taisuke Yamada tai.ker...@cc.rakugaki.org changed: What|Removed |Added CC||tai.ker...@cc.rakugaki.org --- Comment #39 from Taisuke Yamada tai.ker...@cc.rakugaki.org 2011-04-21 11:45:45 --- Is this issue resolved? I'm seeing almost the same issue with 2.6.38 + qemu-kvm-0.14.0 (on NEC Express5800/110Ge server), except that my backtrace is calling paging64_sync_page instead of paging32_sync_page. -- 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
[Bug 27052] Module KVM : unable to handle kernel NULL pointer dereference at
https://bugzilla.kernel.org/show_bug.cgi?id=27052 --- Comment #40 from Avi Kivity a...@redhat.com 2011-04-21 12:13:33 --- (In reply to comment #39) Is this issue resolved? I'm seeing almost the same issue with 2.6.38 + qemu-kvm-0.14.0 (on NEC Express5800/110Ge server), except that my backtrace is calling paging64_sync_page instead of paging32_sync_page. Do you also have netfilter enabled on the host? What happens if you enable debug options as per comment #29? -- 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: performance of virtual functions compared to virtio
On Thu, Apr 21, 2011 at 9:07 AM, Avi Kivity a...@redhat.com wrote: Note I think in both cases we can make significant improvements: - for VFs, steer device interrupts to the cpus which run the vcpus that will receive the interrupts eventually (ISTR some work about this, but not sure) - for virtio, use a DMA engine to copy data (I think there exists code in upstream which does this, but has this been enabled/tuned?) Which data copy in virtio? Is this a vhost-net specific thing you're thinking about? Stefan -- 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] intel-iommu: Fix use after release during device attach
On 2011-01-04 11:42, Jan Kiszka wrote:
Am 10.12.2010 19:44, Chris Wright wrote:
* Jan Kiszka (jan.kis...@siemens.com) wrote:
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -3627,9 +3627,9 @@ static int intel_iommu_attach_device(struct
iommu_domain *domain,
pte = dmar_domain-pgd;
if (dma_pte_present(pte)) {
-free_pgtable_page(dmar_domain-pgd);
dmar_domain-pgd = (struct dma_pte *)
phys_to_virt(dma_pte_addr(pte));
While here, might as well remove the unnecessary cast.
+free_pgtable_page(pte);
}
dmar_domain-agaw--;
}
Reviewed-by: Sheng Yang sh...@linux.intel.com
Acked-by: Chris Wright chr...@sous-sol.org
CC iommu mailing list and David.
Ping...
I think this fix also qualifies for stable (.35 and .36).
Still not merged?
David, do you plan to pick this one up?
thanks,
-chris
Hmm, still no reaction. Trying David's Intel address now...
Jan
Walking through my old queues, I came across this one again.
Given the still lacking reaction from the official maintainer, I'm a
bit confused about the state of intel-iommu. Is it unmaintained? Should
this bug fix better be routed through the KVM tree as its only in-tree
user? Please enlighten me.
Note that the patch became stable material for 35..38 in the meantime,
and it should go into 39 before release as well.
Thanks,
Jan
---8
Obtain the new pgd pointer before releasing the page containing this
value. Remove unneeded cast at this chance as well.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
drivers/pci/intel-iommu.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
v1-v2: Clean up cast as suggested by Chris.
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index 505c1c7..b3e5c43 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -3607,9 +3607,8 @@ static int intel_iommu_attach_device(struct iommu_domain
*domain,
pte = dmar_domain-pgd;
if (dma_pte_present(pte)) {
- free_pgtable_page(dmar_domain-pgd);
- dmar_domain-pgd = (struct dma_pte *)
- phys_to_virt(dma_pte_addr(pte));
+ dmar_domain-pgd = phys_to_virt(dma_pte_addr(pte));
+ free_pgtable_page(pte);
}
dmar_domain-agaw--;
}
--
1.7.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
[PATCH] kvm tools: Use mmap to allocate guest RAM
Using mmap to allocate the RAM enables us to allocate large blocks of memory
for the guest, allowing to boot guests with a large RAM.
Since if we try KVM_SET_USER_MEMORY_REGION with a large memory block KVM used
to Oops (now it just fails), we had to move the actual ioctl to after we
KVM_CREATE_VCPU.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/kvm.h |2 +-
tools/kvm/kvm-run.c |5 -
tools/kvm/kvm.c | 21 +++--
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/tools/kvm/include/kvm/kvm.h b/tools/kvm/include/kvm/kvm.h
index fc76f98..3a44c53 100644
--- a/tools/kvm/include/kvm/kvm.h
+++ b/tools/kvm/include/kvm/kvm.h
@@ -25,7 +25,7 @@ struct kvm {
struct interrupt_table interrupt_table;
};
-struct kvm *kvm__init(const char *kvm_dev, unsigned long ram_size);
+struct kvm *kvm__init(const char *kvm_dev, unsigned long ram_size, bool
use_backing);
void kvm__init_ram(struct kvm *self);
void kvm__delete(struct kvm *self);
bool kvm__load_kernel(struct kvm *kvm, const char *kernel_filename,
diff --git a/tools/kvm/kvm-run.c b/tools/kvm/kvm-run.c
index fb8dcae7..a925a98 100644
--- a/tools/kvm/kvm-run.c
+++ b/tools/kvm/kvm-run.c
@@ -69,6 +69,7 @@ static const char *host_ip_addr;
static const char *guest_mac;
static const char *script;
static bool single_step;
+static bool use_backing;
static bool readonly_image;
extern bool ioport_debug;
extern int active_console;
@@ -84,6 +85,8 @@ static const struct option options[] = {
OPT_GROUP(Basic options:),
OPT_INTEGER('\0', cpus, nrcpus, Number of CPUs),
OPT_U64('m', mem, ram_size, Virtual machine memory size in MiB.),
+ OPT_BOOLEAN('\0', use-backing, use_backing,
+ Use a backing file for virtual RAM),
OPT_STRING('i', image, image_filename, image, Disk image),
OPT_BOOLEAN('\0', readonly, readonly_image,
Don't write changes back to disk image),
@@ -366,7 +369,7 @@ int kvm_cmd_run(int argc, const char **argv, const char
*prefix)
term_init();
- kvm = kvm__init(kvm_dev, ram_size);
+ kvm = kvm__init(kvm_dev, ram_size, use_backing);
memset(real_cmdline, 0, sizeof(real_cmdline));
strcpy(real_cmdline, notsc nolapic noacpi pci=conf1 console=ttyS0 );
diff --git a/tools/kvm/kvm.c b/tools/kvm/kvm.c
index eb1a46c..5e312e9 100644
--- a/tools/kvm/kvm.c
+++ b/tools/kvm/kvm.c
@@ -170,11 +170,12 @@ void kvm__init_ram(struct kvm *self)
die_perror(KVM_SET_USER_MEMORY_REGION ioctl);
}
-struct kvm *kvm__init(const char *kvm_dev, unsigned long ram_size)
+struct kvm *kvm__init(const char *kvm_dev, unsigned long ram_size, bool
use_backing)
{
struct kvm_pit_config pit_config = { .flags = 0, };
struct kvm *self;
int ret;
+ int backfd;
if (!kvm__cpu_supports_vm())
die(Your CPU does not support hardware virtualization);
@@ -214,7 +215,23 @@ struct kvm *kvm__init(const char *kvm_dev, unsigned long
ram_size)
self-ram_size = ram_size;
- self-ram_start = mmap(NULL, ram_size, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1, 0);
+ if (use_backing) {
+ char tmp_template[] = /tmp/kvm_ram.XX;
+
+ backfd = mkstemp(tmp_template);
+ if (backfd 0)
+ die(Failed creating RAM backing file);
+
+ unlink(tmp_template);
+
+ if (ftruncate(backfd, ram_size) 0)
+ die(Failed resizing RAM backing file);
+
+ self-ram_start = mmap(NULL, ram_size, PROT_READ | PROT_WRITE,
MAP_SHARED, backfd, 0);
+ } else {
+ self-ram_start = mmap(NULL, ram_size, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1, 0);
+ }
+
if (self-ram_start == MAP_FAILED)
die(out of memory);
--
1.7.5.rc1
--
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 27052] Module KVM : unable to handle kernel NULL pointer dereference at
https://bugzilla.kernel.org/show_bug.cgi?id=27052 --- Comment #41 from prochazka prochazka.nico...@gmail.com 2011-04-21 12:39:11 --- Hi, I never test #38 from avi kivity suggest, and now i suppres all bridge ( brctl) and netfilter configuration from my server, i'm using openvswitch without this problem. Regards, Nicolas Prochazka. -- 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: [PATCH] kvm tools: Use mmap to allocate guest RAM
On Thu, Apr 21, 2011 at 3:34 PM, Sasha Levin levinsasha...@gmail.com wrote: Using mmap to allocate the RAM enables us to allocate large blocks of memory for the guest, allowing to boot guests with a large RAM. Since if we try KVM_SET_USER_MEMORY_REGION with a large memory block KVM used to Oops (now it just fails), we had to move the actual ioctl to after we KVM_CREATE_VCPU. Signed-off-by: Sasha Levin levinsasha...@gmail.com The changelog seems to be identical with commit 9c2530b7d9b4da8052dfb15f5618b7aa59da6de2 (kvm tools: Use mmap to allocate guest RAM) but the diff is different. Hmm? -- 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] kvm tools: Add option to specify backing storage for RAM
Add --use-backing to allow for the usage of a temporary backing file for guest
RAM.
A temporary file is created and aollocated under /tmp and is used to back the
RAM memory which is mmaped for the guest.
There should be enough storage space under /tmp to use this option (at least
the size of the guest RAM).
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/kvm.h |2 +-
tools/kvm/kvm-run.c |5 -
tools/kvm/kvm.c | 21 +++--
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/tools/kvm/include/kvm/kvm.h b/tools/kvm/include/kvm/kvm.h
index fc76f98..3a44c53 100644
--- a/tools/kvm/include/kvm/kvm.h
+++ b/tools/kvm/include/kvm/kvm.h
@@ -25,7 +25,7 @@ struct kvm {
struct interrupt_table interrupt_table;
};
-struct kvm *kvm__init(const char *kvm_dev, unsigned long ram_size);
+struct kvm *kvm__init(const char *kvm_dev, unsigned long ram_size, bool
use_backing);
void kvm__init_ram(struct kvm *self);
void kvm__delete(struct kvm *self);
bool kvm__load_kernel(struct kvm *kvm, const char *kernel_filename,
diff --git a/tools/kvm/kvm-run.c b/tools/kvm/kvm-run.c
index fb8dcae7..a925a98 100644
--- a/tools/kvm/kvm-run.c
+++ b/tools/kvm/kvm-run.c
@@ -69,6 +69,7 @@ static const char *host_ip_addr;
static const char *guest_mac;
static const char *script;
static bool single_step;
+static bool use_backing;
static bool readonly_image;
extern bool ioport_debug;
extern int active_console;
@@ -84,6 +85,8 @@ static const struct option options[] = {
OPT_GROUP(Basic options:),
OPT_INTEGER('\0', cpus, nrcpus, Number of CPUs),
OPT_U64('m', mem, ram_size, Virtual machine memory size in MiB.),
+ OPT_BOOLEAN('\0', use-backing, use_backing,
+ Use a backing file for virtual RAM),
OPT_STRING('i', image, image_filename, image, Disk image),
OPT_BOOLEAN('\0', readonly, readonly_image,
Don't write changes back to disk image),
@@ -366,7 +369,7 @@ int kvm_cmd_run(int argc, const char **argv, const char
*prefix)
term_init();
- kvm = kvm__init(kvm_dev, ram_size);
+ kvm = kvm__init(kvm_dev, ram_size, use_backing);
memset(real_cmdline, 0, sizeof(real_cmdline));
strcpy(real_cmdline, notsc nolapic noacpi pci=conf1 console=ttyS0 );
diff --git a/tools/kvm/kvm.c b/tools/kvm/kvm.c
index eb1a46c..5e312e9 100644
--- a/tools/kvm/kvm.c
+++ b/tools/kvm/kvm.c
@@ -170,11 +170,12 @@ void kvm__init_ram(struct kvm *self)
die_perror(KVM_SET_USER_MEMORY_REGION ioctl);
}
-struct kvm *kvm__init(const char *kvm_dev, unsigned long ram_size)
+struct kvm *kvm__init(const char *kvm_dev, unsigned long ram_size, bool
use_backing)
{
struct kvm_pit_config pit_config = { .flags = 0, };
struct kvm *self;
int ret;
+ int backfd;
if (!kvm__cpu_supports_vm())
die(Your CPU does not support hardware virtualization);
@@ -214,7 +215,23 @@ struct kvm *kvm__init(const char *kvm_dev, unsigned long
ram_size)
self-ram_size = ram_size;
- self-ram_start = mmap(NULL, ram_size, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1, 0);
+ if (use_backing) {
+ char tmp_template[] = /tmp/kvm_ram.XX;
+
+ backfd = mkstemp(tmp_template);
+ if (backfd 0)
+ die(Failed creating RAM backing file);
+
+ unlink(tmp_template);
+
+ if (ftruncate(backfd, ram_size) 0)
+ die(Failed resizing RAM backing file);
+
+ self-ram_start = mmap(NULL, ram_size, PROT_READ | PROT_WRITE,
MAP_SHARED, backfd, 0);
+ } else {
+ self-ram_start = mmap(NULL, ram_size, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_NORESERVE, -1, 0);
+ }
+
if (self-ram_start == MAP_FAILED)
die(out of memory);
--
1.7.5.rc1
--
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] kvm tools: Add option to specify backing storage for RAM
On Thu, Apr 21, 2011 at 3:45 PM, Sasha Levin levinsasha...@gmail.com wrote: Add --use-backing to allow for the usage of a temporary backing file for guest RAM. A temporary file is created and aollocated under /tmp and is used to back the RAM memory which is mmaped for the guest. There should be enough storage space under /tmp to use this option (at least the size of the guest RAM). Signed-off-by: Sasha Levin levinsasha...@gmail.com OK, but what is this useful for? Why would someone want to do this? -- 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] kvm tools: Add option to specify backing storage for RAM
On Thu, 2011-04-21 at 15:48 +0300, Pekka Enberg wrote: On Thu, Apr 21, 2011 at 3:45 PM, Sasha Levin levinsasha...@gmail.com wrote: Add --use-backing to allow for the usage of a temporary backing file for guest RAM. A temporary file is created and aollocated under /tmp and is used to back the RAM memory which is mmaped for the guest. There should be enough storage space under /tmp to use this option (at least the size of the guest RAM). Signed-off-by: Sasha Levin levinsasha...@gmail.com OK, but what is this useful for? Why would someone want to do this? It's an alternative to creating more swap. When using large RAM sizes for guests on hosts with limited physical RAM/swap this option gives the user a way to use files instead of swap. This can also be extended to use hugetlbfs. -- Sasha. -- 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: performance of virtual functions compared to virtio
On 04/21/2011 03:31 PM, Stefan Hajnoczi wrote: On Thu, Apr 21, 2011 at 9:07 AM, Avi Kivitya...@redhat.com wrote: Note I think in both cases we can make significant improvements: - for VFs, steer device interrupts to the cpus which run the vcpus that will receive the interrupts eventually (ISTR some work about this, but not sure) - for virtio, use a DMA engine to copy data (I think there exists code in upstream which does this, but has this been enabled/tuned?) Which data copy in virtio? Is this a vhost-net specific thing you're thinking about? There are several copies. qemu's virtio-net implementation incurs a copy on tx and on rx when calling the kernel; in addition there is also an internal copy: /* copy in packet. ugh */ len = iov_from_buf(sg, elem.in_num, buf + offset, size - offset); In principle vhost-net can avoid the tx copy, but I think now we have 1 copy on rx and tx each. If a host interface is dedicated to backing a vhost-net interface (say if you have an SR/IOV card) then you can in principle avoid the rx copy as well. An alternative to avoiding the copies is to use a dma engine, like I mentioned. -- 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] kvm tools: Add option to specify backing storage for RAM
On Thu, Apr 21, 2011 at 4:00 PM, Sasha Levin levinsasha...@gmail.com wrote: It's an alternative to creating more swap. When using large RAM sizes for guests on hosts with limited physical RAM/swap this option gives the user a way to use files instead of swap. Well, I don't still quite see the point of this feature. Is there some real world use for running guests with huge memory space that's swap-backed? On Thu, Apr 21, 2011 at 4:00 PM, Sasha Levin levinsasha...@gmail.com wrote: This can also be extended to use hugetlbfs. Recent Linux kernels support transparent hugepages so you can do MADV_HUGEPAGE on mmap'd memory. -- 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
How is irq delivered in kvm?
Hi, I have a specialized e1000 device driver that expects to receive a single frame per interrupt, no more. It's by design and very hard to change (and it does not serve IP traffic). -net socket or tap can sometimes deliver more than one frame in a row and blow up the driver in turn. I'd like to experiment with tap/socket to only call qemu_send_packet..() once and leave pending frames in queue until next time, with hope that guest will have time to process the frame. The problem is I'm new to kvm and not sure how the main loop is run. Will there be guest execution time between two tap/socket polls, how long is it? Or is guest run in parallel with the event loop and qemu_set_irq() somehow signals guest immediately? -- Duy -- 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 v2] intel-iommu: Fix use after release during device attach
* Jan Kiszka (jan.kis...@siemens.com) wrote:
On 2011-01-04 11:42, Jan Kiszka wrote:
Am 10.12.2010 19:44, Chris Wright wrote:
* Jan Kiszka (jan.kis...@siemens.com) wrote:
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -3627,9 +3627,9 @@ static int intel_iommu_attach_device(struct
iommu_domain *domain,
pte = dmar_domain-pgd;
if (dma_pte_present(pte)) {
- free_pgtable_page(dmar_domain-pgd);
dmar_domain-pgd = (struct dma_pte *)
phys_to_virt(dma_pte_addr(pte));
While here, might as well remove the unnecessary cast.
+ free_pgtable_page(pte);
}
dmar_domain-agaw--;
}
Reviewed-by: Sheng Yang sh...@linux.intel.com
Acked-by: Chris Wright chr...@sous-sol.org
CC iommu mailing list and David.
Ping...
I think this fix also qualifies for stable (.35 and .36).
Still not merged?
David, do you plan to pick this one up?
thanks,
-chris
Hmm, still no reaction. Trying David's Intel address now...
Jan
Walking through my old queues, I came across this one again.
Given the still lacking reaction from the official maintainer, I'm a
bit confused about the state of intel-iommu. Is it unmaintained? Should
this bug fix better be routed through the KVM tree as its only in-tree
user? Please enlighten me.
Note that the patch became stable material for 35..38 in the meantime,
and it should go into 39 before release as well.
Thanks,
Jan
---8
Obtain the new pgd pointer before releasing the page containing this
value. Remove unneeded cast at this chance as well.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Acked-by: Chris Wright chr...@sous-sol.org
---
drivers/pci/intel-iommu.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
v1-v2: Clean up cast as suggested by Chris.
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index 505c1c7..b3e5c43 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -3607,9 +3607,8 @@ static int intel_iommu_attach_device(struct
iommu_domain *domain,
pte = dmar_domain-pgd;
if (dma_pte_present(pte)) {
- free_pgtable_page(dmar_domain-pgd);
- dmar_domain-pgd = (struct dma_pte *)
- phys_to_virt(dma_pte_addr(pte));
+ dmar_domain-pgd = phys_to_virt(dma_pte_addr(pte));
+ free_pgtable_page(pte);
}
dmar_domain-agaw--;
}
--
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] kvm tools: Add option to specify backing storage for RAM
On Thu, 2011-04-21 at 16:12 +0300, Pekka Enberg wrote: Well, I don't still quite see the point of this feature. Is there some real world use for running guests with huge memory space that's swap-backed? Not a single guest, but multiple guests which take more RAM than the host can provide using paging. This happened to me when I tried booting several servers to test network bridging. Can't say it's a common use-case though. -- Sasha. -- 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: How is irq delivered in kvm?
On 04/21/2011 04:49 PM, Nguyen Thai Ngoc Duy wrote: Hi, I have a specialized e1000 device driver that expects to receive a single frame per interrupt, no more. It's by design and very hard to change (and it does not serve IP traffic). -net socket or tap can sometimes deliver more than one frame in a row and blow up the driver in turn. I'd like to experiment with tap/socket to only call qemu_send_packet..() once and leave pending frames in queue until next time, with hope that guest will have time to process the frame. I don't understand how the driver can expect that. The card is free to deliver multiple packets per interrupt. Are you counting on fast timing to process the packet before the next packet arrives? If you restrict the number of buffers you provide to the card to exactly one, you'll get one packet per interrupts (and dropped packets). The problem is I'm new to kvm and not sure how the main loop is run. Will there be guest execution time between two tap/socket polls, how long is it? Or is guest run in parallel with the event loop and qemu_set_irq() somehow signals guest immediately? The latter, it's in parallel. Are you using qemu-kvm or qemu? qemu-kvm will deliver better interrupt performance. -- 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] kvm tools: Add option to specify backing storage for RAM
On 04/21/2011 04:12 PM, Pekka Enberg wrote: On Thu, Apr 21, 2011 at 4:00 PM, Sasha Levinlevinsasha...@gmail.com wrote: This can also be extended to use hugetlbfs. Recent Linux kernels support transparent hugepages so you can do MADV_HUGEPAGE on mmap'd memory. Note, it has to be aligned correctly (to a 2M boundary), and it must be anonymous memory. -- 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: How is irq delivered in kvm?
On Thu, Apr 21, 2011 at 9:11 PM, Avi Kivity a...@redhat.com wrote: On 04/21/2011 04:49 PM, Nguyen Thai Ngoc Duy wrote: Hi, I have a specialized e1000 device driver that expects to receive a single frame per interrupt, no more. It's by design and very hard to change (and it does not serve IP traffic). -net socket or tap can sometimes deliver more than one frame in a row and blow up the driver in turn. I'd like to experiment with tap/socket to only call qemu_send_packet..() once and leave pending frames in queue until next time, with hope that guest will have time to process the frame. I don't understand how the driver can expect that. The card is free to deliver multiple packets per interrupt. Are you counting on fast timing to process the packet before the next packet arrives? Yes. It uses ethernet as transport to clone memory from one machine to another in a short, precalculated amount of time. If you restrict the number of buffers you provide to the card to exactly one, you'll get one packet per interrupts (and dropped packets). The problem is I'm new to kvm and not sure how the main loop is run. Will there be guest execution time between two tap/socket polls, how long is it? Or is guest run in parallel with the event loop and qemu_set_irq() somehow signals guest immediately? The latter, it's in parallel. Are you using qemu-kvm or qemu? qemu-kvm will deliver better interrupt performance. I'm using qemu-kvm. What function is used to deliver the interrupt then, kvm_inject_irq? -- Duy -- 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 V3 0/8] macvtap/vhost TX zero copy support
On Wed, Apr 20, 2011 at 3:36 PM, Shirley Ma mashi...@us.ibm.com wrote: This patchset add supports for TX zero-copy between guest and host kernel through vhost. It significantly reduces CPU utilization on the local host on which the guest is located (It reduced 30-50% CPU usage for vhost thread for single stream test). The patchset is based on previous submission and comments from the community regarding when/how to handle guest kernel buffers to be released. This is the simplest approach I can think of after comparing with several other solutions. This patchset includes: 1/8: Add a new sock zero-copy flag, SOCK_ZEROCOPY; 2/8: Add a new device flag, NETIF_F_ZEROCOPY for lower level device support zero-copy; 3/8: Add a new struct skb_ubuf_info in skb_share_info for userspace buffers release callback when lower device DMA has done for that skb; 4/8: Add vhost zero-copy callback in vhost when skb last refcnt is gone; add vhost_zerocopy_add_used_and_signal to notify guest to release TX skb buffers. 5/8: Add macvtap zero-copy in lower device when sending packet is greater than 128 bytes. 6/8: Add Chelsio 10Gb NIC to zero copy feature flag 7/8: Add Intel 10Gb NIC zero copy feature flag 8/8: Add Emulex 10Gb NIC zero copy feature flag Why are only these 3 drivers getting support? As far as I can tell, the only requirement is HIGHDMA. If this is the case, is there really a need for an additional flag to support this? If you can key off of HIGHDMA, all devices that support this would get the benefit. The patchset is built against most recent linux 2.6.git. It has passed netperf/netserver multiple streams stress test on above NICs. The single stream test results from 2.6.37 kernel on Chelsio: 64K message size: copy_from_user dropped from 40% to 5%; vhost thread cpu utilization dropped from 76% to 28% I am collecting more test results against 2.6.39-rc3 kernel and will provide the test matrix later. Thanks Shirley -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 v2] intel-iommu: Fix use after release during device attach
On Thu, 2011-04-21 at 14:32 +0200, Jan Kiszka wrote:
On 2011-01-04 11:42, Jan Kiszka wrote:
Am 10.12.2010 19:44, Chris Wright wrote:
* Jan Kiszka (jan.kis...@siemens.com) wrote:
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -3627,9 +3627,9 @@ static int intel_iommu_attach_device(struct
iommu_domain *domain,
pte = dmar_domain-pgd;
if (dma_pte_present(pte)) {
- free_pgtable_page(dmar_domain-pgd);
dmar_domain-pgd = (struct dma_pte *)
phys_to_virt(dma_pte_addr(pte));
While here, might as well remove the unnecessary cast.
+ free_pgtable_page(pte);
}
dmar_domain-agaw--;
}
Reviewed-by: Sheng Yang sh...@linux.intel.com
Acked-by: Chris Wright chr...@sous-sol.org
CC iommu mailing list and David.
Ping...
I think this fix also qualifies for stable (.35 and .36).
Still not merged?
David, do you plan to pick this one up?
thanks,
-chris
Hmm, still no reaction. Trying David's Intel address now...
Jan
Walking through my old queues, I came across this one again.
Given the still lacking reaction from the official maintainer, I'm a
bit confused about the state of intel-iommu. Is it unmaintained? Should
this bug fix better be routed through the KVM tree as its only in-tree
user? Please enlighten me.
I've been wondering the exact same thing. My last patch took weeks of
prodding, finally went into the maintainer's tree without
acknowledgment, and there's hardly been any activity there to suggest a
pull request for 2.6.39 is going to happen. David, are you still
interested in maintaining this code? Thanks,
Alex
--
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: Does macvtap support host to guest communication?
On Tuesday 19 April 2011, Ashish Saxena wrote: @Arnd, I would like to initiate the dig into into macvtap driver. Could you please provide me some pointers/docs to start with. I dont' have any general recommendations. I'd suggest you start reading the macvlan.c and macvtap.c source code and come back when you have specific questions. Arnd -- 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: How is irq delivered in kvm?
On 04/21/2011 05:23 PM, Nguyen Thai Ngoc Duy wrote: On Thu, Apr 21, 2011 at 9:11 PM, Avi Kivitya...@redhat.com wrote: On 04/21/2011 04:49 PM, Nguyen Thai Ngoc Duy wrote: Hi, I have a specialized e1000 device driver that expects to receive a single frame per interrupt, no more. It's by design and very hard to change (and it does not serve IP traffic). -net socket or tap can sometimes deliver more than one frame in a row and blow up the driver in turn. I'd like to experiment with tap/socket to only call qemu_send_packet..() once and leave pending frames in queue until next time, with hope that guest will have time to process the frame. I don't understand how the driver can expect that. The card is free to deliver multiple packets per interrupt. Are you counting on fast timing to process the packet before the next packet arrives? Yes. It uses ethernet as transport to clone memory from one machine to another in a short, precalculated amount of time. Well, anything time related will misbehave under virtualization. If you restrict the number of buffers you provide to the card to exactly one, you'll get one packet per interrupts (and dropped packets). The problem is I'm new to kvm and not sure how the main loop is run. Will there be guest execution time between two tap/socket polls, how long is it? Or is guest run in parallel with the event loop and qemu_set_irq() somehow signals guest immediately? The latter, it's in parallel. Are you using qemu-kvm or qemu? qemu-kvm will deliver better interrupt performance. I'm using qemu-kvm. What function is used to deliver the interrupt then, kvm_inject_irq? No, kvm_set_irq_level(). -- 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 0/1 v2] KVM: MMU: Optimize guest page table walk
Changelog v1-v2: dropped slot_hint and wrapper. As Avi said, get_user() alone achieved most of the improvement. Before 2.994 us | paging64_walk_addr_generic(); 1.480 us | paging64_walk_addr_generic(); 0.996 us | paging64_walk_addr_generic(); 1.108 us | paging64_walk_addr_generic(); 0.962 us | paging64_walk_addr_generic(); 2.063 us | paging64_walk_addr_generic(); 1.379 us | paging64_walk_addr_generic(); 0.962 us | paging64_walk_addr_generic(); 1.085 us | paging64_walk_addr_generic(); 2.965 us | paging64_walk_addr_generic(); After 2.264 us | paging64_walk_addr_generic(); 1.079 us | paging64_walk_addr_generic(); 0.648 us | paging64_walk_addr_generic(); 0.703 us | paging64_walk_addr_generic(); 0.635 us | paging64_walk_addr_generic(); 0.869 us | paging64_walk_addr_generic(); 0.529 us | paging64_walk_addr_generic(); 0.702 us | paging64_walk_addr_generic(); 0.529 us | paging64_walk_addr_generic(); 0.691 us | paging64_walk_addr_generic(); A little surprise was that the original version itself was a bit fater than before. But I tested this with today's latest kvm.git and some parts had been changed, so it could be. Anyway, this patch improves by some degree! Takuya -- 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 1/1 v2] KVM: MMU: Optimize guest page table walk
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
This patch optimizes the guest page table walk by using get_user()
instead of copy_from_user().
With this patch applied, paging64_walk_addr_generic() has become
about 0.5us to 1.0us faster on my Phenom II machine with NPT on.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
arch/x86/kvm/paging_tmpl.h | 23 ---
1 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 74f8567..825d953 100644
--- a/arch/x86/kvm/paging_tmpl.h
+++ b/arch/x86/kvm/paging_tmpl.h
@@ -117,6 +117,7 @@ static int FNAME(walk_addr_generic)(struct guest_walker
*walker,
gva_t addr, u32 access)
{
pt_element_t pte;
+ pt_element_t __user *ptep_user;
gfn_t table_gfn;
unsigned index, pt_access, uninitialized_var(pte_access);
gpa_t pte_gpa;
@@ -152,6 +153,9 @@ walk:
pt_access = ACC_ALL;
for (;;) {
+ gfn_t real_gfn;
+ unsigned long host_addr;
+
index = PT_INDEX(addr, walker-level);
table_gfn = gpte_to_gfn(pte);
@@ -160,9 +164,22 @@ walk:
walker-table_gfn[walker-level - 1] = table_gfn;
walker-pte_gpa[walker-level - 1] = pte_gpa;
- if (kvm_read_guest_page_mmu(vcpu, mmu, table_gfn, pte,
- offset, sizeof(pte),
- PFERR_USER_MASK|PFERR_WRITE_MASK)) {
+ real_gfn = mmu-translate_gpa(vcpu, gfn_to_gpa(table_gfn),
+ PFERR_USER_MASK|PFERR_WRITE_MASK);
+ if (real_gfn == UNMAPPED_GVA) {
+ present = false;
+ break;
+ }
+ real_gfn = gpa_to_gfn(real_gfn);
+
+ host_addr = gfn_to_hva(vcpu-kvm, real_gfn);
+ if (kvm_is_error_hva(host_addr)) {
+ present = false;
+ break;
+ }
+
+ ptep_user = (pt_element_t __user *)((void *)host_addr + offset);
+ if (get_user(pte, ptep_user)) {
present = false;
break;
}
--
1.7.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 v2] intel-iommu: Fix use after release during device attach
On Thu, 2011-04-21 at 15:28 +0100, Alex Williamson wrote: I've been wondering the exact same thing. My last patch took weeks of prodding, finally went into the maintainer's tree without acknowledgment, and there's hardly been any activity there to suggest a pull request for 2.6.39 is going to happen. David, are you still interested in maintaining this code? Thanks, Yes, sorry, I've been somewhat snowed under with various things. This patch has been in my tree for a while, and I've just merged one more patch which is outstanding and sent Linus a pull request. -- dwmw2 -- 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: Failure to compile latest git (target-i386/kvm.c:953:29: error: variable ‘fop’ set but not used)
On 2011-04-21 16:10, Yaniv Kaul wrote: Fedora 15beta/x64, latest git: [ykaul@ykaul qemu]$ make CCx86_64-softmmu/kvm.o /home/ykaul/qemu/target-i386/kvm.c: In function ‘kvm_get_xsave’: /home/ykaul/qemu/target-i386/kvm.c:953:29: error: variable ‘fop’ set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors make[1]: *** [kvm.o] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 This one looks a bit suspicious: Avi, why do we have kvm_fpu::last_* in the ABI, copying that information from/to user land, but do not handle it otherwise? To my understanding this fop here in xsave corresponds to kvm_fpu::last_opcode in the SET/GET_FPU case, right? It's set to 0 on SET_XSAVE and ignored on GET_XSAVE as this warnings tells us. 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
[PATCH -next] kvm: fix const value warning on i386
From: Randy Dunlap randy.dun...@oracle.com arch/x86/kvm/emulate.c:2598: warning: integer constant is too large for 'long' type Signed-off-by: Randy Dunlap randy.dun...@oracle.com --- arch/x86/kvm/emulate.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20110421.orig/arch/x86/kvm/emulate.c +++ linux-next-20110421/arch/x86/kvm/emulate.c @@ -2595,7 +2595,7 @@ static int check_svme_pa(struct x86_emul u64 rax = kvm_register_read(ctxt-vcpu, VCPU_REGS_RAX); /* Valid physical address? */ - if (rax 0x) + if (rax 0xULL) return emulate_gp(ctxt, 0); return check_svme(ctxt); -- 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 v2] intel-iommu: Fix use after release during device attach
On Thu, 2011-04-21 at 16:42 +0100, David Woodhouse wrote: On Thu, 2011-04-21 at 15:28 +0100, Alex Williamson wrote: I've been wondering the exact same thing. My last patch took weeks of prodding, finally went into the maintainer's tree without acknowledgment, and there's hardly been any activity there to suggest a pull request for 2.6.39 is going to happen. David, are you still interested in maintaining this code? Thanks, Yes, sorry, I've been somewhat snowed under with various things. This patch has been in my tree for a while, and I've just merged one more patch which is outstanding and sent Linus a pull request. Thanks David, I know you've been busy lately. Alex -- 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
device-assignment: difference between assigned_dev_iomem_map and ...map_slow
Hi, latest qemu-kvm bails out on cleanup as it tries to call cpu_register_physical_memory with a zero-sized region of an assigned device. That made me dig into the setup/cleanup of memory mapped io regions, trying to consolidate and fix the code. What are the differences between normal and slow mmio regions? The former are mapped directly to the physical device (via qemu_ram_alloc_from_ptr + cpu_register_physical_memory), the latter have to be dispatched in user land (thus cpu_register_io_memory + cpu_register_physical_memory), right? But why do we need to postpone cpu_register_io_memory to assigned_dev_iomem_map_slow? It looks like that's effectively the only difference between both mapping callbacks (subtracting some bugs and dead code). Can't we set up the io region in assigned_dev_register_regions analogously to normal regions? BTW, the current code is leaking the slow io region on cleanup. Comments appreciated, will translate them into a cleanup patch series. Thanks, Jan (who wanted to do something completely different...) -- 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
KVM Forum 2011: Call For Participation
= KVM Forum 2011: Call For Participation August 15-16, 2011 - Hyatt Regency Vancouver - Vancouver, Canada = KVM is an industry leading open source hypervisor that provides an ideal platform for datacenter virtualization, virtual desktop infrastructure, and cloud computing. Once again, it's time to bring together the community of developers and users that define the KVM ecosystem for our annual technical conference. We will discuss the current state of affairs and plan for the future of KVM, its surrounding infrastructure, and management tools. So mark your calendar and join us in advancing KVM. http://events.linuxfoundation.org/events/kvm-forum/ We are colocated with The Linux Foundation's LinuxCon again this year. KVM Forum attendees will be eligible to attend LinuxCon for a discounted rate. http://events.linuxfoundation.org/events/kvm-forum/register We invite you to lead part of the discussion by submitting a speaking proposal for KVM Forum 2011. http://events.linuxfoundation.org/cfp Suggested topics: KVM - Scaling and performance - Nested virtualization - I/O improvements - PCI device assignment - Driver domains - Time keeping - Resource management (cpu, memory, i/o) - Memory management (page sharing, swapping, huge pages, etc) - Fault tolerance - VEPA, VN-Link, vswitch - Security QEMU - Device model improvements - New devices - Scaling and performance - Desktop virtualization - Spice - Increasing robustness and hardening - Security model - Management interfaces - QMP protocol and implementation - Image formats - Live migration - Live snapshots and merging Virtio - Speeding up existing devices - Alternatives - Virtio on non-Linux Management infrastructure - Libvirt - KVM autotest - OpenStack - Network virtualization management - Enterprise storage management Cloud computing - Scalable storage - Virtual networking - Security - Provisioning - Hybrid SUBMISSION REQUIREMENTS Abstracts due: May 16th, 2011 Notification: May 31th, 2011 Please submit a short abstract (~150 words) describing your presentation proposal. In your submission please note how long your talk will take. Slots vary in length up to 45 minutes. Also include in your proposal the proposal type -- one of: - technical talk - end-user talk - BOF (birds of a feather) session Sumbit your proposal here: http://events.linuxfoundation.org/cfp You will receive a notification whether or not your presentation proposal was accepted by May 31st. END-USER COLLABORATION One of the big challenges as developers is to know what, where and how people actually use our software. We will reserve a few slots for end users talking about their deployment challenges and achievements. If you are using KVM in production you are encouraged submit a speaking proposal. Simply mark it as an end-user collaboration proposal. As and end user, this is a unique opportunity to get your input to developers. BOF SESSION We will reserve some slots in the evening after the main conference tracks, for birds of a feather sessions. These sessions will be less formal than presentation tracks and targetted for people who would like to discuss specific issues with other developers and/or users. If you are interested in getting developers and/or uses together to discuss a specific problem, please submit a BOF proposal. LIGHTNING TALKS In addition to submitted talks we will also have some room for lightning talks. These are short (5 minute) discussions to highlight new work or ideas that aren't complete enough to warrant a full presentation slot. Lightning talk submissions and scheduling will be handled on-site at KVM Forum. HOTEL / TRAVEL The KVM Forum 2011 will be held in Vancouver BC at the Hyatt Regency Vancouver. http://events.linuxfoundation.org/events/kvm-forum/travel Thank you for your interest in KVM. We're looking forward to your submissions and seeing you at the KVM Forum 2011 in August! Thanks, your KVM Forum 2011 Program Commitee Please contact us with any questions or comments. kvm-forum-2011...@redhat.com -- 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: device-assignment: difference between assigned_dev_iomem_map and ...map_slow
On Thu, 2011-04-21 at 18:23 +0200, Jan Kiszka wrote: Hi, latest qemu-kvm bails out on cleanup as it tries to call cpu_register_physical_memory with a zero-sized region of an assigned device. That made me dig into the setup/cleanup of memory mapped io regions, trying to consolidate and fix the code. The teardown is gated by memory_index, so that means it's tearing down a region that wasn't mapped by the guest? What are the differences between normal and slow mmio regions? The former are mapped directly to the physical device (via qemu_ram_alloc_from_ptr + cpu_register_physical_memory), the latter have to be dispatched in user land (thus cpu_register_io_memory + cpu_register_physical_memory), right? Right. But why do we need to postpone cpu_register_io_memory to assigned_dev_iomem_map_slow? It looks like that's effectively the only difference between both mapping callbacks (subtracting some bugs and dead code). Can't we set up the io region in assigned_dev_register_regions analogously to normal regions? I imagine it was an attempt not to overload memory_index, for tests like the one above, but apparently it's not working out so well. I don't see any reason we shouldn't do the cpu_register_io_memory on setup. BTW, the current code is leaking the slow io region on cleanup. Yep, I don't see an cpu_unregister_io_memory() for that region either. Comments appreciated, will translate them into a cleanup patch series. Thanks! Alex -- 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
Failed to compile kvm mod
I am running 2.6.37-5.dmz.1-liquorix-amd64 with ubuntu 10.10, and when i am compiling the kvm mod for 2.6.37 kernel it throws the following errors : nano@server:~/Work/kvm-kmod-2.6.37$ make make -C /lib/modules/2.6.37-5.dmz.1-liquorix-amd64/build M=`pwd` \ LINUXINCLUDE=-I`pwd`/include -Iinclude \ -Iinclude2 -I/lib/modules/2.6.37-5.dmz.1-liquorix-amd64/source/include -I/lib/modules/2.6.37-5.dmz.1-liquorix-amd64/source/arch/x86/include \ -I`pwd`/include-compat -I`pwd`/x86 \ -include include/generated/autoconf.h \ -include `pwd`/x86/external-module-compat.h \ $@ make[1]: Entering directory `/usr/src/linux-headers-2.6.37-5.dmz.1-liquorix-amd64' CC [M] /home/foxmulder/Work/kvm-kmod-2.6.37/x86/svm.o In file included from /home/foxmulder/Work/kvm-kmod-2.6.37/x86/external-module-compat.h:9:0, from command-line:0: include/linux/types.h:4:23: fatal error: asm/types.h: No such file or directory compilation terminated. make[3]: *** [/home/nano/Work/kvm-kmod-2.6.37/x86/svm.o] Error 1 make[2]: *** [/home/nano/Work/kvm-kmod-2.6.37/x86] Error 2 make[1]: *** [_module_/home/nano/Work/kvm-kmod-2.6.37] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-2.6.37-5.dmz.1-liquorix-amd64' make: *** [all] Error 2 While the headers already installed, and double conform with checking the dir myself : nano@server:~/Work/kvm-kmod-2.6.37$ dpkg -l | grep liquorix ii linux-headers-2.6.37-5.dmz.1-liquorix-amd64 2.6.37-16 Header files for Linux 2.6.37-5.dmz.1-liquorix-amd64 ii linux-image-2.6.37-5.dmz.1-liquorix-amd64 2.6.37-16 Linux 2.6.37 for 64-bit PCs ii liquorix-archive-keyring2009.05.25 GnuPG archive keys of the liquorix archive ii liquorix-keyring2009.05.25 GnuPG keys of liquorix Developers ii liquorix-keyrings 2009.05.25 Meta package to grab all useful GnuPG keys for liquorix Reside the include folder there is exist asm-generic folder which seems to having the required headers, i have tried to copy the asm-generic to asm folder but now it stops at here : /home/nano/Work/kvm-kmod-2.6.37/include/asm/kvm_para.h:105:27: fatal error: asm/processor.h: No such file or directory compilation terminated. make[3]: *** [/home/nano/Work/kvm-kmod-2.6.37/x86/svm.o] Error 1 make[2]: *** [/home/nano/Work/kvm-kmod-2.6.37/x86] Error 2 make[1]: *** [_module_/home/nano/Work/kvm-kmod-2.6.37] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-2.6.37-5.dmz.1-liquorix-amd64' make: *** [all] Error 2 The processor.h seems to be reside here /usr/src/linux-headers-2.6.37-5.dmz.1-liquorix-amd64/arch/x86/include/asm -- 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] KVM: x86 emulator: avoid calling wbinvd() macro
Commit 0b56652e33c72092956c651ab6ceb9f0ad081153 fails to build: CC [M] arch/x86/kvm/emulate.o arch/x86/kvm/emulate.c: In function 'x86_emulate_insn': arch/x86/kvm/emulate.c:4095:25: error: macro wbinvd passed 1 arguments, but takes just 0 arch/x86/kvm/emulate.c:4095:3: warning: statement with no effect make[2]: *** [arch/x86/kvm/emulate.o] Error 1 make[1]: *** [arch/x86/kvm] Error 2 make: *** [arch/x86] Error 2 Work around this for now. Signed-off-by: Clemens Noss cn...@gmx.de --- arch/x86/kvm/emulate.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index f683ce1..97b1a29 100644 --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -4092,7 +4092,7 @@ twobyte_insn: rc = em_clts(ctxt); break; case 0x09: /* wbinvd */ - ctxt-ops-wbinvd(ctxt); + (ctxt-ops-wbinvd)(ctxt); break; case 0x08: /* invd */ case 0x0d: /* GrpP (prefetch) */ -- 1.7.4.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
nmi is broken?
Hi,
I noticed recently NMI on guest kernel is not working well. host/guest
kernel is 2.6.39-rc4, and using vmx.
And test code is something like the following:
local_irq_disable();
for (i = 0; i 10; i++) {
int cpu = get_cpu();
printk(%s: nmi %u, lapic %u\n, __FUNCTION__,
nmi_count(cpu), irq_stat[cpu].apic_timer_irqs);
mdelay(1000);
put_cpu();
}
the result is both of nmi and lapic are not increased. If I used
-no-kvm-irqchip, it works fine (increase nmi only). So, it seems to be
the bug of kvm driver side.
Ideas?
--
OGAWA Hirofumi hirof...@mail.parknet.co.jp
--
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: trace-cmd errors on kvm events
On Fri, Apr 08, 2011 at 11:07:23PM +0200, Jan Kiszka wrote: On 2011-04-08 20:53, David Ahern wrote: 2.6.38.2 kernel with trace-cmd git pulled this morning: trace-cmd record -e kvm trace-cmd report 21 | less trace-cmd: No such file or directory Does this error come from trace-cmd failing to find its kvm plugin? Check what strace -e open says. I need to spend some time and fix it. That No such file or directory is from the way trace-cmd does error handling. It checks if errno is set and if so, it prints out perror(). What usually happens is I do a stat() on a file which sets errno, and forget about it. Then if trace-cmd finds some internal error, it calls the warning() message, which then prints out the stale errno. -- Steve -- 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 make error: macro wbinvd passed 1 arguments, but takes just 0
Hi, I use kvm.git 51138ead... ( the latest commit in upstream ). I got the following error, could you have a look? Is the code’s issue or my configuration issue ? Thanks a lot. arch/x86/kvm/emulate.c:4095:25: error: macro wbinvd passed 1 arguments, but takes just 0 arch/x86/kvm/emulate.c: In function 'x86_emulate_insn': arch/x86/kvm/emulate.c:4095: warning: statement with no effect Best Regards, Yongjie Ren(Jay)
RE: kvm make error: macro wbinvd passed 1 arguments, but takes just 0
Sorry, I found cn...@gmx.de gave a patch in this maillist for this issue.
Best Regards,
Yongjie Ren(Jay)
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of
Ren, Yongjie
Sent: Friday, April 22, 2011 9:21 AM
To: kvm@vger.kernel.org
Cc: a...@redhat.com
Subject: kvm make error: macro wbinvd passed 1 arguments, but takes just 0
Hi,
I use kvm.git 51138ead... ( the latest commit in upstream ). I got the
following error, could you have a look? Is the code’s issue or my configuration
issue ? Thanks a lot.
arch/x86/kvm/emulate.c:4095:25: error: macro wbinvd passed 1 arguments, but
takes just 0
arch/x86/kvm/emulate.c: In function 'x86_emulate_insn':
arch/x86/kvm/emulate.c:4095: warning: statement with no effect
Best Regards,
Yongjie Ren(Jay)
N�r��yb�X��ǧv�^�){.n�+h����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
buildbot failure in qemu-kvm on disable_kvm_x86_64_out_of_tree
The Buildbot has detected a new failure of disable_kvm_x86_64_out_of_tree on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_out_of_tree/builds/757 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_1 Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
buildbot failure in qemu-kvm on disable_kvm_x86_64_debian_5_0
The Buildbot has detected a new failure of disable_kvm_x86_64_debian_5_0 on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_debian_5_0/builds/808 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_1 Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
buildbot failure in qemu-kvm on disable_kvm_i386_debian_5_0
The Buildbot has detected a new failure of disable_kvm_i386_debian_5_0 on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_debian_5_0/builds/809 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_2 Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
buildbot failure in qemu-kvm on disable_kvm_i386_out_of_tree
The Buildbot has detected a new failure of disable_kvm_i386_out_of_tree on qemu-kvm. Full details are available at: http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_out_of_tree/builds/757 Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/ Buildslave for this Build: b1_qemu_kvm_2 Build Reason: The Nightly scheduler named 'nightly_disable_kvm' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
buildbot failure in kvm on x86_64
The Buildbot has detected a new failure of x86_64 on kvm. Full details are available at: http://buildbot.b1-systems.de/kvm/builders/x86_64/builds/166 Buildbot URL: http://buildbot.b1-systems.de/kvm/ Buildslave for this Build: b1_kvm_1 Build Reason: The Nightly scheduler named 'nightly_master' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
buildbot failure in kvm on i386
The Buildbot has detected a new failure of i386 on kvm. Full details are available at: http://buildbot.b1-systems.de/kvm/builders/i386/builds/155 Buildbot URL: http://buildbot.b1-systems.de/kvm/ Buildslave for this Build: b1_kvm_1 Build Reason: The Nightly scheduler named 'nightly_master' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
buildbot failure in kvm on next-x86_64
The Buildbot has detected a new failure of next-x86_64 on kvm. Full details are available at: http://buildbot.b1-systems.de/kvm/builders/next-x86_64/builds/144 Buildbot URL: http://buildbot.b1-systems.de/kvm/ Buildslave for this Build: b1_kvm_1 Build Reason: The Nightly scheduler named 'nightly_next' triggered this build Build Source Stamp: [branch next] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
buildbot failure in kvm on next-i386
The Buildbot has detected a new failure of next-i386 on kvm. Full details are available at: http://buildbot.b1-systems.de/kvm/builders/next-i386/builds/144 Buildbot URL: http://buildbot.b1-systems.de/kvm/ Buildslave for this Build: b1_kvm_1 Build Reason: The Nightly scheduler named 'nightly_next' triggered this build Build Source Stamp: [branch next] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot -- 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
