Re: [PATCH trace-cmd] plugin_kvm: disassemble instructions for kvm_emulate_insn
On Sun, 2010-09-19 at 16:33 +0200, Avi Kivity wrote:
> Override kvm_emulate_insn formatting to use a disassembler to format
> the emulated instruction. If a disassembler (udis86) is not available,
> fall back to showing the instruction bytes in hex.
>
> Signed-off-by: Avi Kivity
> ---
>
> Note 1: on top of 'master' with 'trace-cmd-kvm' cherry-picked on top.
Thanks, I merged trace-cmd-kvm into master and applied your patch
(haven't pushed yet).
>
> Note 2: I get output of the form
>
> ... kvm_emulate_insn: 0:f800010527b5: mov $0x0, 0xfffe00b0CAN'T FIND
> FIELD "guest_rip"
>
> which leads me to believe there is a bug in trace_seq_printf when the input
> to %s is "".
I ran this under gdb (nice to do that, where I don't in kernel :-) And
it takes me to kvm_emulate_insn_handler() which does the
trace_seq_printf() fine, but then calls pevent_print_num_field() and
that passes in "guest_rip" where we get the "CAN'T FIND FIELD" error.
In pevent_print_num_field() it searches for "guest_rip" at the top of
the function (pevent_find_field()), but the event kvm_emulate_insn does
not have a "guest_rip" field, then it jumps to the error message.
-- Steve
>
> Makefile | 11 +-
> plugin_kvm.c | 111
> ++
> 2 files changed, 121 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 5282f94..fe34d1c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -74,6 +74,14 @@ ifeq ($(shell sh -c "python-config --includes > /dev/null
> 2>&1 && echo y"), y)
> PYTHON_PY_INSTALL := event-viewer.install tracecmd.install
> tracecmdgui.install
> endif
>
> +# $(call test-build, snippet, ret) -> ret if snippet compiles
> +# -> empty otherwise
> +test-build = $(if $(shell $(CC) -o /dev/null -c -x c - > /dev/null 2>&1 \
> + <<<'$1' && echo y), $2)
> +
> +# have udis86 disassembler library?
> +udis86-flags := $(call test-build,\#include ,-DHAVE_UDIS86
> -ludis86)
> +
> ifeq ("$(origin O)", "command line")
>BUILD_OUTPUT := $(O)
> endif
> @@ -188,6 +196,7 @@ CFLAGS ?= -g -Wall
>
> # Append required CFLAGS
> override CFLAGS += $(CONFIG_FLAGS) $(INCLUDES) $(PLUGIN_DIR_SQ)
> +override CFLAGS += $(udis86-flags)
>
> ifeq ($(VERBOSE),1)
>Q =
> @@ -228,7 +237,7 @@ do_compile_plugin_obj = \
>
> do_plugin_build =\
> ($(print_plugin_build) \
> - $(CC) -shared -nostartfiles -o $@ $<)
> + $(CC) $(CFLAGS) -shared -nostartfiles -o $@ $<)
>
> do_build_static_lib =\
> ($(print_static_lib_build) \
> diff --git a/plugin_kvm.c b/plugin_kvm.c
> index 7217e85..00cac5a 100644
> --- a/plugin_kvm.c
> +++ b/plugin_kvm.c
> @@ -21,9 +21,68 @@
> #include
> #include
> #include
> +#include
>
> #include "parse-events.h"
>
> +#ifdef HAVE_UDIS86
> +
> +#include
> +
> +static ud_t ud;
> +
> +static void init_disassembler(void)
> +{
> + ud_init(&ud);
> + ud_set_syntax(&ud, UD_SYN_ATT);
> +}
> +
> +static const char *disassemble(unsigned char *insn, int len, uint64_t rip,
> +int cr0_pe, int eflags_vm,
> +int cs_d, int cs_l)
> +{
> + int mode;
> +
> + if (!cr0_pe)
> + mode = 16;
> + else if (eflags_vm)
> + mode = 16;
> + else if (cs_l)
> + mode = 64;
> + else if (cs_d)
> + mode = 32;
> + else
> + mode = 16;
> +
> + ud_set_pc(&ud, rip);
> + ud_set_mode(&ud, mode);
> + ud_set_input_buffer(&ud, insn, len);
> + ud_disassemble(&ud);
> + return ud_insn_asm(&ud);
> +}
> +
> +#else
> +
> +static void init_disassembler(void)
> +{
> +}
> +
> +static const char *disassemble(unsigned char *insn, int len, uint64_t rip,
> +int cr0_pe, int eflags_vm,
> +int cs_d, int cs_l)
> +{
> + static char out[15*3+1];
> + int i;
> +
> + for (i = 0; i < len; ++i)
> + sprintf(out + i * 3, "%02x ", insn[i]);
> + out[len*3-1] = '\0';
> + return out;
> +}
> +
> +#endif
> +
> +
> #define VMX_EXIT_REASONS \
> _ER(EXCEPTION_NMI, 0) \
> _ER(EXTERNAL_INTERRUPT, 1) \
> @@ -99,6 +158,53 @@ static int kvm_exit_handler(struct trace_seq *s, struct
> record *record,
> return 0;
> }
>
> +#define KVM_EMUL_INSN_F_CR0_PE (1 << 0)
> +#define KVM_EMUL_INSN_F_EFL_VM (1 << 1)
> +#define KVM_EMUL_INSN_F_CS_D (1 << 2)
> +#define KVM_EMUL_INSN_F_CS_L (1 << 3)
> +
> +static int kvm_emulate_insn_handler(struct trace_seq *s, struct record
> *record,
> + struct event_format *event, void *context)
> +{
> + unsigned long long rip, csbase, len, flags, failed;
> + int llen;
> + uint8_t *insn;
> + const char *disasm;
> +
> + i
Accessing host TSC from a guest kernel
Hello, I'd like to access the host TSC from the inside of a guest kernel and I don't really know if it's possible. I'm working with kvm_clock and I have been playing with the pvclock_vcpu_time_info structure, but I'm not sure if I'm in the right direction. So could you tell me if there is an efficient way to access to access the host TSC (or at least the TSC_OFFSET) from a module inside a guest kernel ? I did it with an hypercall, but it's for tracing purpose and doing an hypercall every time I want to record an event, is way too costly. Thanks, Julien -- 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: [Autotest] [PATCH] KVM-test: Update pci_hotplug to suit for new qemu
On Thu, 2010-09-23 at 21:11 -0300, Lucas Meneghel Rodrigues wrote: > From: Yiqiao Pu > > In the new version of qemu device_add is instead of pci_add. So modify > the scripts to suit for the new version of qemu. Now both nic and block > devices are support in qemu, so keep using monitor command line for > this test. Yiqiao, I have rebased, cleaned up and tested your patch. Thanks! Lucas -- 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-test: Update pci_hotplug to suit for new qemu
From: Yiqiao Pu
In the new version of qemu device_add is instead of pci_add. So modify
the scripts to suit for the new version of qemu. Now both nic and block
devices are support in qemu, so keep using monitor command line for
this test.
Changs from v1:
Can support block device hotplug in scripts. But scsi is still not
supported.
Changs from v2:
- using "?" to check which command is supported in qemu and add the
debug information for unsupported commands.
- using "$add_cmd ?" to check the support devices in command line and
add the debug information for unsupported devices
Signed-off-by: Yiqiao Pu
---
client/tests/kvm/tests/pci_hotplug.py | 113 -
1 files changed, 84 insertions(+), 29 deletions(-)
diff --git a/client/tests/kvm/tests/pci_hotplug.py
b/client/tests/kvm/tests/pci_hotplug.py
index 2c459d7..55cf666 100644
--- a/client/tests/kvm/tests/pci_hotplug.py
+++ b/client/tests/kvm/tests/pci_hotplug.py
@@ -1,20 +1,22 @@
-import logging, os
+import logging, os, commands, re
from autotest_lib.client.common_lib import error
import kvm_subprocess, kvm_test_utils, kvm_utils, kvm_vm
def run_pci_hotplug(test, params, env):
"""
-Test pci devices' hotplug
+Test hotplug of PCI devices.
+
+(Elements between [] are configurable test parameters)
1) PCI add a deivce (NIC / block)
-2) Compare output of hypervisor command `info pci`
-3) Compare output of guest command `reference_cmd`
-4) Verify whether pci_model is shown in `pci_find_cmd`
-5) Check whether the newly added pci device works fine
-6) PCI delete the device, verify whether could remove the pci device
-
-@param test: kvm test object
-@param params: Dictionary with the test parameters
+2) Compare output of monitor command 'info pci'.
+3) Compare output of guest command [reference_cmd].
+4) Verify whether pci_model is shown in [pci_find_cmd].
+5) Check whether the newly added PCI device works fine.
+6) PCI delete the device, verify whether could remove the PCI device.
+
+@param test: KVM test object.
+@param params: Dictionary with the test parameters.
@param env:Dictionary with test environment.
"""
vm = kvm_test_utils.get_living_vm(env, params.get("main_vm"))
@@ -35,26 +37,79 @@ def run_pci_hotplug(test, params, env):
tested_model = params.get("pci_model")
test_type = params.get("pci_type")
-
-if test_type == "nic":
-pci_add_cmd = "pci_add pci_addr=auto nic model=%s" % tested_model
-elif test_type == "block":
-image_params = kvm_utils.get_sub_dict(params, "stg")
-image_filename = kvm_vm.get_image_filename(image_params, test.bindir)
-pci_add_cmd = ("pci_add pci_addr=auto storage file=%s,if=%s" %
- (image_filename, tested_model))
-
-# Execute pci_add (should be replaced by a proper monitor method call)
-add_output = vm.monitor.cmd(pci_add_cmd)
-if not "OK domain" in add_output:
-raise error.TestFail("Add device failed. Hypervisor command is: %s. "
- "Output: %r" % (pci_add_cmd, add_output))
-after_add = vm.monitor.info("pci")
+image_format = params.get("image_format_stg")
+
+# Probe qemu to verify what is the supported syntax for PCI hotplug
+cmd_output = vm.monitor.cmd("?")
+if len(re.findall("\ndevice_add", cmd_output)) > 0:
+cmd_type = "device_add"
+elif len(re.findall("\npci_add", cmd_output)) > 0:
+cmd_type = "pci_add"
+else:
+raise error.TestError("Unknow version of qemu")
+
+if cmd_type == "pci_add":
+if test_type == "nic":
+pci_add_cmd = "pci_add pci_addr=auto nic model=%s" % tested_model
+elif test_type == "block":
+image_params = kvm_utils.get_sub_dict(params, "stg")
+image_filename = kvm_vm.get_image_filename(image_params,
+ test.bindir)
+pci_add_cmd = ("pci_add pci_addr=auto storage file=%s,if=%s" %
+ (image_filename, tested_model))
+# Execute pci_add (should be replaced by a proper monitor method call)
+add_output = vm.monitor.cmd(pci_add_cmd)
+if not "OK domain" in add_output:
+raise error.TestFail("Add PCI device failed. "
+ "Monitor command is: %s, Output: %r" %
+ (pci_add_cmd, add_output))
+after_add = vm.monitor.info("pci")
+
+elif cmd_type == "device_add":
+driver_id = test_type + "-" + kvm_utils.generate_random_id()
+id = test_type + "-" + kvm_utils.generate_random_id()
+if test_type == "nic":
+if tested_model == "virtio":
+tested_model = "virtio-net-pci"
+pci_add_cmd = "device_add id=%s,driver=%s" % (id, tested_model)
+
+elif test_type == "block":
+image_params = kvm_utils.get_su
[GIT PULL] KVM updates for 2.6.36-rc5
Linus, please pull from git://git.kernel.org/pub/scm/virt/kvm/kvm.git kvm-updates/2.6.36 To receive the following updates: Avi Kivity (1): KVM: Fix reboot on Intel hosts Michael S. Tsirkin (1): KVM: fix irqfd assign/deassign race virt/kvm/eventfd.c |3 ++- virt/kvm/kvm_main.c |4 +++- 2 files changed, 5 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KVM timekeeping fixes 4/4] TSC catchup mode
On Wed, Sep 22, 2010 at 09:25:49AM -1000, Zachary Amsden wrote:
> On 09/21/2010 08:18 AM, Marcelo Tosatti wrote:
> >On Mon, Sep 20, 2010 at 03:11:30PM -1000, Zachary Amsden wrote:
> >>On 09/20/2010 05:38 AM, Marcelo Tosatti wrote:
> >>>On Sat, Sep 18, 2010 at 02:38:15PM -1000, Zachary Amsden wrote:
> Negate the effects of AN TYM spell while kvm thread is preempted by
> tracking
> conversion factor to the highest TSC rate and catching the TSC up when it
> has
> fallen behind the kernel view of time. Note that once triggered, we don't
> turn off catchup mode.
>
> A slightly more clever version of this is possible, which only does
> catchup
> when TSC rate drops, and which specifically targets only CPUs with broken
> TSC, but since these all are considered unstable_tsc(), this patch covers
> all necessary cases.
>
> Signed-off-by: Zachary Amsden
> ---
> arch/x86/include/asm/kvm_host.h |6 +++
> arch/x86/kvm/x86.c | 87
> +-
> 2 files changed, 72 insertions(+), 21 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h
> b/arch/x86/include/asm/kvm_host.h
> index 8c5779d..e209078 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -384,6 +384,9 @@ struct kvm_vcpu_arch {
> u64 last_host_tsc;
> u64 last_guest_tsc;
> u64 last_kernel_ns;
> + u64 last_tsc_nsec;
> + u64 last_tsc_write;
> + bool tsc_catchup;
>
> bool nmi_pending;
> bool nmi_injected;
> @@ -444,6 +447,9 @@ struct kvm_arch {
> u64 last_tsc_nsec;
> u64 last_tsc_offset;
> u64 last_tsc_write;
> + u32 virtual_tsc_khz;
> + u32 virtual_tsc_mult;
> + s8 virtual_tsc_shift;
>
> struct kvm_xen_hvm_config xen_hvm_config;
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 09f468a..9152156 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -962,6 +962,7 @@ static inline u64 get_kernel_ns(void)
> }
>
> static DEFINE_PER_CPU(unsigned long, cpu_tsc_khz);
> +unsigned long max_tsc_khz;
>
> static inline int kvm_tsc_changes_freq(void)
> {
> @@ -985,6 +986,24 @@ static inline u64 nsec_to_cycles(u64 nsec)
> return ret;
> }
>
> +static void kvm_arch_set_tsc_khz(struct kvm *kvm, u32 this_tsc_khz)
> +{
> + /* Compute a scale to convert nanoseconds in TSC cycles */
> + kvm_get_time_scale(this_tsc_khz, NSEC_PER_SEC / 1000,
> + &kvm->arch.virtual_tsc_shift,
> + &kvm->arch.virtual_tsc_mult);
> + kvm->arch.virtual_tsc_khz = this_tsc_khz;
> +}
> +
> +static u64 compute_guest_tsc(struct kvm_vcpu *vcpu, s64 kernel_ns)
> +{
> + u64 tsc = pvclock_scale_delta(kernel_ns-vcpu->arch.last_tsc_nsec,
> + vcpu->kvm->arch.virtual_tsc_mult,
> + vcpu->kvm->arch.virtual_tsc_shift);
> + tsc += vcpu->arch.last_tsc_write;
> + return tsc;
> +}
> +
> void kvm_write_tsc(struct kvm_vcpu *vcpu, u64 data)
> {
> struct kvm *kvm = vcpu->kvm;
> @@ -1029,6 +1048,8 @@ void kvm_write_tsc(struct kvm_vcpu *vcpu, u64 data)
>
> /* Reset of TSC must disable overshoot protection below */
> vcpu->arch.hv_clock.tsc_timestamp = 0;
> + vcpu->arch.last_tsc_write = data;
> + vcpu->arch.last_tsc_nsec = ns;
> }
> EXPORT_SYMBOL_GPL(kvm_write_tsc);
>
> @@ -1041,22 +1062,42 @@ static int kvm_guest_time_update(struct kvm_vcpu
> *v)
> s64 kernel_ns, max_kernel_ns;
> u64 tsc_timestamp;
>
> - if ((!vcpu->time_page))
> - return 0;
> -
> /* Keep irq disabled to prevent changes to the clock */
> local_irq_save(flags);
> kvm_get_msr(v, MSR_IA32_TSC,&tsc_timestamp);
> kernel_ns = get_kernel_ns();
> this_tsc_khz = __get_cpu_var(cpu_tsc_khz);
> - local_irq_restore(flags);
>
> if (unlikely(this_tsc_khz == 0)) {
> + local_irq_restore(flags);
> kvm_make_request(KVM_REQ_CLOCK_UPDATE, v);
> return 1;
> }
>
> /*
> + * We may have to catch up the TSC to match elapsed wall clock
> + * time for two reasons, even if kvmclock is used.
> + * 1) CPU could have been running below the maximum TSC rate
> >>>kvmclock handles frequency changes?
> >>>
> + * 2) Broken TSC compensation resets the base at each VCPU
> + * entry to avoid unknown leaps of TSC even when running
> + * again on the same CPU. This may cause apparent elapsed
> >
Re: Growing qcow2 files during block migration ?
On Thu, Sep 23, 2010 at 3:40 PM, Christoph Adomeit wrote: > Lets say my source machine has a qcow2 file with virtual size of 60 GB but > only 2 GB are in use. So the qcow2 file only has a size of 2 GB. > > After block migration the resulting qcow2 file on the target machine has a > size of 60 GB. > > Also the migration is quite slow because it seems to transfer 60 GB instead > of 2 GB. > > Are there any workarounds, ideas/plans to optimize this ? Yes. Although this isn't currently possible in mainline QEMU it is getting attention. There have been several recent threads on QED, image streaming, and block migration. Here is one which touches on zero sectors: http://www.spinics.net/linux/fedora/libvir/msg28144.html 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
Growing qcow2 files during block migration ?
Hi, I love live migrations using the qemu-kvm block migration Feature (migrate -b) but I have a problem with it. Lets say my source machine has a qcow2 file with virtual size of 60 GB but only 2 GB are in use. So the qcow2 file only has a size of 2 GB. After block migration the resulting qcow2 file on the target machine has a size of 60 GB. Also the migration is quite slow because it seems to transfer 60 GB instead of 2 GB. Are there any workarounds, ideas/plans to optimize this ? Thanks Christoph -- 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: [Autotest] [PATCH 18/18] KVM test: Add subtest of testing offload by ethtool
On Thu, 2010-09-23 at 19:11 +0530, pradeep wrote: > On Tue, 14 Sep 2010 19:25:43 -0300 > Lucas Meneghel Rodrigues wrote: > > > The latest case contains TX/RX/SG/TSO/GSO/GRO/LRO test. > > RTL8139 NIC doesn't support TSO, LRO, it's too old, so > > drop offload test from rtl8139. LRO, GRO are only > > supported by latest kernel, virtio nic doesn't support > > receive offloading function. > > > > Initialize the callbacks first and execute all the sub > > tests one by one, all the result will be check at the > > end. When execute this test, vhost should be enabled, > > then most of new features can be used. Vhost doesn't > > support VIRTIO_NET_F_MRG_RXBUF, so do not check large > > packets in received offload test. > > > > Transfer files by scp between host and guest, match > > new opened TCP port by netstat. Capture the packages > > info by tcpdump, it contains package length. > > > > TODO: Query supported offload function by 'ethtool' > > > > Hi Lucas/AMos > > Thanks for the patches. > > Please find below error, when i try to run ethtool test on > my guest (kernel: 2.6.32-71.el6.i386) which is on host (Kernel > 2.6.32-71.el6.x86_64). > > > 'module' object has no attribute 'get_linux_ifname'.. > > > > 04:23:59 DEBUG| Got shell prompt -- logged in > 04:23:59 INFO | Logged into guest 'vm1' > 04:23:59 ERROR| Test failed: AttributeError: 'module' object has no > attribute 'get_linux_ifname' 04:23:59 DEBUG| Postprocessing VM 'vm1'... > > Ethtool is trying to access get_linux_ifname which is not present in > kvm_test_utils.py. AM i missing any patches? > Yes, please verify http://patchwork.test.kernel.org/patch/2540/ Cheers! Lucas -- 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: [Autotest] [PATCH 18/18] KVM test: Add subtest of testing offload by ethtool
On Tue, 14 Sep 2010 19:25:43 -0300 Lucas Meneghel Rodrigues wrote: > The latest case contains TX/RX/SG/TSO/GSO/GRO/LRO test. > RTL8139 NIC doesn't support TSO, LRO, it's too old, so > drop offload test from rtl8139. LRO, GRO are only > supported by latest kernel, virtio nic doesn't support > receive offloading function. > > Initialize the callbacks first and execute all the sub > tests one by one, all the result will be check at the > end. When execute this test, vhost should be enabled, > then most of new features can be used. Vhost doesn't > support VIRTIO_NET_F_MRG_RXBUF, so do not check large > packets in received offload test. > > Transfer files by scp between host and guest, match > new opened TCP port by netstat. Capture the packages > info by tcpdump, it contains package length. > > TODO: Query supported offload function by 'ethtool' > Hi Lucas/AMos Thanks for the patches. Please find below error, when i try to run ethtool test on my guest (kernel: 2.6.32-71.el6.i386) which is on host (Kernel 2.6.32-71.el6.x86_64). 'module' object has no attribute 'get_linux_ifname'.. 04:23:59 DEBUG| Got shell prompt -- logged in 04:23:59 INFO | Logged into guest 'vm1' 04:23:59 ERROR| Test failed: AttributeError: 'module' object has no attribute 'get_linux_ifname' 04:23:59 DEBUG| Postprocessing VM 'vm1'... Ethtool is trying to access get_linux_ifname which is not present in kvm_test_utils.py. AM i missing any patches? Thanks Pradeep -- 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 v9 12/16] Add mp(mediate passthru) device.
>-Original Message-
>From: Michael S. Tsirkin [mailto:m...@redhat.com]
>Sent: Wednesday, September 22, 2010 7:55 PM
>To: Xin, Xiaohui
>Cc: net...@vger.kernel.org; kvm@vger.kernel.org; linux-ker...@vger.kernel.org;
>mi...@elte.hu; da...@davemloft.net; herb...@gondor.hengli.com.au;
>jd...@linux.intel.com
>Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
>
>On Wed, Sep 22, 2010 at 07:41:36PM +0800, Xin, Xiaohui wrote:
>> >-Original Message-
>> >From: Michael S. Tsirkin [mailto:m...@redhat.com]
>> >Sent: Tuesday, September 21, 2010 9:14 PM
>> >To: Xin, Xiaohui
>> >Cc: net...@vger.kernel.org; kvm@vger.kernel.org;
>> >linux-ker...@vger.kernel.org;
>> >mi...@elte.hu; da...@davemloft.net; herb...@gondor.hengli.com.au;
>> >jd...@linux.intel.com
>> >Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
>> >
>> >On Tue, Sep 21, 2010 at 09:39:31AM +0800, Xin, Xiaohui wrote:
>> >> >From: Michael S. Tsirkin [mailto:m...@redhat.com]
>> >> >Sent: Monday, September 20, 2010 7:37 PM
>> >> >To: Xin, Xiaohui
>> >> >Cc: net...@vger.kernel.org; kvm@vger.kernel.org;
>> >> >linux-ker...@vger.kernel.org;
>> >> >mi...@elte.hu; da...@davemloft.net; herb...@gondor.hengli.com.au;
>> >> >jd...@linux.intel.com
>> >> >Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
>> >> >
>> >> >On Mon, Sep 20, 2010 at 04:08:48PM +0800, xiaohui@intel.com wrote:
>> >> >> From: Xin Xiaohui
>> >> >>
>> >> >> ---
>> >> >> Michael,
>> >> >> I have move the ioctl to configure the locked memory to vhost
>> >> >
>> >> >It's ok to move this to vhost but vhost does not
>> >> >know how much memory is needed by the backend.
>> >>
>> >> I think the backend here you mean is mp device.
>> >> Actually, the memory needed is related to vq->num to run zero-copy
>> >> smoothly.
>> >> That means mp device did not know it but vhost did.
>> >
>> >Well, this might be so if you insist on locking
>> >all posted buffers immediately. However, let's assume I have a
>> >very large ring and prepost a ton of RX buffers:
>> >there's no need to lock all of them directly:
>> >
>> >if we have buffers A and B, we can lock A, pass it
>> >to hardware, and when A is consumed unlock A, lock B
>> >and pass it to hardware.
>> >
>> >
>> >It's not really critical. But note we can always have userspace
>> >tell MP device all it wants to know, after all.
>> >
>> Ok. Here are two values we have mentioned, one is how much memory
>> user application wants to lock, and one is how much memory locked
>> is needed to run smoothly. When net backend is setup, we first need
>> an ioctl to get how much memory is needed to lock, and then we call
>> another ioctl to set how much it want to lock. Is that what's in your mind?
>
>That's fine.
>
>> >> And the rlimt stuff is per process, we use current pointer to set
>> >> and check the rlimit, the operations should be in the same process.
>> >
>> >Well no, the ring is handled from the kernel thread: we switch the mm to
>> >point to the owner task so copy from/to user and friends work, but you
>> >can't access the rlimit etc.
>> >
>> Yes, the userspace and vhost kernel is not the same process. But we can
>> record the task pointer as mm.
>
>So you will have to store mm and do device->mm, not current->mm.
>Anyway, better not touch mm on data path.
>
>> >> Now the check operations are in vhost process, as mp_recvmsg() or
>> >> mp_sendmsg() are called by vhost.
>> >
>> >Hmm, what do you mean by the check operations?
>> >send/recv are data path operations, they shouldn't
>> >do any checks, should they?
>> >
>> As you mentioned what infiniband driver done:
>> down_write(¤t->mm->mmap_sem);
>>
>> locked = npages + current->mm->locked_vm;
>> lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
>>
>> if ((locked > lock_limit) && !capable(CAP_IPC_LOCK)) {
>> ret = -ENOMEM;
>> goto out;
>> }
>>
>> cur_base = addr & PAGE_MASK;
>>
>> ret = 0;
>> while (npages) {
>> ret = get_user_pages(current, current->mm, cur_base,
>> min_t(unsigned long, npages,
>>PAGE_SIZE / sizeof (struct page
>> *)),
>> 1, !umem->writable, page_list,
>> vma_list);
>>
>> I think it's a data path too.
>
>in infiniband this is used to 'register memory' which is not data path.
>
>> We do the check because get_user_pages() really pin and locked
>> the memory.
>
>Don't do this. Performance will be bad.
>Do the check once in ioctl and increment locked_vm by max amount you will use.
>On data path just make sure you do not exceed what userspace told you
>to.
What's in my mind is that in the ioctl which to get the memory locked needed to
run smoothly,
it just return a value of how much memory is needed by mp device.
And then in the ioctl which to set the memory locked by user space, it check
the rlimit and
increm
[PATCH 1/1] virtio_console: perf-test fix [FIX] read-out all data after perf-test [FIX] code clean-up
Signed-off-by: Lukas Doktor
Signed-off-by: Jiri Zupka
---
client/tests/kvm/tests/virtio_console.py | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/client/tests/kvm/tests/virtio_console.py
b/client/tests/kvm/tests/virtio_console.py
index 058bb94..d5af383 100644
--- a/client/tests/kvm/tests/virtio_console.py
+++ b/client/tests/kvm/tests/virtio_console.py
@@ -1,3 +1,8 @@
+"""
+virtio_console test
+
+...@copyright: Red Hat 2010
+"""
import array, logging, os, random, re, select, shutil, socket, sys, tempfile
import threading, time
from collections import deque
@@ -180,8 +185,6 @@ def run_virtio_console(test, params, env):
logging.debug("th_recv_check %s: exit(%d)", self.getName(),
self.idx)
-seqTest = threading.Lock();
-
class cpu_load():
"""
@@ -226,7 +229,7 @@ def run_virtio_console(test, params, env):
Start CPU usage measurement
"""
self.old_load = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
-self.startTime = time.time();
+self.startTime = time.time()
self._get_cpu_load()
@@ -287,7 +290,7 @@ def run_virtio_console(test, params, env):
Start CPU usage measurement
"""
self.old_load = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
-self.startTime = time.time();
+self.startTime = time.time()
self._get_cpu_load(self.pid)
@@ -388,7 +391,7 @@ def run_virtio_console(test, params, env):
"timeout: %s", command, vm[0].name, timeout)
vm[1].sendline(command)
(match, data) = vm[1].read_until_last_line_matches(["PASS:", "FAIL:" \
- "[Failed to
execute]"], \
+ "[Failed to execute]"], \
timeout)
return (match, data)
@@ -829,6 +832,11 @@ def run_virtio_console(test, params, env):
exit_event.set()
thread.join()
+# Let the guest read-out all the remaining data
+while not _on_guest("virt.poll('%s', %s)"
+% (port[1], select.POLLIN), vm, 2)[0]:
+time.sleep(1)
+
_guest_exit_threads(vm, [port], [])
if (_time > slice):
--
1.7.2.3
--
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-autotest][Patch] virtio_console: perf-test fix
After the first part of perf_test there were still data in a buffer which caused console failures in this test. With this fix all data are read out and it's possible to use test_perf with console (virtio_console_perf = "console") Additionaly this patch contains some minor code cleanups. -- 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
Problems with e1000 network card on qemu.git
Hi folks:
As most of you might know, we run some daily sanity and functional tests
with both qemu-kvm.git and qemu.git. I decided to write asking for help
with regards to what it appears to be a problem with the e1000 nw card
(the default). Here is a list of what it fails pretty much every day for
qemu.git:
1) Problems logging into guest with e1000 card
kvm.qemu-git.RHEL.5.5.i386.e1000.boot
FAIL Could not log into guest 'vm1'
kvm.qemu-git.RHEL.5.5.i386.e1000.reboot
FAIL Could not log into guest 'vm1'
kvm.qemu-git.RHEL.5.5.i386.e1000.shutdown
FAIL Could not log into guest 'vm1'
^ At first I thought this was some sort of intermittent, harmless
problem, but it reproduces fairly frequently, thing that pretty much
doesn't happen with virtio.
kvm.qemu-git.RHEL.5.5.i386.virtio_net.boot GOODcompleted successfully
kvm.qemu-git.RHEL.5.5.i386.virtio_net.rebootGOODcompleted successfully
kvm.qemu-git.RHEL.5.5.i386.virtio_net.shutdown GOODcompleted successfully
Looking at test logs and screenshots the only thing that I found
abnormal was:
2010-09-23 05:51:02: EXT3-fs: recovery complete.
2010-09-23 05:51:02: EXT3-fs: mounted filesystem with ordered data mode.
2010-09-23 05:51:05: type=1404 audit(1285235453.446:2): enforcing=1
old_enforcing=0 auid=4294967295 ses=4294967295
2010-09-23 05:51:06: type=1403 audit(1285235454.059:3): policy loaded
auid=4294967295 ses=4294967295
2010-09-23 05:53:16: hdc: drive_cmd: status=0x41 { DriveReady Error }
2010-09-23 05:53:16: hdc: drive_cmd: error=0x04 { AbortedCommand }
2010-09-23 05:53:16: ide: failed opcode was: 0xec
^ Serial logs for the RHEL5.5 guest. If someone wants the full serial
log, please let me know.
2) Qemu dies during unattended install
kvm.qemu-git.RHEL.5.5.x86_64.e1000.unattended_install.cdrom
ERROR Guest died before end of OS install
^ This is the bug
https://bugs.launchpad.net/qemu/+bug/588955
Which is, according to preliminary investigation done, a bug on the
slirp code. IMHO, we really need to start looking into those issues,
even because e1000 is the default network card.
Cheers,
Lucas
--
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
