Arnd Bergmann wrote:
> On Tuesday 20 March 2007, Avi Kivity wrote:
>
>>> I find using a patch queue useful though for submitting things
>>> upstream. A good example is our QEMU changes. It's a real pain to
>>> break apart the SVN history into individual patches.
>>>
>> Why not just ex
I noticed that time proceeded twice as fast as the actual time in kvm-17
(not sure that it's a new issue, though). I used an x86-64 FC6 guest
(local and IO APIC, w/ ACPI).
Jun
---
Intel Open Source Technology Center
-
Take S
Nakajima, Jun wrote:
> I noticed that time proceeded twice as fast as the actual time in kvm-17
> (not sure that it's a new issue, though). I used an x86-64 FC6 guest
> (local and IO APIC, w/ ACPI).
>
>
Known issue. Don't know what's causing it, though.
--
error compiling committee.c: too m
From: Joerg Roedel <[EMAIL PROTECTED]>
This patch forbids the guest to execute monitor/mwait instructions on
SVM. This is necessary because the guest can execute these instructions
if they are available even if the kvm cpuid doesn't report its
existence.
Signed-off-by: Joerg Roedel <[EMAIL PROTEC
Avi,
Should libc and a kernel be put into the same repository? As far as I
have seen, the pain of migrating kvm into git was caused by interface
incompatibility between libkvm and kvm due to rapid interface flux. I
think the interface should be well-defined, and boiled down, to the
point that li
I get this error message whenever I try to install or boot windows XP
as a guest OS with kvm-17 on kernel 2.6.20 with an AMD64 X2 CPU.
The full dump:
unhandled vm exit: 0x0
rax ffdff13c rbx 001e rcx rdx
rsi 80541b64 rdi 072
Grrr Andi refused to take my "rdmsr64" patch which moved to a
function-like interface for MSRs, dismissing it as pointless churn.
paravirt_ops cleanups changed a macro to an inline and spotted this
kvm bug.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 47c6ee74a5c5 drivers/kvm/vmx
>I get this error message whenever I try to install or boot windows XP
>as a guest OS with kvm-17 on kernel 2.6.20 with an AMD64 X2 CPU.
>
>The full dump:
>unhandled vm exit: 0x0
>rax ffdff13c rbx 001e rcx rdx
>
>rsi 80541b64 rdi 0
Joerg Roedel wrote:
> From: Joerg Roedel <[EMAIL PROTECTED]>
>
> This patch forbids the guest to execute monitor/mwait instructions on
> SVM. This is necessary because the guest can execute these instructions
> if they are available even if the kvm cpuid doesn't report its
> existence.
>
>
You'
Bugs item #1685449, was opened at 2007-03-21 18:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1685449&group_id=180599
Please note that this message will contain a full copy
Rusty Russell wrote:
> Grrr Andi refused to take my "rdmsr64" patch which moved to a
> function-like interface for MSRs, dismissing it as pointless churn.
>
> paravirt_ops cleanups changed a macro to an inline and spotted this
> kvm bug.
>
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
>
>
On Thu, 2007-03-22 at 09:20 +0200, Avi Kivity wrote:
> My rdmsr_safe (x86_64, i386 is similar/same) is
Erk. Andrew, please drop that patch, and take this one.
It was actually Jeremy's paravirt cleanup patch which changed the
calling convention of rdmsr_safe() to match rdmsr().
I went "oh it's t
Rusty Russell wrote:
> It was actually Jeremy's paravirt cleanup patch which changed the
> calling convention of rdmsr_safe() to match rdmsr().
>
Oops, my little mind hobgoblin is getting out of control...
J
-
Take Su
13 matches
Mail list logo
