date:20070918

Re: [kvm-devel] [PATCH 0/5] Split the emulator: decode & execute

2007-09-18 Thread Laurent Vivier

Avi Kivity wrote:
> Laurent Vivier wrote:
>> Avi Kivity wrote:
>>  
>>> Laurent Vivier (Bull) wrote:
>>>
> Not being able to emulate is sometimes legitimate.  In the case of
> writing to a write-protected guest page table, we simply
> un-write-protect it and go back to the guest (which should now execute
> the instruction natively).
>
> Perhaps the logic that deals with this (the call to
> kvm_mmu_unprotect_page_virt() in emulate_instruction()) was broken by
> your changes.
>
> 
 In fact this case is managed in the error cases of
 emulate_instruction(). My first patch removes this management for
 instruction decoding because I supposed it cannot generate such errors.
 So what I proposed in my last email seems to be the good solution :

 emulate_instruction()
 ...
 r = x86_decode_insn(&vcpu->emulate_ctxt, &emulate_ops);
 if (r == 0)
 r = x86_emulate_insn(&vcpu->emulate_ctxt,
 &emulate_ops);
 ...
 if (r) {
 if (kvm_mmu_unprotect_page_virt(vcpu, cr2))
 return EMULATE_DONE;
 if (!vcpu->mmio_needed) {
 kvm_report_emulation_failure(vcpu, "mmio");
 return EMULATE_FAIL;
 }
 return EMULATE_DO_MMIO;
 }
 ...

   
>>> Yes.  But pushing the kvm_mmu_unprotect_page() to immediately after
>>> the decode stage may be better.
>>>
>>> 
>>
>> OK, but is this the only error case we can have in the decode stage ?
>>   
> 
> Decode can actually have fetch faults in smp (due to the instruction
> lengthening during decode, or due to the page tables changing with
> npt/ept).
> 
> I think these are the only two errors possible for decode: can't decode
> and can't fetch.
> 
>> Should we remove it from after the emulate stage ?
>>
>>   
> 
> Instruction execution shouldn't cause decode failures, so yes, that
> error shouldn't be emitted there.
> 
> But we can defer these fine tunings until later. Let's merge something
> that works first.

Agree, I think it is better to merge something close to the original behavior
before improving it.

I try to post patches today.

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

[kvm-devel] [ kvm-Bugs-1796939 ] network issue of 64bit linux guest

2007-09-18 Thread SourceForge.net

Bugs item #1796939, was opened at 2007-09-18 17:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1796939&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: yunfeng (yunfeng)
Assigned to: Nobody/Anonymous (nobody)
Summary: network issue of 64bit linux guest

Initial Comment:
Environment:

HOST (ia32/ia32e/IA64): ia32e
GUEST (ia32/ia32e/IA64): ia32e
COMMIT: 
21bd205a4c38c06d25f93f20b0e6b26c75f84f44-1edeb9c05aa034633978f31e2c773a1be55ed337
Hardware: harwich/paxville



Bug detailed description:
--
Network of 64bit guest will be lost while copying small files from guest to 
host with scp command. 

error info on host:
[EMAIL PROTECTED] ~]# scp ly test temp* 192.168.134.37:/root/
ssh: connect to host 192.168.134.37 port 22: No route to host
lost connection

error info on guest:
[EMAIL PROTECTED] ~]# scp ly test temp* 192.168.199.79:/root/
ssh: connect to host 192.168.199.79 port 22: No route to host
lost connection

Coping from host to guest has't this issue.
And 32bit guest hasn't this issue

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1796939&group_id=180599

-
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 5/5][RESEND] Call x86_decode_insn() only when needed

2007-09-18 Thread Laurent Vivier

move emulate_ctxt to kvm_vcpu to keep emulate context when we exit from kvm
module. Call x86_decode_insn() only when needed. Modify x86_emulate_insn() to
not modify the context if it must be re-entered.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>

Index: kvm/drivers/kvm/kvm.h
===
--- kvm.orig/drivers/kvm/kvm.h  2007-09-18 10:41:04.0 +0200
+++ kvm/drivers/kvm/kvm.h   2007-09-18 10:42:41.0 +0200
@@ -206,6 +206,8 @@ enum {
VCPU_SREG_LDTR,
 };
 
+#include "x86_emulate.h"
+
 struct kvm_pio_request {
unsigned long count;
int cur_count;
@@ -382,6 +384,10 @@ struct kvm_vcpu {
 
int cpuid_nent;
struct kvm_cpuid_entry cpuid_entries[KVM_MAX_CPUID_ENTRIES];
+
+   /* emulate context */
+
+   struct x86_emulate_ctxt emulate_ctxt;
 };
 
 struct kvm_mem_alias {
@@ -557,7 +563,7 @@ enum emulation_result {
 };
 
 int emulate_instruction(struct kvm_vcpu *vcpu, struct kvm_run *run,
-   unsigned long cr2, u16 error_code);
+   unsigned long cr2, u16 error_code, int no_decode);
 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);
