kvm-devel — kernel virtual machine development

[kvm-devel] cirrusfb division by zero

[Marcelo T. <mto...@re...>]

Anthony, 

The following sequence crashes F9 guests, when using VNC:

# modprobe cirrusfb
# vbetool post

Results in Floating point exception at:

cirrus_do_copy()
{

    depth = s->get_bpp((VGAState *)s) / 8 
    ...
    sx = (src % (width * depth)) / depth;
    ...
}

Problem is that ->get_bpp returns 0.

Following band-aid "fixes it" (coff). I have no idea if its correct
though ?

"vbetool post" corrupts both SDL and VNC displays when using cirrusfb,
but seems a separate problem.


diff --git a/qemu/hw/cirrus_vga.c b/qemu/hw/cirrus_vga.c
index e14ec35..9f860ff 100644
--- a/qemu/hw/cirrus_vga.c
+++ b/qemu/hw/cirrus_vga.c
@@ -709,6 +709,8 @@ static void cirrus_do_copy(CirrusVGAState *s, int dst, int src, int w, in     int notify = 0;

     depth = s->get_bpp((VGAState *)s) / 8;
+    if (!depth)
+        depth = 1;
     s->get_resolution((VGAState *)s, &width, &height);

     /* extra x, y */

[kvm-devel] KVM: PIT: support mode 4

[Marcelo T. <mto...@re...>]

The in-kernel PIT emulation ignores pending timers if operating under
mode 4, which for example DragonFlyBSD uses (and Plan9 too, apparently).

Mode 4 seems to be similar to one-shot mode, other than the fact that it
starts counting after the next CLK pulse once programmed, while mode 1
starts counting immediately, so add a FIXME to enhance precision.

Fixes https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1952988&group_id=180599

Signed-off-by: Marcelo Tosatti <mto...@re...>
Acked-by: Sheng Yang <she...@in...>

diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 908520c..1646102 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -288,6 +288,8 @@ static void pit_load_count(struct kvm *kvm, int channel, u32 val)
 	 * mode 1 is one shot, mode 2 is period, otherwise del timer */
 	switch (ps->channels[0].mode) {
 	case 1:
+        /* FIXME: enhance mode 4 precision */
+	case 4:
 		create_pit_timer(&ps->pit_timer, val, 0);
 		break;
 	case 2:

[kvm-devel] [PATCH] kvm_show_code for ROM code

[Jan K. <jan...@si...>]

Userland-located ROM memory is not available via kvm->physical_memory +
guest_address. To let kvm_show_code also dump useful information when
some problem in ROM (BIOS...) occurs, this patch first tries to obtain
the memory content via the mmio_read callback - maybe not 100% clean,
but works at least for the QEMU use case. If the callback complains
about the given address, we then fall back to RAM access.

Signed-off-by: Jan Kiszka <jan...@si...>
---
 libkvm/libkvm-x86.c |   17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

Index: b/libkvm/libkvm-x86.c
===================================================================
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -393,14 +393,15 @@ int kvm_set_pit(kvm_context_t kvm, struc
 
 void kvm_show_code(kvm_context_t kvm, int vcpu)
 {
+#define CODE_LEN	50
 #define CR0_PE_MASK	(1ULL<<0)
 	int fd = kvm->vcpu_fd[vcpu];
 	struct kvm_regs regs;
 	struct kvm_sregs sregs;
-	int r;
-	unsigned char code[50];
+	int r, n;
 	int back_offset;
-	char code_str[sizeof(code) * 3 + 1];
+	unsigned char code;
+	char code_str[CODE_LEN * 3 + 1];
 	unsigned long rip;
 
 	r = ioctl(fd, KVM_GET_SREGS, &sregs);
@@ -420,12 +421,14 @@ void kvm_show_code(kvm_context_t kvm, in
 	back_offset = regs.rip;
 	if (back_offset > 20)
 	    back_offset = 20;
-	memcpy(code, kvm->physical_memory + rip - back_offset, sizeof code);
 	*code_str = 0;
-	for (r = 0; r < sizeof code; ++r) {
-	    	if (r == back_offset)
+	for (n = -back_offset; n < CODE_LEN-back_offset; ++n) {
+		if (n == 0)
 			strcat(code_str, " -->");
-		sprintf(code_str + strlen(code_str), " %02x", code[r]);
+		r = kvm->callbacks->mmio_read(kvm->opaque, rip + n, &code, 1);
+		if (r < 0)
+			code = *(unsigned char *)(kvm->physical_memory + rip + n);
+		sprintf(code_str + strlen(code_str), " %02x", code);
 	}
 	fprintf(stderr, "code:%s\n", code_str);
 }

Re: [kvm-devel] [PATCH] x86: handle double and triple faults for every exception

[Jan K. <jan...@si...>]

Avi Kivity wrote:
> Jan Kiszka wrote:
>>>> Clear the pending original exception when raising a triple fault. This
>>>> allows to re-use the vcpu instance, e.g. after a reset which is
>>>> typically issued as reaction on the triple fault.
>>>>
>>>> Signed-off-by: Jan Kiszka <jan...@si...>
>>>>
>>>> ---
>>>>  arch/x86/kvm/x86.c |    4 +++-
>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> Index: b/arch/x86/kvm/x86.c
>>>> ===================================================================
>>>> --- a/arch/x86/kvm/x86.c
>>>> +++ b/arch/x86/kvm/x86.c
>>>> @@ -149,8 +149,10 @@ static void handle_multiple_faults(struc
>>>>      if (vcpu->arch.exception.nr != DF_VECTOR) {
>>>>          vcpu->arch.exception.nr = DF_VECTOR;
>>>>          vcpu->arch.exception.error_code = 0;
>>>> -    } else
>>>> +    } else {
>>>>          set_bit(KVM_REQ_TRIPLE_FAULT, &vcpu->requests);
>>>> +        vcpu->arch.exception.pending = false;
>>>> +    }
>>>>  }
>>>>  
>>>>  void kvm_queue_exception(struct kvm_vcpu *vcpu, unsigned nr)
>>>>
>>>>         
>>> There's a bigger problem here.  The exception queue is hidden state that
>>> qemu and load and save.
>>>     
>>
>> Could you elaborate a bit on what the problematic scenario precisely is
>> (that pending triple faults would not be saved/restored while pending
>> exceptions are?), and if I/we can do anything to resolve it?
>>   
> 
> Two scenarios:
> 
>  savevm (no pending exception)
>  guest runs...
>  loadvm (with a pending exception in the current state)
>  spurious exception injected
> 
>  savevm (pending exception, lost)
>  new qemu instance (or live migration)
>  loadvm (exception not delivered)
> 
> The second scenario is not too bad, I guess: for fault-like exceptions,
> the first instruction would fault again and the exception would be
> regenerated.  The first scenario is bad, but I guess very unlikely.
> 
> One fix would be to expose the exception queue to userspace.  I don't
> like it since this is not x86 architectural state but a kvm artifact. 
> Maybe we should clear the exception queue on kvm_set_sregs() (that
> should fix the reset case as well).

Yes, the following still works for me. But I'm not the right person to
ask if there are obscure cases where you may not want this clearing
while just editing some registers (I'm thinking of debugger scenarios
now).

---------

Clear pending exceptions when setting new register values. This avoids
spurious exceptions after restoring a vcpu state or after
reset-on-triple-fault.

Signed-off-by: Jan Kiszka <jan...@si...>
---
 arch/x86/kvm/x86.c |    2 ++
 1 file changed, 2 insertions(+)

Index: b/arch/x86/kvm/x86.c
===================================================================
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3025,6 +3025,8 @@ int kvm_arch_vcpu_ioctl_set_regs(struct 
 
 	kvm_x86_ops->decache_regs(vcpu);
 
+	vcpu->arch.exception.pending = false;
+
 	vcpu_put(vcpu);
 
 	return 0;

[kvm-devel] [PATCH 0/6] SVM: complete support for kvmtrace

[Joerg R. <joe...@am...>]

This series of patches adds the missing kvmtrace markers to the SVM specific
code paths in KVM. Further it adds a new trace event for TDP page faults.

The diffstat:

 arch/x86/kvm/lapic.c  |    4 ++++
 arch/x86/kvm/svm.c    |   45 ++++++++++++++++++++++++++++++++++++++++++---
 arch/x86/kvm/vmx.c    |    2 --
 arch/x86/kvm/x86.c    |   25 ++++++++++++++++++++-----
 include/asm-x86/kvm.h |    1 +
 5 files changed, 67 insertions(+), 10 deletions(-)

[kvm-devel] [PATCH] kvm-userspace: add kvmtrace format for TDP events

[Joerg R. <joe...@am...>]

This patch adds a format line for TDP page faults to the formats file.

Signed-off-by: Joerg Roedel <joe...@am...>
---
 user/formats |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/user/formats b/user/formats
index 5313a47..c6c49d6 100644
--- a/user/formats
+++ b/user/formats
@@ -22,3 +22,4 @@
 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 ]
-- 
1.5.3.7

[kvm-devel] [PATCH] SVM: add tracing support for TDP page faults

[Joerg R. <joe...@am...>]

To distinguish between real page faults and nested page faults they should be
traced as different events. This is implemented by this patch.

Signed-off-by: Joerg Roedel <joe...@am...>
---
 arch/x86/kvm/svm.c    |    4 ++++
 include/asm-x86/kvm.h |    1 +
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index db90984..5528121 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1011,6 +1011,10 @@ static int pf_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
 		KVMTRACE_3D(PAGE_FAULT, &svm->vcpu, error_code,
 			    (u32)fault_address, (u32)(fault_address >> 32),
 			    handler);
+	else
+		KVMTRACE_3D(TDP_FAULT, &svm->vcpu, error_code,
+			    (u32)fault_address, (u32)(fault_address >> 32),
+			    handler);
 
 	return kvm_mmu_page_fault(&svm->vcpu, fault_address, error_code);
 }
diff --git a/include/asm-x86/kvm.h b/include/asm-x86/kvm.h
index 80eefef..6f18408 100644
--- a/include/asm-x86/kvm.h
+++ b/include/asm-x86/kvm.h
@@ -228,5 +228,6 @@ struct kvm_pit_state {
 #define KVM_TRC_CLTS             (KVM_TRC_HANDLER + 0x12)
 #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)
 
 #endif
-- 
1.5.3.7

[kvm-devel] [PATCH] VMX: move APIC_ACCESS trace entry to generic code

[Joerg R. <joe...@am...>]

This patch moves the trace entry for APIC accesses from the VMX code to the
generic lapic code. This way APIC accesses from SVM will also be traced.

Signed-off-by: Joerg Roedel <joe...@am...>
---
 arch/x86/kvm/lapic.c |    4 ++++
 arch/x86/kvm/vmx.c   |    2 --
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 57ac4e4..f42d5a7 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -572,6 +572,8 @@ static u32 __apic_read(struct kvm_lapic *apic, unsigned int offset)
 {
 	u32 val = 0;
 
+	KVMTRACE_1D(APIC_ACCESS, apic->vcpu, (u32)offset, handler);
+
 	if (offset >= LAPIC_MMIO_LENGTH)
 		return 0;
 
@@ -695,6 +697,8 @@ static void apic_mmio_write(struct kvm_io_device *this,
 
 	offset &= 0xff0;
 
+	KVMTRACE_1D(APIC_ACCESS, apic->vcpu, (u32)offset, handler);
+
 	switch (offset) {
 	case APIC_ID:		/* Local APIC ID */
 		apic_set_reg(apic, APIC_ID, val);
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 79cdbe8..26c4f02 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2550,8 +2550,6 @@ static int handle_apic_access(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
 	exit_qualification = vmcs_read64(EXIT_QUALIFICATION);
 	offset = exit_qualification & 0xffful;
 
-	KVMTRACE_1D(APIC_ACCESS, vcpu, (u32)offset, handler);
-
 	er = emulate_instruction(vcpu, kvm_run, 0, 0, 0);
 
 	if (er !=  EMULATE_DONE) {
-- 
1.5.3.7

[kvm-devel] [PATCH] SVM: implement dedicated INTR exit handler

[Joerg R. <joe...@am...>]

With an exit handler for INTR intercepts its possible to account them using
kvmtrace.

Signed-off-by: Joerg Roedel <joe...@am...>
---
 arch/x86/kvm/svm.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 6dce863..ca83c8a 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1086,6 +1086,12 @@ static int nmi_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
 	return 1;
 }
 
+static int intr_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
+{
+	++svm->vcpu.stat.irq_exits;
+	return 1;
+}
+
 static int nop_on_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
 {
 	return 1;
@@ -1369,7 +1375,7 @@ static int (*svm_exit_handlers[])(struct vcpu_svm *svm,
 	[SVM_EXIT_EXCP_BASE + PF_VECTOR] 	= pf_interception,
 	[SVM_EXIT_EXCP_BASE + NM_VECTOR] 	= nm_interception,
 	[SVM_EXIT_EXCP_BASE + MC_VECTOR] 	= mc_interception,
-	[SVM_EXIT_INTR] 			= nop_on_interception,
+	[SVM_EXIT_INTR] 			= intr_interception,
 	[SVM_EXIT_NMI]				= nmi_interception,
 	[SVM_EXIT_SMI]				= nop_on_interception,
 	[SVM_EXIT_INIT]				= nop_on_interception,
-- 
1.5.3.7

[kvm-devel] [PATCH] SVM: implement dedicated NMI exit handler

[Joerg R. <joe...@am...>]

With an exit handler for NMI intercepts its possible to account them using
kvmtrace.

Signed-off-by: Joerg Roedel <joe...@am...>
---
 arch/x86/kvm/svm.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index ab22615..6dce863 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1081,6 +1081,11 @@ static int io_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
 	return kvm_emulate_pio(&svm->vcpu, kvm_run, in, size, port);
 }
 
+static int nmi_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
+{
+	return 1;
+}
+
 static int nop_on_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
 {
 	return 1;
@@ -1365,7 +1370,7 @@ static int (*svm_exit_handlers[])(struct vcpu_svm *svm,
 	[SVM_EXIT_EXCP_BASE + NM_VECTOR] 	= nm_interception,
 	[SVM_EXIT_EXCP_BASE + MC_VECTOR] 	= mc_interception,
 	[SVM_EXIT_INTR] 			= nop_on_interception,
-	[SVM_EXIT_NMI]				= nop_on_interception,
+	[SVM_EXIT_NMI]				= nmi_interception,
 	[SVM_EXIT_SMI]				= nop_on_interception,
 	[SVM_EXIT_INIT]				= nop_on_interception,
 	[SVM_EXIT_VINTR]			= interrupt_window_interception,
-- 
1.5.3.7

[kvm-devel] [PATCH] SVM: add missing kvmtrace markers

[Joerg R. <joe...@am...>]

This patch adds the missing kvmtrace markers to the svm
module of kvm.

Signed-off-by: Joerg Roedel <joe...@am...>
---
 arch/x86/kvm/svm.c |   26 +++++++++++++++++++++++++-
 1 files changed, 25 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index ca83c8a..db90984 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -949,7 +949,9 @@ static void new_asid(struct vcpu_svm *svm, struct svm_cpu_data *svm_data)
 
 static unsigned long svm_get_dr(struct kvm_vcpu *vcpu, int dr)
 {
-	return to_svm(vcpu)->db_regs[dr];
+	unsigned long val = to_svm(vcpu)->db_regs[dr];
+	KVMTRACE_2D(DR_READ, vcpu, (u32)dr, (u32)val, handler);
+	return val;
 }
 
 static void svm_set_dr(struct kvm_vcpu *vcpu, int dr, unsigned long value,
@@ -1004,6 +1006,12 @@ static int pf_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
 
 	fault_address  = svm->vmcb->control.exit_info_2;
 	error_code = svm->vmcb->control.exit_info_1;
+
+	if (!npt_enabled)
+		KVMTRACE_3D(PAGE_FAULT, &svm->vcpu, error_code,
+			    (u32)fault_address, (u32)(fault_address >> 32),
+			    handler);
+
 	return kvm_mmu_page_fault(&svm->vcpu, fault_address, error_code);
 }
 
@@ -1083,12 +1091,14 @@ static int io_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
 
 static int nmi_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
 {
+	KVMTRACE_0D(NMI, &svm->vcpu, handler);
 	return 1;
 }
 
 static int intr_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
 {
 	++svm->vcpu.stat.irq_exits;
+	KVMTRACE_0D(INTR, &svm->vcpu, handler);
 	return 1;
 }
 
@@ -1230,6 +1240,9 @@ static int rdmsr_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
 	if (svm_get_msr(&svm->vcpu, ecx, &data))
 		kvm_inject_gp(&svm->vcpu, 0);
 	else {
+		KVMTRACE_3D(MSR_READ, &svm->vcpu, ecx, (u32)data,
+			    (u32)(data >> 32), handler);
+
 		svm->vmcb->save.rax = data & 0xffffffff;
 		svm->vcpu.arch.regs[VCPU_REGS_RDX] = data >> 32;
 		svm->next_rip = svm->vmcb->save.rip + 2;
@@ -1315,6 +1328,10 @@ static int wrmsr_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
 	u32 ecx = svm->vcpu.arch.regs[VCPU_REGS_RCX];
 	u64 data = (svm->vmcb->save.rax & -1u)
 		| ((u64)(svm->vcpu.arch.regs[VCPU_REGS_RDX] & -1u) << 32);
+
+	KVMTRACE_3D(MSR_WRITE, &svm->vcpu, ecx, (u32)data, (u32)(data >> 32),
+		    handler);
+
 	svm->next_rip = svm->vmcb->save.rip + 2;
 	if (svm_set_msr(&svm->vcpu, ecx, data))
 		kvm_inject_gp(&svm->vcpu, 0);
@@ -1334,6 +1351,8 @@ static int msr_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
 static int interrupt_window_interception(struct vcpu_svm *svm,
 				   struct kvm_run *kvm_run)
 {
+	KVMTRACE_0D(PEND_INTR, &svm->vcpu, handler);
+
 	svm->vmcb->control.intercept &= ~(1ULL << INTERCEPT_VINTR);
 	svm->vmcb->control.int_ctl &= ~V_IRQ_MASK;
 	/*
@@ -1408,6 +1427,9 @@ static int handle_exit(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
 	struct vcpu_svm *svm = to_svm(vcpu);
 	u32 exit_code = svm->vmcb->control.exit_code;
 
+	KVMTRACE_3D(VMEXIT, vcpu, exit_code, (u32)svm->vmcb->save.rip,
+		    (u32)((u64)svm->vmcb->save.rip >> 32), entryexit);
+
 	if (npt_enabled) {
 		int mmu_reload = 0;
 		if ((vcpu->arch.cr0 ^ svm->vmcb->save.cr0) & X86_CR0_PG) {
@@ -1481,6 +1503,8 @@ static inline void svm_inject_irq(struct vcpu_svm *svm, int irq)
 {
 	struct vmcb_control_area *control;
 
+	KVMTRACE_1D(INJ_VIRQ, &svm->vcpu, (u32)irq, handler);
+
 	control = &svm->vmcb->control;
 	control->int_vector = irq;
 	control->int_ctl &= ~V_INTR_PRIO_MASK;
-- 
1.5.3.7

[kvm-devel] [PATCH] x86: add missing kvmtrace bits

[Joerg R. <joe...@am...>]

This patch adds some kvmtrace bits to the generic x86 code
where it is instrumented from SVM.

Signed-off-by: Joerg Roedel <joe...@am...>
---
 arch/x86/kvm/x86.c |   25 ++++++++++++++++++++-----
 1 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 578a0c1..eae6ad5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1971,6 +1971,7 @@ int emulate_invlpg(struct kvm_vcpu *vcpu, gva_t address)
 
 int emulate_clts(struct kvm_vcpu *vcpu)
 {
+	KVMTRACE_0D(CLTS, vcpu, handler);
 	kvm_x86_ops->set_cr0(vcpu, vcpu->arch.cr0 & ~X86_CR0_TS);
 	return X86EMUL_CONTINUE;
 }
@@ -2551,27 +2552,41 @@ void realmode_lmsw(struct kvm_vcpu *vcpu, unsigned long msw,
 
 unsigned long realmode_get_cr(struct kvm_vcpu *vcpu, int cr)
 {
+	unsigned long value;
+
 	kvm_x86_ops->decache_cr4_guest_bits(vcpu);
 	switch (cr) {
 	case 0:
-		return vcpu->arch.cr0;
+		value = vcpu->arch.cr0;
+		break;
 	case 2:
-		return vcpu->arch.cr2;
+		value = vcpu->arch.cr2;
+		break;
 	case 3:
-		return vcpu->arch.cr3;
+		value = vcpu->arch.cr3;
+		break;
 	case 4:
-		return vcpu->arch.cr4;
+		value = vcpu->arch.cr4;
+		break;
 	case 8:
-		return kvm_get_cr8(vcpu);
+		value = kvm_get_cr8(vcpu);
+		break;
 	default:
 		vcpu_printf(vcpu, "%s: unexpected cr %u\n", __func__, cr);
 		return 0;
 	}
+	KVMTRACE_3D(CR_READ, vcpu, (u32)cr, (u32)value,
+		    (u32)((u64)value >> 32), handler);
+
+	return value;
 }
 
 void realmode_set_cr(struct kvm_vcpu *vcpu, int cr, unsigned long val,
 		     unsigned long *rflags)
 {
+	KVMTRACE_3D(CR_WRITE, vcpu, (u32)cr, (u32)val,
+		    (u32)((u64)val >> 32), handler);
+
 	switch (cr) {
 	case 0:
 		kvm_set_cr0(vcpu, mk_cr_64(vcpu->arch.cr0, val));
-- 
1.5.3.7

[kvm-devel] [ kvm-Bugs-1952988 ] in-kernel PIT blocks DragonFlyBSD from booting

[SourceForge.net <no...@so...>]

Bugs item #1952988, was opened at 2008-04-27 15:25
Message generated for change (Comment added) made by carenas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1952988&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: kernel
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Carlo Marcelo Arenas Belon (carenas)
Assigned to: Nobody/Anonymous (nobody)
Summary: in-kernel PIT blocks DragonFlyBSD from booting

Initial Comment:
starting with kvm 64, DragonFlyBSD guests won't be able to boot unless -no-kvm-pit or -no-kvm-irqchip is used (-no-kvm works as well) :

    cpu model: Intel(R) Core(TM)2 CPU
  kvm version: kvm 66 (kvm>=64 fails, kvm<=63 works)
  host kernel: 2.6.24-gentoo-r4 (SMP)
    host arch: x86_64

to replicate, download dragonfly ISO (it is a livecd) and boot from it :

  kvm -curses -cdrom dfly-1.12.2_REL.iso -boot d

----------------------------------------------------------------------

>Comment By: Carlo Marcelo Arenas Belon (carenas)
Date: 2008-04-30 08:47

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

working stable with the patch

----------------------------------------------------------------------

Comment By: Marcelo Tosatti (mtosatti)
Date: 2008-04-28 14:30

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

DragonFlyBSD uses mode 4 of the PIT which the in-kernel emulation
simply ignores.

Mode 4 seems to be similar to one-shot mode, other than the fact
that mode 4 starts counting after the next CLK pulse once programmed,
and mode1 starts counting immediately, so this _should_ be OK:

http://people.redhat.com/~mtosatti/kvm-i8254-mode4.patch

----------------------------------------------------------------------

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

[kvm-devel] [PATCH] make setup_secondary_clock definition dependent on local apic

[Glauber C. <gc...@re...>]

since the pv_apic_ops are only present if CONFIG_X86_LOCAL_APIC is compiled
in, kvmclock failed to build without this option. This patch fixes this

Signed-off-by: Glauber Costa <gc...@re...>
---
 arch/x86/kernel/kvmclock.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index ddee040..4bc1be5 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -133,6 +133,7 @@ static int kvm_register_clock(void)
 	return native_write_msr_safe(MSR_KVM_SYSTEM_TIME, low, high);
 }
 
+#ifdef CONFIG_X86_LOCAL_APIC
 static void kvm_setup_secondary_clock(void)
 {
 	/*
@@ -143,6 +144,7 @@ static void kvm_setup_secondary_clock(void)
 	/* ok, done with our trickery, call native */
 	setup_secondary_APIC_clock();
 }
+#endif
 
 /*
  * After the clock is registered, the host will keep writing to the
@@ -177,7 +179,9 @@ void __init kvmclock_init(void)
 		pv_time_ops.get_wallclock = kvm_get_wallclock;
 		pv_time_ops.set_wallclock = kvm_set_wallclock;
 		pv_time_ops.sched_clock = kvm_clock_read;
+#ifdef CONFIG_X86_LOCAL_APIC
 		pv_apic_ops.setup_secondary_clock = kvm_setup_secondary_clock;
+#endif
 		machine_ops.shutdown  = kvm_shutdown;
 #ifdef CONFIG_KEXEC
 		machine_ops.crash_shutdown  = kvm_crash_shutdown;
-- 
1.5.0.6

Re: [kvm-devel] [PATCH] Handle vma regions with no backing page (v2)

[Anthony L. <an...@co...>]

Andrea Arcangeli wrote:
> On Tue, Apr 29, 2008 at 06:12:51PM -0500, Anthony Liguori wrote:
>   
>> IIUC PPC correctly, all IO pages have corresponding struct pages.  This 
>> means that get_user_pages() would succeed and you can reference count them? 
>>  In this case, we would never take the VM_PFNMAP path.
>>     
>
> get_user_pages only works on vmas where only pfn with struct page can
> be mapped, but if a struct page exists it doesn't mean get_user_pages
> will succeed. All mmio regions should be marked VM_IO as reading on
> them affects hardware somehow and that prevents get_user_pages to work
> on them regardless if a struct page exists.
>   

Ah, thanks for the clarification.

Regards,

Anthony Liguori

Re: [kvm-devel] [PATCH] Handle vma regions with no backing page (v2)

[Hollis B. <ho...@us...>]

On Tuesday 29 April 2008 18:12:51 Anthony Liguori wrote:
> IIUC PPC correctly, all IO pages have corresponding struct pages.  This 
> means that get_user_pages() would succeed and you can reference count 
> them?  In this case, we would never take the VM_PFNMAP path.
> 
> Is that correct?

I think Andrea's answered this, but for the record: I believe ioremap() will 
get you struct pages on PPC, but they don't automatically exist.

-- 
Hollis Blanchard
IBM Linux Technology Center

[kvm-devel] small author mixup (was: git pull KVM updates for 2.6.26rc)

[Christian B. <bor...@de...>]

Am Sonntag, 27. April 2008 schrieb Avi Kivity:
> Carsten Otte (4):
>       s390: KVM preparation: provide hook to enable pgstes in user pagetable
>       KVM: s390: interrupt subsystem, cpu timer, waitpsw
>       KVM: s390: API documentation
>       s390: KVM guest: detect when running on kvm
> 
> Christian Borntraeger (10):
>       KVM: kvm.h: __user requires compiler.h
>       s390: KVM preparation: host memory management changes for s390 kvm
>       s390: KVM preparation: address of the 64bit extint parm in lowcore
>       KVM: s390: sie intercept handling
>       KVM: s390: intercepts for privileged instructions
>       KVM: s390: interprocessor communication via sigp
>       KVM: s390: intercepts for diagnose instructions
>       KVM: s390: add kvm to kconfig on s390
>       KVM: s390: update maintainers
>       s390: KVM guest: virtio device support, and kvm hypercalls

Thats interesting, some of these patches should actually be credited to 
Carsten - and in fact on kvm.git master they are credited to Carsten.

I think the problem is, that these patches contained multiple From lines. On 
kvm.git the first line (Carsten) was used. When you transferred these patches 
to the kvm.git-2.6.26-branch, git used the next From-line as the original one 
was already removed.

While it is not a typical case, is there a better way of specifying multiple 
authors to avoid future confusion?

Christian

Re: [kvm-devel] performance with guests running 2.4 kernels (specifically RHEL3)

[David S. A. <da...@ci...>]

Yes, the 4G/4G patch and the 64G options are both enabled for the hugemem kernel:

CONFIG_HIGHMEM64G=y
CONFIG_X86_4G=y


Differences between the "standard" kernel and the hugemem kernel:

# diff config-2.4.21-47.ELsmp config-2.4.21-47.ELhugemem
2157,2158c2157,2158
< CONFIG_M686=y
< # CONFIG_MPENTIUMIII is not set
---
> # CONFIG_M686 is not set
> CONFIG_MPENTIUMIII=y
2169c2169
< CONFIG_X86_PGE=y
---
> # CONFIG_X86_PGE is not set
2193c2193
< # CONFIG_X86_4G is not set
---
> CONFIG_X86_4G=y
2365,2366c2365
< CONFIG_M686=y
< CONFIG_X86_PGE=y
---
> CONFIG_MPENTIUMIII=y
2369,2372d2367
< # CONFIG_MXT is not set
< CONFIG_HOTPLUG_PCI=y
< CONFIG_HOTPLUG_PCI_COMPAQ=m
< CONFIG_HOTPLUG_PCI_IBM=m
2373a2369
> CONFIG_X86_4G=y
2377,2379d2372
< # CONFIG_EWRK3 is not set
< CONFIG_UNIX98_PTY_COUNT=2048
< CONFIG_HZ=512
2382a2376,2383
> # CONFIG_MXT is not set
> CONFIG_HOTPLUG_PCI=y
> CONFIG_HOTPLUG_PCI_COMPAQ=m
> CONFIG_HOTPLUG_PCI_IBM=m
> # CONFIG_EWRK3 is not set
> CONFIG_UNIX98_PTY_COUNT=2048
> CONFIG_DEBUG_BUGVERBOSE=y
> # CONFIG_PNPBIOS is not set


Avi:

Centos releases:

http://isoredirect.centos.org/centos/3/isos/i386/

I am running RHEL3.8 which I do not see listed. Also, I'll need to work on a
stock install and try to capture some kind of workload that exhibits the
problem. It will be a couple of days.

david


Daniel P. Berrange wrote:
> On Wed, Apr 30, 2008 at 07:39:53AM -0600, David S. Ahern wrote:
>> Avi Kivity wrote:
>>> David S. Ahern wrote:
>>>> Another tidbit for you guys as I make my way through various
>>>> permutations:
>>>> I installed the RHEL3 hugemem kernel and the guest behavior is *much*
>>>> better.
>>>> System time still has some regular hiccups that are higher than xen
>>>> and esx
>>>> (e.g., 1 minute samples out of 5 show system time between 10 and 15%),
>>>> but
>>>> overall guest behavior is good with the hugemem kernel.
>>>>
>>>>   
>>> Wait, the amount of info here is overwhelming. Let's stick with the
>>> current kernel (32-bit, HIGHMEM4G, right?)
>>>
>>> Did you get any traces with bypass_guest_pf=0? That may show more info.
>>>
>> My preference is to stick with the "standard", 32-bit RHEL3 kernel in the guest.
>> My point in the last email was that the hugemem kernel shows a remarkable
>> difference (it uses 3-levels of page tables right?). I was hoping that would
>> ring a bell with someone.
> 
> IIRC, the RHEL-3  hugemem kernel is using the 4g/4g split patches which
> give userspace and kernelspace their own independant pagetables
> 
>   http://lwn.net/Articles/39925/
>   http://lwn.net/Articles/39283/
> 
> Dan.

[kvm-devel] You make me wet real quick

[Cauley <sin...@AN...>]

My neighbor keeps me awake all night with their late night activities http://www.poieuean.com/

Re: [kvm-devel] [PATCH] Handle vma regions with no backing page (v2)

[Carsten O. <co...@de...>]

Avi Kivity wrote:
> Hollis/Xiantao/Carsten, can you confirm that this approach works for 
> you?  Carsten, I believe you don't have mmio, but at least this 
> shouldn't interfere.
Should work fine on s390 afaics.

[kvm-devel] [ kvm-Bugs-1953353 ] could not load PC BIOS '/path/to/bios.bin' on "-m 4096"

[SourceForge.net <no...@so...>]

Bugs item #1953353, was opened at 2008-04-28 14:50
Message generated for change (Comment added) made by izike
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1953353&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: Rafal Wijata (ravpl)
Assigned to: Nobody/Anonymous (nobody)
Summary: could not load PC BIOS '/path/to/bios.bin' on "-m 4096"

Initial Comment:
The maximum amount of memory I can give to kvm is ~3560M

I run custom compiled kvm-66 on F8 box with
Linux mailhub 2.6.24.4-64.fc8 #1 SMP Sat Mar 29 09:15:49 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
The modules are loaded from F8 kernel, rather than those shipped with kvm-66

----------------------------------------------------------------------

>Comment By: Izik Eidus (izike)
Date: 2008-04-30 17:12

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

above 4 giga support in kvm, work stable just for kernel modules with
userspace memory allocation (kvm 50~, or 2.6.25)
however there is no actually any limitation in making it work for older
kernel modules,
i will take a look on it, (but it will take me few weeks until i will
touch it)

----------------------------------------------------------------------

Comment By: Marcelo Tosatti (mtosatti)
Date: 2008-04-30 16:30

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

This bug can be marked as CLOSED.

----------------------------------------------------------------------

Comment By: Rafal Wijata (ravpl)
Date: 2008-04-30 15:53

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

Indeed, I grabbed the kvm-67, recompiled, and loaded modules that comes
with kvm(kvm-intel).
After that I could give to the guest even 6G of ram.

And BTW, after I loaded those modules I was able to assign more than 4
CPUs to the guest as well(I remember there's such bug here).

Thanx for prompt reply.

----------------------------------------------------------------------

Comment By: Marcelo Tosatti (mtosatti)
Date: 2008-04-30 04:34

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

Can you reproduce the problem with the modules shipped with kvm-66?


----------------------------------------------------------------------

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

Re: [kvm-devel] performance with guests running 2.4 kernels (specifically RHEL3)

[Daniel P. B. <ber...@re...>]

On Wed, Apr 30, 2008 at 07:39:53AM -0600, David S. Ahern wrote:
> Avi Kivity wrote:
> > David S. Ahern wrote:
> >> Another tidbit for you guys as I make my way through various
> >> permutations:
> >> I installed the RHEL3 hugemem kernel and the guest behavior is *much*
> >> better.
> >> System time still has some regular hiccups that are higher than xen
> >> and esx
> >> (e.g., 1 minute samples out of 5 show system time between 10 and 15%),
> >> but
> >> overall guest behavior is good with the hugemem kernel.
> >>
> >>   
> > 
> > Wait, the amount of info here is overwhelming. Let's stick with the
> > current kernel (32-bit, HIGHMEM4G, right?)
> > 
> > Did you get any traces with bypass_guest_pf=0? That may show more info.
> > 
> 
> My preference is to stick with the "standard", 32-bit RHEL3 kernel in the guest.
> My point in the last email was that the hugemem kernel shows a remarkable
> difference (it uses 3-levels of page tables right?). I was hoping that would
> ring a bell with someone.

IIRC, the RHEL-3  hugemem kernel is using the 4g/4g split patches which
give userspace and kernelspace their own independant pagetables

  http://lwn.net/Articles/39925/
  http://lwn.net/Articles/39283/

Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [kvm-devel] performance with guests running 2.4 kernels (specifically RHEL3)

[Avi K. <av...@qu...>]

David S. Ahern wrote:
> Avi Kivity wrote:
>   
>> David S. Ahern wrote:
>>     
>>> Another tidbit for you guys as I make my way through various
>>> permutations:
>>> I installed the RHEL3 hugemem kernel and the guest behavior is *much*
>>> better.
>>> System time still has some regular hiccups that are higher than xen
>>> and esx
>>> (e.g., 1 minute samples out of 5 show system time between 10 and 15%),
>>> but
>>> overall guest behavior is good with the hugemem kernel.
>>>
>>>   
>>>       
>> Wait, the amount of info here is overwhelming. Let's stick with the
>> current kernel (32-bit, HIGHMEM4G, right?)
>>
>> Did you get any traces with bypass_guest_pf=0? That may show more info.
>>
>>     
>
> My preference is to stick with the "standard", 32-bit RHEL3 kernel in the guest.
>   

Me too. I would like to see all reasonable guests supported well, 
without performance issues, and not have to tell the use which kernel to 
use.

> My point in the last email was that the hugemem kernel shows a remarkable
> difference (it uses 3-levels of page tables right?). I was hoping that would
> ring a bell with someone.
>   

 From the traces I saw I think the standard kernel is pae as well.  Can 
you verify?  I think it's CONFIG_HIGHMEM4G (instead of 
CONFIG_HIGHMEM64G) but that option may be different for such an old kernel.

> Adding bypass_guest_pf=0 did not improve the situation. Did you want anything
> particular with that setting -- like a RIP summary or a summary of exit-entry
> cycles?
>   

I asked fo this thinking bypass_guest_pf may help show more 
information.  But thinking a bit more, it will not.

I think I do know what the problem is.  I will try it out.  Is there a 
free clone (like centos) available somewhere?

-- 
Any sufficiently difficult bug is indistinguishable from a feature.

Re: [kvm-devel] performance with guests running 2.4 kernels (specifically RHEL3)

[David S. A. <da...@ci...>]

Avi Kivity wrote:
> David S. Ahern wrote:
>> Another tidbit for you guys as I make my way through various
>> permutations:
>> I installed the RHEL3 hugemem kernel and the guest behavior is *much*
>> better.
>> System time still has some regular hiccups that are higher than xen
>> and esx
>> (e.g., 1 minute samples out of 5 show system time between 10 and 15%),
>> but
>> overall guest behavior is good with the hugemem kernel.
>>
>>   
> 
> Wait, the amount of info here is overwhelming. Let's stick with the
> current kernel (32-bit, HIGHMEM4G, right?)
> 
> Did you get any traces with bypass_guest_pf=0? That may show more info.
> 

My preference is to stick with the "standard", 32-bit RHEL3 kernel in the guest.
My point in the last email was that the hugemem kernel shows a remarkable
difference (it uses 3-levels of page tables right?). I was hoping that would
ring a bell with someone.

Adding bypass_guest_pf=0 did not improve the situation. Did you want anything
particular with that setting -- like a RIP summary or a summary of exit-entry
cycles?

david

[kvm-devel] [ kvm-Bugs-1953353 ] could not load PC BIOS '/path/to/bios.bin' on "-m 4096"

[SourceForge.net <no...@so...>]

Bugs item #1953353, was opened at 2008-04-28 07:50
Message generated for change (Comment added) made by mtosatti
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1953353&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: Rafal Wijata (ravpl)
Assigned to: Nobody/Anonymous (nobody)
Summary: could not load PC BIOS '/path/to/bios.bin' on "-m 4096"

Initial Comment:
The maximum amount of memory I can give to kvm is ~3560M

I run custom compiled kvm-66 on F8 box with
Linux mailhub 2.6.24.4-64.fc8 #1 SMP Sat Mar 29 09:15:49 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
The modules are loaded from F8 kernel, rather than those shipped with kvm-66

----------------------------------------------------------------------

Comment By: Marcelo Tosatti (mtosatti)
Date: 2008-04-30 09:30

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

This bug can be marked as CLOSED.

----------------------------------------------------------------------

Comment By: Rafal Wijata (ravpl)
Date: 2008-04-30 08:53

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

Indeed, I grabbed the kvm-67, recompiled, and loaded modules that comes
with kvm(kvm-intel).
After that I could give to the guest even 6G of ram.

And BTW, after I loaded those modules I was able to assign more than 4
CPUs to the guest as well(I remember there's such bug here).

Thanx for prompt reply.

----------------------------------------------------------------------

Comment By: Marcelo Tosatti (mtosatti)
Date: 2008-04-29 21:34

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

Can you reproduce the problem with the modules shipped with kvm-66?


----------------------------------------------------------------------

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