Re: RFC: VMX: initialize TSC offset relative to vm creation time
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 guest, even if > > the host is good. > > > > Older Linux kernels don't handle the situation very well, so > > gettimeofday is likely to go backwards in time: > > > > http://www.mail-archive.com/kvm@vger.kernel.org/msg02955.html > > http://sourceforge.net/tracker/index.php?func=detail&aid=2025534&group_id=180599&atid=893831 > > > > Fix it by initializating the offset of each vcpu relative to vm creation > > time, and moving it from vmx_vcpu_reset to vmx_vcpu_setup, out of the > > APIC MP init path. > > > > > > > > This is good in principle, but we need to detect if we're on a multiple > board host (or a host with unsynced tscs) and do something else in that > case. I think this is a separate, and difficult, problem. For instance older Linux guests that correct the TSC across CPU's are broken at the moment in the unsynced TSC case. That is, the fact that KVM does not handle unsynced TSC's on the host is not an argument against this patch which clearly fixes a bug. Take commit 019960ae9933161c2809fa4ee608ba30d9639fd2 for example. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
kvm broken with new vmap
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 VmallocChunk: 83764 kB so there's plenty of space. The allocation that fails seem to be 512 bytes long. I'm not sure it always fails in there, but it seems so. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Add configure script check for gawk and unifdef when using kvm-userspace.git
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.
> >
> > Signed-off-by: Brian Jackson <[EMAIL PROTECTED]>
> >
> > diff --git a/configure b/configure
> > index 3b5d14f..26f73f3 100755
> > --- a/configure
> > +++ b/configure
> > @@ -113,6 +113,17 @@ if [ -d "$kerneldir/include2" ]; then
> > kernelsourcedir=${kerneldir%/*}/source
> > fi
> >
> > +# check for some utils we use
> > +if [ -d .git ] ; then
> > +if [ ! -x "`which gawk`" ] ; then
> > +echo "gawk not installed and necessary for compiling from git"
> > +exit 1
> > +fi
> > +if [ ! -x "`which unifdef`" ] ; then
> > +echo "unifdef not installed and necessary for compiling from
> > git" +exit 1
> > +fi
>
> This is unlikely to be the correct fix. unifdef is provided by the kernel
> tree, under scripts. What we want is something like this:
>
> - unifdef -DCONFIG_$(ARCH_CONFIG) -UCONFIG_$(NONARCH_CONFIG)
> $1.orig > $1; \
> + $(LINUX)/scripts/unifdef -DCONFIG_$(ARCH_CONFIG)
> -UCONFIG_$(NONARCH_CONFIG) $1.orig > $1; \
>[ $$? -le 2 ] && rm $1.orig
>
Huh... I just apt-get installed unifdef and it started working for me, so I
figured that's what it needed.
The other part of the patch should still be good. Avi, want me to resend just
the gawk bit? Or just leave it out and hope people figure out they need gawk.
> > +
> > #configure user dir
> > (cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir"
> > \ --arch="$arch" \
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Add configure script check for gawk and unifdef when using kvm-userspace.git
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/configure b/configure
> index 3b5d14f..26f73f3 100755
> --- a/configure
> +++ b/configure
> @@ -113,6 +113,17 @@ if [ -d "$kerneldir/include2" ]; then
> kernelsourcedir=${kerneldir%/*}/source
> fi
>
> +# check for some utils we use
> +if [ -d .git ] ; then
> +if [ ! -x "`which gawk`" ] ; then
> +echo "gawk not installed and necessary for compiling from git"
> +exit 1
> +fi
> +if [ ! -x "`which unifdef`" ] ; then
> +echo "unifdef not installed and necessary for compiling from git"
> +exit 1
> +fi
This is unlikely to be the correct fix. unifdef is provided by the kernel tree,
under scripts. What we want is something like this:
- unifdef -DCONFIG_$(ARCH_CONFIG) -UCONFIG_$(NONARCH_CONFIG)
$1.orig > $1; \
+ $(LINUX)/scripts/unifdef -DCONFIG_$(ARCH_CONFIG)
-UCONFIG_$(NONARCH_CONFIG) $1.orig > $1; \
[ $$? -le 2 ] && rm $1.orig
> +
> #configure user dir
> (cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir" \
> --arch="$arch" \
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Glauber Costa.
"Free as in Freedom"
http://glommer.net
"The less confident you are, the more serious you have to act."
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] Add configure script check for gawk and unifdef when using kvm-userspace.git
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
@@ -113,6 +113,17 @@ if [ -d "$kerneldir/include2" ]; then
kernelsourcedir=${kerneldir%/*}/source
fi
+# check for some utils we use
+if [ -d .git ] ; then
+if [ ! -x "`which gawk`" ] ; then
+echo "gawk not installed and necessary for compiling from git"
+exit 1
+fi
+if [ ! -x "`which unifdef`" ] ; then
+echo "unifdef not installed and necessary for compiling from git"
+exit 1
+fi
+
#configure user dir
(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir" \
--arch="$arch" \
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM and VMport, or r76 UUID functionality
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 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 functional? Is anyone able to specify what >> it did emulate such that I could use it for a similar purpose? >> >> Or do I need to look for support in libvirt for the changes in r76 >> that allow passing the UUID of the guest into the SMBIOS information >> via the command line, and start working with those? > > Does the latest released kvm finally support the --uuid arg ? If so we'll > happily make use of it in libvirt - its very little work to add it. We've > just been waiting for it to make it into official released versions, so > we don't rely on something that may still have been changing. '-uuid' is in kvm-77. You can verify the uuid with 'info uuid' on in the qemu monitor. The BIOS modifications did not make it in KVM (1a3329) until 78RC1. I suspect we won't see accurate data in the UUID field until then. I haven't tested 78RC1, but the SMBIOS information returned by dmidecode in 77 does not show the correct UUID. Bryan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Implement GIF, clgi and stgi v5
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.org AIM: ncmikeday | Yahoo IM: ultra.runner PGP key: http://www.ncultra.org/ncmike/pubkey.asc -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Implement GIF, clgi and stgi v5
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. Either edit the patches to reflect this, or try 'git am -3' (not sure if the latter will work). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Implement GIF, clgi and stgi v5
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: http://www.ncultra.org/ncmike/pubkey.asc -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM and VMport, or r76 UUID functionality
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. Currently I'm on r62 (Ubuntu package). Is/was > the VMport code before r76 functional? Is anyone able to specify what > it did emulate such that I could use it for a similar purpose? > > Or do I need to look for support in libvirt for the changes in r76 > that allow passing the UUID of the guest into the SMBIOS information > via the command line, and start working with those? Does the latest released kvm finally support the --uuid arg ? If so we'll happily make use of it in libvirt - its very little work to add it. We've just been waiting for it to make it into official released versions, so we don't rely on something that may still have been changing. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM and VMport, or r76 UUID functionality
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 functional? Is anyone able to specify what it did emulate such that I could use it for a similar purpose? Or do I need to look for support in libvirt for the changes in r76 that allow passing the UUID of the guest into the SMBIOS information via the command line, and start working with those? Bryan McLellan [not subscribed] -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: disable virtualization on kdump
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 this doesn't look that bad. >> > > It makes more sense to have a vmxon api in the core; you call it, the kernel > enables it and sets a flag; then either you or the core can disable it. Yes. That sounds like the most maintainable approach. >> The patches I've sent to the kvm mailing list added a notifier interface >> specific for kexec_crash, using raw_notifier_*(). >> >> IMO, if a notifier registration interface was acceptable, the raw >> notifiers would be good enough for that. But Eric seems to think that >> adding a notifier registration interface for the crash handler path >> wouldn't be a good idea, and I am starting to agree with him. >> >> > > I wouldn't mind notifiers (with a nice comment explaining that you must know > what you're doing, though that's the case with most kernel APIs). I'm fine > with > either approach. This is the 3rd request I have seen for a notifier. This is the first request I have seen for code that must be executed in the kexec on panic path. So history suggest to me that notifiers make it unreasonably easy to get code onto the kexec on panic code path. Occasionally the kexec on panic code path is tested to see how well it works in strange situations like being called from a stack overflow etc. The rest of the history is that previous attempts like lkcd had very programmer friendly interfaces, that worked fine in test environments giving beautiful core dumps, but when things broke in the field they were essentially useless. The kdump approach is still not completely reliable but it does work well enough that people get useful crash dumps sometimes. I feel anything that makes the kexec on panic code path harder to verify it will work when things are crazy broken, like a notifier is something we should avoid. Eric -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] fold struct vcpu_info into CPUState
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
Hollis,
Ok, I looked at the logic in this function again and I think I got some
of it wrong when I did the conversion.
Could you try out this one instead.
Thanks,
Jes
Merge vcpu_info into CPUState.
Moves definition of vcpu related structs to new header qemu-kvm-vcpu.h
and declares this struct in i386/ia64/ppc CPUState structs if USE_KVM
is defined. In addition conver qemu-kvm.c to pull vcpu_info out of
CPUState.
This eliminates ugly static sized array of struct vcpu_info.
Signed-off-by: Jes Sorensen <[EMAIL PROTECTED]>
---
libkvm/kvm-common.h|4 -
libkvm/libkvm.c| 14 ++--
libkvm/libkvm.h|6 +-
qemu/qemu-kvm-vcpu.h | 34 +++
qemu/qemu-kvm.c| 146 +
qemu/target-i386/cpu.h |4 +
qemu/target-ia64/cpu.h |5 +
qemu/target-ppc/cpu.h |5 +
8 files changed, 136 insertions(+), 82 deletions(-)
Index: kvm-userspace.git/libkvm/kvm-common.h
===
--- kvm-userspace.git.orig/libkvm/kvm-common.h
+++ kvm-userspace.git/libkvm/kvm-common.h
@@ -84,11 +84,11 @@
void kvm_show_code(kvm_context_t kvm, int vcpu);
int handle_halt(kvm_context_t kvm, int vcpu);
-int handle_shutdown(kvm_context_t kvm, int vcpu);
+int handle_shutdown(kvm_context_t kvm, void *env);
void post_kvm_run(kvm_context_t kvm, int vcpu);
int pre_kvm_run(kvm_context_t kvm, int vcpu);
int handle_io_window(kvm_context_t kvm);
-int handle_debug(kvm_context_t kvm, int vcpu);
+int handle_debug(kvm_context_t kvm, void *env);
int try_push_interrupts(kvm_context_t kvm);
#endif
Index: kvm-userspace.git/libkvm/libkvm.c
===
--- kvm-userspace.git.orig/libkvm/libkvm.c
+++ kvm-userspace.git/libkvm/libkvm.c
@@ -738,9 +738,9 @@
return 0;
}
-int handle_debug(kvm_context_t kvm, int vcpu)
+int handle_debug(kvm_context_t kvm, void *env)
{
- return kvm->callbacks->debug(kvm->opaque, vcpu);
+ return kvm->callbacks->debug(kvm->opaque, env);
}
int kvm_get_regs(kvm_context_t kvm, int vcpu, struct kvm_regs *regs)
@@ -822,9 +822,9 @@
return kvm->callbacks->halt(kvm->opaque, vcpu);
}
-int handle_shutdown(kvm_context_t kvm, int vcpu)
+int handle_shutdown(kvm_context_t kvm, void *env)
{
- return kvm->callbacks->shutdown(kvm->opaque, vcpu);
+ return kvm->callbacks->shutdown(kvm->opaque, env);
}
int try_push_interrupts(kvm_context_t kvm)
@@ -872,7 +872,7 @@
#endif
}
-int kvm_run(kvm_context_t kvm, int vcpu)
+int kvm_run(kvm_context_t kvm, int vcpu, void *env)
{
int r;
int fd = kvm->vcpu_fd[vcpu];
@@ -948,7 +948,7 @@
r = handle_io(kvm, run, vcpu);
break;
case KVM_EXIT_DEBUG:
- r = handle_debug(kvm, vcpu);
+ r = handle_debug(kvm, env);
break;
case KVM_EXIT_MMIO:
r = handle_mmio(kvm, run);
@@ -962,7 +962,7 @@
#endif
break;
case KVM_EXIT_SHUTDOWN:
- r = handle_shutdown(kvm, vcpu);
+ r = handle_shutdown(kvm, env);
break;
#if defined(__s390__)
case KVM_EXIT_S390_SIEIC:
Index: kvm-userspace.git/libkvm/libkvm.h
===
--- kvm-userspace.git.orig/libkvm/libkvm.h
+++ kvm-userspace.git/libkvm/libkvm.h
@@ -55,7 +55,7 @@
/// generic memory writes to unmapped memory (For MMIO devices)
int (*mmio_write)(void *opaque, uint64_t addr, uint8_t *data,
int len);
-int (*debug)(void *opaque, int vcpu);
+int (*debug)(void *opaque, void *env);
/*!
* \brief Called when the VCPU issues an 'hlt' instruction.
*
@@ -63,7 +63,7 @@
* on the host CPU.
*/
int (*halt)(void *opaque, int vcpu);
-int (*shutdown)(void *opaque, int vcpu);
+int (*shutdown)(void *opaque, void *env);
int (*io_window)(void *opaque);
int (*try_push_interrupts)(void *opaque);
int (*try_push_nmi)(void *opaque);
@@ -181,7 +181,7 @@
* return except for when an error has occured, or when you have sent it
* an EINTR signal.
*/
-int kvm_run(kvm_context_t kvm, int vcpu);
+int kvm_run(kvm_context_t kvm, int vcpu, void *env);
/*!
* \brief Get interrupt flag from on last exit to userspace
Index: kvm-userspace.git/qemu/qemu-kvm-vcpu.h
===
--- /dev/null
+++ kvm-userspace.git/qemu/qemu-kvm-vcpu
Re: [patch] fold struct vcpu_info into CPUState
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, maybe > > current_env isn't being initialized in the IO thread; I only see that > > happening inside ap_main_loop(), which is the vcpu thread. > > > > Hmmm, this is bizarre. If it was the IO thread dieing because of this > I would expect the same to happen on ia64. Could you try and add a test > in the code to find out which thread you are when you die, and maybe > check for current_env being valid? I tested in gdb, and I can confirm that a) current_env was initialized in one thread, and then used in another, and b) current_env was NULL (invalid) when it was used. Are you using virtio on ia64? -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: disable virtualization on kdump
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 no problem. Otherwise we need > > to > > replace the current #UD handler with an iret (perhaps switching temporarily > > to > > another IDT). > > Ugh. We already change the IDT on that code path so that > may be a way to go. I don't see the IDT being changed on native_machine_shutdown(). It even uses notifier chain registration (register_die_notifier()) to sneak a NMI handler in. -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: disable virtualization on kdump
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 (and that this > > INIT was blocked, hanging the machine). Switching to acpi reset worked on > > some > > machines, but not all. Either acpi reset was not implemented on the failing > > machines, or it was wired to INIT and not RESET. > > Right. INIT does not reset things like the MTRRs, I had forgotten > that distinction. > > Frequently the firmware when it regains control at 0x0 > asserts reset, but if we can't get there. Ouch! > > > > Since we already have NMI IPIs, we could disable vmx there. If it is done > > unconditionally and without notifiers, there is no chance of having > > unreviewed > > surprises sneaking in. > > Sounds good to me. The problem here is that we can't disable it unconditionally, so we need to either hack into #UD, or track on which CPUs it is enabled. But tracking on which CPUs it is enabled is exactly what KVM hardware_enable()/hardware_disable() do. To avoid hacking into #UD only for that, I was being inclined to simply add core code to track on which CPUs vmx is enabled. But just calling back into KVM doesn't look too bad, as long as the callback does only what is strictly necessary. It looks a bit better than moving kvm code to the core, and looks simple enough to be better than hacking #UD. Maybe we could have a simple virt-specific callback pointer instead of a whole notifier chain? -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: disable virtualization on kdump
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 (perhaps switching temporarily to > another IDT). Ugh. We already change the IDT on that code path so that may be a way to go. > The general kexec path also wants this fixed. It looks like someone hooked the reboot notifier which should be called on the normal kexec path. Eric -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: disable virtualization on kdump
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 worked on > some > machines, but not all. Either acpi reset was not implemented on the failing > machines, or it was wired to INIT and not RESET. Right. INIT does not reset things like the MTRRs, I had forgotten that distinction. Frequently the firmware when it regains control at 0x0 asserts reset, but if we can't get there. Ouch! > Since we already have NMI IPIs, we could disable vmx there. If it is done > unconditionally and without notifiers, there is no chance of having unreviewed > surprises sneaking in. Sounds good to me. Eric -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Add HPET emulation to qemu (v3)
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)) {
> > +qemu_irq_pulse(irq);
> > +/* windows wants timer0 on irq2 and linux wants irq0,
> > + * so we pulse both
> > + */
> > +if (do_ioapic)
> > +qemu_irq_pulse(timer->state->irqs[2]);
> >
>
> This seems curious and not quite right. We should be able to detect
> whether the HPET is being used in IO APIC mode and raise the appropriate
> interrupt instead of generating a spurious irq0 interrupt.
>
After digging further on this, it turns out that the need for the 2
interrupts was caused by what looks like a problem with the way qemu is
generating interrupts for the ioapic. I will send out a separate patch
for that issue, and make the necessary changes in this hpet code.
> > +}
> > +}
> > +
> > +static void hpet_save(QEMUFile *f, void *opaque)
> > +{
> > +HPETState *s = opaque;
> > +int i;
> > +qemu_put_be64s(f, &s->config);
> > +qemu_put_be64s(f, &s->isr);
> > +/* save current counter value */
> > +s->hpet_counter = hpet_get_ticks(s);
> > +qemu_put_be64s(f, &s->hpet_counter);
> > +
> > +for(i = 0; i < HPET_NUM_TIMERS; i++) {
> > +qemu_put_8s(f, &s->timer[i].tn);
> > +qemu_put_be64s(f, &s->timer[i].config);
> > +qemu_put_be64s(f, &s->timer[i].cmp);
> > +qemu_put_be64s(f, &s->timer[i].fsb);
> > +qemu_put_be64s(f, &s->timer[i].period);
> > +if (s->timer[i].qemu_timer) {
> > +qemu_put_timer(f, s->timer[i].qemu_timer);
> > +}
> >
>
> Would qemu_timer ever be NULL?
You're right... the answer is no. I'll fix that.
> > +
> > +
> > +diff = hpet_calculate_diff(t, cur_tick);
> > +qemu_mod_timer(t->qemu_timer, qemu_get_clock(vm_clock)
> > ++ (int64_t)ticks_to_ns(diff));
> >
>
> May want to convert ticks_to_ns to take and return an int64_t. The
> explicit casting could introduce very subtle bugs.
>
It seems better this way to me, since muldiv64 in ticks_to_ns takes uint64_t.
The likelihood of diff being big enough to create a problem seems small enough.
Am I
missing something?
> > +case HPET_COUNTER:
> > +if (hpet_enabled(s))
> > +cur_tick = hpet_get_ticks(s);
> >
>
> Any reason for hpet_get_ticks(s) to not have this check integrated into it?
When the hpet is being disabled, we need to get the actual count, even though
the
hpet_enabled check would return false. So if I made this change it would
introduce an
ordering issue in the disable code (i.e., get the ticks before setting the hpet
to
disabled)
> > +
> > +/* XXX this is a dirty hack for HPET support w/o LPC
> > + Actually this is a config descriptor for the RCBA */
> >
>
> What's the dirty hack?
This comment is left over from Alexander Graf's code. I'm not sure why it is in
this location and will I'll remove it. But
in comments on the first version of hpet code I produced, Alexander said,
regarding the fixed assignment of HPET_BASE:
"This is a dirty hack that I did to make Mac OS X happy. Actually the HPET base
address gets specified in the RCBA on the
LPC and is configured by the BIOS to point to a valid address, with 0xfed0
being the default (IIRC if you write 0 to
the fields you end up with that address)."
But in other areas of qemu code I see base addresses being hardcoded and am not
sure anything different needs to be done
here. Comments?
>
> Regards,
>
> Anthony Liguori
>
--
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: disable virtualization on kdump
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 else. It wasn't me who tried it, so I can't tell. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: disable virtualization on kdump
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 to have a vmxon api in the core; you call it, the kernel enables it and sets a flag; then either you or the core can disable it. Having to handle #UD would make things more messy, in my opinion. It's not too bad, either relying on exception handlers or hacking our own. BTW, is this problem vmx-specific? Do we need to do something similar for svm? svm needs it as well, since it shares some memory with the cpu. It's less critical though, will likely work even without it. If we trust the exception handlers, there's no problem. Otherwise we need to replace the current #UD handler with an iret (perhaps switching temporarily to another IDT). I think we can't fully trust anything if we are on the crash dump path, so the less code we depend on, the better. So we can point #UD temporarily at an 'addq $3, (%rsp); iret' for the vmxoff instruction. Or implement the 'enable virt extensions' API. The patches I've sent to the kvm mailing list added a notifier interface specific for kexec_crash, using raw_notifier_*(). IMO, if a notifier registration interface was acceptable, the raw notifiers would be good enough for that. But Eric seems to think that adding a notifier registration interface for the crash handler path wouldn't be a good idea, and I am starting to agree with him. I wouldn't mind notifiers (with a nice comment explaining that you must know what you're doing, though that's the case with most kernel APIs). I'm fine with either approach. The general kexec path also wants this fixed. When I've tested it, kexec called the kvm reboot notifier, so everything worked fine. Oh, okay. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: disable virtualization on kdump
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 >> another bit of code to the code that already runs on an NMI handler. >> >> > > That looks like the easiest (and best) way out. > >> My question is: is a notifier chain too much complexity for a sensible >> piece of code like that? If so, a compile-time hook on that point >> would be safer, > > I think an unconditional vmx disable is wanted here, so kexec can work > with other hypervisors. > >> but then it wouldn't work when KVM is compiled as a >> out-of-tree module. >> > > The external module can do without. It's possible to hijack the nmi > vector, but I don't think that's a good idea. If someone wants > kexec+vmx on an older kernel, they can patch that kernel. > >>> 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. >>> >> Good point. My problem was a hang when booting the kdump kernel, but it >> may also cause problems later, when the kdump kernel reboots. >> > > 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 else. Thanks Vivek > > -- > error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: disable virtualization on kdump
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 handler.
>>>
>>
>> Yes. And handling of those NMIs is best effort. Nothing fails if
>> they don't actually run.
>>
>>
>
> Unless someone can come up with another way to disable vmx remotely,
> that's going to change if you have vmx enabled.
>
>> Well we could fairly easily have a non-modular function that does.
>> if (vmx_present && vmx_enabled) {
>>turn_off_vmx();
>> }
>>
>> Which at first skim looks like it is all of about 10-20 machine
>> instructions.
>>
>>
>
> There's no way to query whether vmx is enabled or disabled, AFAICT. So
> we have to execute vmxoff and ignore possible #UDs.
Oops. This means the notifier my patches add would break, if vmx is
disabled on any CPU.
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.
Having to handle #UD would make things more messy, in my opinion.
BTW, is this problem vmx-specific? Do we need to do something similar
for svm?
>
> If we trust the exception handlers, there's no problem. Otherwise we
> need to replace the current #UD handler with an iret (perhaps switching
> temporarily to another IDT).
I think we can't fully trust anything if we are on the crash dump path,
so the less code we depend on, the better.
>
>> There are a few real places where we need code on the kdump
>> path because there it is not possible to do the work any
>> other way. However we need to think long and hard about
>> that because placing the code anywhere besides in a broken
>> and failing kernel is going to be easier to maintain and
>> more reliable.
>>
>
> vmx blocking INITs makes it impossible to leave this to the new kernel.
>
>> I oppose an atomic notifier because it makes the review
>> essentially impossible. If any module can come in and register
>> a notifier we can't know what code is running on that code
>> path and we can't be certain the code is safe in an abnormal
>> case to run on that code path.
>>
>
> What if it's a specialized notifier for kexec? Or even kexec_crash?
The patches I've sent to the kvm mailing list added a notifier interface
specific for kexec_crash, using raw_notifier_*().
IMO, if a notifier registration interface was acceptable, the raw
notifiers would be good enough for that. But Eric seems to think that
adding a notifier registration interface for the crash handler path
wouldn't be a good idea, and I am starting to agree with him.
>
> That said, I have no issue with static code at the call site.
>
>> Right now we only need to support vmx on the kdump path because
>> of what appears to be a hardware design bug. Enabling vmx
>> apparently disables standard functions like an INIT IPI. Things
>> like this do happen but they should be rare.
>>
>
> The general kexec path also wants this fixed.
When I've tested it, kexec called the kvm reboot notifier, so
everything worked fine.
--
Eduardo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix Linux guests migration from AMD to Intel hosts
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. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] fold struct vcpu_info into CPUState
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 that happening inside ap_main_loop(), which is the vcpu thread. Hmmm, this is bizarre. If it was the IO thread dieing because of this I would expect the same to happen on ia64. Could you try and add a test in the code to find out which thread you are when you die, and maybe check for current_env being valid? Thanks, Jes -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: disable virtualization on kdump
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 fails if
they don't actually run.
Unless someone can come up with another way to disable vmx remotely,
that's going to change if you have vmx enabled.
Well we could fairly easily have a non-modular function that does.
if (vmx_present && vmx_enabled) {
turn_off_vmx();
}
Which at first skim looks like it is all of about 10-20 machine
instructions.
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 (perhaps switching
temporarily to another IDT).
There are a few real places where we need code on the kdump
path because there it is not possible to do the work any
other way. However we need to think long and hard about
that because placing the code anywhere besides in a broken
and failing kernel is going to be easier to maintain and
more reliable.
vmx blocking INITs makes it impossible to leave this to the new kernel.
I oppose an atomic notifier because it makes the review
essentially impossible. If any module can come in and register
a notifier we can't know what code is running on that code
path and we can't be certain the code is safe in an abnormal
case to run on that code path.
What if it's a specialized notifier for kexec? Or even kexec_crash?
That said, I have no issue with static code at the call site.
Right now we only need to support vmx on the kdump path because
of what appears to be a hardware design bug. Enabling vmx
apparently disables standard functions like an INIT IPI. Things
like this do happen but they should be rare.
The general kexec path also wants this fixed.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] KVM: SVM: Set the 'busy' flag of the TR selector
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/svm.c index 665008d..743aebd 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -781,6 +781,13 @@ static void svm_get_segment(struct kvm_vcpu *vcpu, if (seg == VCPU_SREG_CS) var->g = s->limit > 0xf; + /* +* Work around a bug where the busy flag in the tr selector +* isn't exposed +*/ + if (seg == VCPU_SREG_TR) + var->type |= 0x2; + var->unusable = !var->present; } -- 1.5.4.3 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] KVM: SVM: Set the 'g' bit of the cs selector for cross-vendor migration
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(-) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 05efc4e..665008d 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -772,6 +772,15 @@ static void svm_get_segment(struct kvm_vcpu *vcpu, var->l = (s->attrib >> SVM_SELECTOR_L_SHIFT) & 1; var->db = (s->attrib >> SVM_SELECTOR_DB_SHIFT) & 1; var->g = (s->attrib >> SVM_SELECTOR_G_SHIFT) & 1; + + /* +* SVM always stores 0 for the 'G' bit in the CS selector in +* the VMCB on a VMEXIT. This hurts cross-vendor migration: +* Intel's VMENTRY has a check on the 'G' bit. +*/ + if (seg == VCPU_SREG_CS) + var->g = s->limit > 0xf; + var->unusable = !var->present; } -- 1.5.4.3 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: disable virtualization on kdump
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 toggle the reset line on the board. At least that has been my experience, and the reason we don't see many problems when we fail to properly shutdown devices before reboot. If vmx persists across that it would seem to be very broken by design. 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 worked on some machines, but not all. Either acpi reset was not implemented on the failing machines, or it was wired to INIT and not RESET. My objections are: on_each_cpu called from after a panic looks like a good way to loose control of the box and never return. Adding a notifier looks like a good way too add functionality onto the kdump path that never gets reviewed for robustness after a kernel crash and thus a good way to remove the usefulness of the kexec on panic kernel path. Since we already have NMI IPIs, we could disable vmx there. If it is done unconditionally and without notifiers, there is no chance of having unreviewed surprises sneaking in. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] kvm: disable virtualization on kdump
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. That looks like the easiest (and best) way out. My question is: is a notifier chain too much complexity for a sensible piece of code like that? If so, a compile-time hook on that point would be safer, I think an unconditional vmx disable is wanted here, so kexec can work with other hypervisors. but then it wouldn't work when KVM is compiled as a out-of-tree module. The external module can do without. It's possible to hijack the nmi vector, but I don't think that's a good idea. If someone wants kexec+vmx on an older kernel, they can patch that kernel. 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. Good point. My problem was a hang when booting the kdump kernel, but it may also cause problems later, when the kdump kernel reboots. The hang was likely caused by vmx blocking INIT. Sigh. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2200006 ] vga vmware and kernel 2.6.25
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 of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Herman BRULE (alpha_one_x86) Assigned to: Nobody/Anonymous (nobody) Summary: vga vmware and kernel 2.6.25 Initial Comment: Hello, when I use this options: -vga vmware I have: kvm: get_dirty_pages returned -2 I'm under: Gentoo linux 2.6.25 64Bits kvm 77 AMD 64Bits Result: In windows xp sp2 32Bits as guest I have a bad screen. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=226&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
