date:20080714


Ben-Ami Yassour wrote:

On Sun, 2008-07-13 at 10:34 +0300, Avi Kivity wrote:
  

Muli Ben-Yehuda wrote:


On the other hand, this means that you will not be able to assign
devices unless you specified this when creating the VM; but I think
this is fair.



It will be nice to support hot-plugged pass-through devices some time
in the future.

  
  
And it should be easy to do too.  The question is whether we need to 
allocate the iommu domain up front (which would mean that a command line 
parameter would be needed, meaning roughly 'support pci device 
assignment on this guest'.  Kind of like -usb, which means 'support usb 
device assignment on this guest'.





I don't think that its that simple...
On a single machine you can have multiple iommu units, each of which controls 
certain PCI slots.
To configure the iommu for a specific device you need to configure the iommu 
unit that controls that device.
This means that we need to know the bus/dev/func of the device before we create 
the VT-d domain.
For hot-plug devices it means that by the time we can create the domain we 
already have memory slots that we need to add to the VT-d mapping.

  


Thanks for the info.  Looks like we have to support both 
memslot-before-iommu and memslot-after-iommu then.


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

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] VMX: Reinject real mode exception

2008-07-14 Thread Jan Kiszka

Avi Kivity wrote:
 Nakajima, Jun wrote:
 On 7/13/2008 8:31:44 AM, Avi Kivity wrote:
  
 Avi Kivity wrote:

 Well, xen and bochs do not push an error code for real mode #GP.  I
 tried running the attached test program but it doesn't work on real
 hardware (it does work on bochs).

   
 Jun, perhaps you can clarify? do #GP exceptions in real-mode push an
 error code?
 

 Avi,

 Exceptions in real-mode do not push an error code in the stack. 
 
 Thanks.  You might consider updating the documentation, for example #DF
 states that an error code of 0 is always pushed.
 
 In vm86 mode #GP exceptions push an error code, triggering a
 protected-mode handler in the monitor, as you know. Is it possible
 that the guest is actually using vm86 mode?
   
 
 No, it's a real mode guest.  It's emulated using vm86, of course, but it
 thinks it's in real mode.  The question was, when we inject a #GP, #SS,
 or #DF  exception, should we also inject an error code, and according to
 your clarification, the answer is no.

Meanwhile I found a clearer statement in the spec as well in chapter
15.1.4: Exceptions do not return error codes in real-address mode. So
here is the update:

---

As we execute real mode guests in VM86 mode, exception have to be
reinjected appropriately when the guest triggered them. For this purpose
the patch adopts the real-mode injection pattern used in vmx_inject_irq
to vmx_queue_exception, additionally taking care that the IP is set
correctly for #BP exceptions. Furthermore it extends
handle_rmode_exception to reinject all those exceptions that can be
raised in real mode.

This fixes the execution of himem.exe from FreeDOS and also makes its
debug.com work properly.

Note that guest debugging in real mode is broken now. This has to be
fixed by the scheduled debugging infrastructure rework (will be done
once base patches for QEMU have been accepted).

Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
 arch/x86/kvm/vmx.c |   41 +++--
 include/asm-x86/kvm_host.h |4 
 2 files changed, 43 insertions(+), 2 deletions(-)

Index: b/arch/x86/kvm/vmx.c
===
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -735,12 +735,30 @@ static void skip_emulated_instruction(st
 static void vmx_queue_exception(struct kvm_vcpu *vcpu, unsigned nr,
bool has_error_code, u32 error_code)
 {
+   struct vcpu_vmx *vmx = to_vmx(vcpu);
+
+   if (has_error_code)
+   vmcs_write32(VM_ENTRY_EXCEPTION_ERROR_CODE, error_code);
+
+   if (vcpu-arch.rmode.active) {
+   vmx-rmode.irq.pending = true;
+   vmx-rmode.irq.vector = nr;
+   vmx-rmode.irq.rip = kvm_rip_read(vcpu);
+   if (nr == BP_VECTOR)
+   vmx-rmode.irq.rip++;
+   vmcs_write32(VM_ENTRY_INTR_INFO_FIELD,
+nr | INTR_TYPE_SOFT_INTR
+| (has_error_code ? INTR_INFO_DELIVER_CODE_MASK : 
0)
+| INTR_INFO_VALID_MASK);
+   vmcs_write32(VM_ENTRY_INSTRUCTION_LEN, 1);
+   kvm_rip_write(vcpu, vmx-rmode.irq.rip - 1);
+   return;
+   }
+
vmcs_write32(VM_ENTRY_INTR_INFO_FIELD,
 nr | INTR_TYPE_EXCEPTION
 | (has_error_code ? INTR_INFO_DELIVER_CODE_MASK : 0)
 | INTR_INFO_VALID_MASK);
-   if (has_error_code)
-   vmcs_write32(VM_ENTRY_EXCEPTION_ERROR_CODE, error_code);
 }
 
 static bool vmx_exception_injected(struct kvm_vcpu *vcpu)
@@ -2231,6 +2249,25 @@ static int handle_rmode_exception(struct
if (((vec == GP_VECTOR) || (vec == SS_VECTOR))  err_code == 0)
if (emulate_instruction(vcpu, NULL, 0, 0, 0) == EMULATE_DONE)
return 1;
+   /*
+* Forward all other exceptions that are valid in real mode.
+* FIXME: Breaks guest debugging in real mode, needs to be fixed with
+*the required debugging infrastructure rework.
+*/
+   switch (vec) {
+   case DE_VECTOR:
+   case DB_VECTOR:
+   case BP_VECTOR:
+   case OF_VECTOR:
+   case BR_VECTOR:
+   case UD_VECTOR:
+   case DF_VECTOR:
+   case SS_VECTOR:
+   case GP_VECTOR:
+   case MF_VECTOR:
+   kvm_queue_exception(vcpu, vec);
+   return 1;
+   }
return 0;
 }
 
Index: b/include/asm-x86/kvm_host.h
===
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -57,6 +57,9 @@
 
 #define DE_VECTOR 0
 #define DB_VECTOR 1
+#define BP_VECTOR 3
+#define OF_VECTOR 4
+#define BR_VECTOR 5
 #define UD_VECTOR 6
 #define NM_VECTOR 7
 #define DF_VECTOR 8
@@ -65,6 +68,7 @@
 #define SS_VECTOR 12
 #define GP_VECTOR 13
 #define PF_VECTOR 14
+#define MF_VECTOR 16
 #define MC_VECTOR

Re: [PATCH 2/2] VMX: Reinject real mode exception


Jan Kiszka wrote:

As we execute real mode guests in VM86 mode, exception have to be
reinjected appropriately when the guest triggered them. For this purpose
the patch adopts the real-mode injection pattern used in vmx_inject_irq
to vmx_queue_exception, additionally taking care that the IP is set
correctly for #BP exceptions. Furthermore it extends
handle_rmode_exception to reinject all those exceptions that can be
raised in real mode.

This fixes the execution of himem.exe from FreeDOS and also makes its
debug.com work properly.

Note that guest debugging in real mode is broken now. This has to be
fixed by the scheduled debugging infrastructure rework (will be done
once base patches for QEMU have been accepted).

  


Applied, thanks.

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

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] libkvm-s390

2008-07-14 Thread Christian Borntraeger

