Re: BSOD with [PATCH 00/13] mmu_notifier kill invalidate_page callback

2017-11-30 12:20+0100, Paolo Bonzini: > On 30/11/2017 10:33, Fabian Grünbichler wrote: > > > > It was reverted in 785373b4c38719f4af6775845df6be1dfaea120f after which > > the symptoms disappeared until this series was merged, which contains > > > > 369ea8242c0fb5239b4ddf0dc568f694bd244de4

Re: BSOD with [PATCH 00/13] mmu_notifier kill invalidate_page callback

2017-11-30 12:20+0100, Paolo Bonzini: > On 30/11/2017 10:33, Fabian Grünbichler wrote: > > > > It was reverted in 785373b4c38719f4af6775845df6be1dfaea120f after which > > the symptoms disappeared until this series was merged, which contains > > > > 369ea8242c0fb5239b4ddf0dc568f694bd244de4

Re: BSOD with [PATCH 00/13] mmu_notifier kill invalidate_page callback

On 30/11/2017 10:33, Fabian Grünbichler wrote: > > It was reverted in 785373b4c38719f4af6775845df6be1dfaea120f after which > the symptoms disappeared until this series was merged, which contains > > 369ea8242c0fb5239b4ddf0dc568f694bd244de4 mm/rmap: update to new mmu_notifier > semantic v2 > >

Re: BSOD with [PATCH 00/13] mmu_notifier kill invalidate_page callback

On 30/11/2017 10:33, Fabian Grünbichler wrote: > > It was reverted in 785373b4c38719f4af6775845df6be1dfaea120f after which > the symptoms disappeared until this series was merged, which contains > > 369ea8242c0fb5239b4ddf0dc568f694bd244de4 mm/rmap: update to new mmu_notifier > semantic v2 > >

BSOD with [PATCH 00/13] mmu_notifier kill invalidate_page callback

in its final form) are affected by a bug triggering BSOD (CRITICAL_STRUCTURE_CORRUPTION) in Windows 10/2016 VMs in Qemu under certain conditions on certain hardware/microcode versions (see below for details). Testing this proved to be quite cumbersome, as only some systems are affected and it

BSOD with [PATCH 00/13] mmu_notifier kill invalidate_page callback

in its final form) are affected by a bug triggering BSOD (CRITICAL_STRUCTURE_CORRUPTION) in Windows 10/2016 VMs in Qemu under certain conditions on certain hardware/microcode versions (see below for details). Testing this proved to be quite cumbersome, as only some systems are affected and it

[PATCH] KVM: nVMX: Fix windows guest BSOD due to fail Intel FlexPriority

From: Wanpeng Li Intel FlexPriority maintains a "virtual TPR" register in memory(Virtual APIC Page), APIC-access Page contains host physical address of guest APIC page, Virtual APIC Page contains host physical address of the page stored LAPIC registers. However, commit

[PATCH] KVM: nVMX: Fix windows guest BSOD due to fail Intel FlexPriority

From: Wanpeng Li Intel FlexPriority maintains a "virtual TPR" register in memory(Virtual APIC Page), APIC-access Page contains host physical address of guest APIC page, Virtual APIC Page contains host physical address of the page stored LAPIC registers. However, commit dc651f440f5 (KVM: nVMX:

Re: BSOD

On Tue, 2007-03-20 at 20:19 +1100, Paul Mackerras wrote: > Anything is better than nothing. At the moment we get nothing if you > are in X when the panic occurs, even for the nicest, most well-behaved > panics. :) If we can change that to getting something sometimes, > that's a win. Treating

Re: BSOD

David Miller writes: > Mode setting is complex and it is not going to work exactly when you > need the kernel crash message the most. It's a matter of writing maybe a dozen MMIO registers on the ATI chips, for instance, with some delays. Provided we have interrupts disabled and udelay still

Re: BSOD

David Miller writes: Mode setting is complex and it is not going to work exactly when you need the kernel crash message the most. It's a matter of writing maybe a dozen MMIO registers on the ATI chips, for instance, with some delays. Provided we have interrupts disabled and udelay still

Re: BSOD

