[COMMIT master] Merge commit '59f2689d9082f2f631253c810f73cd22290144a9' into upstream-merge
From: Avi Kivity a...@redhat.com * commit '59f2689d9082f2f631253c810f73cd22290144a9': Added readonly flag to -drive command qcow2: Allow qcow2 disk images with size zero (x86/Sparc/PPC)-user: fix cpu_copy IDE: Fix reset handling user: move CPU reset call to main.c for x86/PPC/Sparc PPC: rename cpu_ppc_reset to cpu_reset for consistency Sparc64/x86: remove unneeded calls to device reset PPC: remove unneeded calls to device reset sparc32 (mostly): remove unneeded calls to device reset v3: don't call reset functions on cpu initialization vga: fix line comparison vga: Respect Line Compare Register in text modes Conflicts: qemu-config.c Signed-off-by: Avi Kivity a...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Merge commit '4f5e19e6c570459cd524b29b24374f03860f5149' into upstream-merge
From: Avi Kivity a...@redhat.com * commit '4f5e19e6c570459cd524b29b24374f03860f5149': pci_host.h: move functions in pci_host.h into .c file. Conflicts: hw/piix_pci.c Signed-off-by: Avi Kivity a...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Merge commit '1945120112e93aa96af6d6004b36599f783ac563' into upstream-merge
From: Avi Kivity a...@redhat.com * commit '1945120112e93aa96af6d6004b36599f783ac563': Update SeaBIOS to latest Add test suite for json marshalling Provide marshalling mechanism for json QDict: Introduce qdict_iter() Add a unit test for JSON support Add a QObject JSON wrapper Add a JSON parser Add a JSON message boundary identifier Add a lexer for JSON Add a QBool type Add unit test for QFloat Add a QFloat datatype Allow strings to grow in size Add operations to qlist to allow it to be used as a stack Properly escape QDECREF macro arguments Cleanup configure checks for dup3 and fallocate Conflicts: pc-bios/bios.bin (pick qemu-kvm) Signed-off-by: Avi Kivity a...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Merge commit 'fb23162885f7fd8cf7334bed22c25ac32c7d8b9d' into upstream-merge
From: Avi Kivity a...@redhat.com * commit 'fb23162885f7fd8cf7334bed22c25ac32c7d8b9d': pci: initialize pci config headers depending it pci header type. pci: teach pci_default_config_write() ROM bar for normal/bridge device . Changed include order in hw/device-assignment.c. Signed-off-by: Avi Kivity a...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Merge commit '715a664ac4ca3b9e44ffbc0ca41ecd91fbe96656' into upstream-merge
From: Avi Kivity a...@redhat.com * commit '715a664ac4ca3b9e44ffbc0ca41ecd91fbe96656': QemuOpts: command line switches for the config file. QemuOpts: parse config from file. QemuOpts: dump config. QemuOpts: add find_list() Documentation: Add options to image format descriptions Documentation: Don't mention old qemu-img options Documentation: Move image format descriptions to own section Documentation: Add documentation for -chardev Added imlpementation for qemu_error for non-qemu executables eepro100: Improve support for different devices pci/monitor: print out bridge's filtering values and so on. pci: implement pci bridge filtering. pci: factor out pci_for_each_device(). pci: cosmetic on pci_upadte_mappings() Conflicts: qemu-options.hx Signed-off-by: Avi Kivity a...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Merge commit '260c0cd3d985e51b15870ff47e17b7b930efbda1' into upstream-merge
From: Avi Kivity a...@redhat.com
* commit '260c0cd3d985e51b15870ff47e17b7b930efbda1':
pci: use range helper functions.
pci: add helper functions to check ranges overlap.
pci: pcie host and mmcfg support.
vmstate: introduce VMSTATE_BUFFER_UNSAFE_INFO.
pci_host: change the signature of pci_data_{read, write}.
pci: move pci host stuff from pci.c to pci_host.c
pci: factor out the conversion logic from io port address into pci device.
pci: make pci configuration transaction more accurate.
pci: remove bus_num member from struct PCIBus.
pci: 64bit bar support.
Conflicts:
hw/pci.c
Signed-off-by: Avi Kivity a...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Merge commit 'cfc6d90a98ec420998ef2009e359ea04456735ff' into upstream-merge
From: Avi Kivity a...@redhat.com * commit 'cfc6d90a98ec420998ef2009e359ea04456735ff': Add linuxboot to BLOBS Conflicts: Makefile Signed-off-by: Avi Kivity a...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Merge commit 'dd4239d6574ca41c94fc0d0f77ddc728510ffc57' into upstream-merge
From: Avi Kivity a...@redhat.com * commit 'dd4239d6574ca41c94fc0d0f77ddc728510ffc57': Allow build of linuxboot.S with old assemblers Avoid segfault on net_tap_init() failure tap-bsd: handle ifname on FreeBSD hosts Fix tap breakage on BSD hosts (no IFF_VNET_HDR) Fix OpenBSD build of qemu-io Signed-off-by: Avi Kivity a...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Disable generic pci reset
From: Avi Kivity a...@redhat.com
The generic pci reset introduced by c0b1905b28580 breaks Windows XP suspend.
Disable it.
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/hw/pci.c b/hw/pci.c
index f4fdc1e..ca7dd73 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -109,9 +109,12 @@ static int pci_bar(PCIDevice *d, int reg)
static void pci_device_reset(PCIDevice *dev)
{
+#ifdef THIS_BREAKS_WINXP_SUSPEND
int r;
+#endif
memset(dev-irq_state, 0, sizeof dev-irq_state);
+#ifdef THIS_BREAKS_WINXP_SUSPEND
dev-config[PCI_COMMAND] = ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
PCI_COMMAND_MASTER);
dev-config[PCI_CACHE_LINE_SIZE] = 0x0;
@@ -123,6 +126,7 @@ static void pci_device_reset(PCIDevice *dev)
pci_set_long(dev-config + pci_bar(dev, r), dev-io_regions[r].type);
}
pci_update_mappings(dev);
+#endif
}
static void pci_bus_reset(void *opaque)
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Fix mismerge of irq bitmap refactoring
From: Avi Kivity a...@redhat.com
init/reset was left out.
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index 71a6319..1f0d37a 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -1291,6 +1291,7 @@ int kvm_arch_init_vcpu(CPUState *cenv)
qemu_kvm_load_lapic(cenv);
+cenv-interrupt_injected = -1;
#ifdef KVM_CPUID_SIGNATURE
/* Paravirtualization CPUIDs */
@@ -1452,6 +1453,7 @@ void kvm_arch_push_nmi(void *opaque)
void kvm_arch_cpu_reset(CPUState *env)
{
+env-interrupt_injected = -1;
kvm_arch_load_regs(env);
if (!cpu_is_bsp(env)) {
if (kvm_irqchip_in_kernel()) {
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Merge commit '3a3fb96d0d9e3331e3beb672108ec18a6d3d8c1c' into upstream-merge
From: Avi Kivity a...@redhat.com * commit '3a3fb96d0d9e3331e3beb672108ec18a6d3d8c1c': configure: Fix spelling in comment and rework the comment qemu-io: build on all platforms slirp: fix use-after-free ARM PBX-A9 board support ARM Cortex-A9 cpu support ARM FP16 support Built network devices once sb16: remove highspeed reset code audio: Remove conditional around sw which can not be NULL audio: link with -lpulse in addition to -lpulse-simple Fix typo Fix mingw32 build Prevent configuring for a user emulator on a different type of OS Conflicts: configure Signed-off-by: Avi Kivity a...@redhat.com -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: s390: Make psw available on all exits, not just a subset
From: Carsten Otte carst...@de.ibm.com
This patch moves s390 processor status word into the base kvm_run
struct and keeps it up-to date on all userspace exits.
The userspace ABI is broken by this, however there are no applications
in the wild using this. A capability check is provided so users can
verify the updated API exists.
Signed-off-by: Carsten Otte co...@de.ibm.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/s390/include/asm/kvm.h b/arch/s390/include/asm/kvm.h
index 3dfcaeb..82b32a1 100644
--- a/arch/s390/include/asm/kvm.h
+++ b/arch/s390/include/asm/kvm.h
@@ -1,6 +1,5 @@
#ifndef __LINUX_KVM_S390_H
#define __LINUX_KVM_S390_H
-
/*
* asm-s390/kvm.h - KVM s390 specific structures and definitions
*
@@ -15,6 +14,8 @@
*/
#include linux/types.h
+#define __KVM_S390
+
/* for KVM_GET_REGS and KVM_SET_REGS */
struct kvm_regs {
/* general purpose regs for s390 */
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 5445058..f8bcaef 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -117,10 +117,16 @@ long kvm_arch_dev_ioctl(struct file *filp,
int kvm_dev_ioctl_check_extension(long ext)
{
+ int r;
+
switch (ext) {
+ case KVM_CAP_S390_PSW:
+ r = 1;
+ break;
default:
- return 0;
+ r = 0;
}
+ return r;
}
/* Section: vm related */
@@ -420,8 +426,10 @@ static int kvm_arch_vcpu_ioctl_set_initial_psw(struct
kvm_vcpu *vcpu, psw_t psw)
vcpu_load(vcpu);
if (atomic_read(vcpu-arch.sie_block-cpuflags) CPUSTAT_RUNNING)
rc = -EBUSY;
- else
- vcpu-arch.sie_block-gpsw = psw;
+ else {
+ vcpu-run-psw_mask = psw.mask;
+ vcpu-run-psw_addr = psw.addr;
+ }
vcpu_put(vcpu);
return rc;
}
@@ -509,9 +517,6 @@ rerun_vcpu:
switch (kvm_run-exit_reason) {
case KVM_EXIT_S390_SIEIC:
- vcpu-arch.sie_block-gpsw.mask = kvm_run-s390_sieic.mask;
- vcpu-arch.sie_block-gpsw.addr = kvm_run-s390_sieic.addr;
- break;
case KVM_EXIT_UNKNOWN:
case KVM_EXIT_INTR:
case KVM_EXIT_S390_RESET:
@@ -520,6 +525,9 @@ rerun_vcpu:
BUG();
}
+ vcpu-arch.sie_block-gpsw.mask = kvm_run-psw_mask;
+ vcpu-arch.sie_block-gpsw.addr = kvm_run-psw_addr;
+
might_fault();
do {
@@ -539,8 +547,6 @@ rerun_vcpu:
/* intercept cannot be handled in-kernel, prepare kvm-run */
kvm_run-exit_reason = KVM_EXIT_S390_SIEIC;
kvm_run-s390_sieic.icptcode = vcpu-arch.sie_block-icptcode;
- kvm_run-s390_sieic.mask = vcpu-arch.sie_block-gpsw.mask;
- kvm_run-s390_sieic.addr = vcpu-arch.sie_block-gpsw.addr;
kvm_run-s390_sieic.ipa = vcpu-arch.sie_block-ipa;
kvm_run-s390_sieic.ipb = vcpu-arch.sie_block-ipb;
rc = 0;
@@ -552,6 +558,9 @@ rerun_vcpu:
rc = 0;
}
+ kvm_run-psw_mask = vcpu-arch.sie_block-gpsw.mask;
+ kvm_run-psw_addr = vcpu-arch.sie_block-gpsw.addr;
+
if (vcpu-sigset_active)
sigprocmask(SIG_SETMASK, sigsaved, NULL);
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 92045a9..2d241da 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -181,6 +181,11 @@ struct kvm_run {
__u64 cr8;
__u64 apic_base;
+#ifdef __KVM_S390
+ /* the processor status word for s390 */
+ __u64 psw_mask; /* psw upper half */
+ __u64 psw_addr; /* psw lower half */
+#endif
union {
/* KVM_EXIT_UNKNOWN */
struct {
@@ -232,8 +237,6 @@ struct kvm_run {
/* KVM_EXIT_S390_SIEIC */
struct {
__u8 icptcode;
- __u64 mask; /* psw upper half */
- __u64 addr; /* psw lower half */
__u16 ipa;
__u32 ipb;
} s390_sieic;
@@ -492,6 +495,7 @@ struct kvm_ioeventfd {
#ifdef __KVM_HAVE_VCPU_EVENTS
#define KVM_CAP_VCPU_EVENTS 41
#endif
+#define KVM_CAP_S390_PSW 42
#ifdef KVM_CAP_IRQ_ROUTING
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A puzzle on the interrupt disposal of KVM?
I've been studying interrupt delivery in KVM myself lately. I hope I can explain what I've found, but, as I'm pretty new to this, please take my answer with a grain of salt (as I could be wrong). I would really appreciate if someone could correct me here if I am wrong or provide more details! Interrupts from the guest might be delivered via the ioctl KVM_INTERRUPT only when the KVM kmod can do interrupt routing. However, the default setup for KVM these days implements the interrupt controller in the kernel, so this ioctl is unused, and thus, vmx_inject_irq is not directly triggered from userspace. The call to vmx_inject_irq is made upon re-entry to the guest after I.E. the local APIC in the kmod flags that it needs service. To use the example of a PS2 keyboard press, the control flow works like this: 1. Userspace writes to appropriate locations as defined by the i8042 emulator 2. Userspace calls vm ioctl KVM_IRQ_LINE (IRQ=1, Level=1) 3. Control in the kmod eventually makes a call to kvm_apic_set_irq 4. In the local APIC, __apic_accept_irq does a part in setting up the need for service 5. Upon guest entry (vcpu_enter_guest), if there is no nmi and kvm_apic_has_interrupt, the host will call inject_pending_irq 6. inject_pending_irq calls vmx_inject_irq In attempting to answer the second part of your question, I realize this point isn't 100% clear to me either. It would seem the point at which the interrupt is delivered to KVM is always the point at which the guest VCPU is entered. Obviously, if you have a multi-cpu setup the calls to set up the local apic can be done in parallel to running the guest, but interrupt delivery won't happen until the vcpu is re- entered. This seems to mean that interrupts are only delivered when the guest is scheduled out and back in by the kernel. Is this right, guys? Kurt On Nov 23, 2009, at 4:49 PM, Liang YANG wrote: Does the vmx_inject_irq and vmx_inject_nmi inject all the interrupt from outer space ? Then when the interrrupt yielded from hardware is delieved to the QEMU or KVM ? Anyone can help me,, Thanks in advance!! -- BestRegards. YangLiang _ Master Candidate. Department of Computer Science . School of Electronics Engineering Computer Science . _ -- 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
[ kvm-Bugs-2902983 ] Window7 debug version installation fail on KVM
Bugs item #2902983, was opened at 2009-11-24 16:17 Message generated for change (Tracker Item Submitted) made by haoxudong You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2902983group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Xudong Hao (haoxudong) Assigned to: Nobody/Anonymous (nobody) Summary: Window7 debug version installation fail on KVM Initial Comment: Environment: Host OS (ia32/ia32e/IA64): ia32pae ia32e Guest OS (ia32/ia32e/IA64): ia32pae ia32e Guest OS Type (Linux/Windows): Windows7 kvm.git Commit: 212b1ccd9ffb1ed9a7abdcdc57e1d7d31486945b qemu-kvm Commit: 72a56670e2f4a1d905676384fc965ec0bf516b9c Host Kernel Version: 2.6.32-rc7 Hardware: Stoakley Bug detailed description: -- We download Windows7 build iso(debug) and try to install it on KVM, at the begining of install, a blue screen printed STOP: 0X007E... (attach the failed screen), no dmesg information print on host. Reproduce steps: 1) download en_windows_7_checked_build_dvd_x64_398741.iso 2) dd one 20G blank image named ia32e_win7_ent_debug.img 3) qemu-system-x86_64 -smp 2 -m 1024 -hda ia32e_win7_ent_debug.img -cdrom en_windows_7_checked_build_dvd_x64_398741.iso -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2902983group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A puzzle on the interrupt disposal of KVM?
On 24.11.2009, at 09:03, Kurt Kiefer wrote: I've been studying interrupt delivery in KVM myself lately. I hope I can explain what I've found, but, as I'm pretty new to this, please take my answer with a grain of salt (as I could be wrong). I would really appreciate if someone could correct me here if I am wrong or provide more details! Interrupts from the guest might be delivered via the ioctl KVM_INTERRUPT only when the KVM kmod can do interrupt routing. However, the default setup for KVM these days implements the interrupt controller in the kernel, so this ioctl is unused, and thus, vmx_inject_irq is not directly triggered from userspace. The call to vmx_inject_irq is made upon re-entry to the guest after I.E. the local APIC in the kmod flags that it needs service. To use the example of a PS2 keyboard press, the control flow works like this: 1. Userspace writes to appropriate locations as defined by the i8042 emulator 2. Userspace calls vm ioctl KVM_IRQ_LINE (IRQ=1, Level=1) 3. Control in the kmod eventually makes a call to kvm_apic_set_irq 4. In the local APIC, __apic_accept_irq does a part in setting up the need for service 5. Upon guest entry (vcpu_enter_guest), if there is no nmi and kvm_apic_has_interrupt, the host will call inject_pending_irq 6. inject_pending_irq calls vmx_inject_irq In attempting to answer the second part of your question, I realize this point isn't 100% clear to me either. It would seem the point at which the interrupt is delivered to KVM is always the point at which the guest VCPU is entered. Obviously, if you have a multi-cpu setup the calls to set up the local apic can be done in parallel to running the guest, but interrupt delivery won't happen until the vcpu is re-entered. This seems to mean that interrupts are only delivered when the guest is scheduled out and back in by the kernel. Is this right, guys? It means that interrupts are delivered on guest entries. That doesn't mean you have to exit the vcpu thread. You can just as well still be in the vcpu run loop. So if you for example get a #PF in the guest that is trapped by the host because of shadow paging, KVM will check for pending irqs again. 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: kvmmmu tracing
On 11/23/2009 01:06 PM, Johannes Berg wrote: Commit f691fe1da7e2715137d21ae5a80bec64db4625db is really broken wrt. the userspace interface for tracing because of the weird KVM_MMU_PAGE_PRINTK macro. Can you explain what is wrong with it? Maybe we should have a unsafe for export flag for events, if they do strange things like that? As it stands, I can't use trace-cmd on an x86 machine that has kvm enabled because it will try to read all the kvm stuff. Arguably, it should only try to parse it when it needs it (i.e. not for me) but still it's very inconvenient to export something to userspace that it cannot possibly understand. Is userspace reading mmutrace.h? When the structure attributes can be exported via /sys/kernel/debug/tracing? -- 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: Breakage due to commit c1699988 (v3: don't call reset functions on cpu initialization)
On 11/23/2009 09:00 PM, Glauber Costa wrote: On Sun, Nov 22, 2009 at 04:42:12PM +0200, Avi Kivity wrote: A qemu-kvm which merges this commit breaks badly (see qemu-kvm.git next branch). In the commit log for this commit, you write you = Glauber Costa I tested it with qemu (with and without io-thread) and qemu-kvm, and it seems to be doing okay - although qemu-kvm uses a slightly different patch. Can you share the slightly different patch (against 'next') please? Sorry, I don't follow. You said you tested it and it works, so what exactly do we need from me here? No. _You_ tested it and it worked for you. qemu-kvm next fails badly (doesn't even run the bios). I need help from you in finding out why and fixing it. -- 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: Breakage due to commit c1699988 (v3: don't call reset functions on cpu initialization)
On 11/23/2009 11:07 PM, Glauber Costa wrote: On Mon, Nov 23, 2009 at 5:00 PM, Glauber Costaglom...@redhat.com wrote: On Sun, Nov 22, 2009 at 04:42:12PM +0200, Avi Kivity wrote: A qemu-kvm which merges this commit breaks badly (see qemu-kvm.git next branch). In the commit log for this commit, you write I tested it with qemu (with and without io-thread) and qemu-kvm, and it seems to be doing okay - although qemu-kvm uses a slightly different patch. Can you share the slightly different patch (against 'next') please? Sorry, I don't follow. You said you tested it and it works, so what exactly do we need from me here? FYI: Combining that patch with a later fix from Juan fix the issue for qemu-kvm. (504c2948) Also, the patch seems to apply fine ontop of next. I can send a combined version if you want, or you can combine it yourself That commit is already merged. -- 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: kvmmmu tracing
On Tue, 2009-11-24 at 11:50 +0200, Avi Kivity wrote: On 11/23/2009 01:06 PM, Johannes Berg wrote: Commit f691fe1da7e2715137d21ae5a80bec64db4625db is really broken wrt. the userspace interface for tracing because of the weird KVM_MMU_PAGE_PRINTK macro. Can you explain what is wrong with it? It's a big C expression that trace-cmd can't parse :) Is userspace reading mmutrace.h? When the structure attributes can be exported via /sys/kernel/debug/tracing? Yes ... look at /sys/kernel/debug/tracing/events/kvmmmu/kvm_mmu_unsync_page/format for instance. johannes signature.asc Description: This is a digitally signed message part
[PATCH] qemu-kvm: Fix INTx assigned device can't work bug
Commit 6b5bbd04 qdev-ify device assignment forgot to put assigned devices to devs list. So when IRQ routing changed in pci configure space, calling to assigned_dev_update_irqs() won't update device guest IRQ, then assigned INTx devices fail to work. (OK, I am now aware of the fact that people don't use INTx these days...) CC: Gerd Hoffmann kra...@redhat.com Signed-off-by: Sheng Yang sh...@linux.intel.com --- hw/device-assignment.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/device-assignment.c b/hw/device-assignment.c index 516cf14..64f3dc2 100644 --- a/hw/device-assignment.c +++ b/hw/device-assignment.c @@ -1180,6 +1180,7 @@ static int assigned_initfn(struct PCIDevice *pci_dev) goto assigned_out; assigned_dev_load_option_rom(dev); +QLIST_INSERT_HEAD(devs, dev, next); return 0; assigned_out: -- 1.5.4.5 -- 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: kvmmmu tracing
On 11/24/2009 12:05 PM, Johannes Berg wrote: On Tue, 2009-11-24 at 11:50 +0200, Avi Kivity wrote: On 11/23/2009 01:06 PM, Johannes Berg wrote: Commit f691fe1da7e2715137d21ae5a80bec64db4625db is really broken wrt. the userspace interface for tracing because of the weird KVM_MMU_PAGE_PRINTK macro. Can you explain what is wrong with it? It's a big C expression that trace-cmd can't parse :) Um, C can be easily parsed with a C compiler. I don't think you can expect it to be a plain format string and argument list. Is userspace reading mmutrace.h? When the structure attributes can be exported via /sys/kernel/debug/tracing? Yes ... look at /sys/kernel/debug/tracing/events/kvmmmu/kvm_mmu_unsync_page/format for instance. You can fall back to using the attributes to build your own format string. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net
On Tue, Nov 24, 2009 at 08:54:23AM +1030, Rusty Russell wrote:
On Tue, 24 Nov 2009 02:37:01 am Shirley Ma wrote:
+ skb = (struct sk_buff *)buf;
This cast is unnecessary, but a comment would be nice:
Without this cast there is a compile warning.
Hi Shirley,
Looks like buf is a void *, so no cast should be necessary. But I could
be reading the patch wrong.
However, I question whether making it 16 byte is the right thing: the
ethernet header is 14 bytes long, so don't we want 8 bytes of padding?
Because in QEMU it requires 10 bytes header in a separately, so one page
is used to share between virtio_net_hdr header which is 10 bytes head
and rest of data. So I put 6 bytes offset here between two buffers. I
didn't look at the reason why a seperate buf is used for virtio_net_hdr
in QEMU.
It's a qemu bug. It insists the header be an element in the scatterlist by
itself. Unfortunately we have to accommodate it.
We do? Let's just fix this?
All we have to do is replace memcpy with proper iovec walk, correct?
Something like the followng (untested) patch? It's probably not too
late to put this in the next qemu release...
Signed-off-by: Michael S. Tsirkin m...@redhat.com
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 2f147e5..06c5148 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -434,26 +434,59 @@ static int iov_fill(struct iovec *iov, int iovcnt, const
void *buf, int count)
return offset;
}
+static int iov_skip(struct iovec *iov, int iovcnt, int count)
+{
+int offset, i;
+
+offset = i = 0;
+while (offset count i iovcnt) {
+int len = MIN(iov[i].iov_len, count - offset);
+ iov[i].iov_base += len;
+ iov[i].iov_len -= len;
+offset += len;
+i++;
+}
+
+return offset;
+}
+
+static int iov_copy(struct iovec *to, struct iovec *from, int iovcnt, int
count)
+{
+int offset, i;
+
+offset = i = 0;
+while (offset count i iovcnt) {
+int len = MIN(from[i].iov_len, count - offset);
+ to[i].iov_base = from[i].iov_base;
+ to[i].iov_len = from[i].iov_len;
+offset += len;
+i++;
+}
+
+return i;
+}
+
static int receive_header(VirtIONet *n, struct iovec *iov, int iovcnt,
const void *buf, size_t size, size_t hdr_len)
{
-struct virtio_net_hdr *hdr = (struct virtio_net_hdr *)iov[0].iov_base;
+struct virtio_net_hdr hdr = {};
int offset = 0;
-hdr-flags = 0;
-hdr-gso_type = VIRTIO_NET_HDR_GSO_NONE;
+hdr.flags = 0;
+hdr.gso_type = VIRTIO_NET_HDR_GSO_NONE;
if (n-has_vnet_hdr) {
-memcpy(hdr, buf, sizeof(*hdr));
-offset = sizeof(*hdr);
-work_around_broken_dhclient(hdr, buf + offset, size - offset);
+memcpy(hdr, buf, sizeof hdr);
+offset = sizeof hdr;
+work_around_broken_dhclient(hdr, buf + offset, size - offset);
}
+iov_fill(iov, iovcnt, hdr, sizeof hdr);
+
/* We only ever receive a struct virtio_net_hdr from the tapfd,
* but we may be passing along a larger header to the guest.
*/
-iov[0].iov_base += hdr_len;
-iov[0].iov_len -= hdr_len;
+iov_skip(iov, iovcnt, hdr_len);
return offset;
}
@@ -514,7 +547,8 @@ static int receive_filter(VirtIONet *n, const uint8_t *buf,
int size)
static ssize_t virtio_net_receive(VLANClientState *vc, const uint8_t *buf,
size_t size)
{
VirtIONet *n = vc-opaque;
-struct virtio_net_hdr_mrg_rxbuf *mhdr = NULL;
+struct iovec mhdr[VIRTQUEUE_MAX_SIZE];
+int mhdrcnt = 0;
size_t hdr_len, offset, i;
if (!virtio_net_can_receive(n-vc))
@@ -552,16 +586,13 @@ static ssize_t virtio_net_receive(VLANClientState *vc,
const uint8_t *buf, size_
exit(1);
}
-if (!n-mergeable_rx_bufs elem.in_sg[0].iov_len != hdr_len) {
-fprintf(stderr, virtio-net header not in first element\n);
-exit(1);
-}
-
memcpy(sg, elem.in_sg[0], sizeof(sg[0]) * elem.in_num);
if (i == 0) {
-if (n-mergeable_rx_bufs)
-mhdr = (struct virtio_net_hdr_mrg_rxbuf *)sg[0].iov_base;
+if (n-mergeable_rx_bufs) {
+mhdrcnt = iov_copy(mhdr, sg, elem.in_num,
+ sizeof(struct virtio_net_hdr_mrg_rxbuf));
+}
offset += receive_header(n, sg, elem.in_num,
buf + offset, size - offset, hdr_len);
@@ -579,8 +610,12 @@ static ssize_t virtio_net_receive(VLANClientState *vc,
const uint8_t *buf, size_
offset += len;
}
-if (mhdr)
-mhdr-num_buffers = i;
+if (mhdrcnt) {
+uint16_t num = i;
+iov_skip(mhdr, mhdrcnt,
+ offsetof(struct virtio_net_hdr_mrg_rxbuf, num_buffers));
+iov_fill(mhdr, mhdrcnt, num, sizeof num);
+}
virtqueue_flush(n-rx_vq, i);
virtio_notify(n-vdev, n-rx_vq);
@@
Re: Breakage due to commit c1699988 (v3: don't call reset functions on cpu initialization)
FYI: Combining that patch with a later fix from Juan fix the issue for qemu-kvm. (504c2948) Also, the patch seems to apply fine ontop of next. I can send a combined version if you want, or you can combine it yourself That commit is already merged. Applying it ontop of 5d968c942adbc48188dbbcf7d85e69c2e0d7cd8a, which is your merge commit that includes my patch, make qemu-kvm go from non-working to working again. So the problem must be something else. -- Glauber Costa. Free as in Freedom http://glommer.net The less confident you are, the more serious you have to act. -- 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: Breakage due to commit c1699988 (v3: don't call reset functions on cpu initialization)
On 11/24/2009 02:16 PM, Glauber Costa wrote: That commit is already merged. Applying it ontop of 5d968c942adbc48188dbbcf7d85e69c2e0d7cd8a, which is your merge commit that includes my patch, make qemu-kvm go from non-working to working again. So the problem must be something else. It is my misport of Jan's irq bitmap refactoring (init/reset was not ported); pretty easy to fix. -- 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: kvmmmu tracing
On Tue, 2009-11-24 at 12:34 +0200, Avi Kivity wrote:
Um, C can be easily parsed with a C compiler. I don't think you can
expect it to be a plain format string and argument list.
Actually, it turns out that it cannot be parsed even with a C compiler:
({ const char *ret = p-buffer + p-len; static const char *access_str[]
= { ---, --x, w--, w-x, -u-, -ux, wu-, wux }; union
kvm_mmu_page_role role;
...
userspace cannot possibly know from this what union kvm_mmu_page_role
is.
johannes
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 2/2] qemu-kvm: x86: Add support for VCPU event states
On 11/15/2009 05:50 PM, Avi Kivity wrote: Shouldn't you create 13 now? No, I rather think Glauber's 12 should be downgraded to 11 - unless it misses the qemu merge windows for 0.12. My extensions definitely target that release, thus will likely carry 11 in upstream. And we should really try to avoid diverging again. Agree. Will commit the patches. Ugh, so I did it the hard way by merging upstream and porting it (incorrectly), then going back to my queue to see that you had already nicely prepared this for me. -- 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: kvmmmu tracing
On 11/24/2009 04:08 PM, Johannes Berg wrote:
On Tue, 2009-11-24 at 12:34 +0200, Avi Kivity wrote:
Um, C can be easily parsed with a C compiler. I don't think you can
expect it to be a plain format string and argument list.
Actually, it turns out that it cannot be parsed even with a C compiler:
({ const char *ret = p-buffer + p-len; static const char *access_str[]
= { ---, --x, w--, w-x, -u-, -ux, wu-, wux }; union
kvm_mmu_page_role role;
...
userspace cannot possibly know from this what union kvm_mmu_page_role
is.
We can expose kvm_mmu_page_role, but that's a new can of worms. And
it's certainly not meant to be stable across kernel versions.
--
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
The -next kernel no longer boots on kvm in 32bit mode
64bit Intel host system Fedora host environment 32bit guest built with CPU i686 and no PAE support This now momentarily flickers up something then reboots back to the BIOS. -- 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] PPC: Sync guest visible MMU state
On 11/24/2009 09:50 AM, Alexander Graf wrote:
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
index 92045a9..1240fcb 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -492,6 +492,7 @@ struct kvm_ioeventfd {
#ifdef __KVM_HAVE_VCPU_EVENTS
#define KVM_CAP_VCPU_EVENTS 41
#endif
+#define KVM_CAP_PPC_SEGSTATE 42
42 is already taken (s390 psw and D. Adams), please use 43.
--
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] PPC: Sync guest visible MMU state
On 24.11.2009, at 16:02, Avi Kivity wrote:
On 11/24/2009 09:50 AM, Alexander Graf wrote:
Currently userspace has no chance to find out which virtual address space
we're
in and resolve addresses. While that is a big problem for migration, it's
also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
index 92045a9..1240fcb 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -492,6 +492,7 @@ struct kvm_ioeventfd {
#ifdef __KVM_HAVE_VCPU_EVENTS
#define KVM_CAP_VCPU_EVENTS 41
#endif
+#define KVM_CAP_PPC_SEGSTATE 42
42 is already taken (s390 psw and D. Adams), please use 43.
Aww. Any reason I didn't get the s390 patch in a git pull yet? (damn that
Carsten - he got the cool number)
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: [PATCH v2 10/12] Maintain preemptability count even for !CONFIG_PREEMPT kernels
On Tue, 24 Nov 2009, Gleb Natapov wrote: On Mon, Nov 23, 2009 at 11:30:02AM -0600, Christoph Lameter wrote: This adds significant overhead for the !PREEMPT case adding lots of code in critical paths all over the place. I want to measure it. Can you suggest benchmarks to try? AIM9 (reaim9)? Any test suite will do that tests OS performance. Latency will also be negatively impacted. There are already significant regressions in recent kernel releases so many of us who are sensitive to these issues just stick with old kernels (2.6.22 f.e.) and hope that the upstream issues are worked out at some point. There is also lldiag package in my directory. See http://www.kernel.org/pub/linux/kernel/people/christoph/lldiag Try the latency test and the mcast test. Localhost multicast is typically a good test for kernel performance. There is also the page fault test that Kamezawa-san posted recently in the thread where we tried to deal with the long term mmap_sem issues. -- 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] PPC: Sync guest visible MMU state
On 11/24/2009 05:04 PM, Alexander Graf wrote:
index 92045a9..1240fcb 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -492,6 +492,7 @@ struct kvm_ioeventfd {
#ifdef __KVM_HAVE_VCPU_EVENTS
#define KVM_CAP_VCPU_EVENTS 41
#endif
+#define KVM_CAP_PPC_SEGSTATE 42
42 is already taken (s390 psw and D. Adams), please use 43.
Aww. Any reason I didn't get the s390 patch in a git pull yet? (damn that
Carsten - he got the cool number)
It's in the next branch only ('git fetch blah').
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net
On Tue, Nov 24, 2009 at 08:36:32AM -0600, Anthony Liguori wrote: Michael S. Tsirkin wrote: On Tue, Nov 24, 2009 at 08:54:23AM +1030, Rusty Russell wrote: On Tue, 24 Nov 2009 02:37:01 am Shirley Ma wrote: + skb = (struct sk_buff *)buf; This cast is unnecessary, but a comment would be nice: Without this cast there is a compile warning. Hi Shirley, Looks like buf is a void *, so no cast should be necessary. But I could be reading the patch wrong. However, I question whether making it 16 byte is the right thing: the ethernet header is 14 bytes long, so don't we want 8 bytes of padding? Because in QEMU it requires 10 bytes header in a separately, so one page is used to share between virtio_net_hdr header which is 10 bytes head and rest of data. So I put 6 bytes offset here between two buffers. I didn't look at the reason why a seperate buf is used for virtio_net_hdr in QEMU. It's a qemu bug. It insists the header be an element in the scatterlist by itself. Unfortunately we have to accommodate it. We do? Let's just fix this? So does lguest. It's been that way since the beginning. Fixing this would result in breaking older guests. The patch you are replying to fixes this in a way that does not break older guests. We really need to introduce a feature bit if we want to change this. -- MST -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net
On Tue, Nov 24, 2009 at 08:36:32AM -0600, Anthony Liguori wrote: Michael S. Tsirkin wrote: On Tue, Nov 24, 2009 at 08:54:23AM +1030, Rusty Russell wrote: On Tue, 24 Nov 2009 02:37:01 am Shirley Ma wrote: + skb = (struct sk_buff *)buf; This cast is unnecessary, but a comment would be nice: Without this cast there is a compile warning. Hi Shirley, Looks like buf is a void *, so no cast should be necessary. But I could be reading the patch wrong. However, I question whether making it 16 byte is the right thing: the ethernet header is 14 bytes long, so don't we want 8 bytes of padding? Because in QEMU it requires 10 bytes header in a separately, so one page is used to share between virtio_net_hdr header which is 10 bytes head and rest of data. So I put 6 bytes offset here between two buffers. I didn't look at the reason why a seperate buf is used for virtio_net_hdr in QEMU. It's a qemu bug. It insists the header be an element in the scatterlist by itself. Unfortunately we have to accommodate it. We do? Let's just fix this? So does lguest. It does? All I see it doing is writev/readv, and this passes things to tap which handles this correctly. It's been that way since the beginning. Fixing this would result in breaking older guests. If you look at my patch, it handles old guests just fine :). We really need to introduce a feature bit if we want to change this. I am not sure I agree: we can't add feature bits for all bugs, can we? -- MST -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The -next kernel no longer boots on kvm in 32bit mode
On 11/24/2009 04:58 PM, Alan Cox wrote: 64bit Intel host system Fedora host environment 32bit guest built with CPU i686 and no PAE support This now momentarily flickers up something then reboots back to the BIOS. Any chance of a bisect to find out where this was introduced? It's worth upgrading to at least F12 in case this is a kvm bug. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] qemu-kvm: x86: Add support for VCPU event states
On Sun, Nov 15, 2009 at 04:41:26PM +0100, Jan Kiszka wrote: Avi Kivity wrote: On 11/15/2009 05:02 PM, Jan Kiszka wrote: Where should I add /* next version to use: 13 */, and who will take care that this comment will also be kept up to date? The CPU vmstate is already ordered according to logical groups, just look at earlier field. Only recent KVM additions happened to create some version ordering as well. Er, now I'm confused. 11 and 12 indeed do already exist, so how can you update 11 retroactively? Oh, right, good that we discuss this. My patch dated back before the kvmclock addition, which IMHO incorrectly bumped the version numbers. I think the current policy in upstream is that we only increment once per qemu release, not per bit added. Shouldn't you create 13 now? No, I rather think Glauber's 12 should be downgraded to 11 - unless it misses the qemu merge windows for 0.12. My extensions definitely target that release, thus will likely carry 11 in upstream. And we should really try to avoid diverging again. Agree. Anthony, Are Glauber patches going to make it for 0.12, so we can revert current qemu-kvm's CPU_SAVE_VERSION from 12 to 11? Thanks. (and I meant: /* The above list is not sorted wrt version, watch out! */, but now I feel I'm missing something). Ok, can add such a note at the end. Jan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Defer skb allocation for both mergeable buffers and big packets in virtio_net
On Wed, 25 Nov 2009 01:06:32 am Anthony Liguori wrote: So does lguest. It's been that way since the beginning. Fixing this would result in breaking older guests. Agreed, we can't fix it in the guests, but it's a wart. That's why I haven't bothered fixing it, but if someone else wants to I'll cheer all the way. lguest did it because I knew I could fix lguest any time; it was a bad mistake and I will now fix lguest :) We really need to introduce a feature bit if we want to change this. I don't think it's worth it. But the spec does say that the implementation should not rely on the framing (I think there's a note that current implementations are buggy tho, so you should frame it separately anyway). That way future devices can get it right, at least. Thanks, Rusty. -- 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/2] Adds a test to verify resources inside a VM
This patch adds a test for verifying whether the number of cpus and amount
of memory as seen inside a guest is same as allocated to it on the qemu
command line.
Signed-off-by: Sudhir Kumar sku...@linux.vnet.ibm.com
Index: kvm/tests/verify_resources.py
===
--- /dev/null
+++ kvm/tests/verify_resources.py
@@ -0,0 +1,74 @@
+import logging, time
+from autotest_lib.client.common_lib import error
+import kvm_subprocess, kvm_test_utils, kvm_utils
+
+
+Test to verify if the guest has the equal amount of resources
+as allocated through the qemu command line
+
+...@copyright: 2009 IBM Corporation
+...@author: Sudhir Kumar sku...@linux.vnet.ibm.com
+
+
+
+def run_verify_resources(test, params, env):
+
+KVM test for verifying VM resources(#vcpu, memory):
+1) Get resources from the VM parameters
+2) Log into the guest
+3) Get actual resources, compare and report the pass/failure
+
+@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))
+
+# Get info about vcpu and memory from dictionary
+exp_vcpus = int(params.get(smp))
+exp_mem_mb = long(params.get(mem))
+real_vcpus = 0
+real_mem_kb = 0
+real_mem_mb = 0
+# Some memory is used by bios and all, so lower the expected
value say by 5%
+exp_mem_mb = long(exp_mem_mb * 0.95)
+logging.info(The guest should have vcpus: %s % exp_vcpus)
+logging.info(The guest should have min mem: %s MB % exp_mem_mb)
+
+session = kvm_test_utils.wait_for_login(vm)
+
+# Get info about vcpu and memory from within guest
+if params.get(guest_os_type) == Linux:
+output = session.get_command_output(cat /proc/cpuinfo|grep processor)
+for line in output.split('\n'):
+if 'processor' in line:
+real_vcpus = real_vcpus + 1
+
+output = session.get_command_output(cat /proc/meminfo)
+for line in output.split('\n'):
+if 'MemTotal' in line:
+real_mem_kb = long(line.split()[1])
+real_mem_mb = real_mem_kb / 1024
+
+elif params.get(guest_os_type) == Windows:
+# Windows takes long time to display output for systeminfo
+output = session.get_command_output(systeminfo, timeout =
150, internal_timeout = 50)
+for line in output.split('\n'):
+if 'Processor' in line:
+real_vcpus = int(line.split()[1])
+
+for line in output.split('\n'):
+if 'Total Physical Memory' in line:
+ real_mem_mb = long(.join(%s % k for k in
line.split()[3].split(',')))
+
+else:
+raise error.TestFail(Till date this test is supported only
for Linux and Windows)
+
+logging.info(The guest has cpus: %s % real_vcpus)
+logging.info(The guest has mem: %s MB % real_mem_mb)
+if exp_vcpus != real_vcpus or real_mem_mb exp_mem_mb:
+raise error.TestFail(Actual resources(cpu ='%s' memory ='%s' MB)
+ differ from Allocated resources(cpu = '%s' memory ='%s' MB
+ % (real_vcpus, real_mem_mb, exp_vcpus, exp_mem_mb))
+
+session.close()
Sending the patch as an attachment too. Please review and provide your comments.
--
Sudhir Kumar
This patch adds a test for verifying whether the number of cpus and amount
of memory as seen inside a guest is same as allocated to it on the qemu
command line.
Signed-off-by: Sudhir Kumar sku...@linux.vnet.ibm.com
Index: kvm/tests/verify_resources.py
===
--- /dev/null
+++ kvm/tests/verify_resources.py
@@ -0,0 +1,74 @@
+import logging, time
+from autotest_lib.client.common_lib import error
+import kvm_subprocess, kvm_test_utils, kvm_utils
+
+
+Test to verify if the guest has the equal amount of resources
+as allocated through the qemu command line
+
+...@copyright: 2009 IBM Corporation
+...@author: Sudhir Kumar sku...@linux.vnet.ibm.com
+
+
+
+def run_verify_resources(test, params, env):
+
+KVM test for verifying VM resources(#vcpu, memory):
+1) Get resources from the VM parameters
+2) Log into the guest
+3) Get actual resources, compare and report the pass/failure
+
+@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))
+
+# Get info about vcpu and memory from dictionary
+exp_vcpus = int(params.get(smp))
+exp_mem_mb = long(params.get(mem))
+real_vcpus = 0
+real_mem_kb = 0
+real_mem_mb = 0
+# Some memory is used by bios and all, so lower the expected value say by 5%
+exp_mem_mb = long(exp_mem_mb * 0.95)
+logging.info(The guest should have vcpus: %s % exp_vcpus)
+logging.info(The guest should have min mem: %s MB %
[PATCH 2/2] Edit kvm_tests.cfg.sample to include verify_resources test variant
This patch adds the variants for verify_resources test into the kvm_tests.cfg.sample file. Signed-off-by: Sudhir Kumar sku...@linux.vnet.ibm.com Index: kvm/kvm_tests.cfg.sample === --- kvm.orig/kvm_tests.cfg.sample +++ kvm/kvm_tests.cfg.sample @@ -243,6 +243,11 @@ variants: kill_vm = yes kill_vm_gracefully = no +- verify_resources: install setup unattended_install +type = verify_resources +guest_os_type = Linux +kill_vm_on_error = yes + # NICs variants: @@ -526,6 +531,7 @@ variants: # Windows section - @Windows: no autotest linux_s3 +guest_os_type = Windows shutdown_command = shutdown /s /t 0 reboot_command = shutdown /r /t 0 status_test_command = echo %errorlevel% -- Sudhir Kumar -- 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: guest gets stuck on the migration from AMD to Intel
Harald Dunkel wrote: Hi folks, If I migrate a virtual machine (2.6.31.6, amd64) from a host with AMD cpu to an Intel host, then the guest is terminated on the old host as expected, but it gets stuck on the new host. Every 60 seconds it prints a message on the virtual console saying BUG: soft lockup - CPU#0 got stuck for 61s! See http://bugzilla.kernel.org/show_bug.cgi?id=14687 Regards Harri -- 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] PPC: Sync guest visible MMU state
On 11/24/2009 09:50 AM, Alexander Graf wrote:
Currently userspace has no chance to find out which virtual address space we're
in and resolve addresses. While that is a big problem for migration, it's also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
index 92045a9..1240fcb 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -492,6 +492,7 @@ struct kvm_ioeventfd {
#ifdef __KVM_HAVE_VCPU_EVENTS
#define KVM_CAP_VCPU_EVENTS 41
#endif
+#define KVM_CAP_PPC_SEGSTATE 42
42 is already taken (s390 psw and D. Adams), please use 43.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PPC: Sync guest visible MMU state
On 24.11.2009, at 16:02, Avi Kivity wrote:
On 11/24/2009 09:50 AM, Alexander Graf wrote:
Currently userspace has no chance to find out which virtual address space
we're
in and resolve addresses. While that is a big problem for migration, it's
also
unpleasent when debugging, as gdb and the monitor don't work on virtual
addresses.
index 92045a9..1240fcb 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -492,6 +492,7 @@ struct kvm_ioeventfd {
#ifdef __KVM_HAVE_VCPU_EVENTS
#define KVM_CAP_VCPU_EVENTS 41
#endif
+#define KVM_CAP_PPC_SEGSTATE 42
42 is already taken (s390 psw and D. Adams), please use 43.
Aww. Any reason I didn't get the s390 patch in a git pull yet? (damn that
Carsten - he got the cool number)
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PPC: Sync guest visible MMU state
On 11/24/2009 05:04 PM, Alexander Graf wrote:
index 92045a9..1240fcb 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -492,6 +492,7 @@ struct kvm_ioeventfd {
#ifdef __KVM_HAVE_VCPU_EVENTS
#define KVM_CAP_VCPU_EVENTS 41
#endif
+#define KVM_CAP_PPC_SEGSTATE 42
42 is already taken (s390 psw and D. Adams), please use 43.
Aww. Any reason I didn't get the s390 patch in a git pull yet? (damn that
Carsten - he got the cool number)
It's in the next branch only ('git fetch blah').
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
