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 smalle
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 ef
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
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
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:
>>
>> > >
>> > > The hang was likely caused by vmx blocking I
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:
>
> > >
> > > The hang was likely caused by vmx blocking INIT. Sigh.
> >
> > Avi,
> >
> > We boot kdump
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 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:
> >
> > 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
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 funct
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 reason
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 downsid
Eduardo Habkost <[EMAIL PROTECTED]> writes:
> I am still wondering if a simple function pointer (instead of a full
> notifier interface) would be good enough. It looks like a reasonable
> tradeoff.
Oh sorry. As long as we do the whole rcu protected thing so it is safe
to call the function witho
On Mon, Oct 27, 2008 at 10:32:43AM -0700, Eric W. Biederman wrote:
> Avi Kivity <[EMAIL PROTECTED]> writes:
> >
> > 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 appr
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
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
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
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
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
Eduardo Habkost <[EMAIL PROTECTED]> writes:
> On Sun, Oct 26, 2008 at 05:07:45PM +0200, Avi Kivity wrote:
>> Eric W. Biederman wrote:
>
> Is it possible to disable vmx mode before we enable interrrupts in the
> kdump kernel?
>
>
You need IPIs to disable vmx on smp.
>>>
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
On Sun, Oct 26, 2008 at 05:07:45PM +0200, Avi Kivity wrote:
> Eric W. Biederman wrote:
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 ta
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
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 s
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) so
reboots don't work. It also assigns some memory to the cpu; if the new
kernel isn't aware of it, the cpu and the kernel woul
Eduardo Habkost wrote:
Considering they touch both KVM and kexec, which tree would be best way
to get them in?
kvm.git will be happy to hold these patches, provided they are acked by
the relevant maintainer.
(Avi: the patches were sent only to kexec and kvm mailing lists,
initially. If
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
[ 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
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 int
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
> virtuali
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
virtualization on all CPUs just before they are halted.
It has the same purpose
38 matches
Mail list logo