On Tue, 2007-03-20 at 20:19 +1100, Paul Mackerras wrote: Anything is better than nothing. At the moment we get nothing if you are in X when the panic occurs, even for the nicest, most well-behaved panics. :) If we can change that to getting something sometimes, that's a win. Treating the

Re: BSOD

I agree with David and Jessie. All the kernel needs to know for oopses is frame buffer depth, start, stride, and how to get the GPU to "stop" (or it may very well overwrite the screen). Trying to get back to a default mode setting first in the middle of oopsing is very unlikely to succeed. The

Re: BSOD

On Monday, March 19, 2007 1:05 pm David Miller wrote: > From: Jesse Barnes <[EMAIL PROTECTED]> > Date: Mon, 19 Mar 2007 12:54:36 -0700 > > > Kernel based modesetting should get us a lot of things: > > But for panics you're ignoring what Peter and I are saying. > > Mode setting is complex and it is

Re: BSOD

From: Jesse Barnes <[EMAIL PROTECTED]> Date: Mon, 19 Mar 2007 12:54:36 -0700 > Kernel based modesetting should get us a lot of things: But for panics you're ignoring what Peter and I are saying. Mode setting is complex and it is not going to work exactly when you need the kernel crash message

Re: BSOD

On Monday, March 19, 2007 12:38 pm David Miller wrote: > All of this talk makes me appreciate what happens on Sparc machines > even though it has more often than not been ridiculed. > > There the firmware sets the resolution and that's basically what > the kernel and X uses, no mode changes are

Re: BSOD

From: Pete Zaitcev <[EMAIL PROTECTED]> Date: Mon, 19 Mar 2007 12:08:07 -0700 > On Sun, 18 Mar 2007 12:40:45 -0400, Jim Gettys <[EMAIL PROTECTED]> wrote: > > > Also more seriously, a somewhat hybrid approach is in order for mode > > setting: simple mode setting isn't much code and is required for

BSOD (was: [2/6] 2.6.21-rc2: known regressions)

On Sun, 18 Mar 2007 12:40:45 -0400, Jim Gettys <[EMAIL PROTECTED]> wrote: > Also more seriously, a somewhat hybrid approach is in order for mode > setting: simple mode setting isn't much code and is required for sane > behavior on crash (it is nice to get oopses onto a screen); but the full >

BSOD (was: [2/6] 2.6.21-rc2: known regressions)

On Sun, 18 Mar 2007 12:40:45 -0400, Jim Gettys [EMAIL PROTECTED] wrote: Also more seriously, a somewhat hybrid approach is in order for mode setting: simple mode setting isn't much code and is required for sane behavior on crash (it is nice to get oopses onto a screen); but the full blown

Re: BSOD

From: Pete Zaitcev [EMAIL PROTECTED] Date: Mon, 19 Mar 2007 12:08:07 -0700 On Sun, 18 Mar 2007 12:40:45 -0400, Jim Gettys [EMAIL PROTECTED] wrote: Also more seriously, a somewhat hybrid approach is in order for mode setting: simple mode setting isn't much code and is required for sane

Re: BSOD

On Monday, March 19, 2007 12:38 pm David Miller wrote: All of this talk makes me appreciate what happens on Sparc machines even though it has more often than not been ridiculed. There the firmware sets the resolution and that's basically what the kernel and X uses, no mode changes are

Re: BSOD

From: Jesse Barnes [EMAIL PROTECTED] Date: Mon, 19 Mar 2007 12:54:36 -0700 Kernel based modesetting should get us a lot of things: But for panics you're ignoring what Peter and I are saying. Mode setting is complex and it is not going to work exactly when you need the kernel crash message the

Re: BSOD

On Monday, March 19, 2007 1:05 pm David Miller wrote: From: Jesse Barnes [EMAIL PROTECTED] Date: Mon, 19 Mar 2007 12:54:36 -0700 Kernel based modesetting should get us a lot of things: But for panics you're ignoring what Peter and I are saying. Mode setting is complex and it is not going

Re: BSOD

I agree with David and Jessie. All the kernel needs to know for oopses is frame buffer depth, start, stride, and how to get the GPU to stop (or it may very well overwrite the screen). Trying to get back to a default mode setting first in the middle of oopsing is very unlikely to succeed. The