That patch was Carstens last job before he left into vacation. I promised to 
look after it, so I will sent an updated patch soon.

  +/*
  + * This header is for functions  variables that will ONLY be
  + * used inside libkvm for s390x.
  + * THESE ARE NOT EXPOSED TO THE USER AND ARE ONLY FOR USE
  + * WITHIN LIBKVM.
  + *

 
 It isn't a header.

Will fix
 
  + * derived from libkvm-powerpc.c
  + *

 
 So it the comment above.  So much for our review.

I guess libkvm-powerpc.c will be fixed by the powerpc guys?

  +#ifndef __s390x__
   #define KVM_MAX_NUM_MEM_REGIONS 8u
  +#define MAX_VCPUS 64

 
 16
 
  +#else
  +#define KVM_MAX_NUM_MEM_REGIONS 1u
   #define MAX_VCPUS 16

 
 64

Yes, indeed. 

  +#define LIBKVM_S390_ORIGIN (0UL)
 
 Thought you got rid of that?

Sort of. We have the kernel code ready to move away the guest from address 0. 
To achieve that goal we use the offset and limit field in the control block.
Thing is, on older models the offset and limit must be  128GB. that means we 
still cannot use randomly allocated memory. LIBKVM_S390_ORIGIN=1M,2M or 16M 
would be perfectly fine, 2TB (typical malloc space) is not.
Furthermore, this change is still in kvm.git, but not in Linus git. 
Therefore, we would like to keep the guest at 0 and fix that at a later time, 
ok?

Christian

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] libkvm-s390


Christian Borntraeger wrote:
  

+#define LIBKVM_S390_ORIGIN (0UL)
  

Thought you got rid of that?



Sort of. We have the kernel code ready to move away the guest from address 0. 
To achieve that goal we use the offset and limit field in the control block.
Thing is, on older models the offset and limit must be  128GB. that means we 
still cannot use randomly allocated memory. LIBKVM_S390_ORIGIN=1M,2M or 16M 
would be perfectly fine, 2TB (typical malloc space) is not.
Furthermore, this change is still in kvm.git, but not in Linus git. 
Therefore, we would like to keep the guest at 0 and fix that at a later time, 
ok?
  


Certainly.  I suggest exposing this via a KVM_CAP_blah and adapting at 
runtime.


Placing the guest at offset zero is dangerous, since all a guest has to 
do is place a function at guest physical address zero and wait for a 
kernel bug that calls a null function pointer (at least, it would behave 
like that on x86, provided no-execute was disabled; it may well be that 
s390 has additional protection).


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

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/8] kvmppc: kvmtrace: adds trace points for ppc tlb activity v2

From: Jerone Young [EMAIL PROTECTED]
From: Christian Ehrhardt [EMAIL PROTECTED]

This patch adds trace points to track powerpc TLB activities using the
KVM_TRACE infrastructure.
Update to v1:
- fixed wrong indents reported by checkpatch

Signed-off-by: Jerone Young [EMAIL PROTECTED]
Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---

[diffstat]
 arch/powerpc/kvm/44x_tlb.c |   15 ++-
 arch/powerpc/kvm/emulate.c |4 
 include/linux/kvm.h|3 +++
 3 files changed, 21 insertions(+), 1 deletion(-)

[diff]

diff --git a/arch/powerpc/kvm/44x_tlb.c b/arch/powerpc/kvm/44x_tlb.c
--- a/arch/powerpc/kvm/44x_tlb.c
+++ b/arch/powerpc/kvm/44x_tlb.c
@@ -19,6 +19,7 @@
 
 #include linux/types.h
 #include linux/string.h
+#include linux/kvm.h
 #include linux/kvm_host.h
 #include linux/highmem.h
 #include asm/mmu-44x.h
@@ -175,6 +176,10 @@
stlbe-word1 = (hpaddr  0xfc00) | ((hpaddr  32)  0xf);
stlbe-word2 = kvmppc_44x_tlb_shadow_attrib(flags,
vcpu-arch.msr  MSR_PR);
+
+   KVMTRACE_5D(STLB_WRITE, vcpu, victim,
+   stlbe-tid, stlbe-word0, stlbe-word1, stlbe-word2,
+   handler);
 }
 
 void kvmppc_mmu_invalidate(struct kvm_vcpu *vcpu, u64 eaddr, u64 asid)
@@ -203,6 +208,9 @@
 
kvmppc_44x_shadow_release(vcpu, i);
stlbe-word0 = 0;
+   KVMTRACE_5D(STLB_INVAL, vcpu, i,
+   stlbe-tid, stlbe-word0, stlbe-word1,
+   stlbe-word2, handler);
}
up_write(current-mm-mmap_sem);
 }
@@ -216,8 +224,13 @@
/* XXX Replace loop with fancy data structures. */
down_write(current-mm-mmap_sem);
for (i = 0; i = tlb_44x_hwater; i++) {
+   struct tlbe *stlbe = vcpu-arch.shadow_tlb[i];
+
kvmppc_44x_shadow_release(vcpu, i);
-   vcpu-arch.shadow_tlb[i].word0 = 0;
+   stlbe-word0 = 0;
+   KVMTRACE_5D(STLB_INVAL, vcpu, i,
+   stlbe-tid, stlbe-word0, stlbe-word1,
+   stlbe-word2, handler);
}
up_write(current-mm-mmap_sem);
 }
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -169,6 +169,10 @@
 * are mapped on the fly. */
kvmppc_mmu_map(vcpu, eaddr, raddr  PAGE_SHIFT, asid, flags);
}
+
+   KVMTRACE_5D(GTLB_WRITE, vcpu, index,
+   tlbe-tid, tlbe-word0, tlbe-word1, tlbe-word2,
+   handler);
 
return EMULATE_DONE;
 }
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -470,5 +470,8 @@
 #define KVM_TRC_LMSW (KVM_TRC_HANDLER + 0x13)
 #define KVM_TRC_APIC_ACCESS  (KVM_TRC_HANDLER + 0x14)
 #define KVM_TRC_TDP_FAULT(KVM_TRC_HANDLER + 0x15)
+#define KVM_TRC_GTLB_WRITE   (KVM_TRC_HANDLER + 0x16)
+#define KVM_TRC_STLB_WRITE   (KVM_TRC_HANDLER + 0x17)
+#define KVM_TRC_STLB_INVAL   (KVM_TRC_HANDLER + 0x18)
 
 #endif
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/8] kvmppc: kvmtrace: trace powerpc instruction emulation

From: Christian Ehrhardt [EMAIL PROTECTED]

This patch adds a trace point for the instruction emulation on embedded powerpc
utilizing the KVM_TRACE interface.

Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---

[diffstat]
 arch/powerpc/kvm/emulate.c |2 ++
 include/linux/kvm.h|1 +
 2 files changed, 3 insertions(+)

[diff]

diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -769,6 +769,8 @@
break;
}
 
+   KVMTRACE_3D(PPC_INSTR, vcpu, inst, vcpu-arch.pc, emulated, entryexit);
+
if (advance)
vcpu-arch.pc += 4; /* Advance past emulated instruction. */
 
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -473,5 +473,6 @@
 #define KVM_TRC_GTLB_WRITE   (KVM_TRC_HANDLER + 0x16)
 #define KVM_TRC_STLB_WRITE   (KVM_TRC_HANDLER + 0x17)
 #define KVM_TRC_STLB_INVAL   (KVM_TRC_HANDLER + 0x18)
+#define KVM_TRC_PPC_INSTR(KVM_TRC_HANDLER + 0x19)
 
 #endif
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/8] kvmppc: kvmtrace: enable KVM_TRACE building for powerpc

From: Jerone Young [EMAIL PROTECTED]

This patch enables KVM_TRACE to build for PowerPC arch. This means just
adding sections to Kconfig and Makefile.

Signed-off-by: Jerone Young [EMAIL PROTECTED]
Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---

[diffstat]
 Kconfig  |   11 +++
 Makefile |6 --
 2 files changed, 15 insertions(+), 2 deletions(-)

[diff]
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -37,6 +37,17 @@ config KVM_BOOKE_HOST
  Provides host support for KVM on Book E PowerPC processors. Currently
  this works on 440 processors only.
 
+config KVM_TRACE
+   bool KVM trace support
+   depends on KVM  MARKERS  SYSFS
+   select RELAY
+   select DEBUG_FS
+   default n
+   ---help---
+ This option allows reading a trace of kvm-related events through
+ relayfs.  Note the ABI is not considered stable and will be
+ modified in future updates.
+
 source drivers/virtio/Kconfig
 
 endif # VIRTUALIZATION
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -4,9 +4,11 @@
 
 EXTRA_CFLAGS += -Ivirt/kvm -Iarch/powerpc/kvm
 
-common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o coalesced_mmio.o)
+common-objs-y = $(addprefix ../../../virt/kvm/, kvm_main.o coalesced_mmio.o)
 
-kvm-objs := $(common-objs) powerpc.o emulate.o booke_guest.o
+common-objs-$(CONFIG_KVM_TRACE)  += $(addprefix ../../../virt/kvm/, 
kvm_trace.o)
+
+kvm-objs := $(common-objs-y) powerpc.o emulate.o booke_guest.o
 obj-$(CONFIG_KVM) += kvm.o
 
 AFLAGS_booke_interrupts.o := -I$(obj)
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 7/8] kvm-userspace: kvmtrace_format: add statistic section

From: Christian Ehrhardt [EMAIL PROTECTED]

Usually people don't want to read thousands of trace log lines to interpret
the data, a condensed statistic about the traced events is usually better
to read.
This patch adds a new command line switch -s that tells kvmtrace_format to
generate statistics while processing the trace records. Those statistics are
then printed at the end of the output.
This patch contains a statistic function for the ppc instruction emulation.
An example output might look like that:

  mnemonic +  count
---+---
wrteei |   1260
 mfmsr |977
 mtspr |895
 wrtee |742
 mfspr |534
   rfi |179
 mtmsr | 90
   lbz | 53
   stb | 28
   sum =   4758
[...] more detailed statistics about spr, dcr and tlb usage

Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---

[diffstat]
 kvmtrace_format |   73 +++-
 1 file changed, 67 insertions(+), 6 deletions(-)

[diff]
diff --git a/user/kvmtrace_format b/user/kvmtrace_format
--- a/user/kvmtrace_format
+++ b/user/kvmtrace_format
@@ -4,7 +4,7 @@
 
 # Program for reformatting trace buffer output according to user-supplied rules
 
