Menu
▾
▴
kvm-devel — kernel virtual machine development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(33) |
Nov
(325) |
Dec
(320) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(484) |
Feb
(438) |
Mar
(407) |
Apr
(713) |
May
(831) |
Jun
(806) |
Jul
(1023) |
Aug
(1184) |
Sep
(1118) |
Oct
(1461) |
Nov
(1224) |
Dec
(1042) |
| 2008 |
Jan
(1449) |
Feb
(1110) |
Mar
(1428) |
Apr
(1643) |
May
(682) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2008-05-07 12:14:45
|
Bugs item #1959452, was opened at 2008-05-07 20:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959452&group_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: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: XP crashes while rebooting Initial Comment: XP guests will crash while rebooting under the two situations below: 1. The XP guest was intalled with UP ("-smp 1") and booted with ("-smp 2"). (The system will require reboot.) 2. The XP guest was booted with "-smp 4", and then reboot the guest. Here is the error message: [root@vt-nhm1 root]# qemu-system-x86_64 -m 512 -smp 4 -net nic,macaddr=00:ab:3e:0f:be:74,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /media/root/xp-x86.img exception 13 (0) rax 0000000000000000 rbx 0000000000000000 rcx 0000000000000010 rdx 0000000000000000 rsi 0000000000000000 rdi 0000000000000000 rsp 0000000000000000 rbp 0000000000000000 r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000 rip 00000000000101d8 rflags 00033006 cs 1000 (00010000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr 0000 (fffbd000/00002088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt 0/ffff idt 0/ffff cr0 60000010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 3d f5 0f 00 00 0f 83 02 00 fe c2 66 59 66 5b 66 58 e9 42 fe --> bb 30 2f c1 eb 04 8c c8 03 c3 8e d0 bc 28 15 52 8e d8 8e c0 66 0f b7 d0 66 c1 e2 04 66 81 Aborted ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959452&group_id=180599 |
|
From: SourceForge.net <no...@so...> - 2008-05-07 12:08:58
|
Bugs item #1958467, was opened at 2008-05-06 14:36 Message generated for change (Comment added) made by yunfeng You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958467&group_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: Closed Resolution: None Priority: 5 Private: No Submitted By: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: Fail to save restore and live migrate on 32e platform Initial Comment: Environment: ------------ Host OS: RHEL5U1 ia32e Commits: 630741928b4a7eeff27e134d7ba7bc2fc2c764c5-77c9148ba4a89a8dc4ab2ecf525c2de8604ea8c3 Hardware:Platform Woodcrest CPU 4 Memory size 8G' Bug detailed description: -------------------------- Fail to save restore and live migrate on 32e platform. When restore the guest, the new qemu disappeared, host console print: qemu: warning: error while loading state for instance 0x0 of device 'cpu' Migration failed rc=215 Reproduce steps: ---------------- 1.use qcow based image to boot a guest: qemu-img create -b /share/xvs/img/app/ia32p_UP.img -f qcow2 /share/xvs/var/sr qemu-system-x86_64 -m 256 -monitor pty -net nic,macaddr=00:16:3e:35:1c:97,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/sr 2.ctrl+alt+2 switch to qemu monitor and save the guest migrate file:///share/xvs/var/sr123 3.restore qemu-system-x86_64 -m 256 -net nic,macaddr=00:16:3e:35:1c:97,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/sr -incoming file:///share/xvs/var/sr123 Current result: ---------------- Expected result: ---------------- ---------------------------------------------------------------------- >Comment By: yunfeng (yunfeng) Date: 2008-05-07 20:08 Message: Logged In: YES user_id=1283543 Originator: YES Has been fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958467&group_id=180599 |
|
From: SourceForge.net <no...@so...> - 2008-05-07 12:06:56
|
Bugs item #1959443, was opened at 2008-05-07 20:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959443&group_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: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: Fails to restore linux guests with virtio drivers Initial Comment: I tried to save/restore a rhel5u1 guest with virtio drivers. Save the guest is ok. But it failed when run restore. Here is the command I am using: [root@vt-nhm1 ~]# qemu-system-x86_64 -m 512 -smp 1 -net nic,macaddr=00:16:3e:0f:be:84,model=virtio -net tap,script=/etc/kvm/qemu-ifup -hda /root/ia32p_rhel5u1.img -drive file=/media/root/ia32p_suse10u2.img,if=virtio -incoming file://share/xvs/var/sr123 Migration failed rc=201 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1959443&group_id=180599 |
|
From: SourceForge.net <no...@so...> - 2008-05-07 12:04:00
|
Bugs item #1958519, was opened at 2008-05-06 16:05 Message generated for change (Comment added) made by yunfeng You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958519&group_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: Closed Resolution: None Priority: 5 Private: No Submitted By: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: fails to build KVM modules against 2.6.26 kernel Initial Comment: Building KVM modules against 2.6.24 kernel is ok. But building against 2.6.26 kernel will fail. make -j20 -C /lib/modules/2.6.26-rc1-02049-g6307419/build M=`pwd` \ LINUXINCLUDE="-I`pwd`/include -Iinclude -I`pwd`/include-compat \ -include include/linux/autoconf.h" \ "$@" make[1]: Entering directory `/root/kvm' Building modules, stage 2. MODPOST 3 modules WARNING: "kvm_div64_u64" [/root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm.ko] undefined! CC /root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm-amd.mod.o CC /root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm-intel.mod.o CC /root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm.mod.o In file included from <command line>:1: ./include/linux/autoconf.h:516:1: error: /external-module-compat.h: No such file or directory In file included from <command line>:1: ./include/linux/autoconf.h:516:1: error: /external-module-compat.h: No such file or directory In file included from <command line>:1: ./include/linux/autoconf.h:516:1: error: /external-module-compat.h: No such file or directory make[2]: *** [/root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm-intel.mod.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: *** [/root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm-amd.mod.o] Error 1 make[2]: *** [/root/kvm-master-2.6.22-rc4-20080506010222296/kvm-userspace/kernel/kvm.mod.o] Error 1 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/root/kvm' make: *** [all] Error 2 ---------------------------------------------------------------------- >Comment By: yunfeng (yunfeng) Date: 2008-05-07 20:03 Message: Logged In: YES user_id=1283543 Originator: YES Has been fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958519&group_id=180599 |
|
From: SourceForge.net <no...@so...> - 2008-05-07 12:03:37
|
Bugs item #1958464, was opened at 2008-05-06 14:34 Message generated for change (Settings changed) made by yunfeng You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958464&group_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: Closed Resolution: None Priority: 5 Private: No Submitted By: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: "Unknown symbol in module" loading kvm.ko Initial Comment: With today's commits, kvm.git 630741928b4a7eeff27e134d7ba7bc2fc2c764c5 and kvm-userspace.git 77c9148ba4a89a8dc4ab2ecf525c2de8604ea8c3. , I cannot insert PAE KVM modules. Lots of unknown symbols have been reported while inserting kvm.ko. error inserting '/usr/kvm/kvm.ko': -1 Unknown symbol in module dmesg: kvm_intel: Unknown symbol kvm_set_cr4 kvm_intel: Unknown symbol kvm_set_cr0 kvm_intel: Unknown symbol kvm_set_cr8 kvm_intel: Unknown symbol kvm_lapic_enabled kvm_intel: Unknown symbol kvm_mmu_page_fault kvm_intel: Unknown symbol kvm_mmu_reset_context kvm_intel: Unknown symbol kvm_queue_exception_e kvm_intel: Unknown symbol kvm_emulate_cpuid kvm_intel: Unknown symbol kvm_vcpu_init kvm_intel: Unknown symbol gfn_to_hva kvm_intel: Unknown symbol kvm_set_msr_common kvm_intel: Unknown symbol kvm_mmu_set_base_ptes kvm_intel: Unknown symbol kvm_cpu_get_interrupt kvm_intel: Unknown symbol kvm_emulate_pio kvm_intel: Unknown symbol kvm_mmu_set_mask_ptes kvm_intel: Unknown symbol kvm_is_error_hva kvm: Unknown symbol kvm_div64_u64 kvm: emulating preempt notifiers; do not benchmark on this machine loaded kvm module (kvm-67-2059-g9cebc1e) kvm: Unknown symbol kvm_div64_u64 ---------------------------------------------------------------------- >Comment By: yunfeng (yunfeng) Date: 2008-05-07 20:03 Message: Logged In: YES user_id=1283543 Originator: YES Has been fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958464&group_id=180599 |
|
From: Avi K. <av...@qu...> - 2008-05-07 11:13:01
|
Zhang, Xiantao wrote:
> Critical fix for kvm/ia64 build. Issue introduced by
> ea696f9cf37d8ab9236dd133ddb2727264f3add6.
>
> From: Xiantao Zhang <xia...@in...>
> Date: Wed, 7 May 2008 17:34:52 +0800
> Subject: [PATCH] KVM: kvm/ia-64: GVMM module shouldn't link the
> position-dependent objects.
>
> Create two files: memset.S and memcpy.S which just includes the files
> under arch/ia64/lib/{memset.S, memcpy.S} respectively.
>
>
Applied, thanks.
--
error compiling committee.c: too many arguments to function
|
|
From: Avi K. <av...@qu...> - 2008-05-07 11:07:34
|
Zhang, Xiantao wrote: > From: Xiantao Zhang <xia...@in...> > Date: Wed, 7 May 2008 17:37:32 +0800 > Subject: [PATCH] KVM: kvm/ia64 : Using self-defined kvm_fpreg strucutre > to replace > kernel's ia64_fpreg for avoiding conflicts with userspace headers. > Applied, thanks. -- error compiling committee.c: too many arguments to function |
|
From: James P. <jp...@bl...> - 2008-05-07 10:40:16
|
Hi, I compile my kernel with make O=/home/james/compile/linux-2.6.25.1 kvm detects this as the kernel directory. However when building in the "kernel" directory of the project it fails (it tries to include linux/compiler.h which is only in /usr/src/linux/..). This used to work but started breaking in kvm-61 onwards. I want to use kvm 61 but I don't want to dirty up my kernel source tree if I can help it. I tried appending the source directory to the include path with -I but this lead to another missing include (asm/types.h), then I added /usr/include to the path as well and .. well it just got worse. Thanks, James |
|
From: Zhang, X. <xia...@in...> - 2008-05-07 10:33:57
|
Critical fix for kvm/ia64 build. Issue introduced by
ea696f9cf37d8ab9236dd133ddb2727264f3add6.
From: Xiantao Zhang <xia...@in...>
Date: Wed, 7 May 2008 17:34:52 +0800
Subject: [PATCH] KVM: kvm/ia-64: GVMM module shouldn't link the
position-dependent objects.
Create two files: memset.S and memcpy.S which just includes the files
under arch/ia64/lib/{memset.S, memcpy.S} respectively.
Signed-off-by: Xiantao Zhang <xia...@in...>
---
arch/ia64/kvm/Makefile | 2 +-
arch/ia64/kvm/memcpy.S | 1 +
arch/ia64/kvm/memset.S | 1 +
3 files changed, 3 insertions(+), 1 deletions(-)
create mode 100644 arch/ia64/kvm/memcpy.S
create mode 100644 arch/ia64/kvm/memset.S
diff --git a/arch/ia64/kvm/Makefile b/arch/ia64/kvm/Makefile
index 5235339..d60c5c8 100644
--- a/arch/ia64/kvm/Makefile
+++ b/arch/ia64/kvm/Makefile
@@ -54,5 +54,5 @@ EXTRA_CFLAGS_vcpu.o += -mfixed-range=f2-f5,f12-f127
kvm-intel-objs = vmm.o vmm_ivt.o trampoline.o vcpu.o optvfault.o mmio.o
\
vtlb.o process.o
#Add link memcpy and memset to avoid possible structure assignment
error
-kvm-intel-objs += ../lib/memset.o ../lib/memcpy.o
+kvm-intel-objs += memcpy.o memset.o
obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
diff --git a/arch/ia64/kvm/memcpy.S b/arch/ia64/kvm/memcpy.S
new file mode 100644
index 0000000..c04cdbe
--- /dev/null
+++ b/arch/ia64/kvm/memcpy.S
@@ -0,0 +1 @@
+#include "../lib/memcpy.S"
diff --git a/arch/ia64/kvm/memset.S b/arch/ia64/kvm/memset.S
new file mode 100644
index 0000000..83c3066
--- /dev/null
+++ b/arch/ia64/kvm/memset.S
@@ -0,0 +1 @@
+#include "../lib/memset.S"
--
1.5.2
|
|
From: Zhang, X. <xia...@in...> - 2008-05-07 10:30:57
|
> One way would be to define a new kvm_ia64_fpreg and use that. Seems
> that the standard ia64_fpreg is unusable in userspace due to the issue
> you mentioned.
Better way. Attached the patch.
From: Xiantao Zhang <xia...@in...>
Date: Wed, 7 May 2008 17:37:32 +0800
Subject: [PATCH] KVM: kvm/ia64 : Using self-defined kvm_fpreg strucutre
to replace
kernel's ia64_fpreg for avoiding conflicts with userspace headers.
Signed-off-by: Xiantao Zhang <xia...@in...>
---
include/asm-ia64/kvm.h | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/include/asm-ia64/kvm.h b/include/asm-ia64/kvm.h
index eb2d355..a1da4c4 100644
--- a/include/asm-ia64/kvm.h
+++ b/include/asm-ia64/kvm.h
@@ -22,7 +22,6 @@
*/
#include <asm/types.h>
-#include <asm/fpu.h>
#include <linux/ioctl.h>
@@ -61,6 +60,13 @@ struct kvm_ioapic_state {
#define KVM_CONTEXT_SIZE 8*1024
+struct kvm_fpreg {
+ union {
+ unsigned long bits[2];
+ long double __dummy; /* force 16-byte alignment */
+ } u;
+};
+
union context {
/* 8K size */
char dummy[KVM_CONTEXT_SIZE];
@@ -77,7 +83,7 @@ union context {
unsigned long ibr[8];
unsigned long dbr[8];
unsigned long pkr[8];
- struct ia64_fpreg fr[128];
+ struct kvm_fpreg fr[128];
};
};
--
1.5.2
|
|
From: Avi K. <av...@qu...> - 2008-05-07 10:21:31
|
Alexander Graf wrote: > Hi, > > a patch recently introduced PCI device hotplugging. This added > pseudo-buses for every PCI slot, so that each device can be easily > ejected any time. The ACPI specification recommends the inclusion of a > _SUN entry in these though, to enable proper indexation of the slots. > Afaict Linux does not need this, but Darwin does. > > This patch adds the corresponding _SUN entries to the PCI slot > definitions. > Patch looks fine; only missing a signoff. -- error compiling committee.c: too many arguments to function |
|
From: Land <dar...@MA...> - 2008-05-07 10:21:20
|
Give us a click, and you will find your daily needs all at one website. http://www.mimichet.com/ |
|
From: Avi K. <av...@qu...> - 2008-05-07 10:20:51
|
Alexander Graf wrote:
> Hi,
>
> in the DSDT there are two different ways of defining, how an interrupt
> is supposed to be routed. Currently we are using the LNKA - LNKD
> method, which afaict is for legacy support.
> The other method is to directly tell the Operating System, which APIC
> pin the device is attached to. We can get that information from the
> very same entry, the LNKA to LNKD pseudo devices receive it.
>
> For now this does not give any obvious improvement. It does leave room
> for more advanced mappings, with several IOAPICs that can handle more
> devices separately. This might help when we have a lot of devices, as
> currently all devices sit on two interrupt lanes.
>
> More importantly (for me) though, is that Darwin enables the APIC mode
> unconditionally, so it won't easily run in legacy mode.
>
Please properly signoff on patches.
Also:
> + // PCI Slot 8
> + Package() {0x0008ffff, 0, 0, ARQ3},
> + Package() {0x0008ffff, 1, 0, ARQ0},
> + Package() {0x0008ffff, 2, 0, ARQ1},
> + Package() {0x0008ffff, 3, 0, ARQ2},
> +
> + // PCI Slot 9
> + Package() {0x0008ffff, 0, 0, ARQ0},
> + Package() {0x0008ffff, 1, 0, ARQ1},
> + Package() {0x0008ffff, 2, 0, ARQ2},
> + Package() {0x0008ffff, 3, 0, ARQ3},
> +
Slot 9 uses the same addresses as slot 8. Similarly for slot 25.
(found by Marcelo for the code which was the source for this copy-paste)
--
error compiling committee.c: too many arguments to function
|
|
From: Alexander G. <ag...@cs...> - 2008-05-07 09:48:51
|
Avi Kivity wrote: > Who's Dao? Do you mean Dan Phew I'm so really bad at remembering names, sorry about that. I was actually talking about Dan Kenigsberg, who apparently did patches to use the "new" cpuid interface some time ago. |
|
From: Avi K. <av...@qu...> - 2008-05-07 08:19:26
|
Alexander Graf wrote: > > On May 6, 2008, at 6:27 PM, Glauber Costa wrote: > >> qemu recently added support for 3dnow instructions. Because of >> that, 3dnow will be featured among cpuid bits. But this will >> break kvm in cpus that don't have those instructions (which includes >> my laptop). So we fixup our cpuid before exposing it to the guest. > > I actually don't see where the problem is here. As far as I read the > code, the CPUID feature function gets received from the host CPU and > bitwise ANDed with a bunch of features that are known to work. What's > wrong with that approach? Nothing. Note that "known to work" needs to be queried from the kernel, since userspace and the kernel are not guaranteed to match. > But I'm pretty sure Dao can tell us a lot more about this. Has there > been any progress in getting the new CPUID code in? I think I could > review this sometime soon. Who's Dao? Do you mean Dan? -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-05-07 08:15:06
|
Marcelo Tosatti wrote: > Slots 9 and 25 were using the identifier of the previous slot. > > Applied, thanks. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-05-07 08:13:41
|
Marcelo Tosatti wrote: > Otherwise hlt emulation fails if PIT is not injecting IRQ's. > Applied, thanks. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-05-07 08:13:01
|
Glauber Costa wrote: > qemu recently added support for 3dnow instructions. Because of > that, 3dnow will be featured among cpuid bits. But this will > break kvm in cpus that don't have those instructions (which includes > my laptop). So we fixup our cpuid before exposing it to the guest. > > I've already fixed this in userspace. In general I don't like silently modifying cpuid options in the kernel, since that means we cannot be confident as to what the cpuid the guest sees actually is, and so we can't be sure that migration will succeed. Instead, the preferred path is to query what cpuid bits the host support, pass that to the management app in order to compute the greatest common subset, and tell the kernel to use that set. nx is handled differently due to compatibility issues. In time we can remove the special handling. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-05-07 08:00:01
|
Zhang, Xiantao wrote:
>>> #include <asm/types.h>
>>> +
>>> +#ifdef __KERNEL__
>>> #include <asm/fpu.h>
>>> +#else
>>> +#include <signal.h>
>>> +#endif
>>>
>>>
>> Fishy. A kernel header including a userspace header?
>>
>> Maybe you need to include <linux/signal.h> unconditionally?
>>
> Hi, Avi
> You know, kvm.h is shared by userspace and kernel. But
> unfortunately, the usersapce header files have redefinition for one
> strucutre (structure ia64_fpreg) {One in asm/fpu.h and the other one in
> bits/sigcontext}, maybe a bug here.
> Therefore, if userspace code includes fpu.h and sigcontext.h in
> one source file, it will complain the redefinition. Do you have good
> idea to cope with this issue ?
One way would be to define a new kvm_ia64_fpreg and use that. Seems
that the standard ia64_fpreg is unusable in userspace due to the issue
you mentioned.
--
error compiling committee.c: too many arguments to function
|
|
From: Avi K. <av...@qu...> - 2008-05-07 07:56:34
|
Karl Rister wrote: > On Thursday 01 May 2008 7:16:53 pm Marcelo Tosatti wrote: > >> Does -no-kvm-irqchip or -no-kvm-pit makes a difference? If not, please >> grab kvm_stat --once output when that happens. >> > > Per some suggestions I have moved up to kvm-68 which is better, but still > having problems. Replicating the problem with only one guest spinning has > proven quite difficult, but attempting to boot a large smp guest can reliably > recreate the problem. Using -no-kvm-pit did not help the large guest > and -no-kvm-irqchip made it seize up even earlier with only 1 cpu spinning > instead of all of them. > > Can you try the many-uniprocessor-guests scenario, with each guest pinned to a cpu? taskset $(( 1 << (RANDOM % 32) )) qemu ... -- error compiling committee.c: too many arguments to function |
|
From: Zhang, X. <xia...@in...> - 2008-05-07 06:24:09
|
Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> Hi, Avi
>> This patch should go into RC1, otherwise it will block kvm/ia64
>> userspace build.
>>
>> diff --git a/include/asm-ia64/kvm.h b/include/asm-ia64/kvm.h index
>> eb2d355..62b5fad 100644 --- a/include/asm-ia64/kvm.h
>> +++ b/include/asm-ia64/kvm.h
>> @@ -22,7 +22,12 @@
>> */
>>
>> #include <asm/types.h>
>> +
>> +#ifdef __KERNEL__
>> #include <asm/fpu.h>
>> +#else
>> +#include <signal.h>
>> +#endif
>>
>
> Fishy. A kernel header including a userspace header?
>
> Maybe you need to include <linux/signal.h> unconditionally?
Hi, Avi
You know, kvm.h is shared by userspace and kernel. But
unfortunately, the usersapce header files have redefinition for one
strucutre (structure ia64_fpreg) {One in asm/fpu.h and the other one in
bits/sigcontext}, maybe a bug here.
Therefore, if userspace code includes fpu.h and sigcontext.h in
one source file, it will complain the redefinition. Do you have good
idea to cope with this issue ?
Xiantao
|
|
From: Guillaume T. <gui...@ex...> - 2008-05-07 05:57:13
|
On Tue, 06 May 2008 09:30:44 -0500 Anthony Liguori <an...@co...> wrote: > > 8.04 is not a good test-case. 7.10 is what you want to try. Oh yes you're right. I tried 8.04 because Balaji had problems to boot it with the patch. > The good news is, 7.10 appears to work! The bad news is that about 20% > of the time, it crashes and displays the following: > > kvm_run: failed entry, reason 5 > kvm_run returned -8 > > So something appears to be a bit buggy. Still, very good work! I can see the problem with openSuse10.3 too but no so often.... I'm looking for this issue. Thank you for the help, Regards, Guillaume |
|
From: Avi K. <av...@qu...> - 2008-05-07 05:51:12
|
Anthony Liguori wrote:
>> What should be done for unmodified guest where there is no PV driver in
>> the guest? Would a call to mlock() from
>> qemu/hw/pci-passthrough.c/add_pci_passthrough_device() a reasonable
>> thing to do?
>>
>>
>
> Yup. The idea is to ensure that the memory is always present, without
> necessarily taking a reference to it. This allows for memory reclaiming
> which should allow for things like NUMA page migration. We can't swap
> of course but that doesn't mean reclaimation isn't useful.
>
I don't think we can do page migration with VT-d. You need to be able
to detect whether the page has been changed by dma after you've copied
it but before you changed the pte, but VT-d doesn't allow that AFAICT.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
|
|
From: Anthony L. <an...@co...> - 2008-05-07 01:56:31
|
Kay, Allen M wrote: >> We have to ensure we don't swap KVM guest memory while using hardware >> pass-through, but AFAICT, we do not need to make the memory >> non-reclaimable As long as we reprogram the IOMMU with a new, valid, >> mapping everything should be fine. mlock() really gives us the right >> semantics. >> >> Semantically, a PV API that supports DMA window registration simply >> mlock()s the DMA regions on behalf of the guest. No special logic >> should be needed. >> >> > > What should be done for unmodified guest where there is no PV driver in > the guest? Would a call to mlock() from > qemu/hw/pci-passthrough.c/add_pci_passthrough_device() a reasonable > thing to do? > Yup. The idea is to ensure that the memory is always present, without necessarily taking a reference to it. This allows for memory reclaiming which should allow for things like NUMA page migration. We can't swap of course but that doesn't mean reclaimation isn't useful. Regards, Anthony Liguori > Allen > |
|
From: Kay, A. M <all...@in...> - 2008-05-07 00:47:07
|
>We have to ensure we don't swap KVM guest memory while using hardware >pass-through, but AFAICT, we do not need to make the memory >non-reclaimable As long as we reprogram the IOMMU with a new, valid, >mapping everything should be fine. mlock() really gives us the right >semantics. > >Semantically, a PV API that supports DMA window registration simply >mlock()s the DMA regions on behalf of the guest. No special logic >should be needed. > What should be done for unmodified guest where there is no PV driver in the guest? Would a call to mlock() from qemu/hw/pci-passthrough.c/add_pci_passthrough_device() a reasonable thing to do? Allen |
157 messages has been excluded from this view by a project administrator.
