Re: [kvm-devel] BUG_ON in mmu.c:436
Ryan Harper wrote: I've run into a nasty bug while trying to install a Linux guest using VMware Server inside a kvm guest (full dmesg attached and recreate instructions below bug). Can you reproduce this with AUDIT turned on (top of mmu.c)? AUDIT is very slow, so it's recommended to reduce guest memory as much as possible. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-44 release
Avi Kivity wrote: Farkas Levente wrote: Avi Kivity wrote: An important fix to guest smp (it boots now!), and a performance improvement on Intel hardware. I get about 5% boost on a kernel build. There's a new module parameter to kvm-intel.ko that can disable this mechanism, bypass_guest_pf. Load the module with bypass_guest_pf=0 to disable the optimization. It shouldn't be necessary to do that on current processors; it's mostly to protect kvm against changes in hardware since the patch uses reserved bits. make[1]: Entering directory `/usr/src/kernels/2.6.18-8.1.10.el5-x86_64' LD /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/built-in.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/svm.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/vmx.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/vmx-debug.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/kvm_main.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/mmu.o /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/mmu.c:1152: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'last_updated_pte_accessed' /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/mmu.c: In function 'kvm_mmu_pte_write': /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/mmu.c:1180: error: implicit declaration of function 'last_updated_pte_accessed' make[2]: *** [/home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/mmu.o] Error 1 make[1]: *** [_module_/home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel] Error 2 make[1]: Leaving directory `/usr/src/kernels/2.6.18-8.1.10.el5-x86_64' make: *** [all] Error 2 Try adding '#define bool _Bool' to kernel/external-module-compat.h, and let us know. I'll fix it for kvm-45. i just put after the #include linux/smp.h but it doesn't help. ps. anyway if you check my dail snapshot build you can see there is no build after 22th (probably because of this. anyway i see that the snapshot are generated at 0:30, but it which timezone? -- Levente Si vis pacem para bellum! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-44 release
Farkas Levente wrote: Avi Kivity wrote: Farkas Levente wrote: Avi Kivity wrote: An important fix to guest smp (it boots now!), and a performance improvement on Intel hardware. I get about 5% boost on a kernel build. There's a new module parameter to kvm-intel.ko that can disable this mechanism, bypass_guest_pf. Load the module with bypass_guest_pf=0 to disable the optimization. It shouldn't be necessary to do that on current processors; it's mostly to protect kvm against changes in hardware since the patch uses reserved bits. make[1]: Entering directory `/usr/src/kernels/2.6.18-8.1.10.el5-x86_64' LD /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/built-in.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/svm.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/vmx.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/vmx-debug.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/kvm_main.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/mmu.o /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/mmu.c:1152: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'last_updated_pte_accessed' /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/mmu.c: In function 'kvm_mmu_pte_write': /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/mmu.c:1180: error: implicit declaration of function 'last_updated_pte_accessed' make[2]: *** [/home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/mmu.o] Error 1 make[1]: *** [_module_/home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel] Error 2 make[1]: Leaving directory `/usr/src/kernels/2.6.18-8.1.10.el5-x86_64' make: *** [all] Error 2 Try adding '#define bool _Bool' to kernel/external-module-compat.h, and let us know. I'll fix it for kvm-45. i just put after the #include linux/smp.h but it doesn't help. That should have worked. How about '#define bool int'? ps. anyway if you check my dail snapshot build you can see there is no build after 22th (probably because of this. anyway i see that the snapshot are generated at 0:30, but it which timezone? IST (UTC+2) -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-44 release
Avi Kivity wrote: Farkas Levente wrote: Avi Kivity wrote: Farkas Levente wrote: Avi Kivity wrote: An important fix to guest smp (it boots now!), and a performance improvement on Intel hardware. I get about 5% boost on a kernel build. There's a new module parameter to kvm-intel.ko that can disable this mechanism, bypass_guest_pf. Load the module with bypass_guest_pf=0 to disable the optimization. It shouldn't be necessary to do that on current processors; it's mostly to protect kvm against changes in hardware since the patch uses reserved bits. make[1]: Entering directory `/usr/src/kernels/2.6.18-8.1.10.el5-x86_64' LD /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/built-in.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/svm.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/vmx.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/vmx-debug.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/kvm_main.o CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/mmu.o /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/mmu.c:1152: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'last_updated_pte_accessed' /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/mmu.c: In function 'kvm_mmu_pte_write': /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/mmu.c:1180: error: implicit declaration of function 'last_updated_pte_accessed' make[2]: *** [/home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/mmu.o] Error 1 make[1]: *** [_module_/home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel] Error 2 make[1]: Leaving directory `/usr/src/kernels/2.6.18-8.1.10.el5-x86_64' make: *** [all] Error 2 Try adding '#define bool _Bool' to kernel/external-module-compat.h, and let us know. I'll fix it for kvm-45. i just put after the #include linux/smp.h but it doesn't help. That should have worked. How about '#define bool int'? with _Bool: CC [M] /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/vmx.o /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/vmx.c:39: error: expected ')' before '' token /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/vmx.c:39: error: 'param_set__Bool' undeclared here (not in a function) /home/robot/rpm/BUILD/kvm-kmod-44/_kmod_build_/kernel/vmx.c:39: error: 'param_get__Bool' undeclared here (not in a function) with int it's working -- Levente Si vis pacem para bellum! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 3/3] Remove no_wb, use dst.type = OP_NONE instead, idea stollen from xen-3.1
Remove no_wb, use dst.type = OP_NONE instead, idea stollen from xen-3.1
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
drivers/kvm/x86_emulate.c | 76 ++--
drivers/kvm/x86_emulate.h |2 +-
2 files changed, 25 insertions(+), 53 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index d1dec3e..14160f0 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -1005,8 +1005,7 @@ done:
}
static inline int emulate_grp45(struct x86_emulate_ctxt *ctxt,
- struct x86_emulate_ops *ops,
- int *no_wb)
+ struct x86_emulate_ops *ops)
{
struct decode_cache *c = ctxt-decode;
int rc;
@@ -1044,7 +1043,7 @@ static inline int emulate_grp45(struct x86_emulate_ctxt
*ctxt,
c-dst.bytes, ctxt-vcpu);
if (rc != 0)
return rc;
- *no_wb = 1;
+ c-dst.type = OP_NONE;
break;
default:
DPRINTF(Cannot emulate %02x\n, c-b);
@@ -1126,6 +1125,10 @@ static inline int writeback(struct x86_emulate_ctxt
*ctxt,
ctxt-vcpu);
if (rc != 0)
return rc;
+ break;
+ case OP_NONE:
+ /* no writeback */
+ break;
default:
break;
}
@@ -1136,7 +1139,6 @@ int
x86_emulate_insn(struct x86_emulate_ctxt *ctxt, struct x86_emulate_ops *ops)
{
unsigned long cr2 = ctxt-cr2;
- int no_wb = 0;
u64 msr_data;
unsigned long saved_rcx = 0, saved_eip = 0;
struct decode_cache *c = ctxt-decode;
@@ -1330,18 +1332,16 @@ x86_emulate_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
goto done;
break;
case 0xfe ... 0xff: /* Grp4/Grp5 */
- rc = emulate_grp45(ctxt, ops, no_wb);
+ rc = emulate_grp45(ctxt, ops);
if (rc != 0)
goto done;
break;
}
writeback:
- if (!no_wb) {
- rc = writeback(ctxt, ops);
- if (rc != 0)
- goto done;
- }
+ rc = writeback(ctxt, ops);
+ if (rc != 0)
+ goto done;
/* Commit shadow register state. */
memcpy(ctxt-vcpu-regs, c-regs, sizeof c-regs);
@@ -1382,7 +1382,7 @@ special_insn:
register_address_increment(c-regs[VCPU_REGS_RSP],
c-op_bytes);
- no_wb = 1; /* Disable writeback. */
+ c-dst.type = OP_NONE; /* Disable writeback. */
break;
case 0x6c: /* insb */
case 0x6d: /* insw/insd */
@@ -1527,7 +1527,7 @@ special_insn:
case 0xe9: /* jmp rel */
case 0xeb: /* jmp rel short */
JMP_REL(c-src.val);
- no_wb = 1; /* Disable writeback. */
+ c-dst.type = OP_NONE; /* Disable writeback. */
break;
@@ -1537,8 +1537,6 @@ special_insn:
twobyte_insn:
switch (c-b) {
case 0x01: /* lgdt, lidt, lmsw */
- /* Disable writeback. */
- no_wb = 1;
switch (c-modrm_reg) {
u16 size;
unsigned long address;
@@ -1593,56 +1591,30 @@ twobyte_insn:
default:
goto cannot_emulate;
}
+ /* Disable writeback. */
+ c-dst.type = OP_NONE;
break;
case 0x21: /* mov from dr to reg */
- no_wb = 1;
if (c-modrm_mod != 3)
goto cannot_emulate;
rc = emulator_get_dr(ctxt, c-modrm_reg, c-regs[c-modrm_rm]);
+ if (rc)
+ goto cannot_emulate;
+ c-dst.type = OP_NONE; /* no writeback */
break;
case 0x23: /* mov from reg to dr */
- no_wb = 1;
if (c-modrm_mod != 3)
goto cannot_emulate;
rc = emulator_set_dr(ctxt, c-modrm_reg,
c-regs[c-modrm_rm]);
+ if (rc)
+ goto cannot_emulate;
+ c-dst.type = OP_NONE; /* no writeback */
break;
case 0x40 ... 0x4f: /* cmov */
c-dst.val = c-dst.orig_val = c-src.val;
- no_wb = 1;
- /*
-* First, assume we're decoding an even cmov opcode
-* (lsb == 0).
-*/
- switch ((c-b 15) 1) {
- case 0: /* cmovo */
- no_wb = (ctxt-eflags EFLG_OF) ? 0 : 1;
- break;
- case 1:
[kvm-devel] [PATCH 1/3] move grp decoding into functions to make x86_emulate_insn() clearer
To improve readability, move push, writeback, and grp 1a/2/3/4/5/9 emulation
parts into functions.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
drivers/kvm/x86_emulate.c | 451 ++--
1 files changed, 266 insertions(+), 185 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index f294a49..64e8e03 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -896,6 +896,244 @@ done:
return (rc == X86EMUL_UNHANDLEABLE) ? -1 : 0;
}
+static inline void emulate_push(struct x86_emulate_ctxt *ctxt)
+{
+ struct decode_cache *c = ctxt-decode;
+
+ c-dst.type = OP_MEM;
+ c-dst.bytes = c-op_bytes;
+ c-dst.val = c-src.val;
+ register_address_increment(c-regs[VCPU_REGS_RSP], -c-op_bytes);
+ c-dst.ptr = (void *) register_address(ctxt-ss_base,
+ c-regs[VCPU_REGS_RSP]);
+}
+
+static inline int emulate_grp1a(struct x86_emulate_ctxt *ctxt,
+ struct x86_emulate_ops *ops)
+{
+ struct decode_cache *c = ctxt-decode;
+ int rc;
+
+ /* 64-bit mode: POP always pops a 64-bit operand. */
+
+ if (ctxt-mode == X86EMUL_MODE_PROT64)
+ c-dst.bytes = 8;
+
+ rc = ops-read_std(register_address(ctxt-ss_base,
+ c-regs[VCPU_REGS_RSP]),
+ c-dst.val, c-dst.bytes, ctxt-vcpu);
+ if (rc != 0)
+ return rc;
+
+ register_address_increment(c-regs[VCPU_REGS_RSP], c-dst.bytes);
+
+ return 0;
+}
+
+static inline void emulate_grp2(struct decode_cache *c, unsigned long *_eflags)
+{
+ switch (c-modrm_reg) {
+ case 0: /* rol */
+ emulate_2op_SrcB(rol, c-src, c-dst, *_eflags);
+ break;
+ case 1: /* ror */
+ emulate_2op_SrcB(ror, c-src, c-dst, *_eflags);
+ break;
+ case 2: /* rcl */
+ emulate_2op_SrcB(rcl, c-src, c-dst, *_eflags);
+ break;
+ case 3: /* rcr */
+ emulate_2op_SrcB(rcr, c-src, c-dst, *_eflags);
+ break;
+ case 4: /* sal/shl */
+ case 6: /* sal/shl */
+ emulate_2op_SrcB(sal, c-src, c-dst, *_eflags);
+ break;
+ case 5: /* shr */
+ emulate_2op_SrcB(shr, c-src, c-dst, *_eflags);
+ break;
+ case 7: /* sar */
+ emulate_2op_SrcB(sar, c-src, c-dst, *_eflags);
+ break;
+ }
+}
+
+static inline int emulate_grp3(struct x86_emulate_ctxt *ctxt,
+ struct x86_emulate_ops *ops,
+ unsigned long *_eflags)
+{
+ struct decode_cache *c = ctxt-decode;
+ int rc = 0;
+
+ switch (c-modrm_reg) {
+ case 0 ... 1: /* test */
+ /*
+* Special case in Grp3: test has an immediate
+* source operand.
+*/
+ c-src.type = OP_IMM;
+ c-src.ptr = (unsigned long *)c-eip;
+ c-src.bytes = (c-d ByteOp) ? 1 : c-op_bytes;
+ if (c-src.bytes == 8)
+ c-src.bytes = 4;
+ switch (c-src.bytes) {
+ case 1:
+ c-src.val = insn_fetch(s8, 1, c-eip);
+ break;
+ case 2:
+ c-src.val = insn_fetch(s16, 2, c-eip);
+ break;
+ case 4:
+ c-src.val = insn_fetch(s32, 4, c-eip);
+ break;
+ }
+ emulate_2op_SrcV(test, c-src, c-dst, *_eflags);
+ break;
+ case 2: /* not */
+ c-dst.val = ~c-dst.val;
+ break;
+ case 3: /* neg */
+ emulate_1op(neg, c-dst, *_eflags);
+ break;
+ default:
+ DPRINTF(Cannot emulate %02x\n, c-b);
+ rc = X86EMUL_UNHANDLEABLE;
+ break;
+ }
+done:
+ return rc;
+}
+
+static inline int emulate_grp45(struct x86_emulate_ctxt *ctxt,
+ struct x86_emulate_ops *ops,
+ unsigned long *_eflags,
+ int *no_wb)
+{
+ struct decode_cache *c = ctxt-decode;
+ int rc;
+
+ switch (c-modrm_reg) {
+ case 0: /* inc */
+ emulate_1op(inc, c-dst, *_eflags);
+ break;
+ case 1: /* dec */
+ emulate_1op(dec, c-dst, *_eflags);
+ break;
+ case 4: /* jmp abs */
+ if (c-b == 0xff)
+ c-eip = c-dst.val;
+ else {
+ DPRINTF(Cannot emulate %02x\n, c-b);
+ return X86EMUL_UNHANDLEABLE;
+ }
+ break;
+ case 6: /* push */
+
+ /* 64-bit mode: PUSH always
[kvm-devel] [PATCH 0/3] Make some cleanup in x86_emulate.c
This patch series makes some cleanups in x86_emulate.c [PATCH 1/3] move some parts of x86_decode_insn() into functions. [PATCH 2/3] remove _eflags and use directly ctxt-eflags [PATCH 3/3] remove no_wb It has been rebased to current master. Signed-off-by: Laurent Vivier [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2/3] remove _eflags and use directly ctxt-eflags.
Remove _eflags and use directly ctxt-eflags. Caching eflags is not needed as
it is restored to vcpu by kvm_main.c:emulate_instruction() from ctxt-eflags
only if emulation doesn't fail.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
drivers/kvm/x86_emulate.c | 121 ++---
1 files changed, 59 insertions(+), 62 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 64e8e03..d1dec3e 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -930,37 +930,37 @@ static inline int emulate_grp1a(struct x86_emulate_ctxt
*ctxt,
return 0;
}
-static inline void emulate_grp2(struct decode_cache *c, unsigned long *_eflags)
+static inline void emulate_grp2(struct x86_emulate_ctxt *ctxt)
{
+ struct decode_cache *c = ctxt-decode;
switch (c-modrm_reg) {
case 0: /* rol */
- emulate_2op_SrcB(rol, c-src, c-dst, *_eflags);
+ emulate_2op_SrcB(rol, c-src, c-dst, ctxt-eflags);
break;
case 1: /* ror */
- emulate_2op_SrcB(ror, c-src, c-dst, *_eflags);
+ emulate_2op_SrcB(ror, c-src, c-dst, ctxt-eflags);
break;
case 2: /* rcl */
- emulate_2op_SrcB(rcl, c-src, c-dst, *_eflags);
+ emulate_2op_SrcB(rcl, c-src, c-dst, ctxt-eflags);
break;
case 3: /* rcr */
- emulate_2op_SrcB(rcr, c-src, c-dst, *_eflags);
+ emulate_2op_SrcB(rcr, c-src, c-dst, ctxt-eflags);
break;
case 4: /* sal/shl */
case 6: /* sal/shl */
- emulate_2op_SrcB(sal, c-src, c-dst, *_eflags);
+ emulate_2op_SrcB(sal, c-src, c-dst, ctxt-eflags);
break;
case 5: /* shr */
- emulate_2op_SrcB(shr, c-src, c-dst, *_eflags);
+ emulate_2op_SrcB(shr, c-src, c-dst, ctxt-eflags);
break;
case 7: /* sar */
- emulate_2op_SrcB(sar, c-src, c-dst, *_eflags);
+ emulate_2op_SrcB(sar, c-src, c-dst, ctxt-eflags);
break;
}
}
static inline int emulate_grp3(struct x86_emulate_ctxt *ctxt,
- struct x86_emulate_ops *ops,
- unsigned long *_eflags)
+ struct x86_emulate_ops *ops)
{
struct decode_cache *c = ctxt-decode;
int rc = 0;
@@ -987,13 +987,13 @@ static inline int emulate_grp3(struct x86_emulate_ctxt
*ctxt,
c-src.val = insn_fetch(s32, 4, c-eip);
break;
}
- emulate_2op_SrcV(test, c-src, c-dst, *_eflags);
+ emulate_2op_SrcV(test, c-src, c-dst, ctxt-eflags);
break;
case 2: /* not */
c-dst.val = ~c-dst.val;
break;
case 3: /* neg */
- emulate_1op(neg, c-dst, *_eflags);
+ emulate_1op(neg, c-dst, ctxt-eflags);
break;
default:
DPRINTF(Cannot emulate %02x\n, c-b);
@@ -1006,7 +1006,6 @@ done:
static inline int emulate_grp45(struct x86_emulate_ctxt *ctxt,
struct x86_emulate_ops *ops,
- unsigned long *_eflags,
int *no_wb)
{
struct decode_cache *c = ctxt-decode;
@@ -1014,10 +1013,10 @@ static inline int emulate_grp45(struct x86_emulate_ctxt
*ctxt,
switch (c-modrm_reg) {
case 0: /* inc */
- emulate_1op(inc, c-dst, *_eflags);
+ emulate_1op(inc, c-dst, ctxt-eflags);
break;
case 1: /* dec */
- emulate_1op(dec, c-dst, *_eflags);
+ emulate_1op(dec, c-dst, ctxt-eflags);
break;
case 4: /* jmp abs */
if (c-b == 0xff)
@@ -1056,7 +1055,6 @@ static inline int emulate_grp45(struct x86_emulate_ctxt
*ctxt,
static inline int emulate_grp9(struct x86_emulate_ctxt *ctxt,
struct x86_emulate_ops *ops,
- unsigned long *_eflags,
unsigned long cr2)
{
struct decode_cache *c = ctxt-decode;
@@ -1072,7 +1070,7 @@ static inline int emulate_grp9(struct x86_emulate_ctxt
*ctxt,
c-regs[VCPU_REGS_RAX] = (u32) (old 0);
c-regs[VCPU_REGS_RDX] = (u32) (old 32);
- *_eflags = ~EFLG_ZF;
+ ctxt-eflags = ~EFLG_ZF;
} else {
new = ((u64)c-regs[VCPU_REGS_RCX] 32) |
@@ -1081,7 +1079,7 @@ static inline int emulate_grp9(struct x86_emulate_ctxt
*ctxt,
rc = ops-cmpxchg_emulated(cr2, old, new, 8, ctxt-vcpu);
if (rc != 0)
return rc;
- *_eflags |= EFLG_ZF;
+ ctxt-eflags |= EFLG_ZF;
}
return 0;
}
@@ -1141,7 +1139,6 @@
[kvm-devel] [PATCH 0/3] virtio implementation (draft VI)
I'm not reposting the drivers this time since they haven't changed significantly. See http://lguest.ozlabs.org/patches for the whole thing, from new-io.patch onwards). Changes since last version: - Switch to our own bus implementation, rather than relying on an implementation-specific bus to back this up. - Make virtio_config_ops much higher-level, don't assume layout of config space. - Expose struct virtqueue again and move ops inside that. - virtio_ring uses 64 bit address, 32 bit length, not addr64 + offset16 + len16. - flags in virtio_ring to allow suppression of interrupts (by guest) or notifications (by host). I'm not too unhappy with this as it stands. Feedback welcome! Cheers, Rusty. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/3] virtio interface
This attempts to implement a virtual I/O layer which should allow
common drivers to be efficiently used across most virtual I/O
mechanisms. It will no-doubt need further enhancement.
The virtio drivers add buffers to virtio queues; as the buffers are consumed
the driver interrupt callbacks are invoked.
There is also a generic implementation of config space which drivers can query
to get setup information from the host.
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
---
drivers/Kconfig |2
drivers/Makefile|1
drivers/virtio/Kconfig |3
drivers/virtio/Makefile |1
drivers/virtio/config.c | 13 ++
drivers/virtio/virtio.c | 187 +++
include/linux/mod_devicetable.h |6 +
include/linux/virtio.h | 110 ++
include/linux/virtio_config.h | 111 +++
9 files changed, 434 insertions(+)
===
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -87,4 +87,6 @@ source drivers/kvm/Kconfig
source drivers/kvm/Kconfig
source drivers/uio/Kconfig
+
+source drivers/virtio/Kconfig
endmenu
===
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -88,3 +88,4 @@ obj-$(CONFIG_HID) += hid/
obj-$(CONFIG_HID) += hid/
obj-$(CONFIG_PPC_PS3) += ps3/
obj-$(CONFIG_OF) += of/
+obj-$(CONFIG_VIRTIO) += virtio/
===
--- /dev/null
+++ b/drivers/virtio/Kconfig
@@ -0,0 +1,3 @@
+# Virtio always gets selected by whoever wants it.
+config VIRTIO
+ bool
===
--- /dev/null
+++ b/drivers/virtio/Makefile
@@ -0,0 +1,1 @@
+obj-$(CONFIG_VIRTIO) += virtio.o
===
--- /dev/null
+++ b/drivers/virtio/config.c
@@ -0,0 +1,13 @@
+/* Configuration space parsing helpers for virtio.
+ *
+ * The configuration is [type][len][... len bytes ...] fields.
+ *
+ * Copyright 2007 Rusty Russell, IBM Corporation.
+ * GPL v2 or later.
+ */
+#include linux/err.h
+#include linux/virtio.h
+#include linux/virtio_config.h
+#include linux/bug.h
+#include asm/system.h
+
===
--- /dev/null
+++ b/drivers/virtio/virtio.c
@@ -0,0 +1,187 @@
+#include linux/virtio.h
+#include linux/spinlock.h
+#include linux/virtio_config.h
+
+static ssize_t device_show(struct device *_d,
+ struct device_attribute *attr, char *buf)
+{
+ struct virtio_device *dev = container_of(_d,struct virtio_device,dev);
+ return sprintf(buf, %hu, dev-id.device);
+}
+static ssize_t vendor_show(struct device *_d,
+ struct device_attribute *attr, char *buf)
+{
+ struct virtio_device *dev = container_of(_d,struct virtio_device,dev);
+ return sprintf(buf, %hu, dev-id.vendor);
+}
+static ssize_t status_show(struct device *_d,
+ struct device_attribute *attr, char *buf)
+{
+ struct virtio_device *dev = container_of(_d,struct virtio_device,dev);
+ return sprintf(buf, 0x%08x, dev-config-get_status(dev));
+}
+static struct device_attribute virtio_dev_attrs[] = {
+ __ATTR_RO(device),
+ __ATTR_RO(vendor),
+ __ATTR_RO(status),
+ __ATTR_NULL
+};
+
+static inline int virtio_id_match(const struct virtio_device *dev,
+ const struct virtio_device_id *id)
+{
+ if (id-device != dev-id.device)
+ return 0;
+
+ return id-vendor == VIRTIO_DEV_ANY_ID || id-vendor != dev-id.vendor;
+}
+
+/* This looks through all the IDs a driver claims to support. If any of them
+ * match, we return 1 and the kernel will call virtio_dev_probe(). */
+static int virtio_dev_match(struct device *_dv, struct device_driver *_dr)
+{
+ unsigned int i;
+ struct virtio_device *dev = container_of(_dv,struct virtio_device,dev);
+ const struct virtio_device_id *ids;
+
+ ids = container_of(_dr, struct virtio_driver, driver)-id_table;
+ for (i = 0; ids[i].device; i++)
+ if (virtio_id_match(dev, ids[i]))
+ return 1;
+ return 0;
+}
+
+struct virtio_bus {
+ struct bus_type bus;
+ struct device dev;
+};
+
+static struct virtio_bus virtio_bus = {
+ .bus = {
+ .name = virtio,
+ .match = virtio_dev_match,
+ .dev_attrs = virtio_dev_attrs,
+ },
+ .dev = {
+ /* Can override this if you have a real bus behind it. */
+ .parent = NULL,
+ .bus_id = virtio,
+ }
+};
+
+static void add_status(struct virtio_device *dev, unsigned status)
+{
+ dev-config-set_status(dev, dev-config-get_status(dev)
[kvm-devel] [PATCH 2/3] virtio ring implementation
These helper routines supply most of the virtqueue_ops for hypervisors
which want to use a ring for virtio. Unlike the previous lguest
implementation:
1) The rings are variable sized (2^n-1 elements).
2) They have an unfortunate limit of 65535 bytes per sg element.
3) The page numbers are always 64 bit (PAE anyone?)
4) They no longer place used[] on a separate page, just a separate
cacheline.
5) We do a modulo on a variable. We could be tricky if we cared.
6) Interrupts and notifies are suppressed using flags within the rings.
Users need only implement the new_vq and free_vq hooks (KVM wants the
guest to allocate the rings, lguest does it sanely).
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
---
arch/i386/lguest/Kconfig |1
drivers/virtio/Kconfig |5
drivers/virtio/Makefile |1
drivers/virtio/virtio_ring.c | 316 ++
include/linux/virtio_ring.h | 119 +++
5 files changed, 442 insertions(+)
===
--- a/arch/i386/lguest/Kconfig
+++ b/arch/i386/lguest/Kconfig
@@ -2,6 +2,7 @@ config LGUEST_GUEST
bool Lguest guest support
select PARAVIRT
depends on !X86_PAE
+ select VIRTIO_RING
help
Lguest is a tiny in-kernel hypervisor. Selecting this will
allow your kernel to boot under lguest. This option will increase
===
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -1,3 +1,8 @@
# Virtio always gets selected by whoever wants it.
config VIRTIO
bool
+
+# Similarly the virtio ring implementation.
+config VIRTIO_RING
+ bool
+ depends on VIRTIO
===
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -1,1 +1,2 @@ obj-$(CONFIG_VIRTIO) += virtio.o
obj-$(CONFIG_VIRTIO) += virtio.o
+obj-$(CONFIG_VIRTIO_RING) += virtio_ring.o
===
--- /dev/null
+++ b/drivers/virtio/virtio_ring.c
@@ -0,0 +1,316 @@
+/* Virtio ring implementation.
+ *
+ * Copyright 2007 Rusty Russell IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+#include linux/virtio.h
+#include linux/virtio_ring.h
+#include linux/device.h
+
+#ifdef DEBUG
+/* For development, we want to crash whenever the ring is screwed. */
+#define BAD_RING(vq, fmt...) \
+ do { dev_err(vq-vq.vdev-dev, fmt); BUG(); } while(0)
+#define START_USE(vq) \
+ do { if ((vq)-in_use) panic(in_use = %i\n, (vq)-in_use);
(vq)-in_use = __LINE__; mb(); } while(0)
+#define END_USE(vq) \
+ do { BUG_ON(!(vq)-in_use); (vq)-in_use = 0; mb(); } while(0)
+#else
+#define BAD_RING(vq, fmt...) \
+ do { dev_err(vq-vq.vdev-dev, fmt); (vq)-broken = true; } while(0)
+#define START_USE(vq)
+#define END_USE(vq)
+#endif
+
+struct vring_virtqueue
+{
+ struct virtqueue vq;
+
+ /* Actual memory layout for this queue */
+ struct vring vring;
+
+ /* Other side has made a mess, don't try any more. */
+ bool broken;
+
+ /* Number of free buffers */
+ unsigned int num_free;
+ /* Head of free buffer list. */
+ unsigned int free_head;
+ /* Number we've added since last sync. */
+ unsigned int num_added;
+
+ /* Last used index we've seen. */
+ unsigned int last_used_idx;
+
+ /* How to notify other side. FIXME: commonalize hcalls! */
+ void (*notify)(struct virtqueue *vq);
+
+#ifdef DEBUG
+ /* They're supposed to lock for us. */
+ unsigned int in_use;
+#endif
+
+ /* Tokens for callbacks. */
+ void *data[];
+};
+
+#define to_vvq(_vq) container_of(_vq, struct vring_virtqueue, vq)
+
+static int vring_add_buf(struct virtqueue *_vq,
+struct scatterlist sg[],
+unsigned int out,
+unsigned int in,
+void *data)
+{
+ struct vring_virtqueue *vq = to_vvq(_vq);
+ unsigned int i, avail, head, uninitialized_var(prev);
+
+ BUG_ON(data == NULL);
+ BUG_ON(out + in vq-vring.num);
+ BUG_ON(out + in == 0);
+
+
[kvm-devel] [PATCH 3/3] virtio module alias support
This adds the logic to convert the virtio ids into module aliases, and
includes a modalias entry in sysfs.
Unfortunately this does not seem sufficient to have the module
autoprobed at startup on my Ubuntu system. Greg? Am I missing some
udev magic?
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
---
drivers/virtio/virtio.c |9 +
scripts/mod/file2alias.c | 18 ++
2 files changed, 27 insertions(+)
===
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -20,10 +20,19 @@ static ssize_t status_show(struct device
struct virtio_device *dev = container_of(_d,struct virtio_device,dev);
return sprintf(buf, 0x%08x, dev-config-get_status(dev));
}
+static ssize_t modalias_show(struct device *_d,
+struct device_attribute *attr, char *buf)
+{
+ struct virtio_device *dev = container_of(_d,struct virtio_device,dev);
+
+ return sprintf(buf, virtio:d%08Xv%08X\n,
+ dev-id.device, dev-id.vendor);
+}
static struct device_attribute virtio_dev_attrs[] = {
__ATTR_RO(device),
__ATTR_RO(vendor),
__ATTR_RO(status),
+ __ATTR_RO(modalias),
__ATTR_NULL
};
===
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -484,6 +484,20 @@ static int do_parisc_entry(const char *f
return 1;
}
+/* Looks like: virtio:dNvN */
+static int do_virtio_entry(const char *filename, struct virtio_device_id *id,
+ char *alias)
+{
+ id-device = TO_NATIVE(id-device);
+ id-vendor = TO_NATIVE(id-vendor);
+
+ strcpy(alias, virtio:);
+ ADD(alias, d, 1, id-device);
+ ADD(alias, v, id-vendor != VIRTIO_DEV_ANY_ID, id-vendor);
+
+ return 1;
+}
+
/* Ignore any prefix, eg. v850 prepends _ */
static inline int sym_is(const char *symbol, const char *name)
{
@@ -599,6 +613,10 @@ void handle_moddevtable(struct module *m
do_table(symval, sym-st_size,
sizeof(struct parisc_device_id), parisc,
do_parisc_entry, mod);
+ else if (sym_is(symname, __mod_virtio_device_table))
+ do_table(symval, sym-st_size,
+sizeof(struct virtio_device_id), virtio,
+do_virtio_entry, mod);
}
/* Now add out buffered information to the generated C source */
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-43 release
Avi Kivity wrote: You can call kvm_disable_irqchip_creation() to kill in-kernel pic and friends. (the logic is inverted -- the function should be kvm_enable_irqchip_creation() so that this problem would not occur) Ok, will try, next question first though as I'm running in trouble much earlier in -44: I get suspious page faults. I *think* it happens because I'm changing guest page tables from outside (i.e. host application), and the new intel pgtable optimization bits don't expect that (yes, it is a vt box). A quick scan of kvmctl.h doesn't show anything which looks like I could call to tell kvm the guest page tables have been modified. Hints how to handle this? thanks, Gerd - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-43 release
Gerd Hoffmann wrote: Avi Kivity wrote: You can call kvm_disable_irqchip_creation() to kill in-kernel pic and friends. (the logic is inverted -- the function should be kvm_enable_irqchip_creation() so that this problem would not occur) Ok, will try, next question first though as I'm running in trouble much earlier in -44: I get suspious page faults. I *think* it happens because I'm changing guest page tables from outside (i.e. host application), and the new intel pgtable optimization bits don't expect that (yes, it is a vt box). Well, the older implementation doesn't expect that either. You can disable the optimization with bypass_guest_pf=0, though. A quick scan of kvmctl.h doesn't show anything which looks like I could call to tell kvm the guest page tables have been modified. Hints how to handle this? There's a kvm_mmu_zap_all() function, but it isn't exposed. It's very coarse grained, but can be used for experiments. You could write a new ioctl that tells kvm that some pages were modified by the host; that's useful for guests which page out page tables (and so, during page in, disk dma could overwrite a page table). -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] KVM: apic round robin cleanup
If no apic is enabled in the bitmap of an interrupt delivery with
delivery
mode of lowest priority, a warning should be reported rather than select
a fallback vcpu
Signed-off-by: Qing He [EMAIL PROTECTED]
Signed-off-by: Eddie (Yaozu) Dong [EMAIL PROTECTED]
---
drivers/kvm/lapic.c | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/kvm/lapic.c b/drivers/kvm/lapic.c
index ddf9f20..6e0f7e5 100644
--- a/drivers/kvm/lapic.c
+++ b/drivers/kvm/lapic.c
@@ -395,10 +395,9 @@ static int __apic_accept_irq(struct kvm_lapic
*apic, int delivery_mode,
struct kvm_lapic *kvm_apic_round_robin(struct kvm *kvm, u8 vector,
unsigned long bitmap)
{
- int vcpu_id;
int last;
int next;
- struct kvm_lapic *apic;
+ struct kvm_lapic *apic = NULL;
last = kvm-round_robin_prev_vcpu;
next = last;
@@ -415,14 +414,8 @@ struct kvm_lapic *kvm_apic_round_robin(struct kvm
*kvm, u8 vector,
} while (next != last);
kvm-round_robin_prev_vcpu = next;
- if (!apic) {
- vcpu_id = ffs(bitmap) - 1;
- if (vcpu_id 0) {
- vcpu_id = 0;
- printk(KERN_DEBUG vcpu not ready for
apic_round_robin\n);
- }
- apic = kvm-vcpus[vcpu_id]-apic;
- }
+ if (!apic)
+ printk(KERN_DEBUG vcpu not ready for
apic_round_robin\n);
return apic;
}
--
1.5.1.2
0001-KVM-apic-round-robin-cleanup.patch
Description: 0001-KVM-apic-round-robin-cleanup.patch
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] KVM: x86_emulator: no writeback for bt
(p.s., this patch is before Laurent's patch of no_wb removal, the change is minor to adapt to OP_NONE) Signed-off-by: Qing He [EMAIL PROTECTED] --- drivers/kvm/x86_emulate.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c index f294a49..6ab67fe 100644 --- a/drivers/kvm/x86_emulate.c +++ b/drivers/kvm/x86_emulate.c @@ -1549,6 +1549,7 @@ twobyte_insn: break; case 0xa3: bt: /* bt */ + no_wb = 1; /* only subword offset */ c-src.val = (c-dst.bytes 3) - 1; emulate_2op_SrcV_nobyte(bt, c-src, c-dst, _eflags); -- 1.5.1.2 0002-KVM-x86_emulator-no-writeback-for-bt.patch Description: 0002-KVM-x86_emulator-no-writeback-for-bt.patch - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-43 release
I *think* it happens because I'm changing guest page tables from outside (i.e. host application), and the new intel pgtable optimization bits don't expect that (yes, it is a vt box). Well, the older implementation doesn't expect that either. You can disable the optimization with bypass_guest_pf=0, though. Thanks. Using bypass_guest_pf=0 and irqchip_disable() brings things back to -41 level of functionality. kvm not expecting both guest and host app changing pagetables could explain other problems I'm seeing though, so maybe i better fix that. Long term it isn't planned to stay that way anyway, it's just handy for proof-of-concept because userspace is very easy to hack and debug ... thanks, Gerd - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Test result for KVM, kernel 62d1ea7.. , userspace 667f2deff8..
Hi, all, This is today's KVM test result against kvm.git 62d1ea7fdcdb905072198e4cec8f724c8ad33092 and kvm-userspace.git 667f2deff8cea6327f0c832afea2f4952b8f199e. In today's testing, smp windows still couldn't be booted up. 1 issue is closed 1. save/restore 64-bit linux guest fails https://sourceforge.net/tracker/index.php?func=detailaid=1799590group_ id=180599atid=893831 This issue should be invalid, the command to test sare/restore missed a parameter. Old issues: 1. 64bit guest with 1.5GBmem cannot start network https://sourceforge.net/tracker/index.php?func=detailaid=1792984group_ id=180599atid=893831 2. Cannot boot win2k guest https://sourceforge.net/tracker/?func=detailatid=893831aid=1768187gro up_id=180599 3. Network issue of 64bit linux guest https://sourceforge.net/tracker/index.php?func=detailaid=1796939group_ id=180599atid=893831 4. blue screen while install 64bit vista https://sourceforge.net/tracker/?func=detailatid=893831aid=1796941gro up_id=180599 5. Create multiple guests simultaneously or create one guest many times may fail https://sourceforge.net/tracker/index.php?func=detailaid=1741312group_ id=180599atid=893831 6. Can not boot IA32e RHEL 4u3 guest with -no-acpi https://sourceforge.net/tracker/index.php?func=detailaid=1741314group_ id=180599atid=893831 7. Some ltp test cases fail https://sourceforge.net/tracker/index.php?func=detailaid=1741316group_ id=180599atid=893831 8. Linux guest crash without nolapic, 2.6.22 kernel. https://sourceforge.net/tracker/?func=detailatid=893831aid=1769884gro up_id=180599 9. Cannot boot smp windows guests SMP XP windows guest will hang SMP win2k guest will turn black SMP 2003 windows reports driver error. https://sourceforge.net/tracker/index.php?func=detailaid=1799596group_ id=180599atid=893831 Thanks Yunfeng - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Test result for KVM, kernel 62d1ea7.. , userspace 667f2deff8..
hi, it seems we've got a real tester:-) for ma all of the bellow are serious bugs (tomorrow i'll try to send more detail of our host crash too) and imho the latest 'stable' version was kvm-36. wouldn't be better to postpone all patches and infrastructure changes (virtio and others) until these have been fixed and try to produce a new 'stable' release? i understand then everybody (including myself) would like to see these new features in the latest and greatest kvm release, but at the same time i'd be nice to think about the end users too. may some version cane be labeled as stable (eg 36) and the latest as devel. this can help a lot for those who are not read this list. Zhao, Yunfeng wrote: Hi, all, This is today's KVM test result against kvm.git 62d1ea7fdcdb905072198e4cec8f724c8ad33092 and kvm-userspace.git 667f2deff8cea6327f0c832afea2f4952b8f199e. In today's testing, smp windows still couldn't be booted up. 1 issue is closed 1. save/restore 64-bit linux guest fails https://sourceforge.net/tracker/index.php?func=detailaid=1799590group_ id=180599atid=893831 This issue should be invalid, the command to test sare/restore missed a parameter. Old issues: 1. 64bit guest with 1.5GBmem cannot start network https://sourceforge.net/tracker/index.php?func=detailaid=1792984group_ id=180599atid=893831 2. Cannot boot win2k guest https://sourceforge.net/tracker/?func=detailatid=893831aid=1768187gro up_id=180599 3. Network issue of 64bit linux guest https://sourceforge.net/tracker/index.php?func=detailaid=1796939group_ id=180599atid=893831 4. blue screen while install 64bit vista https://sourceforge.net/tracker/?func=detailatid=893831aid=1796941gro up_id=180599 5. Create multiple guests simultaneously or create one guest many times may fail https://sourceforge.net/tracker/index.php?func=detailaid=1741312group_ id=180599atid=893831 6. Can not boot IA32e RHEL 4u3 guest with -no-acpi https://sourceforge.net/tracker/index.php?func=detailaid=1741314group_ id=180599atid=893831 7. Some ltp test cases fail https://sourceforge.net/tracker/index.php?func=detailaid=1741316group_ id=180599atid=893831 8. Linux guest crash without nolapic, 2.6.22 kernel. https://sourceforge.net/tracker/?func=detailatid=893831aid=1769884gro up_id=180599 9. Cannot boot smp windows guests SMP XP windows guest will hang SMP win2k guest will turn black SMP 2003 windows reports driver error. https://sourceforge.net/tracker/index.php?func=detailaid=1799596group_ id=180599atid=893831 Thanks Yunfeng - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel -- Levente Si vis pacem para bellum! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace 114b08b..
Zhao, Yunfeng wrote: Avi, I still cannot boot up the smp windows against the latest commits. What are the symptoms, exactly? It works reliably here. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Test result for KVM, kernel 62d1ea7.. , userspace 667f2deff8..
Farkas Levente wrote: hi, it seems we've got a real tester:-) for ma all of the bellow are serious bugs (tomorrow i'll try to send more detail of our host crash too) and imho the latest 'stable' version was kvm-36. wouldn't be better to postpone all patches and infrastructure changes (virtio and others) until these have been fixed and try to produce a new 'stable' release? i understand then everybody (including myself) would like to see these new features in the latest and greatest kvm release, but at the same time i'd be nice to think about the end users too. may some version cane be labeled as stable (eg 36) and the latest as devel. this can help a lot for those who are not read this list. You can use -no-kvm-irqchip to get stability similar to kvm-36. Stopping vitrio development will not get the other issues fixed. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace 114b08b..
Avi Kivity wrote: Zhao, Yunfeng wrote: Avi, I still cannot boot up the smp windows against the latest commits. What are the symptoms, exactly? It works reliably here. It works for me too (winXP + smp 4), but I had to update kvm-userspace to last commits as well. Yunfeng, did you update it too ? Laurent -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/3] Make some cleanup in x86_emulate.c
Laurent Vivier wrote: This patch series makes some cleanups in x86_emulate.c [PATCH 1/3] move some parts of x86_decode_insn() into functions. [PATCH 2/3] remove _eflags and use directly ctxt-eflags [PATCH 3/3] remove no_wb It has been rebased to current master. Applied all, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: x86_emulator: no writeback for bt
He, Qing wrote: (p.s., this patch is before Laurent's patch of no_wb removal, the change is minor to adapt to OP_NONE) Applied, thanks. Does it solve some specific issue with a guest? I'll have to send it for 2.6.23 as well if it does. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: apic round robin cleanup
He, Qing wrote: If no apic is enabled in the bitmap of an interrupt delivery with delivery mode of lowest priority, a warning should be reported rather than select a fallback vcpu Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/3] virtio ring implementation
Rusty Russell wrote:
These helper routines supply most of the virtqueue_ops for hypervisors
which want to use a ring for virtio. Unlike the previous lguest
implementation:
1) The rings are variable sized (2^n-1 elements).
2) They have an unfortunate limit of 65535 bytes per sg element.
3) The page numbers are always 64 bit (PAE anyone?)
4) They no longer place used[] on a separate page, just a separate
cacheline.
5) We do a modulo on a variable. We could be tricky if we cared.
6) Interrupts and notifies are suppressed using flags within the rings.
Users need only implement the new_vq and free_vq hooks (KVM wants the
guest to allocate the rings, lguest does it sanely).
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
[snip]
+irqreturn_t vring_interrupt(int irq, void *_vq)
+{
+ struct vring_virtqueue *vq = to_vvq(_vq);
+
+ pr_debug(virtqueue interrupt for %p\n, vq);
+
+ if (unlikely(vq-broken))
+ return IRQ_HANDLED;
+
+ if (more_used(vq)) {
+ pr_debug(virtqueue callback for %p (%p)\n,
+vq, vq-vq.callback);
+ if (!vq-vq.callback)
+ return IRQ_NONE;
+ if (!vq-vq.callback(vq-vq))
+ vq-vring.avail-flags |=
VRING_AVAIL_F_NO_INTERRUPT;
+ } else
+ pr_debug(virtqueue %p no more used\n, vq);
+
+ return IRQ_HANDLED;
+}
+
Seems like there is a problem with shared irq line, the interrupt
handler always returns IRQ_HANDLED (except for the trivial case
were the callback is null).
It can be solved by having a host irq counter (in the shared ring) and a
guest irq counter and return
mb(); return (host_counter!=guest_counter)? IRQ_HANDLED:IRQ_NONE;
Dor.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace 114b08b..
Oh... Just checked the source code in our build machine, the kvm.git is not updated to latest. I have fixed the issue, let's wait and see the new testing results. Sorry for the mistake! Thanks Yunfeng -Original Message- From: Laurent Vivier [mailto:[EMAIL PROTECTED] Sent: 2007年9月24日 21:13 To: Avi Kivity Cc: Zhao, Yunfeng; kvm-devel@lists.sourceforge.net Subject: Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace 114b08b.. Avi Kivity wrote: Zhao, Yunfeng wrote: Avi, I still cannot boot up the smp windows against the latest commits. What are the symptoms, exactly? It works reliably here. It works for me too (winXP + smp 4), but I had to update kvm-userspace to last commits as well. Yunfeng, did you update it too ? Laurent -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Test result for KVM, kernel 62d1ea7.. , userspace 667f2deff8..
Avi Kivity wrote: Farkas Levente wrote: hi, it seems we've got a real tester:-) for ma all of the bellow are serious bugs (tomorrow i'll try to send more detail of our host crash too) and imho the latest 'stable' version was kvm-36. wouldn't be better to postpone all patches and infrastructure changes (virtio and others) until these have been fixed and try to produce a new 'stable' release? i understand then everybody (including myself) would like to see these new features in the latest and greatest kvm release, but at the same time i'd be nice to think about the end users too. may some version cane be labeled as stable (eg 36) and the latest as devel. this can help a lot for those who are not read this list. You can use -no-kvm-irqchip to get stability similar to kvm-36. Perhaps a workaround for end user could be to disable by default kvm irqchip and add an option to enable it (--use-kvm-irqchip) ? Laurent -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Test result for KVM, kernel 62d1ea7.. , userspace 667f2deff8..
Laurent Vivier wrote: Avi Kivity wrote: Farkas Levente wrote: hi, it seems we've got a real tester:-) for ma all of the bellow are serious bugs (tomorrow i'll try to send more detail of our host crash too) and imho the latest 'stable' version was kvm-36. wouldn't be better to postpone all patches and infrastructure changes (virtio and others) until these have been fixed and try to produce a new 'stable' release? i understand then everybody (including myself) would like to see these new features in the latest and greatest kvm release, but at the same time i'd be nice to think about the end users too. may some version cane be labeled as stable (eg 36) and the latest as devel. this can help a lot for those who are not read this list. You can use -no-kvm-irqchip to get stability similar to kvm-36. Perhaps a workaround for end user could be to disable by default kvm irqchip and add an option to enable it (--use-kvm-irqchip) ? I thought of it, but that would mean we wouldn't see the problems, so they wouldn't get fixed. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Bug-Report: kvm-44 crashes with -no-kvm with -rc6 host on AMD64 (Stepping F)
Hi list, I've observed that current kvm-44 userspace with Avi's git as of yesterday does not boot our debian test image on an AMD64 machine. The kernel seems to die various panic's in sequence (too fast to observe), the final one is in __delay(). Everything seems well without -no-kvm option with the very same userspace. In case of problems in reproducing this, let me know so that I can collect debug data. so long, Carsten - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Bug-Report: kvm-44 crashes with -no-kvm with -rc6 host on AMD64 (Stepping F)
On 9/24/07, Carsten Otte [EMAIL PROTECTED] wrote: Hi list, I've observed that current kvm-44 userspace with Avi's git as of yesterday does not boot our debian test image on an AMD64 machine. The kernel seems to die various panic's in sequence (too fast to observe), the final one is in __delay(). Host kernel? Or the guest? Everything seems well without -no-kvm option with the very same userspace. In case of problems in reproducing this, let me know so that I can collect debug data. If it's the guest you can append -serial file:/tmp/log.txt to KVM command line and add console=ttyS0 to the guest kernel command line. Luca - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Test result for KVM, kernel 62d1ea7.. , userspace 667f2deff8..
Avi Kivity wrote: Laurent Vivier wrote: Avi Kivity wrote: Farkas Levente wrote: hi, it seems we've got a real tester:-) for ma all of the bellow are serious bugs (tomorrow i'll try to send more detail of our host crash too) and imho the latest 'stable' version was kvm-36. wouldn't be better to postpone all patches and infrastructure changes (virtio and others) until these have been fixed and try to produce a new 'stable' release? i understand then everybody (including myself) would like to see these new features in the latest and greatest kvm release, but at the same time i'd be nice to think about the end users too. may some version cane be labeled as stable (eg 36) and the latest as devel. this can help a lot for those who are not read this list. You can use -no-kvm-irqchip to get stability similar to kvm-36. Perhaps a workaround for end user could be to disable by default kvm irqchip and add an option to enable it (--use-kvm-irqchip) ? I thought of it, but that would mean we wouldn't see the problems, so they wouldn't get fixed. I agree: enabling by default development features allows you to have more bug feedbacks. It's a choice... Laurent -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Bug-Report: kvm-44 crashes with -no-kvm with -rc6 host on AMD64 (Stepping F)
Carsten Otte wrote: Hi list, I've observed that current kvm-44 userspace with Avi's git as of yesterday does not boot our debian test image on an AMD64 machine. The kernel seems to die various panic's in sequence (too fast to observe), the final one is in __delay(). Everything seems well without -no-kvm option with the very same userspace. In case of problems in reproducing this, let me know so that I can collect debug data. Fixed in git now. Actually the bug has been in there for quite a long time. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Extending VGA ram?
Hi! I'd like to use screen resolutions of 1920x1200 to 2560x1600 at 32bpp. So far I managed to raise the pixel limit, but not the memory size, and 8MB is a bit low for what I want. [EMAIL PROTECTED] works fine, but 32bpp results in a segfault. Increasing VGA_RAM_SIZE in qemu/vl.h doesn't help. What else does this depend on? MfG, Ulrich -- Heinz Ulrich Stille / Tel.: +49-541-9400473 / Fax: +49-541-9400450 design_d gmbh / Wilhelmstr. 16 / 49076 Osnabrück / www.design-d.de Osnabrück HRB 19116 / Geschäftsführer: Günter Tammen, Rolf Tammen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Purify x86_decode_insn() error case management
Purify x86_decode_insn() error case management,
the only valid case is on protected page access, other cases are errors
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
drivers/kvm/kvm_main.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index cecdb1b..60798e3 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1272,7 +1272,7 @@ int emulate_instruction(struct kvm_vcpu *vcpu,
u16 error_code,
int no_decode)
{
- int r = 0;
+ int r;
vcpu-mmio_fault_cr2 = cr2;
kvm_x86_ops-cache_regs(vcpu);
@@ -1315,10 +1315,14 @@ int emulate_instruction(struct kvm_vcpu *vcpu,
get_segment_base(vcpu, VCPU_SREG_FS);
r = x86_decode_insn(vcpu-emulate_ctxt, emulate_ops);
+ if (r) {
+ if (kvm_mmu_unprotect_page_virt(vcpu, cr2))
+ return EMULATE_DONE;
+ return EMULATE_FAIL;
+ }
}
- if (r == 0)
- r = x86_emulate_insn(vcpu-emulate_ctxt, emulate_ops);
+ r = x86_emulate_insn(vcpu-emulate_ctxt, emulate_ops);
if (vcpu-pio.string)
return EMULATE_DO_MMIO;
--
1.5.2.4
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Extending VGA ram?
Heinz Ulrich Stille wrote: Hi! I'd like to use screen resolutions of 1920x1200 to 2560x1600 at 32bpp. So far I managed to raise the pixel limit, but not the memory size, and 8MB is a bit low for what I want. [EMAIL PROTECTED] works fine, but 32bpp results in a segfault. Increasing VGA_RAM_SIZE in qemu/vl.h doesn't help. What else does this depend on? You'll need to emulate a card that supports these resolutions. I don't think cirrus does. The vmware vga display in qemu-cvs probably does, but it hasn't been ported to kvm yet. You might try that. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace 114b08b..
Still doesn't work after updated to the kvm-44. 0n 64bit host a xp guest with 2vcpus still gets froze during booting Just like this https://sourceforge.net/tracker/download.php?group_id=180599atid=893831file_id=246597aid=1799596 The test machine is a harwitch + paxville with 16 LPs I build the kvm as external modules of kernel 2.6.22. Thanks Yunfeng -Original Message- From: Laurent Vivier [mailto:[EMAIL PROTECTED] Sent: 2007年9月24日 21:13 To: Avi Kivity Cc: Zhao, Yunfeng; kvm-devel@lists.sourceforge.net Subject: Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace 114b08b.. Avi Kivity wrote: Zhao, Yunfeng wrote: Avi, I still cannot boot up the smp windows against the latest commits. What are the symptoms, exactly? It works reliably here. It works for me too (winXP + smp 4), but I had to update kvm-userspace to last commits as well. Yunfeng, did you update it too ? Laurent -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Extending VGA ram?
Avi Kivity wrote: Heinz Ulrich Stille wrote: Hi! I'd like to use screen resolutions of 1920x1200 to 2560x1600 at 32bpp. So far I managed to raise the pixel limit, but not the memory size, and 8MB is a bit low for what I want. [EMAIL PROTECTED] works fine, but 32bpp results in a segfault. Increasing VGA_RAM_SIZE in qemu/vl.h doesn't help. What else does this depend on? You'll need to emulate a card that supports these resolutions. I don't think cirrus does. The vmware vga display in qemu-cvs probably does, but it hasn't been ported to kvm yet. You might try that. BTW, what is your politic about qemu: do you update qemu inside kvm on qemu release only ? Laurent -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Extending VGA ram?
On Monday 24 September 2007, Avi Kivity wrote: You'll need to emulate a card that supports these resolutions. I don't think cirrus does. The vmware vga display in qemu-cvs probably does, but it hasn't been ported to kvm yet. You might try that. I use Windows XP on std-vga. I tried hacking vgabios to report higher resolutions and memory, but that doesn't seem to make any difference. Windows lists 32bpp even if memory is insufficient for that. So where is the catch? Would it be possible to make std vga support large resolutions without too much effort? MfG, Ulrich -- Heinz Ulrich Stille / Tel.: +49-541-9400473 / Fax: +49-541-9400450 design_d gmbh / Wilhelmstr. 16 / 49076 Osnabrück / www.design-d.de Osnabrück HRB 19116 / Geschäftsführer: Günter Tammen, Rolf Tammen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Extending VGA ram?
Laurent Vivier wrote: BTW, what is your politic about qemu: do you update qemu inside kvm on qemu release only ? I plan to do a merge soon (if things become too stable), but if qemu releases before that, I'd be much happier. Merging soon has the benefits of bringing in all the good stuff and making future merges easier; on the other hand it can bring in unstable code. On the balance I think a merge would be helpful now. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio module alias support
On Mon, Sep 24, 2007 at 07:16:34PM +1000, Rusty Russell wrote: This adds the logic to convert the virtio ids into module aliases, and includes a modalias entry in sysfs. Unfortunately this does not seem sufficient to have the module autoprobed at startup on my Ubuntu system. Greg? Am I missing some udev magic? You also need to pass the MODINFO environment variable to the hotplug call so that udev can pick it up. hope this helps, greg k-h - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace 114b08b..
Zhao, Yunfeng wrote: Still doesn't work after updated to the kvm-44. 0n 64bit host a xp guest with 2vcpus still gets froze during booting Just like this https://sourceforge.net/tracker/download.php?group_id=180599atid=893831file_id=246597aid=1799596 The test machine is a harwitch + paxville with 16 LPs I build the kvm as external modules of kernel 2.6.22. Works here with external module hosted on 2.6.20-1.2962.fc6; let's try to narrow down the differences. - the Windows version here is Version 5.1 (Build 2600.xpsp_sp2_gdr.070227-2254 : Service Pack 2); what do you have? - please send me your host .config so I can try and run with that. Running userspace kvm-44-3-g6b83c95 and kernel kvm-44-5-g2cd2d1d. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Extending VGA ram?
Heinz Ulrich Stille wrote: On Monday 24 September 2007, Avi Kivity wrote: You'll need to emulate a card that supports these resolutions. I don't think cirrus does. The vmware vga display in qemu-cvs probably does, but it hasn't been ported to kvm yet. You might try that. I use Windows XP on std-vga. I tried hacking vgabios to report higher resolutions and memory, but that doesn't seem to make any difference. Windows lists 32bpp even if memory is insufficient for that. So where is the catch? Would it be possible to make std vga support large resolutions without too much effort? I don't really know. The vga bios, qemu device model, memory size, and guest driver all have to cooperate for this to work. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] expose host CPU features to guests: Take 3
As with previous Takes of this patch, its purpose is to expose host
CPU features to guests. It proved rather helpful to KVM in various
benchmarks, and it should similarly speed kqemu up. Note that it does
not extend the set of emulated opcodes, only exposes what's supported by
the host CPU.
Another purpose for Take 2 is to add the -cpu option to the x86
architecture, similarly to that of other architectures.
-cpu 486, pentium, pentium2 and pentium3 are supported in addition to
finer-grained features such as -cpu pentium,-mmx . As in Take 1,
-cpu host exposes host features to guest.
This patch exposes the requested CPU also right after RESET command, and
not only in CPUID.
Please let me know if you have more suggestions,
Dan.
===
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.342
diff -u -p -r1.342 vl.c
--- vl.c17 Sep 2007 21:25:20 - 1.342
+++ vl.c24 Sep 2007 16:53:29 -
@@ -7694,6 +7694,8 @@ int main(int argc, char **argv)
mips_cpu_list(stdout, fprintf);
#elif defined(TARGET_SPARC)
sparc_cpu_list(stdout, fprintf);
+#elif defined(TARGET_I386)
+x86_cpu_list(stdout, fprintf);
#endif
exit(0);
} else {
Index: hw/pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.85
diff -u -p -r1.85 pc.c
--- hw/pc.c 17 Sep 2007 08:09:47 - 1.85
+++ hw/pc.c 24 Sep 2007 16:53:29 -
@@ -666,7 +666,7 @@ static void pc_init1(int ram_size, int v
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename,
- int pci_enabled)
+ int pci_enabled, const char *cpu_model)
{
char buf[1024];
int ret, linux_boot, i;
@@ -682,6 +682,13 @@ static void pc_init1(int ram_size, int v
linux_boot = (kernel_filename != NULL);
/* init CPUs */
+if (cpu_model == NULL)
+cpu_model = basic;
+
+if (x86_find_cpu_by_name(cpu_model)) {
+fprintf(stderr, Unable to find x86 CPU definition\n);
+exit(1);
+}
for(i = 0; i smp_cpus; i++) {
env = cpu_init();
if (i != 0)
@@ -948,7 +955,7 @@ static void pc_init_pci(int ram_size, in
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 1);
+ initrd_filename, 1, cpu_model);
}
static void pc_init_isa(int ram_size, int vga_ram_size, int boot_device,
@@ -962,7 +969,7 @@ static void pc_init_isa(int ram_size, in
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 0);
+ initrd_filename, 0, cpu_model);
}
QEMUMachine pc_machine = {
Index: target-i386/cpu.h
===
RCS file: /sources/qemu/qemu/target-i386/cpu.h,v
retrieving revision 1.48
diff -u -p -r1.48 cpu.h
--- target-i386/cpu.h 23 Sep 2007 15:28:04 - 1.48
+++ target-i386/cpu.h 24 Sep 2007 16:53:30 -
@@ -274,23 +274,56 @@
#define CPUID_CMOV (1 15)
#define CPUID_PAT (1 16)
#define CPUID_PSE36 (1 17)
+#define CPUID_PN (1 18)
#define CPUID_CLFLUSH (1 19)
-/* ... */
+#define CPUID_DTS (1 21)
+#define CPUID_ACPI (1 22)
#define CPUID_MMX (1 23)
#define CPUID_FXSR (1 24)
#define CPUID_SSE (1 25)
#define CPUID_SSE2 (1 26)
+#define CPUID_SS (1 27)
+#define CPUID_HT (1 28)
+#define CPUID_TM (1 29)
+#define CPUID_IA64 (1 30)
+#define CPUID_PBE (1 31)
#define CPUID_EXT_SSE3 (1 0)
#define CPUID_EXT_MONITOR (1 3)
+#define CPUID_EXT_DSCPL(1 4)
+#define CPUID_EXT_VMX (1 5)
+#define CPUID_EXT_SMX (1 6)
+#define CPUID_EXT_EST (1 7)
+#define CPUID_EXT_TM2 (1 8)
+#define CPUID_EXT_SSSE3(1 9)
+#define CPUID_EXT_CID (1 10)
#define CPUID_EXT_CX16 (1 13)
+#define CPUID_EXT_XTPR (1 14)
+#define CPUID_EXT_DCA (1 17)
+#define CPUID_EXT_POPCNT (1 22)
#define CPUID_EXT2_SYSCALL (1 11)
+#define CPUID_EXT2_MP (1 19)
#define CPUID_EXT2_NX (1 20)
+#define CPUID_EXT2_MMXEXT (1 22)
#define CPUID_EXT2_FFXSR (1 25)
+#define CPUID_EXT2_PDPE1GB (1 26)
+#define CPUID_EXT2_RDTSCP (1 27)
#define CPUID_EXT2_LM (1 29)
+#define CPUID_EXT2_3DNOWEXT (1 30)
+#define CPUID_EXT2_3DNOW (1 31)
+#define CPUID_EXT3_LAHF_LM (1 0)
+#define CPUID_EXT3_CMP_LEG (1 1)
#define CPUID_EXT3_SVM (1 2)
+#define CPUID_EXT3_EXTAPIC (1 3)
+#define CPUID_EXT3_CR8LEG (1 4)
+#define CPUID_EXT3_ABM (1 5)
+#define CPUID_EXT3_SSE4A
[kvm-devel] [PATCH][RFC] mmu:remove the usage of the private field by the rmap.
in order to be able to allocate the memory to kvm from userspace we have to remove the private usage made by the rmap. this patch add array to each memory slot sorted by gfn that hold rmap to each page. to make the finding of gfn from spte address, we are adding another page to each kvm_mmu_page, that hold to each spte - spt offset the gfn of it. thanks - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][RFC] mmu:remove the usage of the private field by the rmap.
I think you forgot to include the patch? Regards, Anthony Liguori Izik Eidus wrote: in order to be able to allocate the memory to kvm from userspace we have to remove the private usage made by the rmap. this patch add array to each memory slot sorted by gfn that hold rmap to each page. to make the finding of gfn from spte address, we are adding another page to each kvm_mmu_page, that hold to each spte - spt offset the gfn of it. thanks - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] BUG_ON in mmu.c:436
Ryan Harper wrote: * Avi Kivity [EMAIL PROTECTED] [2007-09-24 02:57]: Ryan Harper wrote: I've run into a nasty bug while trying to install a Linux guest using VMware Server inside a kvm guest (full dmesg attached and recreate instructions below bug). Can you reproduce this with AUDIT turned on (top of mmu.c)? AUDIT is very slow, so it's recommended to reduce guest memory as much as possible. Working on it -- running for the better part of today with 256MB and I'm still booting up the guest. I'll let you know how things go tomorrow. Any thoughts on how to speed audit runs up other than lower guest memory? savevm right before you're about to launch your test w/o audit enabled. then launch with loadvm and audit enabled and hit enter to launch your test. Regards, Anthony Liguori - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1/3] virtio interface
On Monday 24 September 2007, Rusty Russell wrote:
This attempts to implement a virtual I/O layer which should allow
common drivers to be efficiently used across most virtual I/O
mechanisms. It will no-doubt need further enhancement.
Hi Rusty,
Thanks for your update, as you can imagine, I'm much happier with
this version ;-)
+
+struct virtio_bus {
+ struct bus_type bus;
+ struct device dev;
+};
+
+static struct virtio_bus virtio_bus = {
+ .bus = {
+ .name = virtio,
+ .match = virtio_dev_match,
+ .dev_attrs = virtio_dev_attrs,
+ },
+ .dev = {
+ /* Can override this if you have a real bus behind it. */
+ .parent = NULL,
+ .bus_id = virtio,
+ }
+};
This is a pattern I've seen a few times before, but could never understand
what it's good for. What is your reason for defining a new data structure
that is used only once, instead of just
static struct bus_type virtio_bus_type;
static struct device virtio_root_dev;
Also, I would not mix the two in a single source file. Instead, I think
every driver that can provide virtio devices (pci, lguest, ...) should
be responsible for setting the parent appropriately.
+#ifndef _LINUX_VIRTIO_CONFIG_H
+#define _LINUX_VIRTIO_CONFIG_H
+/* Virtio devices use a standardized configuration space to define their
+ * features and pass configuration information, but each implementation can
+ * store and access that space differently. */
+#include linux/types.h
+
+/* Status byte for guest to report progress, and synchronize config. */
+/* We have seen device and processed generic fields (VIRTIO_CONFIG_F_VIRTIO)
*/
+#define VIRTIO_CONFIG_S_ACKNOWLEDGE 1
+/* We have found a driver for the device. */
+#define VIRTIO_CONFIG_S_DRIVER 2
+/* Driver has used its parts of the config, and is happy */
+#define VIRTIO_CONFIG_S_DRIVER_OK4
+/* We've given up on this device. */
+#define VIRTIO_CONFIG_S_FAILED 0x80
+
+/* Feature byte (actually 7 bits availabe): */
+/* Requirements/features of the virtio implementation. */
+#define VIRTIO_CONFIG_F_VIRTIO 1
+/* Requirements/features of the virtqueue (may have more than one). */
+#define VIRTIO_CONFIG_F_VIRTQUEUE 2
+
+#ifdef __KERNEL__
+struct virtio_device;
+
+/**
+ * virtio_config_ops - operations for configuring a virtio device
+ * @find: search for the next configuration field of the given type.
+ * vdev: the virtio_device
+ * type: the feature type
+ * len: the (returned) length of the field if found.
+ * Returns a token if found, or NULL. Never returnes the same field twice
+ * (ie. it's used up).
+ * @get: read the value of a configuration field after find().
+ * vdev: the virtio_device
+ * token: the token returned from find().
+ * buf: the buffer to write the field value into.
+ * len: the length of the buffer (given by find()).
+ * Note that contents are conventionally little-endian.
+ * @set: write the value of a configuration field after find().
+ * vdev: the virtio_device
+ * token: the token returned from find().
+ * buf: the buffer to read the field value from.
+ * len: the length of the buffer (given by find()).
+ * Note that contents are conventionally little-endian.
+ * @get_status: read the status byte
+ * vdev: the virtio_device
+ * Returns the status byte
+ * @set_status: write the status byte
+ * vdev: the virtio_device
+ * status: the new status byte
+ * @find_vq: find the first VIRTIO_CONFIG_F_VIRTQUEUE and create a virtqueue.
+ * vdev: the virtio_device
+ * callback: the virqtueue callback
+ * Returns the new virtqueue or ERR_PTR().
+ * @del_vq: free a virtqueue found by find_vq().
+ */
+struct virtio_config_ops
+{
+ void *(*find)(struct virtio_device *vdev, u8 type, unsigned *len);
+ void (*get)(struct virtio_device *vdev, void *token,
+ void *buf, unsigned len);
+ void (*set)(struct virtio_device *vdev, void *token,
+ const void *buf, unsigned len);
+ u8 (*get_status)(struct virtio_device *vdev);
+ void (*set_status)(struct virtio_device *vdev, u8 status);
+ struct virtqueue *(*find_vq)(struct virtio_device *vdev,
+ bool (*callback)(struct virtqueue *));
+ void (*del_vq)(struct virtqueue *vq);
+};
The configuration logic looks more complicated than it should be.
Maybe more of this can be done using data structure definitions instead
of dynamic callback. E.g. the virtqueues of a given device can be
listed as members of the struct virtio_device.
+/**
+ * virtio_config_val - get a single virtio config and mark it used.
+ * @config: the virtio config space
+ * @type: the type to search for.
+ * @val: a pointer to the value to fill in.
+ *
+ * Once used, the config type is marked with VIRTIO_CONFIG_F_USED so it can't
+ * be found again. This version does
Re: [kvm-devel] [PATCH 2/3] virtio ring implementation
On Mon, 2007-09-24 at 15:44 +0200, Dor Laor wrote: Seems like there is a problem with shared irq line, the interrupt handler always returns IRQ_HANDLED (except for the trivial case were the callback is null). It can be solved by having a host irq counter (in the shared ring) and a guest irq counter and return mb(); return (host_counter!=guest_counter)? IRQ_HANDLED:IRQ_NONE; Or we could make the callback return irqreturn_t and have an explicit disable hook to disable interrupts. Using the return value of the callback to disable the queue has always made be a little uncomfortable, but it's slightly more efficient than a separate hook. Thanks, Rusty. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio module alias support
On Mon, 2007-09-24 at 09:02 -0700, Greg KH wrote:
On Mon, Sep 24, 2007 at 07:16:34PM +1000, Rusty Russell wrote:
This adds the logic to convert the virtio ids into module aliases, and
includes a modalias entry in sysfs.
Unfortunately this does not seem sufficient to have the module
autoprobed at startup on my Ubuntu system. Greg? Am I missing some
udev magic?
You also need to pass the MODINFO environment variable to the hotplug
call so that udev can pick it up.
hope this helps,
Well, I finally decoded this as follows:
You need to implement the bus_type.uevent hook, and use
add_uevent_var() to add a MODALIAS=virtio:... var. See
drivers/pci/hotplug.c.
Not sure why I need the modalias here when it's in sysfs. But, it
works.
Thanks!
Rusty.
---
Module autoprobing support for virtio drivers.
This adds the logic to convert the virtio ids into module aliases, and
includes a modalias entry in sysfs and the env var to make probing work.
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
---
drivers/virtio/virtio.c |9 +
scripts/mod/file2alias.c | 18 ++
2 files changed, 27 insertions(+)
diff -r 4b377c58d110 drivers/virtio/virtio.c
--- a/drivers/virtio/virtio.c Mon Sep 24 18:46:28 2007 +1000
+++ b/drivers/virtio/virtio.c Tue Sep 25 10:42:18 2007 +1000
@@ -19,11 +19,20 @@ static ssize_t status_show(struct device
{
struct virtio_device *dev = container_of(_d,struct virtio_device,dev);
return sprintf(buf, 0x%08x, dev-config-get_status(dev));
+}
+static ssize_t modalias_show(struct device *_d,
+struct device_attribute *attr, char *buf)
+{
+ struct virtio_device *dev = container_of(_d,struct virtio_device,dev);
+
+ return sprintf(buf, virtio:d%08Xv%08X\n,
+ dev-id.device, dev-id.vendor);
}
static struct device_attribute virtio_dev_attrs[] = {
__ATTR_RO(device),
__ATTR_RO(vendor),
__ATTR_RO(status),
+ __ATTR_RO(modalias),
__ATTR_NULL
};
@@ -48,6 +57,22 @@ static int virtio_dev_match(struct devic
for (i = 0; ids[i].device; i++)
if (virtio_id_match(dev, ids[i]))
return 1;
+ return 0;
+}
+
+static int virtio_uevent(struct device *_dv, char **envp,
+int num_envp, char *buffer, int buffer_size)
+{
+ struct virtio_device *dev = container_of(_dv,struct virtio_device,dev);
+ int i = 0, err;
+ int length = 0;
+
+ err = add_uevent_var(envp, num_envp, i, buffer, buffer_size, length,
+MODALIAS=virtio:d%08Xv%08X,
+dev-id.device, dev-id.vendor);
+ if (err)
+ return err;
+ envp[i] = NULL;
return 0;
}
@@ -61,6 +86,7 @@ static struct virtio_bus virtio_bus = {
.name = virtio,
.match = virtio_dev_match,
.dev_attrs = virtio_dev_attrs,
+ .uevent = virtio_uevent,
},
.dev = {
/* Can override this if you have a real bus behind it. */
diff -r 4b377c58d110 scripts/mod/file2alias.c
--- a/scripts/mod/file2alias.c Mon Sep 24 18:46:28 2007 +1000
+++ b/scripts/mod/file2alias.c Mon Sep 24 18:46:28 2007 +1000
@@ -484,6 +484,20 @@ static int do_parisc_entry(const char *f
return 1;
}
+/* Looks like: virtio:dNvN */
+static int do_virtio_entry(const char *filename, struct virtio_device_id *id,
+ char *alias)
+{
+ id-device = TO_NATIVE(id-device);
+ id-vendor = TO_NATIVE(id-vendor);
+
+ strcpy(alias, virtio:);
+ ADD(alias, d, 1, id-device);
+ ADD(alias, v, id-vendor != VIRTIO_DEV_ANY_ID, id-vendor);
+
+ return 1;
+}
+
/* Ignore any prefix, eg. v850 prepends _ */
static inline int sym_is(const char *symbol, const char *name)
{
@@ -599,6 +613,10 @@ void handle_moddevtable(struct module *m
do_table(symval, sym-st_size,
sizeof(struct parisc_device_id), parisc,
do_parisc_entry, mod);
+ else if (sym_is(symname, __mod_virtio_device_table))
+ do_table(symval, sym-st_size,
+sizeof(struct virtio_device_id), virtio,
+do_virtio_entry, mod);
}
/* Now add out buffered information to the generated C source */
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
Hi,
On 24/09/2007, Dan Kenigsberg [EMAIL PROTECTED] wrote:
As with previous Takes of this patch, its purpose is to expose host
CPU features to guests. It proved rather helpful to KVM in various
benchmarks, and it should similarly speed kqemu up. Note that it does
not extend the set of emulated opcodes, only exposes what's supported by
the host CPU.
Another purpose for Take 2 is to add the -cpu option to the x86
architecture, similarly to that of other architectures.
-cpu 486, pentium, pentium2 and pentium3 are supported in addition to
finer-grained features such as -cpu pentium,-mmx . As in Take 1,
-cpu host exposes host features to guest.
This patch exposes the requested CPU also right after RESET command, and
not only in CPUID.
Please let me know if you have more suggestions,
Dan.
===
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.342
diff -u -p -r1.342 vl.c
--- vl.c17 Sep 2007 21:25:20 - 1.342
+++ vl.c24 Sep 2007 16:53:29 -
@@ -7694,6 +7694,8 @@ int main(int argc, char **argv)
mips_cpu_list(stdout, fprintf);
#elif defined(TARGET_SPARC)
sparc_cpu_list(stdout, fprintf);
+#elif defined(TARGET_I386)
+x86_cpu_list(stdout, fprintf);
#endif
exit(0);
} else {
Index: hw/pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.85
diff -u -p -r1.85 pc.c
--- hw/pc.c 17 Sep 2007 08:09:47 - 1.85
+++ hw/pc.c 24 Sep 2007 16:53:29 -
@@ -666,7 +666,7 @@ static void pc_init1(int ram_size, int v
DisplayState *ds, const char **fd_filename, int
snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename,
- int pci_enabled)
+ int pci_enabled, const char *cpu_model)
{
char buf[1024];
int ret, linux_boot, i;
@@ -682,6 +682,13 @@ static void pc_init1(int ram_size, int v
linux_boot = (kernel_filename != NULL);
/* init CPUs */
+if (cpu_model == NULL)
+cpu_model = basic;
+
+if (x86_find_cpu_by_name(cpu_model)) {
+fprintf(stderr, Unable to find x86 CPU definition\n);
+exit(1);
+}
for(i = 0; i smp_cpus; i++) {
env = cpu_init();
if (i != 0)
@@ -948,7 +955,7 @@ static void pc_init_pci(int ram_size, in
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 1);
+ initrd_filename, 1, cpu_model);
}
static void pc_init_isa(int ram_size, int vga_ram_size, int boot_device,
@@ -962,7 +969,7 @@ static void pc_init_isa(int ram_size, in
pc_init1(ram_size, vga_ram_size, boot_device,
ds, fd_filename, snapshot,
kernel_filename, kernel_cmdline,
- initrd_filename, 0);
+ initrd_filename, 0, cpu_model);
}
QEMUMachine pc_machine = {
Index: target-i386/cpu.h
===
RCS file: /sources/qemu/qemu/target-i386/cpu.h,v
retrieving revision 1.48
diff -u -p -r1.48 cpu.h
--- target-i386/cpu.h 23 Sep 2007 15:28:04 - 1.48
+++ target-i386/cpu.h 24 Sep 2007 16:53:30 -
@@ -274,23 +274,56 @@
#define CPUID_CMOV (1 15)
#define CPUID_PAT (1 16)
#define CPUID_PSE36 (1 17)
+#define CPUID_PN (1 18)
#define CPUID_CLFLUSH (1 19)
-/* ... */
+#define CPUID_DTS (1 21)
+#define CPUID_ACPI (1 22)
#define CPUID_MMX (1 23)
#define CPUID_FXSR (1 24)
#define CPUID_SSE (1 25)
#define CPUID_SSE2 (1 26)
+#define CPUID_SS (1 27)
+#define CPUID_HT (1 28)
+#define CPUID_TM (1 29)
+#define CPUID_IA64 (1 30)
+#define CPUID_PBE (1 31)
#define CPUID_EXT_SSE3 (1 0)
#define CPUID_EXT_MONITOR (1 3)
+#define CPUID_EXT_DSCPL(1 4)
+#define CPUID_EXT_VMX (1 5)
+#define CPUID_EXT_SMX (1 6)
+#define CPUID_EXT_EST (1 7)
+#define CPUID_EXT_TM2 (1 8)
+#define CPUID_EXT_SSSE3(1 9)
+#define CPUID_EXT_CID (1 10)
#define CPUID_EXT_CX16 (1 13)
+#define CPUID_EXT_XTPR (1 14)
+#define CPUID_EXT_DCA (1 17)
+#define CPUID_EXT_POPCNT (1 22)
#define CPUID_EXT2_SYSCALL (1 11)
+#define CPUID_EXT2_MP (1 19)
#define CPUID_EXT2_NX (1 20)
+#define CPUID_EXT2_MMXEXT (1 22)
#define CPUID_EXT2_FFXSR (1 25)
+#define CPUID_EXT2_PDPE1GB (1 26)
+#define CPUID_EXT2_RDTSCP (1 27)
#define CPUID_EXT2_LM (1 29)
+#define CPUID_EXT2_3DNOWEXT (1 30)
+#define CPUID_EXT2_3DNOW (1 31)
+#define CPUID_EXT3_LAHF_LM (1 0)
+#define
Re: [kvm-devel] [PATCH 3/3] virtio module alias support
On Tue, Sep 25, 2007 at 10:50:04AM +1000, Rusty Russell wrote: On Mon, 2007-09-24 at 09:02 -0700, Greg KH wrote: On Mon, Sep 24, 2007 at 07:16:34PM +1000, Rusty Russell wrote: This adds the logic to convert the virtio ids into module aliases, and includes a modalias entry in sysfs. Unfortunately this does not seem sufficient to have the module autoprobed at startup on my Ubuntu system. Greg? Am I missing some udev magic? You also need to pass the MODINFO environment variable to the hotplug call so that udev can pick it up. hope this helps, Well, I finally decoded this as follows: You need to implement the bus_type.uevent hook, and use add_uevent_var() to add a MODALIAS=virtio:... var. See drivers/pci/hotplug.c. Ah, sorry, thanks for intrepreting it properly :) Not sure why I need the modalias here when it's in sysfs. But, it works. udev does not read from sysfs anymore, it just uses the environment variables. It's faster and race-free that way. thanks, greg k-h - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio module alias support
On Mon, 2007-09-24 at 18:57 -0700, Greg KH wrote: On Tue, Sep 25, 2007 at 10:50:04AM +1000, Rusty Russell wrote: Not sure why I need the modalias here when it's in sysfs. But, it works. udev does not read from sysfs anymore, it just uses the environment variables. It's faster and race-free that way. Should I leave the modalias entry in sysfs for back compat, or not? This will be for = 2.6.24 only... Thanks, Rusty. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace 114b08b..
The attachment is the .config I am using now. And one more difference is in our testing most guests are created with qcow images. Thanks Yunfeng -Original Message- From: Avi Kivity [mailto:[EMAIL PROTECTED] Sent: 2007年9月25日 0:13 To: Zhao, Yunfeng Cc: Laurent Vivier; kvm-devel@lists.sourceforge.net Subject: Re: [kvm-devel] Test result for KVM, kernel 06f0698c.. , userspace 114b08b.. Zhao, Yunfeng wrote: Still doesn't work after updated to the kvm-44. 0n 64bit host a xp guest with 2vcpus still gets froze during booting Just like this https://sourceforge.net/tracker/download.php?group_id=180599atid=893831fi le_id=246597aid=1799596 The test machine is a harwitch + paxville with 16 LPs I build the kvm as external modules of kernel 2.6.22. Works here with external module hosted on 2.6.20-1.2962.fc6; let's try to narrow down the differences. - the Windows version here is Version 5.1 (Build 2600.xpsp_sp2_gdr.070227-2254 : Service Pack 2); what do you have? - please send me your host .config so I can try and run with that. Running userspace kvm-44-3-g6b83c95 and kernel kvm-44-5-g2cd2d1d. -- error compiling committee.c: too many arguments to function # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22-rc4 # Tue Jun 12 10:26:35 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set CONFIG_GENERIC_CPU=y CONFIG_X86_L1_CACHE_BYTES=128 CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_INTERNODE_CACHE_BYTES=128 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_HT=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y CONFIG_NUMA=y CONFIG_K8_NUMA=y CONFIG_NODES_SHIFT=6 CONFIG_X86_64_ACPI_NUMA=y CONFIG_NUMA_EMU=y CONFIG_ARCH_DISCONTIGMEM_ENABLE=y CONFIG_ARCH_DISCONTIGMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set CONFIG_DISCONTIGMEM_MANUAL=y # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_DISCONTIGMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_NEED_MULTIPLE_NODES=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_MIGRATION=y CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y CONFIG_OUT_OF_LINE_PFN_TO_PAGE=y CONFIG_NR_CPUS=32 CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y
Re: [kvm-devel] [PATCH 3/3] virtio module alias support
On Tue, Sep 25, 2007 at 12:11:15PM +1000, Rusty Russell wrote: On Mon, 2007-09-24 at 18:57 -0700, Greg KH wrote: On Tue, Sep 25, 2007 at 10:50:04AM +1000, Rusty Russell wrote: Not sure why I need the modalias here when it's in sysfs. But, it works. udev does not read from sysfs anymore, it just uses the environment variables. It's faster and race-free that way. Should I leave the modalias entry in sysfs for back compat, or not? This will be for = 2.6.24 only... No, leave it in sysfs, other tools use it (like older versions of udev). thanks, greg k-h - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [RFC][PATCH]Memory mapped TPR shadow feature enabling
These patches enable memory mapped TPR shadow (FlexPriority).
Since TPR is accessed very frequently by 32bit Windows, especially SMP
guest, with FlexPriority enabled, we saw significant performance gain.
The issue is: FlexPriority needs to add a memory slot to the vm to make
shadow work with APIC access page.
We don't like the idea to add a memory slot, but no better choice now.
Our propose is to add p2m table to KVM, while seems this is still a long
way to go.
BTW: I didn't use the offset(or other info) provide by CPU when handling
APIC access vmexit. Instead, I used a bit in cmd_type(including
no_decode) to tell emulator decode memory operand by itself when
necessary. That's because I only got the guest physical address when
handling APIC access vmexit, but emulator need a guest virtual address
to fit its flow. I have tried some ways, and current solution seems the
most proper one.
--
From 3e83b579d0e9368f0f8223c24eac9898b9623aa2 Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Fri, 14 Sep 2007 09:51:54 +0800
Subject: [PATCH] Add a slot for apic access usage, not elegant but no
choice
---
user/kvmctl.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/user/kvmctl.c b/user/kvmctl.c
index f358dc1..7e75945 100644
--- a/user/kvmctl.c
+++ b/user/kvmctl.c
@@ -248,6 +248,7 @@ int kvm_create(kvm_context_t kvm, unsigned long
phys_mem_bytes, void **vm_mem)
unsigned long dosmem = 0xa;
unsigned long exmem = 0xc;
unsigned long pcimem = 0xf000;
+ unsigned long apicmem= 0xfee0;
unsigned long memory = (phys_mem_bytes + PAGE_SIZE - 1)
PAGE_MASK;
int fd = kvm-fd;
int zfd;
@@ -267,6 +268,11 @@ int kvm_create(kvm_context_t kvm, unsigned long
phys_mem_bytes, void **vm_mem)
.memory_size = memory pcimem ? 0 : memory - pcimem,
.guest_phys_addr = 0x1,
};
+ struct kvm_memory_region apic_memory = {
+ .slot = 5,
+ .memory_size = PAGE_SIZE,
+ .guest_phys_addr = apicmem,
+ };
if (memory = pcimem)
extended_memory.memory_size = pcimem - exmem;
@@ -302,9 +308,16 @@ int kvm_create(kvm_context_t kvm, unsigned long
phys_mem_bytes, void **vm_mem)
}
}
+ r = ioctl(fd, KVM_SET_MEMORY_REGION, apic_memory);
+ if (r == -1) {
+ fprintf(stderr, kvm_create_memory_region: %m\n);
+ return -1;
+ }
+
kvm_memory_region_save_params(kvm, low_memory);
kvm_memory_region_save_params(kvm, extended_memory);
kvm_memory_region_save_params(kvm, above_4g_memory);
+ kvm_memory_region_save_params(kvm, apic_memory);
*vm_mem = mmap(NULL, memory, PROT_READ|PROT_WRITE, MAP_SHARED,
fd, 0);
if (*vm_mem == MAP_FAILED) {
--
1.5.2
From 5b814299e3fb0912b1337749d42e3ef33b2615e7 Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Mon, 24 Sep 2007 16:10:40 +0800
Subject: [PATCH] Enable memory-mapped TPR shadow feature
---
drivers/kvm/irq.h |2 +
drivers/kvm/kvm.h |2 +-
drivers/kvm/kvm_main.c| 23 ++---
drivers/kvm/lapic.c |3 ++
drivers/kvm/vmx.c | 76
+---
drivers/kvm/vmx.h |3 ++
drivers/kvm/x86_emulate.c | 14 +++-
drivers/kvm/x86_emulate.h |4 ++
8 files changed, 112 insertions(+), 15 deletions(-)
diff --git a/drivers/kvm/irq.h b/drivers/kvm/irq.h
index 11fc014..afbfa0c 100644
--- a/drivers/kvm/irq.h
+++ b/drivers/kvm/irq.h
@@ -118,6 +118,8 @@ struct kvm_lapic {
struct kvm_vcpu *vcpu;
struct page *regs_page;
void *regs;
+ struct page *apic_access_page;
+ hpa_t apic_access_hpa;
};
#ifdef DEBUG
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 051cdbe..bb8534a 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -565,7 +565,7 @@ enum emulation_result {
};
int emulate_instruction(struct kvm_vcpu *vcpu, struct kvm_run *run,
- unsigned long cr2, u16 error_code, int
no_decode);
+ unsigned long cr2, u16 error_code, int
cmd_type);
void kvm_report_emulation_failure(struct kvm_vcpu *cvpu, const char
*context);
void realmode_lgdt(struct kvm_vcpu *vcpu, u16 size, unsigned long
address);
void realmode_lidt(struct kvm_vcpu *vcpu, u16 size, unsigned long
address);
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index cecdb1b..0ebae4c 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1080,14 +1080,19 @@ static int emulator_read_emulated(unsigned long
addr,
memcpy(val, vcpu-mmio_data, bytes);
vcpu-mmio_read_completed = 0;
return X86EMUL_CONTINUE;
- } else if (emulator_read_std(addr, val, bytes, vcpu)
- == X86EMUL_CONTINUE)
- return X86EMUL_CONTINUE;
+ }