-import re, sys, string, signal, struct, os, getopt
+import re, sys, string, signal, struct, os, getopt, operator
 
 def usage():
 print  sys.stderr, \
@@ -29,6 +29,12 @@
   this script may not be able to keep up with the output of kvmtrace
   if it is piped directly.  In these circumstances you should have
   kvmtrace output to a file for processing off-line.
+
+  kvmtrace_format has the following additional switches
+  -c mhz - specifies the mhz of the traced machine used to convert
+   cycle data in trace records into time
+  -s - if this switch is set additional trace statistics are
+   created and printed at the end of the output
   
 sys.exit(1)
 
@@ -60,6 +66,33 @@
 interrupted = 1
 
 # ppc instruction decoding for event type 0x00020019 (PPC_INSTR)
+# some globals for statistic summaries
+stat_ppc_instr_mnemonic = {};
+stat_ppc_instr_spr = {};
+stat_ppc_instr_dcr = {};
+stat_ppc_instr_tlb = {};
+
+def ppc_instr_print_summary(sortedlist, colname):
+   print \n\n%14s + %10s % (colname, count)
+   print %s % (15*-+++11*-)
+   sum = 0
+   for value, key in sortedlist:
+   sum += key
+   print %14s | %10d % (value, key)
+   print %14s = %10d % (sum, sum)
+
+
+def ppc_instr_summary():
+   # don't print empty statistics
+if stat_ppc_instr_mnemonic:
+   
ppc_instr_print_summary(sorted(stat_ppc_instr_mnemonic.iteritems(), 
key=operator.itemgetter(1), reverse=True), mnemonic)
+if stat_ppc_instr_spr:
+   ppc_instr_print_summary(sorted(stat_ppc_instr_spr.iteritems(), 
key=operator.itemgetter(1), reverse=True), mnemonic-spr)
+if stat_ppc_instr_dcr:
+   ppc_instr_print_summary(sorted(stat_ppc_instr_dcr.iteritems(), 
key=operator.itemgetter(1), reverse=True), mnemonic-dcr)
+if stat_ppc_instr_tlb:
+   ppc_instr_print_summary(sorted(stat_ppc_instr_tlb.iteritems(), 
key=operator.itemgetter(1), reverse=True), mnemonic-tlb)
+
 def get_op(instr):
 return (instr  26);
 
@@ -293,28 +326,53 @@
return UNKNOWN
 
 def get_special(instr):
+   name = get_name(instr);
+   if stat_ppc_instr_mnemonic.has_key(name):
+   stat_ppc_instr_mnemonic[name] += 1
+   else:
+   stat_ppc_instr_mnemonic[name] = 1
+
if get_op(instr) == 31:
if (get_xop(instr) == 339) or (get_xop(instr) == 467):
sprn = get_sprn(instr);
-   return (- sprn 0x%03x %8s % (sprn, 
get_sprn_name(sprn)))
+   sprn_name = get_sprn_name(sprn);
+   stat_idx = name+-+sprn_name
+   if stat_ppc_instr_spr.has_key(stat_idx):
+   stat_ppc_instr_spr[stat_idx] += 1
+   else:
+   stat_ppc_instr_spr[stat_idx] = 1
+   return (- sprn 0x%03x %8s % (sprn, sprn_name))
elif (get_xop(instr) == 323 ) or (get_xop(instr) == 451):
-   return (- dcrn 0x%03x % get_dcrn(instr))
+   dcrn = get_dcrn(instr);
+   stat_idx = name+-+(%04X%dcrn)
+   if stat_ppc_instr_dcr.has_key(stat_idx):
+   stat_ppc_instr_dcr[stat_idx] += 1
+   else:
+   stat_ppc_instr_dcr[stat_idx] = 1
+   return (- dcrn 0x%03x % dcrn)
elif (get_xop(instr) == 978 ) or (get_xop(instr) == 451):
-

[PATCH 6/8] kvm-userspace: kvmtrace_format: add ppc instruction emulation

From: Christian Ehrhardt [EMAIL PROTECTED]

This patch adds the handling of the ppc instruction emulation trace records.
Due to the fact that those are more complex than the classic formats file
way this patch adds a check of the event id and maps to the internal handler
function if needed (other complex trace records that might appear in future
can hook up there too).
Additionally this fixes the ppc tlb trace record definitions in the formats
file now that the revised kernel patch series is submitted.

Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---

[diffstat]
 formats |   16 +--
 kvmtrace_format |  276 +---
 2 files changed, 268 insertions(+), 24 deletions(-)

[diff]

diff --git a/user/formats b/user/formats
--- a/user/formats
+++ b/user/formats
@@ -23,13 +23,9 @@
 0x00020013  %(tsc)d (+%(reltsc)8d)  LMSW  vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ value = 0x%(1)08x ]
 0x00020014  %(tsc)d (+%(reltsc)8d)  APIC_ACCESS   vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ offset = 0x%(1)08x ]
 0x00020015  %(tsc)d (+%(reltsc)8d)  TDP_FAULT vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ errorcode = 0x%(1)08x, virt = 0x%(3)08x %(2)08x ]
-# ppc: context switch
-0x00020016  %(tsc)d (+%(reltsc)8d)  CONT_SWITCH   vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x
-# ppc: tlb write
-0x00020017  %(tsc)d (+%(reltsc)8d)  TLB_WRITEvcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ index = 0x%(1)08x, tid = 0x%(2)08x, word1=0x%(3)08x, 
word2=0x%(4)08x, word3=0x%(5)08x ]
-# ppc: tlb invalidate
-0x00020018  %(tsc)d (+%(reltsc)8d)  TLB_INVAL vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ index = 0x%(1)08x, tid = 0x%(2)08x, word1=0x%(3)08x, 
word2=0x%(4)08x, word3=0x%(5)08x ]
-# ppc: guest TLB write
-0x00020019  %(tsc)d (+%(reltsc)8d)  GTLB_WRITEvcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ index = 0x%(1)08x, tid = 0x%(2)08x, word1=0x%(3)08x, 
word2=0x%(4)08x, word3=0x%(5)08x ]
-# ppc: shadow TLB write
-0x00020020  %(tsc)d (+%(reltsc)8d)  STLB_WRITE   vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ index = 0x%(1)08x, tid = 0x%(2)08x, word1=0x%(3)08x, 
word2=0x%(4)08x, word3=0x%(5)08x ]
+# ppc: tlb traces
+0x00020016  GTLB_WRITEvcpu = 0x%(vcpu)08x  pid = 0x%(pid)08x [ index = 
0x%(1)08x, tid = 0x%(2)08x, word1=0x%(3)08x, word2=0x%(4)08x, word3=0x%(5)08x ]
+0x00020017  STLB_WRITEvcpu = 0x%(vcpu)08x  pid = 0x%(pid)08x [ index = 
0x%(1)08x, tid = 0x%(2)08x, word1=0x%(3)08x, word2=0x%(4)08x, word3=0x%(5)08x ]
+0x00020018  STLB_INVALvcpu = 0x%(vcpu)08x  pid = 0x%(pid)08x [ index = 
0x%(1)08x, tid = 0x%(2)08x, word1=0x%(3)08x, word2=0x%(4)08x, word3=0x%(5)08x ]
+# ppc: instruction emulation - this type is handled more complex in 
kvmtrace_format, but listed to show the eventid and transported data
+#0x00020019  %(tsc)d (+%(reltsc)8d)  PPC_INSTR vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ instr = 0x%(1)08x, pc = 0x%(2)08x, emul = 0x%(3)08x, nsec = 
%(4)08d ]
diff --git a/user/kvmtrace_format b/user/kvmtrace_format
--- a/user/kvmtrace_format
+++ b/user/kvmtrace_format
@@ -58,6 +58,250 @@
 def sighand(x,y):
 global interrupted
 interrupted = 1
+
+# ppc instruction decoding for event type 0x00020019 (PPC_INSTR)
+def get_op(instr):
+return (instr  26);
+
+def get_xop(instr):
+return (instr  1)  0x3ff;
+
+def get_sprn(instr):
+   return ((instr  16)  0x1f) | ((instr  6)  0x3e0)
+
+def get_dcrn(instr):
+   return ((instr  16)  0x1f) | ((instr  6)  0x3e0);
+
+def get_tlbwe_type(instr):
+   ws = (instr  11)  0x1f;
+   if ws == 0:
+   return PAGEID
+   elif ws == 1:
+   return XLAT
+   elif ws == 2:
+   return ATTRIB
+   else:
+   return UNKNOWN
+
+def get_name(instr):
+   if get_op(instr)==3:
+   return trap
+   elif get_op(instr)==19:
+   if get_xop(instr) == 50:
+   return rfi
+   else:
+   return unknown
+   elif get_op(instr)==31:
+   if get_xop(instr) == 83:
+   return mfmsr
+
+   elif get_xop(instr) == 87:
+   return lbzx
+
+   elif get_xop(instr) == 131:
+   return wrtee
+
+   elif get_xop(instr) == 146:
+   return mtmsr
+
+   elif get_xop(instr) == 163:
+   return wrteei
+
+   elif get_xop(instr) == 215:
+   return stbx
+
+   elif get_xop(instr) == 247:
+   return stbux
+
+   elif get_xop(instr) == 279:
+   return lhzx
+
+   elif get_xop(instr) == 311:
+   return lhzux
+
+   elif get_xop(instr) == 323:
+   return mfdcr
+
+   elif get_xop(instr) == 339:
+   return mfspr
+
+   elif get_xop(instr) == 407:
+   return