Index: kvm/drivers/kvm/kvm_main.c
===
--- kvm.orig/drivers/kvm/kvm_main.c 2007-09-18 10:42:05.0 +0200
+++ kvm/drivers/kvm/kvm_main.c  2007-09-18 11:08:45.0 +0200
@@ -1251,45 +1251,56 @@ struct x86_emulate_ops emulate_ops = {
 int emulate_instruction(struct kvm_vcpu *vcpu,
struct kvm_run *run,
unsigned long cr2,
-   u16 error_code)
+   u16 error_code,
+   int no_decode)
 {
-   struct x86_emulate_ctxt emulate_ctxt;
-   int r;
-   int cs_db, cs_l;
+   int r = 0;
 
vcpu->mmio_fault_cr2 = cr2;
kvm_x86_ops->cache_regs(vcpu);
 
-   kvm_x86_ops->get_cs_db_l_bits(vcpu, &cs_db, &cs_l);
+   vcpu->mmio_is_write = 0;
+   vcpu->pio.string = 0;
 
-   emulate_ctxt.vcpu = vcpu;
-   emulate_ctxt.eflags = kvm_x86_ops->get_rflags(vcpu);
-   emulate_ctxt.cr2 = cr2;
-   emulate_ctxt.mode = (emulate_ctxt.eflags & X86_EFLAGS_VM)
-   ? X86EMUL_MODE_REAL : cs_l
-   ? X86EMUL_MODE_PROT64 : cs_db
-   ? X86EMUL_MODE_PROT32 : X86EMUL_MODE_PROT16;
-
-   if (emulate_ctxt.mode == X86EMUL_MODE_PROT64) {
-   emulate_ctxt.cs_base = 0;
-   emulate_ctxt.ds_base = 0;
-   emulate_ctxt.es_base = 0;
-   emulate_ctxt.ss_base = 0;
-   } else {
-   emulate_ctxt.cs_base = get_segment_base(vcpu, VCPU_SREG_CS);
-   emulate_ctxt.ds_base = get_segment_base(vcpu, VCPU_SREG_DS);
-   emulate_ctxt.es_base = get_segment_base(vcpu, VCPU_SREG_ES);
-   emulate_ctxt.ss_base = get_segment_base(vcpu, VCPU_SREG_SS);
-   }
+   if (!no_decode) {
+   int cs_db, cs_l;
+   kvm_x86_ops->get_cs_db_l_bits(vcpu, &cs_db, &cs_l);
+
+   vcpu->emulate_ctxt.vcpu = vcpu;
+   vcpu->emulate_ctxt.eflags = kvm_x86_ops->get_rflags(vcpu);
+   vcpu->emulate_ctxt.cr2 = cr2;
+   vcpu->emulate_ctxt.mode =
+   (vcpu->emulate_ctxt.eflags & X86_EFLAGS_VM)
+   ? X86EMUL_MODE_REAL : cs_l
+   ? X86EMUL_MODE_PROT64 : cs_db
+   ? X86EMUL_MODE_PROT32 : X86EMUL_MODE_PROT16;
+
+   if (vcpu->emulate_ctxt.mode == X86EMUL_MODE_PROT64) {
+   vcpu->emulate_ctxt.cs_base = 0;
+   vcpu->emulate_ctxt.ds_base = 0;
+   vcpu->emulate_ctxt.es_base = 0;
+   vcpu->emulate_ctxt.ss_base = 0;
+   } else {
+   vcpu->emulate_ctxt.cs_base =
+   get_segment_base(vcpu, VCPU_SREG_CS);
+   vcpu->emulate_ctxt.ds_base =
+   get_segment_base(vcpu, VCPU_SREG_DS);
+   vcpu->emulate_ctxt.es_base =
+   get_segment_base(vcpu, VCPU_SREG_ES);
+   vcpu->emulate_ctxt.ss_base =
+   get_segment_base(vcpu, VCPU_SREG_SS);
+   }
 
-   emulate_ctxt.gs_base = get_segment_base(vcpu, VCPU_SREG_GS);
-   emulate_ctxt.fs_base = get_segment_base(vcpu, VCPU_SREG_FS);
+   vcpu->emulate_ctxt.gs_base =
+   get_segment_base(vcpu, VCPU_SREG_GS);
+   vcpu->emulate_ctxt.fs_base =
+   get_segment_base(vcpu, VCPU_SREG_FS);
+
+

[kvm-devel] Test report for KVM, kvm.git: 93f9d893.. , kvm-userspace.git 1edeb9c0..

2007-09-18 Thread Zhao, Yunfeng

Hi,

This is today's KVM test result against kvm.git
93f9d89379572b47006840d6a6ca22cc9e1548b2 and kvm-userspace.git
1edeb9c05aa034633978f31e2c773a1be55ed337.
One issue has been fixed:
1. guest timer 2 times faster than network timer
https://sourceforge.net/tracker/index.php?func=detail&aid=1791444&group_
id=180599&atid=893831

Two new issues have found:
1. Network issue of 64bit linux guest
https://sourceforge.net/tracker/index.php?func=detail&aid=1796939&group_
id=180599&atid=893831
2. blue screen while install 64bit vista
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1796941&gro
up_id=180599

Following Issues still exist

1. 64bit 4GB guest cannot start network
https://sourceforge.net/tracker/index.php?func=detail&aid=1792984&group_
id=180599&atid=893831
2. high cpu usage of 32bit windows xp/2003
https://sourceforge.net/tracker/index.php?func=detail&aid=1792999&group_
id=180599&atid=893831
3. Create multiple guests simultaneously or create one guest many times
may fail 
https://sourceforge.net/tracker/index.php?func=detail&aid=1741312&group_
id=180599&atid=893831
4. Can not boot IA32e RHEL 4u3 guest with -no-acpi
https://sourceforge.net/tracker/index.php?func=detail&aid=1741314&group_
id=180599&atid=893831
5. Some ltp test cases fail
https://sourceforge.net/tracker/index.php?func=detail&aid=1741316&group_
id=180599&atid=893831
6. Cannot boot window 2k guest
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1768187&gro
up_id=180599
7. Linux guest crash without nolapic, 2.6.22 kernel.
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1769884&gro
up_id=180599
8. Can not install 64bit Vista guest


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

[kvm-devel] [PATCH 4/5][RESEND] emulate_instruction() calls now x86_decode_insn() and x86_emulate_insn()

2007-09-18 Thread Laurent Vivier

emulate_instruction() calls now x86_decode_insn() and x86_emulate_insn().
x86_emulate_insn() is x86_emulate_memop() without the decoding part.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>

Index: kvm/drivers/kvm/kvm_main.c
===
--- kvm.orig/drivers/kvm/kvm_main.c 2007-09-18 09:45:19.0 +0200
+++ kvm/drivers/kvm/kvm_main.c  2007-09-18 10:40:45.0 +0200
@@ -1287,7 +1287,10 @@ int emulate_instruction(struct kvm_vcpu 
 
vcpu->mmio_is_write = 0;
vcpu->pio.string = 0;
-   r = x86_emulate_memop(&emulate_ctxt, &emulate_ops);
+   r = x86_decode_insn(&emulate_ctxt, &emulate_ops);
+   if (r == 0)
+   r = x86_emulate_insn(&emulate_ctxt, &emulate_ops);
+
if (vcpu->pio.string)
return EMULATE_DO_MMIO;
 
Index: kvm/drivers/kvm/x86_emulate.c
===
--- kvm.orig/drivers/kvm/x86_emulate.c  2007-09-18 10:40:37.0 +0200
+++ kvm/drivers/kvm/x86_emulate.c   2007-09-18 10:40:45.0 +0200
@@ -911,18 +911,14 @@ done:
 }
 
 int
-x86_emulate_memop(struct x86_emulate_ctxt *ctxt, struct x86_emulate_ops *ops)
+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 _eflags = ctxt->eflags;
struct decode_cache *decode = &ctxt->decode;
-   int rc;
-
-   rc = x86_decode_insn(ctxt, ops);
-   if (rc)
-   return rc;
+   int rc = 0;
 
if (decode->src.type == OP_MEM) {
decode->src.ptr = (unsigned long *)ctxt->cr2;
Index: kvm/drivers/kvm/x86_emulate.h
===
--- kvm.orig/drivers/kvm/x86_emulate.h  2007-09-18 10:06:02.0 +0200
+++ kvm/drivers/kvm/x86_emulate.h   2007-09-18 10:40:45.0 +0200
@@ -178,12 +178,9 @@ struct x86_emulate_ctxt {
 #define X86EMUL_MODE_HOST X86EMUL_MODE_PROT64
 #endif
 
-/*
- * x86_emulate_memop: Emulate an instruction that faulted attempting to
- *read/write a 'special' memory area.
- * Returns -1 on failure, 0 on success.
- */
-int x86_emulate_memop(struct x86_emulate_ctxt *ctxt,
- struct x86_emulate_ops *ops);
+int x86_decode_insn(struct x86_emulate_ctxt *ctxt,
+   struct x86_emulate_ops *ops);
+int x86_emulate_insn(struct x86_emulate_ctxt *ctxt,
+struct x86_emulate_ops *ops);
 
 #endif /* __X86_EMULATE_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] [PATCH 3/5][RESEND] move all decoding process to function x86_decode_insn().

2007-09-18 Thread Laurent Vivier

move all decoding process to function x86_decode_insn().

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>

Index: kvm/drivers/kvm/x86_emulate.c
===
--- kvm.orig/drivers/kvm/x86_emulate.c  2007-09-18 10:41:06.0 +0200
+++ kvm/drivers/kvm/x86_emulate.c   2007-09-18 10:41:40.0 +0200
@@ -518,20 +518,16 @@ static int test_cc(unsigned int conditio
 }
 
 int
-x86_emulate_memop(struct x86_emulate_ctxt *ctxt, struct x86_emulate_ops *ops)
+x86_decode_insn(struct x86_emulate_ctxt *ctxt, struct x86_emulate_ops *ops)
 {
struct decode_cache *decode = &ctxt->decode;
u8 sib, rex_prefix = 0;
unsigned int i;
int rc = 0;
-   unsigned long cr2 = ctxt->cr2;
int mode = ctxt->mode;
int index_reg = 0, base_reg = 0, scale, rip_relative = 0;
-   int no_wb = 0;
-   u64 msr_data;
 
/* Shadow copy of register state. Committed on successful emulation. */
-   unsigned long _eflags = ctxt->eflags;
 
memset(decode, 0, sizeof(struct decode_cache));
decode->eip = ctxt->vcpu->rip;
@@ -624,8 +620,10 @@ done_prefixes:
}
 
/* Unrecognised? */
-   if (decode->d == 0)
-   goto cannot_emulate;
+   if (decode->d == 0) {
+   DPRINTF("Cannot emulate %02x\n", decode->b);
+   return -1;
+   }
}
 
/* ModRM and SIB bytes. */
@@ -789,7 +787,7 @@ done_prefixes:
}
if (decode->ad_bytes != 8)
decode->modrm_ea = (u32)decode->modrm_ea;
-   cr2 = decode->modrm_ea;
+   ctxt->cr2 = decode->modrm_ea;
modrm_done:
;
}
@@ -844,13 +842,6 @@ done_prefixes:
break;
  srcmem_common:
decode->src.type = OP_MEM;
-   decode->src.ptr = (unsigned long *)cr2;
-   decode->src.val = 0;
-   if ((rc = ops->read_emulated((unsigned long)decode->src.ptr,
-  &decode->src.val,
-  decode->src.bytes, ctxt->vcpu)) != 0)
-   goto done;
-   decode->src.orig_val = decode->src.val;
break;
case SrcImm:
decode->src.type = OP_IMM;
@@ -883,7 +874,7 @@ done_prefixes:
switch (decode->d & DstMask) {
case ImplicitOps:
/* Special instructions do their own operand decoding. */
-   goto special_insn;
+   return 0;
case DstReg:
decode->dst.type = OP_REG;
if ((decode->d & ByteOp)
@@ -912,7 +903,44 @@ done_prefixes:
break;
case DstMem:
decode->dst.type = OP_MEM;
-   decode->dst.ptr = (unsigned long *)cr2;
+   break;
+   }
+
+done:
+   return (rc == X86EMUL_UNHANDLEABLE) ? -1 : 0;
+}
+
+int
+x86_emulate_memop(struct x86_emulate_ctxt *ctxt, struct x86_emulate_ops *ops)
+{
+   unsigned long cr2 = ctxt->cr2;
+   int no_wb = 0;
+   u64 msr_data;
+   unsigned long _eflags = ctxt->eflags;
+   struct decode_cache *decode = &ctxt->decode;
+   int rc;
+
+   rc = x86_decode_insn(ctxt, ops);
+   if (rc)
+   return rc;
+
+   if (decode->src.type == OP_MEM) {
+   decode->src.ptr = (unsigned long *)ctxt->cr2;
+   decode->src.val = 0;
+   if ((rc = ops->read_emulated((unsigned long)decode->src.ptr,
+&decode->src.val,
+decode->src.bytes,
+ctxt->vcpu)) != 0)
+   goto done;
+   decode->src.orig_val = decode->src.val;
+   }
+
+   if ((decode->d & DstMask) == ImplicitOps)
+   goto special_insn;
+
+
+   if (decode->dst.type == OP_MEM) {
+   decode->dst.ptr = (unsigned long *)ctxt->cr2;
decode->dst.bytes = (decode->d & ByteOp) ? 1 : decode->op_bytes;
decode->dst.val = 0;
if (decode->d & BitOp) {
@@ -927,7 +955,6 @@ done_prefixes:
   &decode->dst.val,
  decode->dst.bytes, ctxt->vcpu)) != 0))
