On Sat, Sep 13, 2008 at 07:55:02AM +0300, Avi Kivity wrote:
> Marcelo Tosatti wrote:
> > VMX initializes the TSC offset for each vcpu at different times, and
> > also reinitializes it for vcpus other than 0 on APIC SIPI message.
> >
> > This bug causes the TSC's to appear unsynchronized in the gues
Hello Nick,
KVM is currently broken upstream, starting with commit
db64fe02258f1507e13fe5212a989922323685ce (rewrite vmap layer)
The symptoms are some vmallocs from kvm fail.
cat /proc/meminfo shows this at the time of the fail:
VmallocTotal: 122880 kB
VmallocUsed: 15184 kB
VmallocChun
On Monday 27 October 2008 3:29:22 pm Glauber Costa wrote:
> On Mon, Oct 27, 2008 at 6:08 PM, Brian Jackson <[EMAIL PROTECTED]> wrote:
> > When building kvm-userspace from git, gawk and unifdef are used by
> > kernel/Makefile. Without this check it's non-obvious why kernel/Makefile
> > fails.
> >
On Mon, Oct 27, 2008 at 6:08 PM, Brian Jackson <[EMAIL PROTECTED]> wrote:
> When building kvm-userspace from git, gawk and unifdef are used by
> kernel/Makefile. Without this check it's non-obvious why kernel/Makefile
> fails.
>
> Signed-off-by: Brian Jackson <[EMAIL PROTECTED]>
>
> diff --git a/co
When building kvm-userspace from git, gawk and unifdef are used by
kernel/Makefile. Without this check it's non-obvious why kernel/Makefile
fails.
Signed-off-by: Brian Jackson <[EMAIL PROTECTED]>
diff --git a/configure b/configure
index 3b5d14f..26f73f3 100755
--- a/configure
+++ b/configure
@@
On Mon, Oct 27, 2008 at 11:19 AM, Daniel P. Berrange
<[EMAIL PROTECTED]> wrote:
> On Mon, Oct 27, 2008 at 11:06:30AM -0700, Bryan McLellan wrote:
>> I'm trying to associate KVM hosts and guests programmatically in a
>> production environment. With VMWare-Server I had passed a variable
>> (hostname
On 27/10/08 21:29 +0200, Avi Kivity wrote:
>
> Mainline recently renamed include/asm-x86 to arch/x86/include/asm.
> Either edit the patches to reflect this, or try 'git am -3' (not sure
> if the latter will work).
Thanks! editing the patches works fine.
Mike
--
Mike Day
http://www.ncultra
Mike Day wrote:
On 20/10/08 19:04 +0200, Alexander Graf wrote:
include/asm-x86/kvm_host.h |3 +++
This file is not present in my clone of Avi's tree, so the patch
doesn't apply.
Am I missing a step?
Mainline recently renamed include/asm-x86 to arch/x86/include/asm.
Eithe
On 20/10/08 19:04 +0200, Alexander Graf wrote:
> include/asm-x86/kvm_host.h |3 +++
This file is not present in my clone of Avi's tree, so the patch
doesn't apply.
Am I missing a step?
thanks,
Mike
--
Mike Day
http://www.ncultra.org
AIM: ncmikeday | Yahoo IM: ultra.runner
PGP key: ht
On Mon, Oct 27, 2008 at 11:06:30AM -0700, Bryan McLellan wrote:
> I'm trying to associate KVM hosts and guests programmatically in a
> production environment. With VMWare-Server I had passed a variable
> (hostname of host) through the backdoor using the vmware-cmd and
> vmware-server binaries. Curr
I'm trying to associate KVM hosts and guests programmatically in a
production environment. With VMWare-Server I had passed a variable
(hostname of host) through the backdoor using the vmware-cmd and
vmware-server binaries. Currently I'm on r62 (Ubuntu package). Is/was
the VMport code before r76 fun
Avi Kivity <[EMAIL PROTECTED]> writes:
> Eduardo Habkost wrote:
>> Can't we just set a flag when we are about to enable vmx, so we run vmxoff
>> only when know it's enabled? There will be a tiny window between setting
>> this flag and and actually running vmxon where things could go wrong,
>> but
Hollis Blanchard wrote:
This is 100% repeatable, and it doesn't happen without your patch
applied.
0x10116f1c in kvm_update_interrupt_request (env=0x103d4718)
at /home/hollisb/source/kvm-userspace-ppc.hg/qemu/qemu-kvm.c:142
142 if (current_env->vcpu_info.created &&
(gdb) bt
Hol
On Mon, 2008-10-27 at 10:48 +0100, Jes Sorensen wrote:
> Hollis Blanchard wrote:
> > It looks like qemu is actually switching threads when this happens...
> > I'm not sure what the current state is of qemu/KVM threads... I think we
> > have 1 thread per vcpu, plus 1 IO thread? If that's right, mayb
On Mon, Oct 27, 2008 at 08:05:50AM -0700, Eric W. Biederman wrote:
> Avi Kivity <[EMAIL PROTECTED]> writes:
>
> > There's no way to query whether vmx is enabled or disabled, AFAICT. So we
> > have
> > to execute vmxoff and ignore possible #UDs.
> >
> > If we trust the exception handlers, there's
On Mon, Oct 27, 2008 at 08:02:31AM -0700, Eric W. Biederman wrote:
> Avi Kivity <[EMAIL PROTECTED]> writes:
>
> > Eric W. Biederman wrote:
> >
> > We've observed on some machines that keyboard controller reset didn't work,
> > and
> > that the fallback to triple-fault asserted INIT and not RESET
Avi Kivity <[EMAIL PROTECTED]> writes:
> There's no way to query whether vmx is enabled or disabled, AFAICT. So we
> have
> to execute vmxoff and ignore possible #UDs.
>
> If we trust the exception handlers, there's no problem. Otherwise we need to
> replace the current #UD handler with an iret
Avi Kivity <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>
> We've observed on some machines that keyboard controller reset didn't work,
> and
> that the fallback to triple-fault asserted INIT and not RESET (and that this
> INIT was blocked, hanging the machine). Switching to acpi reset
On Tue, 2008-10-21 at 10:21 -0500, Anthony Liguori wrote:
> Beth Kon wrote:
Thanks for the feedback, Anthony. I'll only respond where I have
specific comments. Otherwise, I agree to your suggestions and will make
the changes.
> > +if(timer_enabled(timer) && hpet_enabled(timer->state)) {
>
Vivek Goyal wrote:
The hang was likely caused by vmx blocking INIT. Sigh.
Avi,
We boot kdump kernel with maxcpus=1. IIUC, in that code path we will not
be using INIT. So did you try booting kdump kernel with maxcpus=1 and did
it work for you? If not than problem could be something el
Eduardo Habkost wrote:
Can't we just set a flag when we are about to enable vmx, so we run vmxoff
only when know it's enabled? There will be a tiny window between setting
this flag and and actually running vmxon where things could go wrong,
but this doesn't look that bad.
It makes more sense
On Mon, Oct 27, 2008 at 10:54:01AM +0200, Avi Kivity wrote:
> Eduardo Habkost wrote:
>>> (we can use NMI IPIs, but that will likely be messy)
>>>
>>
>> NMI IPIs are already used on x86 native_machine_crash_shutdown(), so
>> it wouldn't get more messy that it is currently. We just need to add
>
On Mon, Oct 27, 2008 at 11:13:41AM +0200, Avi Kivity wrote:
> Eric W. Biederman wrote:
>>> NMI IPIs are already used on x86 native_machine_crash_shutdown(), so
>>> it wouldn't get more messy that it is currently. We just need to add
>>> another bit of code to the code that already runs on an NMI ha
Amit Shah wrote:
These two patches export some bits from SVM's VMCB to the state
that enable migration from AMD hosts to Intel hosts.
x86 Linux-32 bit and 64-bit guests successfully migrate after
applying these patches. Note: Intel->AMD migration of guests
already works.
Applied, thanks.
-
Hollis Blanchard wrote:
It looks like qemu is actually switching threads when this happens...
I'm not sure what the current state is of qemu/KVM threads... I think we
have 1 thread per vcpu, plus 1 IO thread? If that's right, maybe
current_env isn't being initialized in the IO thread; I only see
Eric W. Biederman wrote:
NMI IPIs are already used on x86 native_machine_crash_shutdown(), so
it wouldn't get more messy that it is currently. We just need to add
another bit of code to the code that already runs on an NMI handler.
Yes. And handling of those NMIs is best effort. Nothing
The busy flag of the TR selector is not set by the hardware. This breaks
migration from amd hosts to intel hosts.
Signed-off-by: Amit Shah <[EMAIL PROTECTED]>
---
arch/x86/kvm/svm.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/sv
The hardware does not set the 'g' bit of the cs selector and this breaks
migration from amd hosts to intel hosts. Set this bit if the segment
limit is beyond 1 MB.
Signed-off-by: Amit Shah <[EMAIL PROTECTED]>
---
arch/x86/kvm/svm.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-
Eric W. Biederman wrote:
But what happens when the kdump kernel reboots? If it is uniprocessor, it will
never have a chance to disable vmx on other cpus. Using acpi reset (now
default) works around this on some machines, but not all.
Mostly likely any reboot path will trigger software to
Eduardo Habkost wrote:
(we can use NMI IPIs, but that will likely be messy)
NMI IPIs are already used on x86 native_machine_crash_shutdown(), so
it wouldn't get more messy that it is currently. We just need to add
another bit of code to the code that already runs on an NMI handler.
T
Bugs item #226, was opened at 2008-10-27 08:24
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=226&group_id=180599
Please note that this message will contain a full copy
31 matches
Mail list logo
