Ingo Molnar wrote:
here's a really stupid question that i remember having seen discussed
here before but for which i didnt find the answer in the archives: if i
do a shutdown/halt in a KVM (Linux/Fedora) guest then is qemu supposed
to exit back to the command line? Currently qemu just keeps
Jonathan Khoo wrote:
Hi guys,
I am trying to compile kvm for FC5 (2.6.15-1.2054_FC5smp) and I got
the following error:
Does anyone knows how I can resolve the error?
Many thanks for your help!
/root/kvm-12/qemu/qemu-kvm.c: In function `load_regs':
/root/kvm-12/qemu/qemu-kvm.c:225: unable
John Markh wrote:
Hi,
I managed to compile the KVM from sources (KVM-016) under Fedora Core
6 (i686).
The only problem I had was gcc4.x. After downgrading to 3.4.6 I
managed to compile and use KVM.
I tried to create VM for Windows 2003 (legal) and Fedora Core 6, both
with success.
Since
Mikko Husari wrote:
Hi!
the howto says that i should use qemu instead of qemu-system-x86_64
when using 32bit, my problem is that i dont have that plain qemu and
when using qemu-system-x86_64 winxpsp2 gets bsod right after mup.sys
is loaded, im able to use that installation when -no-kvm
PAGE_MASK is an unsigned long, so using it to mask physical addresses on
i386 (which are 64-bit wide) leads to truncation. This can result in
page-private of unrelated memory pages being modified, with disasterous
results.
Fix by not using PAGE_MASK for physical addresses; instead calculate
the
KVM shadow page tables are always in pae mode, regardless of the guest
setting. This means that a guest pde (mapping 4MB of memory) is mapped
to two shadow pdes (mapping 2MB each).
When the guest writes to a pte or pde, we intercept the write and emulate it.
We also remove any shadowed mappings
This patchset contains fixes I plan to submit pre 2.6.21: a fix for
large memory 32-bit hosts, and a fix for non-pae 32-bit guests.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel
* Avi Kivity [EMAIL PROTECTED] wrote:
PAGE_MASK is an unsigned long, so using it to mask physical addresses
on i386 (which are 64-bit wide) leads to truncation. This can result
in page-private of unrelated memory pages being modified, with
disasterous results.
Fix by not using
From: Ingo Molnar [EMAIL PROTECTED]
Subject: [patch] KVM: fix AUDIT code
fix build bug with AUDIT defined. (it's off by default)
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Index: linux/drivers/kvm/mmu.c
===
---
Ingo Molnar wrote:
From: Ingo Molnar [EMAIL PROTECTED]
Subject: [patch] KVM: fix AUDIT code
fix build bug with AUDIT defined. (it's off by default)
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Index: linux/drivers/kvm/mmu.c
Anthony Liguori [EMAIL PROTECTED] writes:
I've got a patch that should appear in virtbench soon that actually
measures vmcall latency.
http://ozlabs.org/~rusty/virtbench
Thanks Anthony. I have a newbie question though. In the vmcall function in the
patch:
+static int vmcall(unsigned
Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
I've actually never tried an orderly shutdown - I'm too impatient :).
As it works well in qemu (0.8.2), I expect the problem is with our
non-functioning acpi (the kernel complains acpi is broken when it
starts up).
do
hm, i just noticed that in vmx_vcpu_run() KVM restores %fs quite late.
This is a bit awkward under v2.6.21 x86 because there we use %fs for the
KERNEL_PDA area. Things like 'current' rely on it. So maybe we should
just do this unconditionally in assembly:
movl $(__KERNEL_PDA), %edx;
* Avi Kivity [EMAIL PROTECTED] wrote:
i'm also wondering about this bit:
kvm_run-exit_type = 0;
if (fail) {
kvm_run-exit_type = KVM_EXIT_TYPE_FAIL_ENTRY;
kvm_run-exit_reason = vmcs_read32(VM_INSTRUCTION_ERROR);
Subject: [patch] KVM: always reload segment selectors
From: Ingo Molnar [EMAIL PROTECTED]
failed VM entry on VMX might still change %fs or %gs, thus make sure
that KVM always reloads the segment selectors. This is crutial on both
x86 and x86_64: x86 has __KERNEL_PDA in %fs on which things like
Ingo Molnar wrote:
Subject: [patch] KVM: always reload segment selectors
From: Ingo Molnar [EMAIL PROTECTED]
failed VM entry on VMX might still change %fs or %gs, thus make sure
that KVM always reloads the segment selectors. This is crutial on both
x86 and x86_64: x86 has __KERNEL_PDA in
Currently when passing the a PIO emulation request to userspace, we
rely on userspace updating %rax (on 'in' instructions) and %rsi/%rdi/%rcx
(on string instructions). This (a) requires two extra ioctls for getting
and setting the registers and (b) is unfriendly to non-x86 archs, when
they get
Some ioctls ignore their arguments. By requiring them to be zero now,
we allow a nonzero value to have some special meaning in the future.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
---
drivers/kvm/kvm_main.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
---
drivers/kvm/kvm_main.c |6 ++
include/linux/kvm.h|5 +
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 747966e..376538c 100644
--- a/drivers/kvm/kvm_main.c
+++
This allows userspace to ignore the io.rep field. No a big deal, but
friendly.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
---
drivers/kvm/svm.c |1 +
drivers/kvm/vmx.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index
Currently, userspace is told about the nature of the last exit from the
guest using two fields, exit_type and exit_reason, where exit_type has
just two enumerations (and no need for more). So fold exit_type into
exit_reason, reducing the complexity of determining what really happened.
Allow a special signal mask to be used while executing in guest mode. This
allows signals to be used to interrupt a vcpu without requiring signal
delivery to a userspace handler, which is quite expensive. Userspace still
receives -EINTR and can get the signal via sigwait().
Signed-off-by: Avi
The recent changes have left the ioctl numbers in complete disarray.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
---
include/linux/kvm.h | 34 +-
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index
This allows us to store offsets in the kernel/user kvm_run area, and be
sure that userspace has them mapped. As offsets can be outside the
kvm_run struct, userspace has no way of knowing how much to mmap.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
---
drivers/kvm/kvm_main.c |8 +++-
That ioctl does not transfer any data, so it should be an _IO rather than an
_IOW.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
---
include/linux/kvm.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index c6dd4a7..d89189a 100644
We no longer emulate single instructions in userspace. Instead, we service
mmio or pio requests.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
---
drivers/kvm/kvm_main.c |5 -
include/linux/kvm.h|3 +--
2 files changed, 1 insertions(+), 7 deletions(-)
diff --git
KVM used to handle cpuid by letting userspace decide what values to
return to the guest. We now handle cpuid completely in the kernel. We
still let userspace decide which values the guest will see by having
userspace set up the value table beforehand (this is necessary to allow
management
Instead of passing a 'struct kvm_run' back and forth between the kernel and
userspace, allocate a page and allow the user to mmap() it. This reduces
needless copying and makes the interface expandable by providing lots of
free space.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
---
This is redundant, as we also return -EINTR from the ioctl, but it
allows us to examine the exit_reason field on resume without seeing
old data.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
---
drivers/kvm/svm.c |2 ++
drivers/kvm/vmx.c |2 ++
include/linux/kvm.h |3 ++-
3 files
This is useful for paravirtualized graphics devices, for example.
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
---
drivers/kvm/kvm_main.c | 18 +-
include/linux/kvm.h| 10 +-
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/kvm/kvm_main.c
Omar Khan wrote:
Anthony Liguori [EMAIL PROTECTED] writes:
I've got a patch that should appear in virtbench soon that actually
measures vmcall latency.
http://ozlabs.org/~rusty/virtbench
Thanks Anthony. I have a newbie question though. In the vmcall function in the
patch:
Omar Khan wrote:
Anthony Liguori [EMAIL PROTECTED] writes:
I've got a patch that should appear in virtbench soon that actually
measures vmcall latency.
http://ozlabs.org/~rusty/virtbench
Thanks Anthony. I have a newbie question though. In the vmcall
function
in the
patch:
+static
On Sun, 2007-03-11 at 13:24 +0100, Ingo Molnar wrote:
hm, i just noticed that in vmx_vcpu_run() KVM restores %fs quite late.
This is a bit awkward under v2.6.21 x86 because there we use %fs for the
KERNEL_PDA area. Things like 'current' rely on it. So maybe we should
just do this
Dor,
Did you use kvm-16?
Yes, but this problem also occurred in older versions of KVM; I was
simply too lazy to send a message in this forum.
Is there a chance you're using qemu's original bios ( from qemu's rpm )?
I don't know what is qemu's original bios ( from qemu's rpm ).
currently rpm
34 matches
Mail list logo