[PATCH 8/8] kvm-userspace: kvmtrace: cycles are now ktime_t timestamps

From: Christian Ehrhardt [EMAIL PROTECTED]

Due to the fact that the cycle counter is now completely replaced by the more
generic time based code (getnstimeofday) this patch renames all occurances of
the old cycle code to make it clear that this is now a timestamp.
Due to some values now growing a big larger (relts) the patch also
increases the print width of those values.

Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---

[diffstat]
 formats |   50 +-
 kvmtrace_format |   41 +
 2 files changed, 42 insertions(+), 49 deletions(-)

[diff]

diff --git a/user/formats b/user/formats
--- a/user/formats
+++ b/user/formats
@@ -1,31 +1,31 @@
-0x  %(tsc)d (+%(reltsc)8d)  unknown (0x%(event)016x) vcpu = 
0x%(vcpu)08x  pid = 0x%(pid)08x [ 0x%(1)08x 0x%(2)08x 0x%(3)08x 0x%(4)08x 
0x%(5)08x ]
+0x  %(ts)d (+%(relts)12d)  unknown (0x%(event)016x) vcpu = 
0x%(vcpu)08x  pid = 0x%(pid)08x [ 0x%(1)08x 0x%(2)08x 0x%(3)08x 0x%(4)08x 
0x%(5)08x ]
 
-0x00010001  %(tsc)d (+%(reltsc)8d)  VMENTRY   vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x
-0x00010002  %(tsc)d (+%(reltsc)8d)  VMEXITvcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ exitcode = 0x%(1)08x, rip = 0x%(3)08x %(2)08x ]
-0x00020001  %(tsc)d (+%(reltsc)8d)  PAGE_FAULTvcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ errorcode = 0x%(1)08x, virt = 0x%(3)08x %(2)08x ]
-0x00020002  %(tsc)d (+%(reltsc)8d)  INJ_VIRQ  vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ vector = 0x%(1)02x ]
-0x00020003  %(tsc)d (+%(reltsc)8d)  REDELIVER_EVT vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ vector = 0x%(1)02x ]
-0x00020004  %(tsc)d (+%(reltsc)8d)  PEND_INTR vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ vector = 0x%(1)02x ]
-0x00020005  %(tsc)d (+%(reltsc)8d)  IO_READ   vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ port = 0x%(1)04x, size = %(2)d ]
-0x00020006  %(tsc)d (+%(reltsc)8d)  IO_WRITE  vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ port = 0x%(1)04x, size = %(2)d ]
-0x00020007  %(tsc)d (+%(reltsc)8d)  CR_READ   vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ CR# = %(1)d, value = 0x%(3)08x %(2)08x ]
-0x00020008  %(tsc)d (+%(reltsc)8d)  CR_WRITE  vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ CR# = %(1)d, value = 0x%(3)08x %(2)08x ]
-0x00020009  %(tsc)d (+%(reltsc)8d)  DR_READ   vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ DR# = %(1)d, value = 0x%(2)08x ]
-0x0002000A  %(tsc)d (+%(reltsc)8d)  DR_WRITE  vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ DR# = %(1)d, value = 0x%(2)08x ]
-0x0002000B  %(tsc)d (+%(reltsc)8d)  MSR_READ  vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ MSR# = 0x%(1)08x, data = 0x%(3)08x %(2)08x ]
-0x0002000C  %(tsc)d (+%(reltsc)8d)  MSR_WRITE vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ MSR# = 0x%(1)08x, data = 0x%(3)08x %(2)08x ]
-0x0002000D  %(tsc)d (+%(reltsc)8d)  CPUID vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ func = 0x%(1)08x, eax = 0x%(2)08x, ebx = 0x%(3)08x, ecx = 
0x%(4)08x edx = 0x%(5)08x]
-0x0002000E  %(tsc)d (+%(reltsc)8d)  INTR  vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ vector = 0x%(1)02x ]
-0x0002000F  %(tsc)d (+%(reltsc)8d)  NMI   vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x
-0x00020010  %(tsc)d (+%(reltsc)8d)  VMMCALL   vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ func = 0x%(1)08x ]
-0x00020011  %(tsc)d (+%(reltsc)8d)  HLT   vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x
-0x00020012  %(tsc)d (+%(reltsc)8d)  CLTS  vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x
-0x00020013  %(tsc)d (+%(reltsc)8d)  LMSW  vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ value = 0x%(1)08x ]
-0x00020014  %(tsc)d (+%(reltsc)8d)  APIC_ACCESS   vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ offset = 0x%(1)08x ]
-0x00020015  %(tsc)d (+%(reltsc)8d)  TDP_FAULT vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ errorcode = 0x%(1)08x, virt = 0x%(3)08x %(2)08x ]
+0x00010001  %(ts)d (+%(relts)12d)  VMENTRY   vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x
+0x00010002  %(ts)d (+%(relts)12d)  VMEXITvcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ exitcode = 0x%(1)08x, rip = 0x%(3)08x %(2)08x ]
+0x00020001  %(ts)d (+%(relts)12d)  PAGE_FAULTvcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ errorcode = 0x%(1)08x, virt = 0x%(3)08x %(2)08x ]
+0x00020002  %(ts)d (+%(relts)12d)  INJ_VIRQ  vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ vector = 0x%(1)02x ]
+0x00020003  %(ts)d (+%(relts)12d)  REDELIVER_EVT vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ vector = 0x%(1)02x ]
+0x00020004  %(ts)d (+%(relts)12d)  PEND_INTR vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ vector = 0x%(1)02x ]
+0x00020005  %(ts)d (+%(relts)12d)  IO_READ   vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ port = 0x%(1)04x, size = %(2)d ]
+0x00020006  %(ts)d (+%(relts)12d)  IO_WRITE  vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ port = 0x%(1)04x, size = %(2)d ]
+0x00020007  %(ts)d (+%(relts)12d)  CR_READ   vcpu = 0x%(vcpu)08x  pid = 
0x%(pid)08x [ CR# = %(1)d, value = 0x%(3)08x %(2)08x ]
+0x00020008  %(ts)d

[PATCH 0/8] kvmtrace: powerpc support and timestamps for KVM_TRACE v3

From: Christian Ehrhardt [EMAIL PROTECTED]

Changing kvmtrace code to use timestamps and add powerpc support.

This is the revised series including the feedback from the earlier submission
last week. I now also added the userspace changes which complete the series.

Updated in v3:
patch 2/8 now uses ktime_get() for all architectures as discussed

The series contains eight patches (3 generic / 5 powerpc code):

Subject: [PATCH 1/8] kvmtrace: Remove use of bit fields in kvm trace structure 
v3
Introducing a endian save way to store the flags event,tcs, num_data 
Subject: [PATCH 2/8] kvmtrace: replace get_cycles with getnstimeofday
use a new timestamp source (ktime_get) which makes it 32/64 bit save,
comparable and does not need an arch hook
Subject: [PATCH 3/8] kvmppc: kvmtrace: enable KVM_TRACE building for powerpc
enable KVM_TRACE for powerpc in Kconfig/Makefile
Subject: [PATCH 4/8] kvmppc: kvmtrace: adds trace points for ppc tlb activity v2
use KVM_TRACE to track tlb/shadow tlb activity on embedded powerpc
Subject: [PATCH 5/8] kvmppc: kvmtrace: trace powerpc instruction emulation
use KVM_TRACE to track instruction emulation overhead
Subject: [PATCH 6/8] kvm-userspace: kvmtrace_format: add ppc instruction 
emulation
extension to kvmtrace_format to handle complex event types e.g. ppc
instructon emulation
Subject: [PATCH 7/8] kvm-userspace: kvmtrace_format: add statistic section
adding statistic creation/prsentation to the kvmtrace data processing
Subject: [PATCH 8/8] kvm-userspace: kvmtrace: rename cycles to timestamp
it is no more tracking cycles, so rename variables and change comments

Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---

[diffstat]
 arch/powerpc/kvm/emulate.c   |2
 b/arch/powerpc/kvm/44x_tlb.c |   15 ++
 b/arch/powerpc/kvm/Kconfig   |   11 +
 b/arch/powerpc/kvm/Makefile  |6
 b/arch/powerpc/kvm/emulate.c |4
 b/include/linux/kvm.h|   17 ++
 b/user/formats   |   16 --
 b/user/kvmtrace_format   |  276 ---
 b/virt/kvm/kvm_trace.c   |   19 +-
 include/linux/kvm.h  |   10 +
 user/formats |   50 +++
 user/kvmtrace_format |  114 +
 virt/kvm/kvm_trace.c |   18 +-
 13 files changed, 452 insertions(+), 106 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/8] kvmtrace: Remove use of bit fields in kvm trace structure v3