goto done;
-   break;
}
decode->dst.orig_val = decode->dst.val;
 
@@ -985,7 +1012,7 @@ done_prefixes:
emulate_2op_SrcV("cmp", decode->src, decode->dst, _eflags);
break;
case 0x63:  /* movsxd */
-   if (mode != X86EMUL_MODE_PROT64)
+   if (ctxt->mode != X86EMUL_MODE_PROT64)
goto cannot_emulate;
decode->dst.val = (s32) decode->src.val;
break;

[kvm-devel] [PATCH 0/5][RESEND] Split the emulator: decode & execute

2007-09-18 Thread Laurent Vivier

These patches split the emulator in two parts: one to decode the instruction,
the other to execute it. The decode part is then called only when needed.

[PATCH 1/5] x86_emulate-remove_unused, some cleanup: remove unused functions
[PATCH 2/5] x86_emulate-context, move all x86_emulate_memop() common variables
between decode and execute to a structure decode_cache.

struct decode_cache {
u8 twobyte;
u8 b;
u8 lock_prefix;
u8 rep_prefix;
u8 op_bytes;
u8 ad_bytes;
struct operand src;
struct operand dst;
unsigned long *override_base;
unsigned int d;
unsigned long regs[NR_VCPU_REGS];
unsigned long eip;
/* modrm */
u8 modrm;
u8 modrm_mod;
u8 modrm_reg;
u8 modrm_rm;
u8 use_modrm_ea;
unsigned long modrm_ea;
unsigned long modrm_val;
   };

[PATCH 3/5] x86_emulate-decode_insn, move all decoding process to function
x86_decode_insn().
[PATCH 4/5] x86_emulate-split, emulate_instruction() calls now x86_decode_insn()
and x86_emulate_insn(). x86_emulate_insn() is x86_emulate_memop()
without the decoding part.
[PATCH 5/5] x86_emulate-optimize, move emulate_ctxt to kvm_vcpu to keep emulate
context when we exit from kvm module. Call x86_decode_insn() only
when needed. Modify x86_emulate_insn() to not modify the context if
it must be re-entered.

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
-- 
- [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

[kvm-devel] [PATCH 1/5][RESEND] some cleanup: remove unused functions

2007-09-18 Thread Laurent Vivier

Remove #ifdef functions never used

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>

Index: kvm/drivers/kvm/x86_emulate.c
===
--- kvm.orig/drivers/kvm/x86_emulate.c  2007-09-16 11:33:01.0 +0200
+++ kvm/drivers/kvm/x86_emulate.c   2007-09-17 09:05:19.0 +0200
@@ -1598,42 +1598,3 @@ cannot_emulate:
DPRINTF("Cannot emulate %02x\n", b);
return -1;
 }
-
-#ifdef __XEN__
-
-#include 
-#include 
-
-int
-x86_emulate_read_std(unsigned long addr,
-unsigned long *val,
-unsigned int bytes, struct x86_emulate_ctxt *ctxt)
-{
-   unsigned int rc;
-
-   *val = 0;
-
-   if ((rc = copy_from_user((void *)val, (void *)addr, bytes)) != 0) {
-   propagate_page_fault(addr + bytes - rc, 0); /* read fault */
-   return X86EMUL_PROPAGATE_FAULT;
-   }
-
-   return X86EMUL_CONTINUE;
-}
-
-int
-x86_emulate_write_std(unsigned long addr,
- unsigned long val,
- unsigned int bytes, struct x86_emulate_ctxt *ctxt)
-{
-   unsigned int rc;
-
-   if ((rc = copy_to_user((void *)addr, (void *)&val, bytes)) != 0) {
-   propagate_page_fault(addr + bytes - rc, PGERR_write_access);
-   return X86EMUL_PROPAGATE_FAULT;
-   }
-
-   return X86EMUL_CONTINUE;
-}
-
-#endif
-
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 001/104] KVM: Fix *nopage() in kvm_main.c

2007-09-18 Thread Nick Piggin

On Tuesday 18 September 2007 04:19, Avi Kivity wrote:
> Nick Piggin wrote:
> >> I should mention that the converting to use ->fault() is a 15-minute
> >> change; the tricky part is adding backwards compatibility for the
> >> external module package.
> >
> > It should be mostly possible to ifdef a nopage() handler, which is
> > just a wrapper function to translate arguments then call your new
> > ->fault() handler. With luck, fault would mostly inline into nopage,
> > and do some constant folding to make it cheaper...
> >
> > I'm planning to go through and convert the rest of the in-tree users
> > at some point soon, so if you do get a chance to convert your
> > upstream code before I try, it would nice ;)
>
> In kvm I don't add compatibility #ifdefs to mainline, instead I have an
> awk script that massages the sources into something that all kernels can
> grok.

Sure, but my suggestion is just a way to make it possible without having
to maintain a lot of duplicated code. The point is simply that we'll be
getting rid of nopage from mainline sooner or later, and it will probably
be less painful for your out of tree stuff if you do it rather than me. Maybe.

> It isn't pretty but it works.

It is pretty for mainline :) I appreciate you going out of your way to make
the code nicer rather than just make your life easier.

-
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] Add vmmcall/vmcall to x86_emulate (v3)

2007-09-18 Thread Avi Kivity

Anthony Liguori wrote:
> Add vmmcall/vmcall to x86_emulate.  Future patch will implement functionality
> for these instructions.
>
>   

Applied 1-3, 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

[kvm-devel] [PATCH 2/5][RESEND] move all x86_emulate_memop() to a structure

2007-09-18 Thread Laurent Vivier

move all x86_emulate_memop() common variables between decode and execute to a
structure decode_cache.

struct decode_cache {
u8 twobyte;
u8 b;
u8 lock_prefix;
u8 rep_prefix;
u8 op_bytes;
u8 ad_bytes;
struct operand src;
struct operand dst;
unsigned long *override_base;
unsigned int d;
unsigned long regs[NR_VCPU_REGS];
unsigned long eip;
/* modrm */
u8 modrm;
u8 modrm_mod;
u8 modrm_reg;
u8 modrm_rm;
u8 use_modrm_ea;
unsigned long modrm_ea;
unsigned long modrm_val;
   };

Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>

Index: kvm/drivers/kvm/x86_emulate.c
===
--- kvm.orig/drivers/kvm/x86_emulate.c  2007-09-18 10:01:56.0 +0200
+++ kvm/drivers/kvm/x86_emulate.c   2007-09-18 10:05:42.0 +0200
@@ -221,13 +221,6 @@ static u16 twobyte_table[256] = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
 };
 
-/* Type, address-of, and value of an instruction's operand. */
-struct operand {
-   enum { OP_REG, OP_MEM, OP_IMM } type;
-   unsigned int bytes;
-   unsigned long val, orig_val, *ptr;
-};
-
 /* EFLAGS bit definitions. */
 #define EFLG_OF (1<<11)
 #define EFLG_DF (1<<10)
