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 ke
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:22
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.
Gregory Haskins wrote:
> Solved Issue 2) "exception 12" during BIOS real-mode execution on kvm-15. I
> bisected this down to svn revision 4423. When I backed out the bios.bin to
> the previous version, I am now able to get the later code to boot (14-16).
> Note that the CDROM is now inaccessi
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
Ingo Molnar wrote:
> Subject: [patch] KVM: trivial whitespace fixes
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> trivial whitespace fixes.
>
>
Applied, thanks. I really need to get my commit scripts to check this.
--
error compiling committee.c: too many arguments to function
-
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 c
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 a
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> 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
* 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
===
--- linux.orig/driv
* 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 you mean this message:
U
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> > static void audit_mappings(struct kvm_vcpu *vcpu)
> > {
> >-unsigned i;
> >+unsigned i, j;
> >
> > if (vcpu->mmu.root_level == 4) {
> > audit_mappings_page(vcpu, vcpu->mmu.root_hpa, 0, 4);
> >
>
> My audit_mappings() doesn't
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(uns
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).
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;
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 unconditionally in assembly:
>
>
* 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_P
This patchset updates the kvm userspace interface to what I hope will
be the long-term stable interface. Provisions are included for extending
the interface later. The patches address performance and cleanliness
concerns.
One patch is missing -- I'd like the string pio transfers not to include
g
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 kvm
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 a/dri
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 b176
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.
Signed-off-
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 Ki
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 d8
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 +++-
i
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 10064
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 a/drivers/kvm/kv
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 softwar
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]>
---
drivers/kvm/
Older userspace didn't care, but newer userspace (with the cpuid changes)
does.
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
---
drivers/kvm/svm.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index 0311665..2396ada 100644
--- a/
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 b/
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 i
>
>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
funct
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 unco
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
Subject: [patch] KVM: mmu.c, change BUG_ON() to WARN_ON()
From: Ingo Molnar <[EMAIL PROTECTED]>
this triggered for me with the cr3 cache - do not crash the host, just
warn about the condition. (Given that there is code after the BUG_ON()
this was the anticipated behavior i suspect.)
Signed-off-
> (Given that there is code after the BUG_ON() this was the anticipated
> behavior i suspect.)
ignore this sentence - it wasnt a BUG_ON(1).
Ingo
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForg
44 matches
Mail list logo
