From: Marcelo Tosatti mtosa...@redhat.com
The invlpg prefault optimization breaks Windows 2008 R2 occasionally.
The visible effect is that the invlpg handler instantiates a pte which
is, microseconds later, written with a different gfn by another vcpu.
The OS could have other mechanisms to
On 12/07/2009 10:51 PM, Marcelo Tosatti wrote:
The BAD_POOL_HEADER BSOD happens at address 0xF8A000DDD000 (complaining it contains
00, Arg4).
Walking the pagetables takes to 0x18996 as the pte page:
(qemu) xp 0x18996ee8 (vaddr 0xF8A000DDD000)
18996ee8: 0x153c9963
(qemu)
On Sat, Dec 05, 2009 at 10:15:44PM +0200, Avi Kivity wrote:
On 12/05/2009 09:42 PM, Marcelo Tosatti wrote:
I don't think the OS has other mechanisms, though - the processor can
speculate the tlb so that would be an OS bug.
Can it? I figured it relied on the fact that no access (therefore no
The invlpg prefault optimization breaks Windows 2008 R2 occasionally.
The visible effect is that the invlpg handler instantiates a pte which
is, microseconds later, written with a different gfn by another vcpu.
The OS could have other mechanisms to prevent a present translation from
being
On 12/05/2009 04:34 PM, Marcelo Tosatti wrote:
The invlpg prefault optimization breaks Windows 2008 R2 occasionally.
The visible effect is that the invlpg handler instantiates a pte which
is, microseconds later, written with a different gfn by another vcpu.
The OS could have other mechanisms
On 12/05/2009 06:57 PM, Avi Kivity wrote:
Looks like we considered this, since kvm_read_guest_atomic() is only
needed if inside the spinlock, but some other change moved the
spin_unlock() upwards. Will investigate history.
No, the bug was there from day one (and survived a year):
+
On 12/05/2009 09:42 PM, Marcelo Tosatti wrote:
I don't think the OS has other mechanisms, though - the processor can
speculate the tlb so that would be an OS bug.
Can it? I figured it relied on the fact that no access (therefore no TLB
entry instantiation) meant there is no need to invlpg