From: Christian Ehrhardt [EMAIL PROTECTED]
From: Jerone Young [EMAIL PROTECTED]

This patch fixes kvmtrace use on big endian systems. When using bit fields the
compiler will lay data out in the wrong order expected when laid down into a
file.
This fixes it by using one variable instead of using bit fields.

Updates in v3:
- fixed macro definition bug in v2
- ensured in macro operator order
- fixed whitespace/indent issues
- removed superfluous initialization

Signed-off-by: Jerone Young [EMAIL PROTECTED]
Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---

[diffstat]
 include/linux/kvm.h  |   17 ++---
 virt/kvm/kvm_trace.c |   19 ++-
 2 files changed, 24 insertions(+), 12 deletions(-)

[diff]

diff --git a/include/linux/kvm.h b/include/linux/kvm.h
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -311,9 +311,13 @@
 
 /* This structure represents a single trace buffer record. */
 struct kvm_trace_rec {
-   __u32 event:28;
-   __u32 extra_u32:3;
-   __u32 cycle_in:1;
+   /* variable rec_val
+* is split into:
+* bits 0 - 27  - event id
+* bits 28 -30  - number of extra data args of size u32
+* bits 31  - binary indicator for if tsc is in record
+*/
+   __u32 rec_val;
__u32 pid;
__u32 vcpu_id;
union {
@@ -326,6 +330,13 @@
} nocycle;
} u;
 } __attribute__((packed));
+
+#define TRACE_REC_EVENT_ID(val) \
+   (0x0fff  (val))
+#define TRACE_REC_NUM_DATA_ARGS(val) \
+   (0x7000  ((val)  28))
+#define TRACE_REC_TCS(val) \
+   (0x8000  ((val)  31))
 
 #define KVMIO 0xAE
 
diff --git a/virt/kvm/kvm_trace.c b/virt/kvm/kvm_trace.c
--- a/virt/kvm/kvm_trace.c
+++ b/virt/kvm/kvm_trace.c
@@ -54,12 +54,13 @@
struct kvm_trace *kt = kvm_trace;
struct kvm_trace_rec rec;
struct kvm_vcpu *vcpu;
-   inti, extra, size;
+   inti, size;
+   u32extra;
 
if (unlikely(kt-trace_state != KVM_TRACE_STATE_RUNNING))
return;
 
-   rec.event   = va_arg(*args, u32);
+   rec.rec_val = TRACE_REC_EVENT_ID(va_arg(*args, u32));
vcpu= va_arg(*args, struct kvm_vcpu *);
rec.pid = current-tgid;
rec.vcpu_id = vcpu-vcpu_id;
@@ -67,21 +68,21 @@
extra   = va_arg(*args, u32);
WARN_ON(!(extra = KVM_TRC_EXTRA_MAX));
extra   = min_t(u32, extra, KVM_TRC_EXTRA_MAX);
-   rec.extra_u32   = extra;
 
-   rec.cycle_in= p-cycle_in;
-
-   if (rec.cycle_in) {
+   rec.rec_val |= TRACE_REC_TCS(p-cycle_in)
+   | TRACE_REC_NUM_DATA_ARGS(extra);
+   
+   if (p-cycle_in) {
rec.u.cycle.cycle_u64 = get_cycles();
 
-   for (i = 0; i  rec.extra_u32; i++)
+   for (i = 0; i  extra; i++)
rec.u.cycle.extra_u32[i] = va_arg(*args, u32);
} else {
-   for (i = 0; i  rec.extra_u32; i++)
+   for (i = 0; i  extra; i++)
rec.u.nocycle.extra_u32[i] = va_arg(*args, u32);
}
 
-   size = calc_rec_size(rec.cycle_in, rec.extra_u32 * sizeof(u32));
+   size = calc_rec_size(p-cycle_in, extra * sizeof(u32));
relay_write(kt-rchan, rec, size);
 }
 
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] libkvm-s390

2008-07-14 Thread Christian Borntraeger

Am Montag, 14. Juli 2008 schrieb Avi Kivity:
 Certainly.  I suggest exposing this via a KVM_CAP_blah and adapting at 
 runtime.
 
 Placing the guest at offset zero is dangerous, since all a guest has to 
 do is place a function at guest physical address zero and wait for a 
 kernel bug that calls a null function pointer (at least, it would behave 
 like that on x86, provided no-execute was disabled; it may well be that 
 s390 has additional protection).

Since we have separate address space for kernel and userspace this should be 
fine for s390. But I totally agree that offset != 0 is better for quality and 
testing. During KVM Forum time frame I found some null pointer accesses in 
our userspace code when I changed offset to 1MB. In the long term we 
definitely want to move our guest.

Christian
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ kvm-Bugs-2017966 ] Booting Vista Guest may crash host

Bugs item #2017966, was opened at 2008-07-14 06:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=2017966group_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: Jiajun Xu (jiajun)
Assigned to: Nobody/Anonymous (nobody)
Summary: Booting Vista Guest may crash host

Initial Comment:
Booting Vista Guest may cause host hang on latest commit.
kvm.git a10cfebe86cf85a1d2ab02fccbc1e8c2b3eb92b5 and 
userspace.git fbd8c32b77751236b35397e05c0bc84c48833d97.

The issue does not happen every time, but booting Vista Guest for more than 10 
times can reproduce the bug. 

Serial output is attached.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=2017966group_id=180599
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

KVM Test result, kernel a10cfeb.., userspace fbd8c32.. -- One New issue

2008-07-14 Thread Xu, Jiajun

Hi All,

This is today's KVM test result against kvm.git
a10cfebe86cf85a1d2ab02fccbc1e8c2b3eb92b5 and kvm-userspace.git
fbd8c32b77751236b35397e05c0bc84c48833d97.

One New issue:

1. Booting Vista Guest may crash host
https://sourceforge.net/tracker/?func=detailatid=893831aid=2017966group_id=180599
The issue does not happen every time, but we can reproduce it after
booting Vista Guest for 10 times.

Two Old Issues:

1. 32bits Rhel5/FC6 guest may fail to reboot after installation
https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599

2. failure to migrate guests with more than 4GB of RAM
https://sourceforge.net/tracker/index.php?func=detailaid=1971512group_id=180599atid=893831

Test environment

Platform
Woodcrest

CPU 4
Memory size 8G'

Details

IA32-pae: 1. boot guest with 256M
memory PASS
2. boot guest with 1500M memory PASS
3. boot 4 same guest in parallel PASS
4. boot two windows xp guestPASS
5. boot linux and windows guest in parallel PASS
6. save/restore 32-bit HVM guests PASS
7. save/restore 32-bit HVM guests with 4 vcpus PASS
8. live migration 32-bit HVM guests PASS
9. live migration 32-bit HVM guests with 4 vcpus PASS
10. boot base kernel linux
PASS

11. kernel build on SMP linux guestPASS
12. LTP on linux guest
PASS

13. boot Windows 2000 without ACPI PASS
14. boot Windows 2000 with ACPI enabled PASS
15. boot Windows 2003 with ACPI enabled PASS
16. boot Windows xp with ACPI enabled PASS
17. boot Windows vista with ACPI enabled PASS
18. boot SMP Windows 2000 with ACPI enabled PASS
19. boot SMP Windows 2003 with ACPI enabled PASS
20. boot SMP Windows xp with ACPI enabled PASS
21. boot SMP Windows 2008 with ACPI enabled PASS

IA32e: 1. boot 32-bit guest with 256M
memory PASS
2. boot 64-bit guest with 256M memory PASS
3. boot 32-bit guest with 1500M memory PASS
4. boot 64-bit guest with 1500M memory PASS
5. boot 4G pae
guest PASS
6. boot 4G 64-bit
guest PASS
7. boot four 32-bit guest in
parallel PASS
8. boot four 64-bit guest in
parallel PASS
9. boot two 32-bit windows xp in parallel PASS
10. boot 32-bit linux and 32 bit windows guest in parallel PASS
11. boot four 32-bit different guest in para
PASS
12. save/restore 32-bit linux guests
PASS
13. save/restore 64-bit linux guests
PASS

