Eric W. Biederman wrote:
svm can writeback into memory at odd times if we don't do this, and the
cost
is
small - clear a bit in EFER. There's no reason to be lazy.
Especially if we can clear that bit unconditionally (when
EFER is present) I'm all for it.
That is the case.
Cool. I
Chris Lalancette wrote:
I'm pretty sure you have to test for it first; pre-64 bit x86 hardware doesn't
have the EFER register, so you'll fault on access. On the other hand pre-64 bit
x86 hardware doesn't usually (ever?) have VT extensions either.
All amd hardware that supports svm has an
Eric W. Biederman wrote:
Avi Kivity [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Most of the reason I was wondering is that the cpu hardware probing
largely seems to be a duplicate of what we have in the core for
probing cpu capabilities already, and could likely be made smaller
Eric W. Biederman wrote:
I think I will get flamed if I try to pull to the core a bunch of code
that always lived in the KVM module. 8)
Why is KVM modular anyway? That seems like some pretty core cpu
functionality...
Many reasons. Developers like the ability to rmmod and modprobe
Eduardo Habkost wrote:
I think I will get flamed if I try to pull to the core a bunch of code
that always lived in the KVM module. 8)
Having a simple api to enter vmx or svm mode in core code should not be
too bad. The kvm hardware_enable() stuff could simply call that. The
only
Avi Kivity [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
I think I will get flamed if I try to pull to the core a bunch of code
that always lived in the KVM module. 8)
Why is KVM modular anyway? That seems like some pretty core cpu
functionality...
Many reasons. Developers like
Eric W. Biederman wrote:
Most of the reason I was wondering is that the cpu hardware probing
largely seems to be a duplicate of what we have in the core for
probing cpu capabilities already, and could likely be made smaller
by building upon the existing codebase.
We use the core cpuid
On Mon, Oct 27, 2008 at 09:09:37AM -0400, Vivek Goyal wrote:
On Mon, Oct 27, 2008 at 10:54:01AM +0200, Avi Kivity wrote:
snip
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
Eduardo Habkost wrote:
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.
vmx also disallows changing some bits in cr0 and cr4; for
On Wed, Oct 29, 2008 at 06:10:06PM -0200, Eduardo Habkost wrote:
On Mon, Oct 27, 2008 at 09:09:37AM -0400, Vivek Goyal wrote:
On Mon, Oct 27, 2008 at 10:54:01AM +0200, Avi Kivity wrote:
snip
The hang was likely caused by vmx blocking INIT. Sigh.
Avi,
We boot kdump kernel with
Vivek Goyal [EMAIL PROTECTED] writes:
On Wed, Oct 29, 2008 at 06:10:06PM -0200, Eduardo Habkost wrote:
On Mon, Oct 27, 2008 at 09:09:37AM -0400, Vivek Goyal wrote:
On Mon, Oct 27, 2008 at 10:54:01AM +0200, Avi Kivity wrote:
snip
The hang was likely caused by vmx blocking INIT. Sigh.
Avi Kivity [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Most of the reason I was wondering is that the cpu hardware probing
largely seems to be a duplicate of what we have in the core for
probing cpu capabilities already, and could likely be made smaller
by building upon the existing
On Mon, Oct 27, 2008 at 10:32:43AM -0700, Eric W. Biederman wrote:
Avi Kivity [EMAIL PROTECTED] writes:
snip
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.
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.
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
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
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.
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
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
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
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
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
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
Avi Kivity [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Why do we need to disable vmx mode before booting a normal linux kernel?
vmx mode blocks INIT (even on the host; not just on the guests)
*blink* broken hardware design there.
so reboots don't
work. It also assigns some memory
Eric W. Biederman wrote:
so reboots don't
work. It also assigns some memory to the cpu; if the new kernel isn't aware of
it,
Not a problem for a kdump kernel, as it lives out of a reserved region
of memory.
But it is a problem for general kexec.
Is it possible to disable vmx mode
On Sun, Oct 26, 2008 at 05:07:45PM +0200, Avi Kivity wrote:
Eric W. Biederman wrote:
snip
Is it possible to disable vmx mode before we enable interrrupts in the
kdump kernel?
You need IPIs to disable vmx on smp.
Thank you. Reading your description and taking a quick look at
Avi Kivity [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
so reboots don't
work. It also assigns some memory to the cpu; if the new kernel isn't aware
of
it,
Not a problem for a kdump kernel, as it lives out of a reserved region
of memory.
But it is a problem for general kexec.
Eduardo Habkost [EMAIL PROTECTED] writes:
On Sun, Oct 26, 2008 at 05:07:45PM +0200, Avi Kivity wrote:
Eric W. Biederman wrote:
snip
Is it possible to disable vmx mode before we enable interrrupts in the
kdump kernel?
You need IPIs to disable vmx on smp.
Thank you. Reading
On Thu, Oct 23, 2008 at 10:28:24AM +1100, Simon Horman wrote:
On Mon, Oct 20, 2008 at 01:01:32PM -0200, Eduardo Habkost wrote:
The following two patches should make kdump work when the kvm-intel module
is loaded. We need to disable vmx mode before booting the kdump kernel,
so I've
[ Added Andrew Morton, Eric Biederman, Vivek Goyal and Haren Myneni to CC ]
On Thu, Oct 23, 2008 at 05:41:29PM -0200, Eduardo Habkost wrote:
On Thu, Oct 23, 2008 at 10:28:24AM +1100, Simon Horman wrote:
On Mon, Oct 20, 2008 at 01:01:32PM -0200, Eduardo Habkost wrote:
The following two
Simon Horman [EMAIL PROTECTED] writes:
[ Added Andrew Morton, Eric Biederman, Vivek Goyal and Haren Myneni to CC ]
On Thu, Oct 23, 2008 at 05:41:29PM -0200, Eduardo Habkost wrote:
On Thu, Oct 23, 2008 at 10:28:24AM +1100, Simon Horman wrote:
On Mon, Oct 20, 2008 at 01:01:32PM -0200, Eduardo
On Mon, Oct 20, 2008 at 01:01:32PM -0200, Eduardo Habkost wrote:
The following two patches should make kdump work when the kvm-intel module
is loaded. We need to disable vmx mode before booting the kdump kernel,
so I've introduced a notifier interface where KVM can hook and disable
32 matches
Mail list logo
