[Avi could you please still consider this patch for your 2.6.31 patchqueue?
It's fairly simple, but important to handle memory errors in guests]
VT-x needs an explicit MC vector intercept to handle machine checks in the
hyper visor.
It also has a special option to catch machine checks that
On Thu, Jun 04, 2009 at 02:48:17PM +0300, Avi Kivity wrote:
Andi Kleen wrote:
[Avi could you please still consider this patch for your 2.6.31 patchqueue?
It's fairly simple, but important to handle memory errors in guests]
Oh yes, and it'll be needed for -stable. IIUC, right now a
Andi Kleen wrote:
This assumption is incorrect. This code is executed after preemption
has been enabled, and we may have even slept before reaching it.
The only thing that counts here is the context before the machine
check event. If there was a vmexit we know it was in guest context.
On Thu, Jun 04, 2009 at 03:49:03PM +0300, Avi Kivity wrote:
Andi Kleen wrote:
This assumption is incorrect. This code is executed after preemption
has been enabled, and we may have even slept before reaching it.
The only thing that counts here is the context before the machine
check
Andi Kleen wrote:
vmcs access work because we have a preempt notifier called when we are
scheduled in, and will execute vmclear/vmptrld as necessary. Look at
kvm_preempt_ops in virt/kvm_main.c.
I see. So we need to move that check earlier. Do you have a preference
where it should be?
Andi Kleen wrote:
There's no good place as it breaks the nice exit handler table. You
could put it in vmx_complete_interrupts() next to NMI handling.
I think I came up with a easy cheesy but not too bad solution now that should
work. It simply remembers the CPU in the vcpu structure and
On Thu, Jun 04, 2009 at 04:49:50PM +0300, Avi Kivity wrote:
Andi Kleen wrote:
There's no good place as it breaks the nice exit handler table. You
could put it in vmx_complete_interrupts() next to NMI handling.
I think I came up with a easy cheesy but not too bad solution now that