14. save/restore 64-bit linux guests with 4 vcpus PASS
15. save/restore 32-bit linux guests with 4 vcpus PASS
16. live migration 64bit linux
guests PASS
17. live migration 32bit linux
guests PASS
18. live migration 64bit linux guests with 4 vcpus PASS
19. live migration 32bit linux guests with 4 vcpus PASS
20. boot 32-bit
x-server PASS 21.
kernel build in 32-bit linux guest OS PASS
22. kernel build in 64-bit linux guest OS PASS
23. LTP on 32-bit linux guest OS
PASS
24. LTP on 64-bit linux guest OS
PASS

25. boot 64-bit guests with ACPI enabled PASS
26. boot 32-bit Windows 2000 without ACPIPASS
27. boot 32-bit Windows xp without ACPIPASS
28. boot 64-bit Windows xp with ACPI enabledPASS
29. boot 64-bit Windows vista with ACPI enabled PASS
30. boot 32-bit SMP Windows 2000 with ACPI enabled PASS
31. boot 32-bit SMP windows 2003 with ACPI enabled PASS
32. boot 32-bit SMP Windows xp with ACPI enabledPASS
33. boot 64-bit SMP Windows vista with ACPI enabled FAIL

Re: [PATCH 0/8] kvmtrace: powerpc support and timestamps for KVM_TRACE v3


[EMAIL PROTECTED] wrote:

From: Christian Ehrhardt [EMAIL PROTECTED]

Changing kvmtrace code to use timestamps and add powerpc support.

This is the revised series including the feedback from the earlier submission
last week. I now also added the userspace changes which complete the series.

  


All applied, thanks.

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

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ kvm-Bugs-2017966 ] Booting Vista Guest may crash host

Bugs item #2017966, was opened at 2008-07-14 16:30
Message generated for change (Comment added) made by avik
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=2017966group_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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Jiajun Xu (jiajun)
Assigned to: Nobody/Anonymous (nobody)
Summary: Booting Vista Guest may crash host

Initial Comment:
Booting Vista Guest may cause host hang on latest commit.
kvm.git a10cfebe86cf85a1d2ab02fccbc1e8c2b3eb92b5 and 
userspace.git fbd8c32b77751236b35397e05c0bc84c48833d97.

The issue does not happen every time, but booting Vista Guest for more than 10 
times can reproduce the bug. 

Serial output is attached.

--

Comment By: Avi Kivity (avik)
Date: 2008-07-14 16:59

Message:
Logged In: YES 
user_id=539971
Originator: NO

Is this Vista x86 or Vista x64?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=2017966group_id=180599
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ kvm-Bugs-2017998 ] Booting Vista Guest may crash host

Bugs item #2017998, was opened at 2008-07-14 07:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=2017998group_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: Jiajun Xu (jiajun)
Assigned to: Nobody/Anonymous (nobody)
Summary: Booting Vista Guest may crash host

Initial Comment:
Booting Vista Guest may cause host hang on latest commit.
kvm.git a10cfebe86cf85a1d2ab02fccbc1e8c2b3eb92b5 and 
userspace.git fbd8c32b77751236b35397e05c0bc84c48833d97.

The issue does not happen every time, but booting Vista Guest for more than 10 
times can reproduce the bug. 

Serial output is attached.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=2017998group_id=180599
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ kvm-Bugs-2017966 ] Booting Vista Guest may crash host

Bugs item #2017966, was opened at 2008-07-14 06:30
Message generated for change (Comment added) made by jiajun
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=2017966group_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: Jiajun Xu (jiajun)
Assigned to: Nobody/Anonymous (nobody)
Summary: Booting Vista Guest may crash host

Initial Comment:
Booting Vista Guest may cause host hang on latest commit.
kvm.git a10cfebe86cf85a1d2ab02fccbc1e8c2b3eb92b5 and 
userspace.git fbd8c32b77751236b35397e05c0bc84c48833d97.

The issue does not happen every time, but booting Vista Guest for more than 10 
times can reproduce the bug. 

Serial output is attached.

--

Comment By: Jiajun Xu (jiajun)
Date: 2008-07-14 07:08

Message:
Logged In: YES 
user_id=2142959
Originator: YES

It's Vista x86.

--

Comment By: Avi Kivity (avik)
Date: 2008-07-14 06:59

Message:
Logged In: YES 
user_id=539971
Originator: NO

Is this Vista x86 or Vista x64?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=893831aid=2017966group_id=180599
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BUG: SMP instable with WinXP

2008-07-14 Thread Dietmar Maurer

Kvm: kvm-70 (also tested with kvm-snapshot-20080713.tar.gz)
Kernel: 2.6.24.4

Trying to install WinXp SP2 with -smp 2 fails:

/usr/bin/kvm -usbdevice tablet -name xp -smp 2 -localtime -k de -drive
file=/var/lib/vz/template/iso/de_winxp_pro_with_sp2_vl.iso,if=ide,index=
2,media=cdrom -drive
file=/var/lib/vz/images/101/vm-101-disk.qcow2,if=scsi,index=0,boot=on -m
512 -net tap,vlan=0,script=/var/lib/qemu-server/bridge-vlan0 -net
nic,vlan=0,model=rtl8139,macaddr=B6:3C:78:93:F5:FB

The second reboot always gives an endless loop:

kvm_handle_exit: unexpected, valid vectoring info and exit reason is 0x9

The host is totally unstable after that.

- Dietmar


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANNOUNCE] kvm-71 release

Again, this took longer than I'd like, but the new release is finally 
out. It's composed mainly of incremental fixes, but important ones.


Changes from kvm-70:
- fix virtio isr clearing (Laurent Vivier)
- kvmtrace ppc userspace support (Jerone Young)
- avoid fragmenting virtio-blk transfers (Anthony Liguori, Mark McLoughlin)
- ia64 build fixes (Anthony Xu)
- remove unnecessary virtio-net printout (Marcelo Tosatti)
- remove configure warning about gcc 3 (Carlo Marcelo Arenas Belon)
- rhel 5.2/centos 5.2 host support
- merge qemu-svn
 - adds pulseaudio driver
 - nbd client/server
- disable cpu emulation by default on ia64 (Xiantao Zhang)
- place test support files in a library (Jerone Young)
- fix qemu monitor screendump
- fix lost interrupt when changing a device irq
 - fixes devices going away when disabled and enabled several times
- fix oops on shutdown freeing coalesced mmio page (Akio Takebe)
- optimize segment register access in emulator
- allow run-time enabling of mmu debug
- fix host msr corruption when host preempt is enabled
- fix kvmclock (Gerd Hoffmann)
- rename badly named msrs (Sheng Yang)
- fix incorrect usage of vmcs_config when using ept (Sheng Yang)
- emulate performance counter msrs on Intel (Chris Lalancette)
 - allows Linux 2.6.9 guests to boot
- optimize vapic locking when disabled (Marcelo Tosatti)
- don't allocate dirty bitmap for s390 (Catsten Otte)
- fix memory leak on guest exit (Carsten Otte)
- update s390 guest base and limit (Christian Borntraeger)
- optimize access to guest registers (Marcelo Tosatti)
- add memory clobber to hypercalls (Anthony Liguori)
 - fixes booting guests compiled with gcc 4.3
- fix ioapic hang on heavy load (Mark McLoughlin)
- move kvmtrace definitions to common header (Hollis Blanchard)
- fix suspend/resume on AMD (Joerg Roedel)
- make some functions static (Adrian Bunk)
- fix shrinker locking (Marcelo Tosatti)
- fix ept tlb flush (Sheng Yang)
- fix signal handling on uninitialized vcpus
- fix hlt instruction in real mode (Mohammed Gamal)
- check pic irq range (Ben-Ami Yassour)
- add function to inject irqs into guests (Amit Shah)

Notes:
If you use the modules bundled with kvm-70, you can use any version
of Linux from 2.6.16 upwards.  You may also use kvm-70 userspace with 
the kvm modules provided by Linux 2.6.22 or above.  Some features may 
only be available in newer releases.


http://kvm.qumranet.com


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

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] libkvm-s390

2008-07-14 Thread Anthony Liguori


Carsten Otte wrote:

This patch makes libkvm build and work on s390. It should be a noop for
all other architectures.
  


I'm thinking of spending some time eliminate libkvm altogether in the 
next month or so.  Noone seems to be using it for alternative userspaces 
and the code that interacts with it in QEMU badly needs refactoring.


Dropping the abstraction will probably result in a big drop in lines of 
code and would probably make it more clear anyway.


Regards,