@@ -430,25 +423,28 @@ struct operand {
 
 /* Access/update address held in a register, based on addressing mode. */
 #define address_mask(reg)  \
-   ((ad_bytes == sizeof(unsigned long)) ?  \
-   (reg) : ((reg) & ((1UL << (ad_bytes << 3)) - 1)))
+   ((decode->ad_bytes == sizeof(unsigned long)) ?  \
+   (reg) : ((reg) & ((1UL << (decode->ad_bytes << 3)) - 1)))
 #define register_address(base, reg) \
((base) + address_mask(reg))
 #define register_address_increment(reg, inc)\
do {\
/* signed type ensures sign extension to long */\
int _inc = (inc);   \
-   if ( ad_bytes == sizeof(unsigned long) )\
+   if (decode->ad_bytes == sizeof(unsigned long))  \
(reg) += _inc;  \
else\
-   (reg) = ((reg) & ~((1UL << (ad_bytes << 3)) - 1)) | \
-  (((reg) + _inc) & ((1UL << (ad_bytes << 3)) - 1)); \
+   (reg) = ((reg) &\
+~((1UL << (decode->ad_bytes << 3)) - 1)) | \
+  (((reg) + _inc) &\
+  ((1UL << (decode->ad_bytes << 3)) - 1)); \
} while (0)
 
 #define JMP_REL(rel)   \
do {\
-   _eip += (int)(rel); \
-   _eip = ((op_bytes == 2) ? (uint16_t)_eip : (uint32_t)_eip); \
+   decode->eip += (int)(rel);  \
+   decode->eip = ((decode->op_bytes == 2) ?\
+   (uint16_t)decode->eip : (uint32_t)decode->eip); \
} while (0)
 
 /*
@@ -524,39 +520,35 @@ static int test_cc(unsigned int conditio
 int
 x86_emulate_memop(struct x86_emulate_ctxt *ctxt, struct x86_emulate_ops *ops)
 {
-   unsigned d;
-   u8 b, sib, twobyte = 0, rex_prefix = 0;
-   u8 modrm, modrm_mod = 0, modrm_reg = 0, modrm_rm = 0;
-   unsigned long *override_base = NULL;
-   unsigned int op_bytes, ad_bytes, lock_prefix = 0, rep_prefix = 0, i;
+   struct decode_cache *decode = &ctxt->decode;
+   u8 sib, rex_prefix = 0;
+   unsigned int i;
int rc = 0;
-   struct operand src, dst;
unsigned long cr2 = ctxt->cr2;
int mode = ctxt->mode;
-   unsigned long modrm_ea;
-   int use_modrm_ea, index_reg = 0, base_reg = 0, scale, rip_relative = 0;
+   int index_reg = 0, base_reg = 0, scale, rip_relative = 0;
int no_wb = 0;
u64 msr_data;
 
/* Shadow copy of register state. Committed on successful emulation. */
-   unsigned long _regs[NR_VCPU_REGS];
-   unsigned long _eip = ctxt->vcpu->rip, _eflags = ctxt->eflags;
-   unsigned long modrm_val = 0;
+   unsigned long _eflags = ctxt->eflags;
 
-   memcpy(_regs, ctxt->vcpu->regs, sizeof _regs);
+   memset(decode, 0, sizeof(struct decode_cache));
+   decode->eip

[kvm-devel] [ kvm-Bugs-1796941 ] blue screen while install 64bit vista

2007-09-18 Thread SourceForge.net

Bugs item #1796941, was opened at 2007-09-18 17:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1796941&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: yunfeng (yunfeng)
Assigned to: Nobody/Anonymous (nobody)
Summary: blue screen while install 64bit vista

Initial Comment:
Installer of 64bit vista crashes with blue screen error after booting for a 
little while.
If adding -no-kvm, the installation will have no any problem.
See the attached snapshot pic.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1796941&group_id=180599

-
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 report for KVM, kvm.git: 93f9d893.. , kvm-userspace.git 1edeb9c0..

2007-09-18 Thread Avi Kivity

Zhao, Yunfeng wrote:Izik is addressing

> 2. blue screen while install 64bit vista
> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1796941&gro
> up_id=180599
>   

Can you say what was the last version (or commit hash) which worked?

-- 
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 0/5][RESEND] Split the emulator: decode & execute

2007-09-18 Thread Laurent Vivier

Avi Kivity wrote:
> Laurent Vivier wrote:
>> These patches split the emulator in two parts: one to decode the instruction,
>> the other to execute it. The decode part is then called only when needed.
>>
>>   
> 
> Applied all, thanks.
> 
> I changed the name of the variable 'decode' to 'c' to reduce the number 
> of line splits.

No problem

> This patchset, in addition to the correctness issues, also enables 
> further cleaning up of x86_emulate.c: since most variables are now in a 
> structure, chunks of the code can be moved to a separate function that 
> takes just the decode cache.  This will reduce
> the high indent level and increase readability.

I can do that 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/5][RESEND] Split the emulator: decode & execute

2007-09-18 Thread Avi Kivity

Laurent Vivier wrote:
> These patches split the emulator in two parts: one to decode the instruction,
> the other to execute it. The decode part is then called only when needed.
>
>   

Applied all, thanks.

I changed the name of the variable 'decode' to 'c' to reduce the number 
of line splits.

This patchset, in addition to the correctness issues, also enables 
further cleaning up of x86_emulate.c: since most variables are now in a 
structure, chunks of the code can be moved to a separate function that 
takes just the decode cache.  This will reduce
the high indent level and increase readability.

-- 
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 001/104] KVM: Fix *nopage() in kvm_main.c

2007-09-18 Thread Avi Kivity

Nick Piggin wrote:
> On Tuesday 18 September 2007 04:19, Avi Kivity wrote:
>   
>> Nick Piggin wrote:
>> 
 I should mention that the converting to use ->fault() is a 15-minute
 change; the tricky part is adding backwards compatibility for the
 external module package.
 
>>> It should be mostly possible to ifdef a nopage() handler, which is
>>> just a wrapper function to translate arguments then call your new
>>> ->fault() handler. With luck, fault would mostly inline into nopage,
>>> and do some constant folding to make it cheaper...
>>>
>>> I'm planning to go through and convert the rest of the in-tree users
>>> at some point soon, so if you do get a chance to convert your
>>> upstream code before I try, it would nice ;)
>>>   
>> In kvm I don't add compatibility #ifdefs to mainline, instead I have an
>> awk script that massages the sources into something that all kernels can
>> grok.
>> 
>
> Sure, but my suggestion is just a way to make it possible without having
> to maintain a lot of duplicated code. The point is simply that we'll be
> getting rid of nopage from mainline sooner or later, and it will probably
> be less painful for your out of tree stuff if you do it rather than me. Maybe.
>
>   

Certainly it's best done by someone familiar with the kvm external 
module hackery.  I'll do it during 2.6.24 if no one beats me to it.

-- 
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] [ kvm-Bugs-1796939 ] network issue of 64bit linux guest

2007-09-18 Thread Avi Kivity

SourceForge.net wrote:
>
> Bug detailed description:
> --
> Network of 64bit guest will be lost while copying small files from guest to 
> host with scp command. 
>
> error info on host:
> [EMAIL PROTECTED] ~]# scp ly test temp* 192.168.134.37:/root/
> ssh: connect to host 192.168.134.37 port 22: No route to host
> lost connection
>
>   

This can be worked around with '-no-kvm-irqchip' for kvm or 'noapic'  on 
the guest kernel command line.  Looks like a bug in ioapic emulation.

-- 
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] [ kvm-Bugs-1796939 ] network issue of 64bit linux guest

2007-09-18 Thread Avi Kivity

Avi Kivity wrote:
> SourceForge.net wrote:
>>
>> Bug detailed description:
>> --
>> Network of 64bit guest will be lost while copying small files from 
>> guest to host with scp command.
>> error info on host:
>> [EMAIL PROTECTED] ~]# scp ly test temp* 192.168.134.37:/root/
>> ssh: connect to host 192.168.134.37 port 22: No route to host
>> lost connection
>>
>>   
>
> This can be worked around with '-no-kvm-irqchip' for kvm or 'noapic'  
> on the guest kernel command line.  Looks like a bug in ioapic emulation.
>

Should now be fixed in kvm.git.

-- 
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] Refactor hypercall infrastructure (v3)

2007-09-18 Thread Avi Kivity

Anthony Liguori wrote:
> This patch refactors the current hypercall infrastructure to better support 
> live
> migration and SMP.  It eliminates the hypercall page by trapping the UD
> exception that would occur if you used the wrong hypercall instruction for the
> underlying architecture and replacing it with the right one lazily.
>
> It also introduces the infrastructure to probe for hypercall available via
> CPUID leaves 0x4000.  CPUID leaf 0x4001 should be filled out by
> userspace.
>
> A fall-out of this patch is that the unhandled hypercalls no longer trap to
> userspace.  There is very little reason though to use a hypercall to 
> communicate
> with userspace as PIO or MMIO can be used.  There is no code in tree that uses
> userspace hypercalls.
>
>   


Surprisingly, this patch kills Windows XP (ACPI HAL).  I'll try to find 
out why.


-- 
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] Refactor hypercall infrastructure (v3)

2007-09-18 Thread Avi Kivity

