From: Mohammed Gamal [EMAIL PROTECTED]
Since checking for vcpu-arch.rmode.active is already done whenever we
call handle_rmode_exception(), checking it inside the function is redundant.
Signed-off-by: Mohammed Gamal [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git
From: Avi Kivity [EMAIL PROTECTED]
The direct mapped shadow code (used for real mode and two dimensional paging)
sets upper-level ptes using direct assignment rather than calling
set_shadow_pte(). A nonpae host will split this into two writes, which opens
up a race if another vcpu accesses the
From: Avi Kivity [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
index c31164e..55e179a 100644
--- a/arch/x86/kvm/i8259.c
+++ b/arch/x86/kvm/i8259.c
@@ -30,6 +30,11 @@
#include linux/kvm_host.h
+static void
Bugs item #1842160, was opened at 2007-11-30 21:12
Message generated for change (Comment added) made by carenas
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=1842160group_id=180599
Please note that this message will contain a full copy of the comment
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
Mohammed Gamal wrote:
Since checking for vcpu-arch.rmode.active is already done whenever we
call handle_rmode_exception(), checking it inside the function is redundant.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send
Jan Kiszka wrote:
It looks like that we should forward all #DB exceptions to the guest in
real mode unless we are sure they were caused by a host-injection. Here
is more or less a hack to achieve this (breaking guest debugging for
now):
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index
Glauber Costa wrote:
On Thu, Jul 10, 2008 at 12:39 PM, Avi Kivity [EMAIL PROTECTED] wrote:
Anthony Liguori wrote:
yes. It is address 0xc8821000, apparently part of a pci controller
initialization.
qemu pci starts at 0xe000 IIRC. So maybe the guest is flushing
random
Carsten Otte wrote:
This patch makes libkvm build and work on s390. It should be a noop for
all other architectures.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
Index: kvm-userspace/libkvm/config-s390x.mak
===
--- /dev/null
Zhang, Xiantao wrote:
From 03ac444d1ab4446c587e8180ceaba60b9e75b28d Mon Sep 17 00:00:00 2001
From: Xiantao Zhang [EMAIL PROTECTED]
Date: Fri, 11 Jul 2008 10:13:08 +0800
Subject: [PATCH] KVM: external module: Moving x86-speicif files to x86
directory.
Create x86 directory to hold x86-specific
Avi Kivity wrote:
Jan Kiszka wrote:
It looks like that we should forward all #DB exceptions to the guest in
real mode unless we are sure they were caused by a host-injection. Here
is more or less a hack to achieve this (breaking guest debugging for
now):
diff --git a/arch/x86/kvm/vmx.c
On Sun, Jul 13, 2008 at 12:09 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Avi Kivity wrote:
Jan Kiszka wrote:
It looks like that we should forward all #DB exceptions to the guest in
real mode unless we are sure they were caused by a host-injection. Here
is more or less a hack to achieve this
Jan Kiszka wrote:
But it seems the best thing to do is not to trap #DB in
update_exception_bitmap()?
Was my first idea as well. I do not understand what is going on there,
but when I simply exclude #DB from the exception bitmap in real mode,
the problem pops up again: #GP on
Mohammed Gamal wrote:
+vmx_inject_irq(vcpu, vec);
kvm_queue_exception()
OK.
Not so fast, the GP# pops up again with kvm_queue_exception(). Why
should we use kvm_queue_exception() here?
kvm_queue_exception() will also block interrupt injection. Without
Zhang, Xiantao wrote:
From 28058e18bd74c23c9b7444fbd831311798a53592 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang [EMAIL PROTECTED]
Date: Fri, 11 Jul 2008 09:14:23 +0800
Subject: [PATCH] KVM: Qemu: Fix ia64 build issue.
Fix ia64 build issue due to latest merge with upstream.
Applied,
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
arch/x86/kvm/svm.c |4
arch/x86/kvm/vmx.c |2 +-
include/asm-x86/kvm_host.h |1 +
3 files changed, 2 insertions(+), 5 deletions(-)
Index: b/arch/x86/kvm/svm.c
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
Avi Kivity wrote:
Jan Kiszka wrote:
...
@@ -2234,6 +2252,24 @@ 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
Jan Kiszka wrote:
Avi Kivity wrote:
Jan Kiszka wrote:
...
@@ -2234,6 +2252,24 @@ 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
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?
--
error
Avi Kivity wrote:
Marcelo Tosatti wrote:
The PIC code makes little effort to avoid kvm_vcpu_kick(), resulting in
unnecessary guest exits in some conditions.
For example, if the timer interrupt is routed through the IOAPIC, IRR
for IRQ 0 will get set but not cleared, since the APIC is handling
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
On Sun, Jul 13, 2008 at 9:47 PM, Nakajima, Jun [EMAIL PROTECTED] 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
Thanks David.
I tried the cpu_set command... it exits the VM :( (kvm-70 on Fedora)
-- What about memory ?
-- Any one else on paused state at least ? (can I look at CPU reg.. or
something ?)
Thanks
/Jd
--- On Wed, 7/9/08, David Mair [EMAIL PROTECTED] wrote:
From: David Mair [EMAIL
24 matches
Mail list logo