Anthony Liguori


Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
Index: kvm-userspace/libkvm/config-s390x.mak
===
--- /dev/null
+++ kvm-userspace/libkvm/config-s390x.mak
@@ -0,0 +1,6 @@
+
+LIBDIR := /lib
+CFLAGS +=
+CFLAGS += -D__s390x__
+
+libkvm-$(ARCH)-objs := libkvm-s390x.o
Index: kvm-userspace/libkvm/libkvm-s390x.c
===
--- /dev/null
+++ kvm-userspace/libkvm/libkvm-s390x.c
@@ -0,0 +1,98 @@
+/*
+ * This header is for functions  variables that will ONLY be
+ * used inside libkvm for s390x.
+ * THESE ARE NOT EXPOSED TO THE USER AND ARE ONLY FOR USE
+ * WITHIN LIBKVM.
+ *
+ * derived from libkvm-powerpc.c
+ *
+ * Copyright 2008 IBM Corporation
+ * Authors:
+ * Carsten Otte [EMAIL PROTECTED]
+ *
+ * This work is licensed under the GNU LGPL license, version 2.
+ */
+
+#include libkvm.h
+#include errno.h
+#include stdio.h
+#include inttypes.h
+
+int handle_dcr(struct kvm_run *run,  kvm_context_t kvm, int vcpu)
+{
+   fprintf(stderr, %s: Operation not supported\n, __FUNCTION__);
+   return -1;
+}
+
+int kvm_alloc_kernel_memory(kvm_context_t kvm, unsigned long memory,
+   void **vm_mem)
+{
+   fprintf(stderr, %s: Operation not supported\n, __FUNCTION__);
+   return -1;
+}
+
+void *kvm_create_kernel_phys_mem(kvm_context_t kvm, unsigned long phys_start,
+unsigned long len, int log, int writable)
+{
+   fprintf(stderr, %s: Operation not supported\n, __FUNCTION__);
+   return NULL;
+}
+
+void kvm_show_code(kvm_context_t kvm, int vcpu)
+{
+   fprintf(stderr, %s: Operation not supported\n, __FUNCTION__);
+}
+
+void kvm_show_regs(kvm_context_t kvm, int vcpu)
+{
+   struct kvm_regs regs;
+   int i;
+
+   if (kvm_get_regs(kvm, vcpu, regs))
+   return;
+   /*
+   fprintf(stderr,guest vcpu #%d\n, vcpu);
+   fprintf(stderr,pc:   %016PRIx64 msr:  %016PRIx64\n,
+   regs.pc, regs.msr);
+   fprintf(stderr,lr:   %016PRIx64 ctr:  %016PRIx64\n,
+   regs.lr, regs.ctr);
+   fprintf(stderr,srr0: %016PRIx64 srr1: %016PRIx64\n,
+   regs.srr0, regs.srr1);
+   for (i=0; i32; i+=4)
+   {
+   fprintf(stderr, gpr%02d: %016PRIx64 %016PRIx64 %016PRIx64
+%016PRIx64\n, i,
+   regs.gpr[i],
+   regs.gpr[i+1],
+   regs.gpr[i+2],
+   regs.gpr[i+3]);
+   }
+
+   fflush(stdout);
+   */
+}
+
+int kvm_arch_create(kvm_context_t kvm, unsigned long phys_mem_bytes,
+void **vm_mem)
+{
+   return 0;
+}
+
+int kvm_arch_create_default_phys_mem(kvm_context_t kvm,
+   unsigned long phys_mem_bytes,
+   void **vm_mem)
+{
+   return 0;
+}
+
+int kvm_arch_run(struct kvm_run *run, kvm_context_t kvm, int vcpu)
+{
+   int ret = 0;
+
+   switch (run-exit_reason){
+   default:
+   ret = 1;
+   break;
+   }
+   return ret;
+}
Index: kvm-userspace/Makefile
===
--- kvm-userspace.orig/Makefile
+++ kvm-userspace/Makefile
@@ -5,7 +5,7 @@ DESTDIR=
 
 rpmrelease = devel
 
-sane-arch = $(subst i386,x86,$(subst x86_64,x86,$(ARCH)))