Avi Kivity wrote:
> Avi Kivity wrote:
>> Anthony Liguori wrote:
>>  
>>> This patch refactors the current hypercall infrastructure to better 
>>> support live
>>> migration and SMP.  It eliminates the hypercall page by trapping the UD
>>> exception that would occur if you used the wrong hypercall 
>>> instruction for the
>>> underlying architecture and replacing it with the right one lazily.
>>>
>>> It also introduces the infrastructure to probe for hypercall 
>>> available via
>>> CPUID leaves 0x4000.  CPUID leaf 0x4001 should be filled out by
>>> userspace.
>>>
>>> A fall-out of this patch is that the unhandled hypercalls no longer 
>>> trap to
>>> userspace.  There is very little reason though to use a hypercall to 
>>> communicate
>>> with userspace as PIO or MMIO can be used.  There is no code in tree 
>>> that uses
>>> userspace hypercalls.
>>>
>>>   
>>
>>
>> Surprisingly, this patch kills Windows XP (ACPI HAL).  I'll try to 
>> find out why.
>>
>>   
>
> Not trapping #UD brings things back to normal.  So, Windows likes to 
> execute undefined instructions, and we don'd handle these well.
>
Okay, vmx_inject_ud() was broken.  Fixed 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 2/3] Refactor hypercall infrastructure (v3)

2007-09-18 Thread Avi Kivity

Avi Kivity wrote:
> Anthony Liguori wrote:
>   
>> This patch refactors the current hypercall infrastructure to better support 
>> live
>> migration and SMP.  It eliminates the hypercall page by trapping the UD
>> exception that would occur if you used the wrong hypercall instruction for 
>> the
>> underlying architecture and replacing it with the right one lazily.
>>
>> It also introduces the infrastructure to probe for hypercall available via
>> CPUID leaves 0x4000.  CPUID leaf 0x4001 should be filled out by
>> userspace.
>>
>> A fall-out of this patch is that the unhandled hypercalls no longer trap to
>> userspace.  There is very little reason though to use a hypercall to 
>> communicate
>> with userspace as PIO or MMIO can be used.  There is no code in tree that 
>> uses
>> userspace hypercalls.
>>
>>   
>> 
>
>
> Surprisingly, this patch kills Windows XP (ACPI HAL).  I'll try to find 
> out why.
>
>   

Not trapping #UD brings things back to normal.  So, Windows likes to 
execute undefined instructions, and we don'd handle these well.

I really should start asking for unit tests for these kinds of things 
(execute undefined instruction, see the #UD, say ok).

-- 
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] Refactor hypercall infrastructure (v3)

2007-09-18 Thread Anthony Liguori

Avi Kivity wrote:
> Avi Kivity wrote:
>   
>> Avi Kivity wrote:
>> 
>>> Anthony Liguori wrote:
>>>  
>>>   
 This patch refactors the current hypercall infrastructure to better 
 support live
 migration and SMP.  It eliminates the hypercall page by trapping the UD
 exception that would occur if you used the wrong hypercall 
 instruction for the
 underlying architecture and replacing it with the right one lazily.

 It also introduces the infrastructure to probe for hypercall 
 available via
 CPUID leaves 0x4000.  CPUID leaf 0x4001 should be filled out by
 userspace.

 A fall-out of this patch is that the unhandled hypercalls no longer 
 trap to
 userspace.  There is very little reason though to use a hypercall to 
 communicate
 with userspace as PIO or MMIO can be used.  There is no code in tree 
 that uses
 userspace hypercalls.

>>> Surprisingly, this patch kills Windows XP (ACPI HAL).  I'll try to 
>>> find out why.
>>>
>>>   
>>>   
>> Not trapping #UD brings things back to normal.  So, Windows likes to 
>> execute undefined instructions, and we don'd handle these well.
>>
>> 
> Okay, vmx_inject_ud() was broken.  Fixed now.
>   

Yeah, I was just about to send the patch for that.  Sorry about that, I 
didn't even think to test Windows...

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] windows 2003 smp guest

2007-09-18 Thread Avi Kivity

Haydn Solomon wrote:
> I am interested in installing smp windows 2003 server guest and have 
> some questions.
>
> 1.  Is windows smp guest working and performing well at this point in kvm?

It's working will with -no-kvm-irqchip.  Not so sure without the switch, 
but we're improving things.

I haven't tested performance very thoroughly.  What's your workload?

> 2.  If question 1 above is true, then what HAL should I choose during 
> installation and what other flags should I use when running it?
>

Good question.  What HALs are available for Windows 2003 SMP?

-- 
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] windows 2003 smp guest

2007-09-18 Thread Haydn Solomon

I am interested in installing smp windows 2003 server guest and have some
questions.

1.  Is windows smp guest working and performing well at this point in kvm?
2.  If question 1 above is true, then what HAL should I choose during
installation and what other flags should I use when running it?

Thanks for any help in advance.

Haydn
-
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] windows 2003 smp guest

2007-09-18 Thread Haydn Solomon

On 9/18/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
>
> Haydn Solomon wrote:
> >
> >
> > On 9/18/07, *Avi Kivity* <[EMAIL PROTECTED] >
> > wrote:
> >
> >
> >
> > It's working will with -no-kvm-irqchip.  Not so sure without the
> > switch,
> > but we're improving things.
> >
> > I haven't tested performance very thoroughly.  What's your workload?
> >
> >
> > My workload medium to high. Running full cisco labs using cisco
> emulator.
>
> Well, no idea what that is.



Didn't think you would as this is more on the networking side.  You may find
it interesting as it actually an emulator emulating mips architecture (
which cisco ios runs on ) on x86. You can check it out at
http://www.ipflow.utc.fr/index.php/Cisco_7200_Simulator if you care to.

>
> >
> >
> > Good question.  What HALs are available for Windows 2003 SMP?
> >
> >
> > The following are available...
> >
> > acpi multiprocessor pc
> > acpi uniprocessor pc
> > acpi pc
> > mps uniprocessor pc
> > mps multiprocessor pc
> > standard pc
> > other
> >
> >
>
> mps multiprocessor may give the best performance, though I've never
> tested it.



I'll try this and provide some feedback.

> --
> > error compiling committee.c: too many arguments to function
> >
> >
> >
> > One other question. I'm doing this a core 2 duo and am wondering about
> > number vcpu. I know xen for example can have more vcpus than physical
> > cpus, example 4 vcpus on 2 physical cpus/cores. What is the
> > recommendation for best performance? I would imagine a one to one ie.
> > 2 vcpus on 2 cores/cpus?
> >
> >
>
> Yes, 1:1 (or less) is best.  Overcommitting cpus will definitely degrade
> performance drastically.



ok.

--
> 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] using the kvm python wrapper (was Re: [PATCH] Fallback to use /sbin/ifconfig if /sbin/ip is not available)

2007-09-18 Thread Avi Kivity

Carlo Marcelo Arenas Belon wrote:
> On Sun, Sep 16, 2007 at 12:03:05PM +0200, Avi Kivity wrote:
> 
>   
>> but why is anyone using this wrapper?  I thought I was the 
>> only one, and that from tradition rather than any real need.
>> 
>
> at least in my case, out of confusion, as it gets installed and is not
> prepared to work in an installed tree but in the root of a compiled one, hence
> generating errors when executed.
>
> FWIW, it is also being used by debian in their kvm package installed in
> /etc/kvm/utils/kvm as you can see from :
>
>   http://packages.debian.org/sid/kvm
>
> I agree though that it isn't really that useful, and in that case it should
> be probably removed (or at least not part of make install)
>   

I don't think it's installed as part of the kvm Makefile.  Maybe that's 
a debian specific thing?

-- 
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] windows 2003 smp guest

2007-09-18 Thread Haydn Solomon

On 9/18/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>
> It's working will with -no-kvm-irqchip.  Not so sure without the switch,
> but we're improving things.
>
> I haven't tested performance very thoroughly.  What's your workload?

My workload medium to high. Running full cisco labs using cisco emulator.

>
> Good question.  What HALs are available for Windows 2003 SMP?

The following are available...

acpi multiprocessor pc
acpi uniprocessor pc
acpi pc
mps uniprocessor pc
mps multiprocessor pc
standard pc
other

--
> error compiling committee.c: too many arguments to function

One other question. I'm doing this a core 2 duo and am wondering about
number vcpu. I know xen for example can have more vcpus than physical cpus,
example 4 vcpus on 2 physical cpus/cores. What is the recommendation for
best performance? I would imagine a one to one ie. 2 vcpus on 2 cores/cpus?
-
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] windows 2003 smp guest

2007-09-18 Thread Avi Kivity

Haydn Solomon wrote:
>
>
> On 9/18/07, *Avi Kivity* <[EMAIL PROTECTED] > 
> wrote:
>
>
>
> It's working will with -no-kvm-irqchip.  Not so sure without the
> switch,
> but we're improving things.
>
> I haven't tested performance very thoroughly.  What's your workload?
>
>
> My workload medium to high. Running full cisco labs using cisco emulator.

Well, no idea what that is.

>
>
>
> Good question.  What HALs are available for Windows 2003 SMP?
>
>
> The following are available...
>
> acpi multiprocessor pc
> acpi uniprocessor pc
> acpi pc
> mps uniprocessor pc
> mps multiprocessor pc
> standard pc
> other
>  
>

mps multiprocessor may give the best performance, though I've never 
tested it.

> --
> error compiling committee.c: too many arguments to function 
>
>
>
> One other question. I'm doing this a core 2 duo and am wondering about 
> number vcpu. I know xen for example can have more vcpus than physical 
> cpus, example 4 vcpus on 2 physical cpus/cores. What is the 
> recommendation for best performance? I would imagine a one to one ie. 
> 2 vcpus on 2 cores/cpus?
>
>

Yes, 1:1 (or less) is best.  Overcommitting cpus will definitely degrade 
performance drastically.

-- 
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] reduce msr efer reloads on heavyweight vmexit

2007-09-18 Thread Dong, Eddie

Avi Kivity wrote:
> Eddie, can you review the attached patch?  It improves on your efer
> reload patch by avoiding a reload even if EFER.SCE is different in the
> guest and host, in some scenarios.
> 
Avi:
Good optimization! It should be safe since SYSCALL/SYSRET will check 
following condition which will always leads to #UD in 32 bits guest no matter 
SCE is set or not.

IF (CS.L ≠ 1 ) or (IA32_EFER.LMA ≠ 1) or (IA32_EFER.SCE ≠ 1)
(* Not in 64-Bit Mode or SYSCALL/SYSRET not enabled in IA32_EFER *)
THEN #UD; FI;

thanks, eddie

-
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] windows 2003 smp guest

2007-09-18 Thread Haydn Solomon

>
> > >
> > >
> > > Good question.  What HALs are available for Windows 2003 SMP?
> > >
> > >
> > > The following are available...
> > >
> > > acpi multiprocessor pc
> > > acpi uniprocessor pc
> > > acpi pc
> > > mps uniprocessor pc
> > > mps multiprocessor pc
> > > standard pc
> > > other
> > >
> > >
> >
> > mps multiprocessor may give the best performance, though I've never
> > tested it.
>
>
>
> I'll try this and provide some feedback.
>


First attempt at this and qemu process hung during install.. it went to
sleep and never woke up. Any suggestions on what to try next?  My parameters
for install were as follows:

/usr/local/kvm/bin/qemu-system-x86_64 \
-hda server2k3r2smp.img \
-m 512 \
-no-rtc \
-localtime \
-smp 2 \
-no-kvm-irqchip \
-net nic,model=rtl8139 \
-net user \
-boot d \
-cdrom /home/hsolomon/isos/en_win_srv_2003_r2_enterprise_cd1.iso &
-
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] windows 2003 smp guest

2007-09-18 Thread Avi Kivity

Haydn Solomon wrote:
>
>
> >
> >
> >
> > Good question.  What HALs are available for Windows 2003 SMP?
> >
> >
> > The following are available...
> >
> > acpi multiprocessor pc
> > acpi uniprocessor pc
> > acpi pc
> > mps uniprocessor pc
> > mps multiprocessor pc
> > standard pc
> > other
> >
> >
>
> mps multiprocessor may give the best performance, though I've
> never
> tested it.
>
>
>
> I'll try this and provide some feedback.
>
>
>
> First attempt at this and qemu process hung during install.. it went 
> to sleep and never woke up. Any suggestions on what to try next?  My 
> parameters for install were as follows:
>
> /usr/local/kvm/bin/qemu-system-x86_64 \
> -hda server2k3r2smp.img \
> -m 512 \
> -no-rtc \
> -localtime \
> -smp 2 \
> -no-kvm-irqchip \
> -net nic,model=rtl8139 \
> -net user \
> -boot d \
> -cdrom /home/hsolomon/isos/en_win_srv_2003_r2_enterprise_cd1.iso &
>
>

I'll just have to debug this.  Looks like no one tried it before.

-- 
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] windows 2003 smp guest

2007-09-18 Thread Haydn Solomon

Many thanks.

On 9/18/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
>
> Haydn Solomon wrote:
> >
> >
> > >
> > >
> > >
> > > Good question.  What HALs are available for Windows 2003
> SMP?
> > >
> > >
> > > The following are available...
> > >
> > > acpi multiprocessor pc
> > > acpi uniprocessor pc
> > > acpi pc
> > > mps uniprocessor pc
> > > mps multiprocessor pc
> > > standard pc
> > > other
> > >
> > >
> >
> > mps multiprocessor may give the best performance, though I've
> > never
> > tested it.
> >
> >
> >
> > I'll try this and provide some feedback.
> >
> >
> >
> > First attempt at this and qemu process hung during install.. it went
> > to sleep and never woke up. Any suggestions on what to try next?  My
> > parameters for install were as follows:
> >
> > /usr/local/kvm/bin/qemu-system-x86_64 \
> > -hda server2k3r2smp.img \
> > -m 512 \
> > -no-rtc \
> > -localtime \
> > -smp 2 \
> > -no-kvm-irqchip \
> > -net nic,model=rtl8139 \
> > -net user \
> > -boot d \
> > -cdrom /home/hsolomon/isos/en_win_srv_2003_r2_enterprise_cd1.iso &
> >
> >
>
> I'll just have to debug this.  Looks like no one tried it before.
>
> --
> 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] [ kvm-Bugs-1797204 ] Mouse disappears

2007-09-18 Thread SourceForge.net

Bugs item #1797204, was opened at 2007-09-18 13:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1797204&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert McGwier (rwmcgwier)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mouse disappears

Initial Comment:
I am attempting to install Fedora Core 7 i386 in a Qemu/Kvm image under Ubuntu 
7.04 x86_64.  With the exception of the usual acpi snafus, the entire thing 
goes smoothly, and reboots and runs.  As soon as Qemu captures the mouse and it 
is touched,  it disappears.  


This is a generic USB mouse plugged into A Dell Optiplex 745 with a Q6700 
Intel.  The kvm_intel virtualization works (the speed difference is profound),  
the tap bridge to the etherne works (FC 7 informs me there are 187 packages to 
update on a minimal install) but no mouse at all.

I am running kvm-40.  Ubuntu 7.04 64 bit latest updates is the host,  FC7 
standard DVD iso distro is the guest.  No mouse.

Bob McGwier




--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1797204&group_id=180599

-
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] [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

2007-09-18 Thread Anthony Liguori

Ryan Harper wrote:
> Playing around with running VMware-server within a KVM guest and noticed
> that whenever we launch a VM within the guest, KVM reports a GP fault in
> set_cr3.  Removing the fault injection (raised for attempting to set
> reserved bits) for the non-pae case allows memtest to boot and run 
> within VMWare Server, running in a KVM Linux guest.
>
> This same test (Linux, VMware-server, booting/running memtest iso) works
> fine on bare-metal.  Thoughts?
>   

Setting reserved bits is different from setting MBZ bits since the 
behaviors undefined.  If something as common as VMware is depending on 
being able to set a reserved bit then perhaps the right thing to do from 
KVM's perspective is to let it.

I'm curious if Zach or Jun have any comments about the right thing to do 
here.

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

-
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] Gigabit networking speeds

2007-09-18 Thread Anthony Liguori

Gerard Saraber wrote:
> Hi,
> we were testing the network throughput with some simple wget tests,
> grabbing a 112MB file off another machine, the host OS gets 46MB/sec
> transferring that file, but the guest virtual ones only get 10-14MB/sec,
> I'm using model=rtl8139 for the nic, and a tap via a bridge,

This is unfortunately the expected results with the rtl8139 nic.  Dor 
and Rusty's PV network driver should give you closer to your expected 
results.  Dor posted a link pretty recently to it.  It will probably be 
a little while before it's all ready for prime-time though.

Regards,

Anthony Liguori

>  I'm
> wondering if I'm doing something wrong, is there another nic model I can
> use to make it faster? or use a different method besides the network tap
> +bridge thing? 
> I tested two guests pulling the same file at the same time, both got
> ~10MB/sec, so it seems the host is up to it, but the guests are somehow
> limited..
> I saw some patches for an "IOQ" driver, should I be using a different
> kernel tree?
>
> I'm using kvm-40 and linux 2.6.23-rc6
>
>   

-
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] ignore set_cr3 GP fault in non-pae mode

2007-09-18 Thread Ryan Harper

Playing around with running VMware-server within a KVM guest and noticed
that whenever we launch a VM within the guest, KVM reports a GP fault in
set_cr3.  Removing the fault injection (raised for attempting to set
reserved bits) for the non-pae case allows memtest to boot and run 
within VMWare Server, running in a KVM Linux guest.

This same test (Linux, VMware-server, booting/running memtest iso) works
fine on bare-metal.  Thoughts?

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
[EMAIL PROTECTED]

This patch removes the fault injected when the guest attempts to set reserved
bits in cr3.  X86 hardware doesn't generate a fault when setting reserved bits.
The result of this patch is that vmware-server, running within a kvm guest,
boots and runs memtest from an iso.

Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>

diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 353e585..386f9c1 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -573,13 +573,6 @@ void set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
inject_gp(vcpu);
return;
}
-   } else {
-   if (cr3 & CR3_NONPAE_RESERVED_BITS) {
-   printk(KERN_DEBUG
-  "set_cr3: #GP, reserved bits\n");
-   inject_gp(vcpu);
-   return;
-   }
}
}
 