+sane-arch = $(subst i386,x86,$(subst x86_64,x86,$(subst s390x,s390,$(ARCH
 
 .PHONY: kernel user libkvm qemu bios vgabios extboot clean libfdt
 
Index: kvm-userspace/libkvm/kvm-common.h

===
--- kvm-userspace.orig/libkvm/kvm-common.h
+++ kvm-userspace/libkvm/kvm-common.h
@@ -18,8 +18,15 @@
 
 /* FIXME: share this number with kvm */

 /* FIXME: or dynamically alloc/realloc regions */
+#ifndef __s390x__
 #define KVM_MAX_NUM_MEM_REGIONS 8u
+#define MAX_VCPUS 64
+#else
+#define KVM_MAX_NUM_MEM_REGIONS 1u
 #define MAX_VCPUS 16
+#define LIBKVM_S390_ORIGIN (0UL)
+#endif
+
 
 /* kvm abi verison variable */

 extern int kvm_abi;
Index: kvm-userspace/libkvm/kvm-s390x.h
===
--- /dev/null
+++ kvm-userspace/libkvm/kvm-s390x.h
@@ -0,0 +1,30 @@
+/*
+ * This header is for functions  variables that will ONLY be
+ * used inside libkvm for s390.
+ * THESE ARE NOT EXPOSED TO THE USER AND ARE ONLY FOR USE
+ * WITHIN LIBKVM.
+ *
+ *

Re: [ANNOUNCE] kvm-71 release

2008-07-14 Thread Farkas Levente


Avi Kivity wrote:
Again, this took longer than I'd like, but the new release is finally 
out. It's composed mainly of incremental fixes, but important ones.


Changes from kvm-70:
- fix virtio isr clearing (Laurent Vivier)
- kvmtrace ppc userspace support (Jerone Young)
- avoid fragmenting virtio-blk transfers (Anthony Liguori, Mark McLoughlin)
- ia64 build fixes (Anthony Xu)
- remove unnecessary virtio-net printout (Marcelo Tosatti)
- remove configure warning about gcc 3 (Carlo Marcelo Arenas Belon)
- rhel 5.2/centos 5.2 host support


but this bug on 5.2 (which is similar that i already reported with 70) 
is still in and the previously applied patch is not working anymore:

-
make KDIR=/usr/src/kernels/2.6.18-92.1.6.el5-x86_64
make -C /usr/src/kernels/2.6.18-92.1.6.el5-x86_64 M=`pwd` \
LINUXINCLUDE=-I`pwd`/include -Iinclude -I`pwd`/include-compat \
-include include/linux/autoconf.h \
-include `pwd`/external-module-compat.h
make[1]: Entering directory `/usr/src/kernels/2.6.18-92.1.6.el5-x86_64'
  LD  /home/robot/rpm/BUILD/kvm-kmod-71/_kmod_build_/kernel/built-in.o
  CC [M]  /home/robot/rpm/BUILD/kvm-kmod-71/_kmod_build_/kernel/svm.o
In file included from command line:2:
/home/robot/rpm/BUILD/kvm-kmod-71/_kmod_build_/kernel/external-module-compat.h:360: 
error: redefinition of typedef 'bool'

include/linux/types.h:36: error: previous declaration of 'bool' was here
-

--
  Levente   Si vis pacem para bellum!
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/2] VMX: Reinject real mode exception

2008-07-14 Thread Nakajima, Jun

On 7/14/2008 3:04:17 AM, Avi Kivity wrote:
 Nakajima, Jun wrote:
  On 7/13/2008 8:31:44 AM, Avi Kivity wrote:
 
   Avi Kivity wrote:
  
Well, xen and bochs do not push an error code for real mode #GP.
I tried running the attached test program but it doesn't work on
real hardware (it does work on bochs).
   
   Jun, perhaps you can clarify? do #GP exceptions in real-mode push
   an error code?
  
 
  Avi,
 
  Exceptions in real-mode do not push an error code in the stack.

 Thanks.  You might consider updating the documentation, for example
 #DF states that an error code of 0 is always pushed.


If you are looking at the description of Chapter 5, at the top it says This 
chapter describes the interrupt and exception-handling mechanism when operating 
in protected mode on an Intel 64 or IA-32 processor. ... Chapter 15, 8086 
Emulation, describes information specific to interrupt and exception 
mechanisms in real-address and virtual-8086 mode..
 .
Jun Nakajima | Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Questions on the VMentry failure patch


Mohammed Gamal wrote:

On Thu, Jul 10, 2008 at 4:48 PM, Mohammed Gamal [EMAIL PROTECTED] wrote:
  

 It's true indeed, the patch did increase the likelihood of the
problem with me (although it occurs every few runs). I modified
invalid_guest_state() to call kvm_report_emulation_failure() in all
cases and I noticed that whenever the crash happens it happens here:

rip 6e10 66 b8 20 00

It's too late at night here, so I'll not lookup the opcode map now :)
. I'll further look into it later.



Another thing, I tried -no-kvm-pit switch and it tremendously increase
the likelihood of the crash to almost a 100%.

  

I updated to the latest kvm-userspace git tree, and now the failure is
happening at completely random instructions whether or not we are
using -no-kvm-pit.




I didn't have the gfxboot source code in hand, but now that I've got
it. It clears out that the failure always occurs in the
switch_to_pm_20 routine. However, the failure doesn't happen at one
particular instruction, but either doesn't happen at all or happens at
any instruction between addresses 6e10 and 6e27.

I'm suspecting it might be some kind of a race condition, although I
don't see where in the code - kernel side to specific - that this race
exactly might occur. Maybe the locking changes in the userspace side
helped some underlying issue to come up to the surface just like what
happened with FreeDOS. I'll look further into it, any
pointers/help/suggestions are appreciated.
  


I suspected an interrupt, which fits the scenario you describe.  
Although Anthony tested this and found out interrupts were not involved, 
IIRC.


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

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Questions on the VMentry failure patch


Anthony Liguori wrote:


I suspected an interrupt, which fits the scenario you describe.  
Although Anthony tested this and found out interrupts were not 
involved, IIRC.


It was at least not occurring for me when an interrupt was being 
injected.  That's not to say that it isn't somehow affected by 
interrupt injections but it doesn't appear to be the obvious interrupt 
occurs while doing switch_to_pm_20.


A good thing to check is whether guest interrupts are enabled at that 
point.  I suspect they aren't.


It might be a host interrupt, forcing an exit (and an entry) at a random 
point, which then fails.


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

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Questions on the VMentry failure patch

2008-07-14 Thread Mohammed Gamal

On Mon, Jul 14, 2008 at 7:24 PM, Avi Kivity [EMAIL PROTECTED] wrote:
 Anthony Liguori wrote:

 I suspected an interrupt, which fits the scenario you describe.  Although
 Anthony tested this and found out interrupts were not involved, IIRC.

 It was at least not occurring for me when an interrupt was being injected.
  That's not to say that it isn't somehow affected by interrupt injections
 but it doesn't appear to be the obvious interrupt occurs while doing
 switch_to_pm_20.

 A good thing to check is whether guest interrupts are enabled at that point.
  I suspect they aren't.


You are right indeed. IF isn't set in the guest's rflags the only bits
set are NT and IOPL=1
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] libkvm-s390

2008-07-14 Thread Anthony Liguori


Christian Borntraeger wrote:

Am Montag, 14. Juli 2008 schrieb Anthony Liguori:
  

Carsten Otte wrote:


This patch makes libkvm build and work on s390. It should be a noop for
all other architectures.
  
  
I'm thinking of spending some time eliminate libkvm altogether in the 
next month or so.  Noone seems to be using it for alternative userspaces 
and the code that interacts with it in QEMU badly needs refactoring.


Dropping the abstraction will probably result in a big drop in lines of 
code and would probably make it more clear anyway.



Does that mean, that I can stop finishing Carstens patch?
  


Depends.  I'd say there's not a lot of utility making kuli use libkvm in 
it's current form.  If you're trying to get QEMU working, then getting 
libkvm working is probably a good start.


It's still not clear whether libkvm is a useful abstraction.  It may be 
that we want to refactor libkvm to be more useful so it's not 100% clear 
atm that it's going away.


Regards,

Anthony Liguori


Christian
  


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] allow enabling/disabling NPT by reloading only the architecture module

2008-07-14 Thread Joerg Roedel

If NPT is enabled after loading both KVM modules on AMD and it should be
disabled, both KVM modules must be reloaded. If only the architecture module is
reloaded the behavior is undefined. With this patch it is possible to disable
NPT only by reloading the kvm_amd module.

Signed-off-by: Joerg Roedel [EMAIL PROTECTED]
---
 arch/x86/kvm/mmu.c |6 ++
 arch/x86/kvm/svm.c |3 ++-
 include/asm-x86/kvm_host.h |1 +
 3 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index bcd0adb..6376e50 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1874,6 +1874,12 @@ void kvm_enable_tdp(void)
 }
 EXPORT_SYMBOL_GPL(kvm_enable_tdp);
 
+void kvm_disable_tdp(void)
+{
+   tdp_enabled = false;
+}
+EXPORT_SYMBOL_GPL(kvm_disable_tdp);
+
 static void free_mmu_pages(struct kvm_vcpu *vcpu)
 {
struct kvm_mmu_page *sp;
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 0c3320e..09e753f 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -452,7 +452,8 @@ static __init int svm_hardware_setup(void)
if (npt_enabled) {
printk(KERN_INFO kvm: Nested Paging enabled\n);
kvm_enable_tdp();
-   }
+   } else
+   kvm_disable_tdp();
 
return 0;
 
diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
index b893a85..f760749 100644
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -567,6 +567,7 @@ int kvm_fix_hypercall(struct kvm_vcpu *vcpu);
 int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva, u32 error_code);
 
 void kvm_enable_tdp(void);
+void kvm_disable_tdp(void);
 
 int load_pdptrs(struct kvm_vcpu *vcpu, unsigned long cr3);
 int complete_pio(struct kvm_vcpu *vcpu);
-- 
1.5.3.7


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

KVM IO performance

2008-07-14 Thread Sukanto Ghosh

Hi all,

Why has the IO device emulation part been kept in userspace ?
IO attempts cause VM-exits to the KVM (running in kernel-mode) it then
forwards these requests to the userspace (mode-switch). After
completion of IO in userspace, another mode switch is done to KVM
before resuming the guests.
What would be the problems had the device emulation parts been moved
totally to kernelspace ?


-- 
Regards,
Sukanto Ghosh
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Sharing variables/memory between host and guest ?

2008-07-14 Thread Arn

 How can one share memory (a few variables not necessarily a page)
 between host/hypervisor and guest VM ?

 If you use the -mem-path qemu option, all guest memory will be in a file on
 tmpfs.  You can mmap that file and access all guest memory.  Of course, this
 is hitting the problem with a fairly bit hammer; more refined approaches are
 possible.

Could you outline the other approaches ?

Thanks
arn
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ANNOUNCE] kvm-71 release (typedef 'bool' on RHEL 5.2)

2008-07-14 Thread Erik Bussink

On Mon, 2008-07-14 at 18:00 +0300, Avi Kivity wrote:
 Again, this took longer than I'd like, but the new release is finally 
 out. It's composed mainly of incremental fixes, but important ones.
 
 Changes from kvm-70:
 ...
 - rhel 5.2/centos 5.2 host support

Thanks for the new release Avi. I'm trying to get kvm-71 to compile on
RHEL 5.2 (x86_64), but I'm running in a typedef 'bool' issue.
Here is my output... I've run thru the 1st make, so this make only shows
the problem.

[EMAIL PROTECTED] kvm-71]# uname -a
Linux eowyn.bussink.local 2.6.18-92.1.6.el5 #1 SMP Fri Jun 20 02:36:06
 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

[EMAIL PROTECTED] kvm-71]# make
make -C libkvm
make[1]: Entering directory `/root/src/kvm-71/libkvm'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/root/src/kvm-71/libkvm'
make -C extboot
make[1]: Entering directory `/root/src/kvm-71/extboot'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/root/src/kvm-71/extboot'
if ! [ -f qemu/pc-bios/extboot.bin ] \
   || ! cmp -s qemu/pc-bios/extboot.bin extboot/extboot.bin;
then \
cp extboot/extboot.bin qemu/pc-bios/extboot.bin; \
fi
make -C qemu
make[1]: Entering directory `/root/src/kvm-71/qemu'
make -C x86_64-softmmu all
make[2]: Entering directory `/root/src/kvm-71/qemu/x86_64-softmmu'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/root/src/kvm-71/qemu/x86_64-softmmu'
make[1]: Leaving directory `/root/src/kvm-71/qemu'
make -C kernel
make[1]: Entering directory `/root/src/kvm-71/kernel'
make -C /lib/modules/2.6.18-92.1.6.el5/build M=`pwd` \
LINUXINCLUDE=-I`pwd`/include -Iinclude
-I`pwd`/include-compat \
-include include/linux/autoconf.h \
-include `pwd`/external-module-compat.h
make[2]: Entering directory `/usr/src/kernels/2.6.18-92.1.6.el5-x86_64'
  CC [M]  /root/src/kvm-71/kernel/svm.o
In file included from command line:2:
/root/src/kvm-71/kernel/external-module-compat.h:360: error:
redefinition of typedef ‘bool’
include/linux/types.h:36: error: previous declaration of ‘bool’ was here
make[3]: *** [/root/src/kvm-71/kernel/svm.o] Error 1
make[2]: *** [_module_/root/src/kvm-71/kernel] Error 2
make[2]: Leaving directory `/usr/src/kernels/2.6.18-92.1.6.el5-x86_64'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/root/src/kvm-71/kernel'
make: *** [kernel] Error 2
[EMAIL PROTECTED] kvm-71]# 

Thanks for the good work.
Erik


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ kvm-Bugs-2017998 ] Booting Vista Guest may crash host