-
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] Gigabit networking speeds

2007-09-18 Thread Gerard Saraber

Hi,
we were testing the network throughput with some simple wget tests,
grabbing a 112MB file off another machine, the host OS gets 46MB/sec
transferring that file, but the guest virtual ones only get 10-14MB/sec,
I'm using model=rtl8139 for the nic, and a tap via a bridge, I'm
wondering if I'm doing something wrong, is there another nic model I can
use to make it faster? or use a different method besides the network tap
+bridge thing? 
I tested two guests pulling the same file at the same time, both got
~10MB/sec, so it seems the host is up to it, but the guests are somehow
limited..
I saw some patches for an "IOQ" driver, should I be using a different
kernel tree?

I'm using kvm-40 and linux 2.6.23-rc6

-- 
Regards,
Gerard Saraber
Network Admin, Rarcoa, Inc.
(630) 654-2580 x199
[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

Re: [kvm-devel] [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

2007-09-18 Thread Nakajima, Jun

Anthony Liguori wrote:
> Ryan Harper wrote:
> > Playing around with running VMware-server within a KVM guest and
noticed
> > that whenever we launch a VM within the guest, KVM reports a GP
fault in
> > set_cr3.  Removing the fault injection (raised for attempting to set
> > reserved bits) for the non-pae case allows memtest to boot and run
> > within VMWare Server, running in a KVM Linux guest.
> > 
> > This same test (Linux, VMware-server, booting/running memtest iso)
works
> > fine on bare-metal.  Thoughts?
> > 
> 
> Setting reserved bits is different from setting MBZ bits since the
> behaviors undefined.  If something as common as VMware is depending on
> being able to set a reserved bit then perhaps the right thing to do
from
> KVM's perspective is to let it.
> 
> I'm curious if Zach or Jun have any comments about the right thing to
do
> here.
> 

As long as the guest is protected mode (unlike the long mode), the Intel
spec does _not_ say that reserved bits checking is enforced for CR3. As
far as I looked at the AMD spec, looks like #GP is caused even in
protected mode... Does the test work for AMD systems?

> Regards,
> 
> Anthony Liguori
> 

Jun
---
Intel Open Source Technology Center

-
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] [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

2007-09-18 Thread Ryan Harper

* Nakajima, Jun <[EMAIL PROTECTED]> [2007-09-18 16:22]:
> Anthony Liguori wrote:
> > Ryan Harper wrote:
> > > Playing around with running VMware-server within a KVM guest and
> noticed
> > > that whenever we launch a VM within the guest, KVM reports a GP
> fault in
> > > set_cr3.  Removing the fault injection (raised for attempting to set
> > > reserved bits) for the non-pae case allows memtest to boot and run
> > > within VMWare Server, running in a KVM Linux guest.
> > > 
> > > This same test (Linux, VMware-server, booting/running memtest iso)
> works
> > > fine on bare-metal.  Thoughts?
> > > 
> > 
> > Setting reserved bits is different from setting MBZ bits since the
> > behaviors undefined.  If something as common as VMware is depending on
> > being able to set a reserved bit then perhaps the right thing to do
> from
> > KVM's perspective is to let it.
> > 
> > I'm curious if Zach or Jun have any comments about the right thing to
> do
> > here.
> > 
> 
> As long as the guest is protected mode (unlike the long mode), the Intel
> spec does _not_ say that reserved bits checking is enforced for CR3. As
> far as I looked at the AMD spec, looks like #GP is caused even in
> protected mode... Does the test work for AMD systems?

I ran my test on an AMD host.

> 
> > Regards,
> > 
> > Anthony Liguori
> > 
> 
> 
> Jun
> ---
> Intel Open Source Technology Center

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
[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

Re: [kvm-devel] [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

2007-09-18 Thread Nakajima, Jun

Ryan Harper wrote:
> * Nakajima, Jun <[EMAIL PROTECTED]> [2007-09-18 16:22]:
> > Anthony Liguori wrote:
> > > Ryan Harper wrote:
> > > > Playing around with running VMware-server within a KVM guest and
noticed
> > > > that whenever we launch a VM within the guest, KVM reports a GP
fault in
> > > > set_cr3.  Removing the fault injection (raised for attempting to
set
> > > > reserved bits) for the non-pae case allows memtest to boot and
run
> > > > within VMWare Server, running in a KVM Linux guest.
> > > > 
> > > > This same test (Linux, VMware-server, booting/running memtest
iso) works
> > > > fine on bare-metal.  Thoughts?
> > > > 
> > > 
> > > Setting reserved bits is different from setting MBZ bits since the
> > > behaviors undefined.  If something as common as VMware is
depending on
> > > being able to set a reserved bit then perhaps the right thing to
do from
> > > KVM's perspective is to let it.
> > > 
> > > I'm curious if Zach or Jun have any comments about the right thing
to do
> > > here. 
> > > 
> > 
> > As long as the guest is protected mode (unlike the long mode), the
Intel
> > spec does _not_ say that reserved bits checking is enforced for CR3.
As
> > far as I looked at the AMD spec, looks like #GP is caused even in
> > protected mode... Does the test work for AMD systems?
> 
> I ran my test on an AMD host.

Well then the patch sounds fine to me.

Jun
---
Intel Open Source Technology Center

-
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] [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

2007-09-18 Thread Zachary Amsden

On Tue, 2007-09-18 at 16:25 -0500, Ryan Harper wrote:
> * Nakajima, Jun <[EMAIL PROTECTED]> [2007-09-18 16:22]:
> > Anthony Liguori wrote:
> > > Ryan Harper wrote:
> > > > Playing around with running VMware-server within a KVM guest and
> > noticed
> > > > that whenever we launch a VM within the guest, KVM reports a GP
> > fault in
> > > > set_cr3.  Removing the fault injection (raised for attempting to set
> > > > reserved bits) for the non-pae case allows memtest to boot and run
> > > > within VMWare Server, running in a KVM Linux guest.
> > > > 
> > > > This same test (Linux, VMware-server, booting/running memtest iso)
> > works
> > > > fine on bare-metal.  Thoughts?
> > > > 
> > > 
> > > Setting reserved bits is different from setting MBZ bits since the
> > > behaviors undefined.  If something as common as VMware is depending on
> > > being able to set a reserved bit then perhaps the right thing to do
> > from
> > > KVM's perspective is to let it.
> > > 
> > > I'm curious if Zach or Jun have any comments about the right thing to
> > do
> > > here.
> > > 
> > 
> > As long as the guest is protected mode (unlike the long mode), the Intel
> > spec does _not_ say that reserved bits checking is enforced for CR3. As
> > far as I looked at the AMD spec, looks like #GP is caused even in
> > protected mode... Does the test work for AMD systems?
> 
> I ran my test on an AMD host.

We have a test which verifies #GP is not caused by setting the bits on
either AMD or Intel chips.  "Stray" bits can get turned on in some cases
when switching between 64-bit, PAE and non-PAE address modes.

Were you testing on a 64-bit host kernel?

Zach


-
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] [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

2007-09-18 Thread Ryan Harper

* Zachary Amsden <[EMAIL PROTECTED]> [2007-09-18 16:59]:
> On Tue, 2007-09-18 at 16:25 -0500, Ryan Harper wrote:
> > * Nakajima, Jun <[EMAIL PROTECTED]> [2007-09-18 16:22]:
> > > Anthony Liguori wrote:
> > > > Ryan Harper wrote:
> > > > > Playing around with running VMware-server within a KVM guest and
> > > noticed
> > > > > that whenever we launch a VM within the guest, KVM reports a GP
> > > fault in
> > > > > set_cr3.  Removing the fault injection (raised for attempting to set
> > > > > reserved bits) for the non-pae case allows memtest to boot and run
> > > > > within VMWare Server, running in a KVM Linux guest.
> > > > > 
> > > > > This same test (Linux, VMware-server, booting/running memtest iso)
> > > works
> > > > > fine on bare-metal.  Thoughts?
> > > > > 
> > > > 
> > > > Setting reserved bits is different from setting MBZ bits since the
> > > > behaviors undefined.  If something as common as VMware is depending on
> > > > being able to set a reserved bit then perhaps the right thing to do
> > > from
> > > > KVM's perspective is to let it.
> > > > 
> > > > I'm curious if Zach or Jun have any comments about the right thing to
> > > do
> > > > here.
> > > > 
> > > 
> > > As long as the guest is protected mode (unlike the long mode), the Intel
> > > spec does _not_ say that reserved bits checking is enforced for CR3. As
> > > far as I looked at the AMD spec, looks like #GP is caused even in
> > > protected mode... Does the test work for AMD systems?
> > 
> > I ran my test on an AMD host.
> 
> We have a test which verifies #GP is not caused by setting the bits on
> either AMD or Intel chips.  "Stray" bits can get turned on in some cases
> when switching between 64-bit, PAE and non-PAE address modes.
> 
> Were you testing on a 64-bit host kernel?

64-bit Host running 32-bit KVM Guest. VMware-server shouldn't be seeing
anything 64-bit AFAIK.


> 
> Zach

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
[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] (big) real mode emulation - correct code placement

2007-09-18 Thread Nitin A Kamble

Hi Avi,
  Some emulation case statements have gone to wrong place in the
upstream tree. This patch fixes that. This time I have created the patch
using the git-format-patch command as per your suggestion.

  Please apply.

-- 
Thanks & Regards,
Nitin
Open Source Technology Center, Intel Corporation
-
The mind is like a parachute; it works much better when it's open


0001-This-code-has-gone-to-wrong-place-in-the-file.-Movin.patch
Description: application/mbox


signature.asc
Description: This is a digitally signed message part
-
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] Using VMChannel to communicate with the host.

2007-09-18 Thread Cam Macdonell

Dor Laor wrote:

>>
> Hmm, well it's an old code that Uri will rebase for virtio so just drop it.
> I just thought it might help.
>>

No worries.  In terms of moving to virtIO I grabbed your tree previously 
to look at it.  To test and play around with virtIO, do I need to use 
your kernel (or module) in the guest?

Thanks,
Cam

-
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] PowerPC 440 progress

2007-09-18 Thread Tim Anderson

Great job Hollis! 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Hollis Blanchard
> Sent: Tuesday, September 18, 2007 3:42 PM
> To: kvm-ppc-devel
> Cc: kvm-devel
> Subject: [kvm-devel] PowerPC 440 progress
> 
> With the attached patch, we can now execute a 440 Linux guest on a 440
> host through many initcalls:
> 
> CPU clock-frequency <- 0x27bc86ae (667MHz)
> CPU timebase-frequency <- 0x27bc86ae (667MHz)
> /plb: clock-frequency <- 9ef21ab (167MHz)
> /plb/opb: clock-frequency <- 4f790d5 (83MHz)
> /plb/opb/ebc: clock-frequency <- 34fb5e3 (56MHz)
> /plb/opb/[EMAIL PROTECTED]: clock-frequency <- a8c000 (11MHz)
> /plb/opb/[EMAIL PROTECTED]: clock-frequency <- a8c000 (11MHz)
> /plb/opb/[EMAIL PROTECTED]: clock-frequency <- a8c000 (11MHz)
> /plb/opb/[EMAIL PROTECTED]: clock-frequency <- a8c000 (11MHz)
> Memory <- <0x0 0x0 0x900> (144MB)
> ENET0: local-mac-address <- 00:00:00:00:00:00
> ENET1: local-mac-address <- 00:00:00:00:00:00
> 
> zImage starting: loaded at 0x0040 (sp: 0x00fffe98)
> Allocating 0x263c5c bytes for kernel ...
> gunzipping (0x <- 
> 0x0040b000:0x00661acc)...done 0x243a9c bytes
> 
> Linux/PowerPC load: 
> Finalizing device tree... flat tree at 0x66e3a0
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> Using Bamboo machine description
> Linux version 2.6.23-rc1 ([EMAIL PROTECTED]) (gcc 
> version 3.4.2) #88 Tue Sep 18 17:18:36 CDT 2007
> console [udbg0] enabled
> setup_arch: bootmem
> arch: exit
> Zone PFN ranges:
>   DMA 0 ->36864
>   Normal  36864 ->36864
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0:0 ->36864
> Built 1 zonelists in Zone order.  Total pages: 36576
> Kernel command line: console=ttyS0 debug
> UIC0 (32 IRQ sources) at DCR 0xc0
> UIC1 (32 IRQ sources) at DCR 0xd0
> PID hash table entries: 1024 (order: 10, 4096 bytes)
> time_init: decrementer frequency = 666.70 MHz
> time_init: processor frequency   = 666.70 MHz
> Dentry cache hash table entries: 32768 (order: 5, 
> 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 143500k/147456k available (2192k kernel code, 
> 3816k reserved, 100k data, 127k bss, 124k init)
> Calibrating delay loop... 1167.36 BogoMIPS (lpj=2334720)
> Mount-cache hash table entries: 512
> NET: Registered protocol family 16
> 
> PCI: Probing PCI hardware
> NET: Registered protocol family 2
> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
> TCP established hash table entries: 8192 (order: 4, 
> 65536 bytes)
> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP reno registered
> io scheduler noop registered
> io scheduler anticipatory registered (default)
> io scheduler deadline registered
> io scheduler cfq registered
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, 
> IRQ sharing enabled
> 
> The guest currently seems to be stuck in the serial driver 
> reading IER.
> Qemu doesn't seem to be getting the accesses though, so more debugging
> is required.
> 
> Also, signal delivery and scheduling other host tasks are now working,
> which makes for a nicer development environment. If you run "gdb qemu"
> on the host, you can at least do a post-mortem of guest memory.
> 
> Interesting note (at least, I thought it was interesting): since the
> guest can read the timebase without trapping, we must always 
> report the
> real timebase frequency to the guest.
> 
> The easiest way to do this right now was to implement DCR-read
> passthrough, since that's where the Linux bootwrapper gets the
> frequencies for the device tree. Long-term, we may want to have qemu
> supply a device tree itself (but it still must report the real
> frequency).
> 
> Another interesting note: since the guest can read SPRG4-7 without
> trapping, we must context-switch those registers.
> 
> Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
> 
> -- 
> Hollis Blanchard
> IBM Linux Technology Center
> 


-
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] windows 2003 smp guest

2007-09-18 Thread He, Qing



>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Avi Kivity
>Sent: 2007年9月18日 22:06
>To: Haydn Solomon
>Cc: kvm-devel
>Subject: Re: [kvm-devel] windows 2003 smp guest
>
>Haydn Solomon wrote:
>> I am interested in installing smp windows 2003 server guest and have
>> some questions.
>>
>> 1.  Is windows smp guest working and performing well at this point in kvm?
>
>It's working will with -no-kvm-irqchip.  Not so sure without the switch,
>but we're improving things.
>
>I haven't tested performance very thoroughly.  What's your workload?

It's also working well on my side if the option is not presented :-)

>
>> 2.  If question 1 above is true, then what HAL should I choose during
>> installation and what other flags should I use when running it?
>>
>
>Good question.  What HALs are available for Windows 2003 SMP?

I'm using ACPI multiprocessor HAL, don't know how MPS multiprocessor HAL works.

>
>--
>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

-
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] windows 2003 smp guest

2007-09-18 Thread Haydn Solomon

I'm going to try the acpi multiprocessor HAL and see how that works. What
kind of performance do you get with it?

On 9/18/07, He, Qing <[EMAIL PROTECTED]> wrote:
>
>
>
> >-Original Message-
> >From: [EMAIL PROTECTED]
> >[mailto:[EMAIL PROTECTED] On Behalf Of Avi Kivity
> >Sent: 2007年9月18日 22:06
> >To: Haydn Solomon
> >Cc: kvm-devel
> >Subject: Re: [kvm-devel] windows 2003 smp guest
> >
> >Haydn Solomon wrote:
> >> I am interested in installing smp windows 2003 server guest and have
> >> some questions.
> >>
> >> 1.  Is windows smp guest working and performing well at this point in
> kvm?
> >
> >It's working will with -no-kvm-irqchip.  Not so sure without the switch,
> >but we're improving things.
> >
> >I haven't tested performance very thoroughly.  What's your workload?
>
> It's also working well on my side if the option is not presented :-)
>
> >
> >> 2.  If question 1 above is true, then what HAL should I choose during
> >> installation and what other flags should I use when running it?
> >>
> >
> >Good question.  What HALs are available for Windows 2003 SMP?
>
> I'm using ACPI multiprocessor HAL, don't know how MPS multiprocessor HAL
> works.
>
> >
> >--
> >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
>
-
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 report for KVM, kvm.git: 93f9d893.. , kvm-userspace.git 1edeb9c0..

2007-09-18 Thread Zhao, Yunfeng

It's hard to tell. 
We didn't run installation of Vista nightly. 

>-Original Message-
>From: Avi Kivity [mailto:[EMAIL PROTECTED]
>Sent: 2007年9月18日 17:34
>To: Zhao, Yunfeng
>Cc: kvm-devel@lists.sourceforge.net
>Subject: Re: [kvm-devel] Test report for KVM, kvm.git: 93f9d893.. ,
>kvm-userspace.git 1edeb9c0..
>
>Zhao, Yunfeng wrote:Izik is addressing
>
>
>> 2. blue screen while install 64bit vista
>> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1796941&gro
>> up_id=180599
>>
>
>Can you say what was the last version (or commit hash) which worked?
>
>
>--
>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

48 matches

Mail list logo