Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
On 10/25/18 11:11 PM, Tamas K Lengyel wrote: > On Thu, Oct 25, 2018 at 9:08 AM Tamas K Lengyel > wrote: >> >> On Thu, Oct 25, 2018 at 9:02 AM Razvan Cojocaru >> wrote: >>> >>> On 10/25/18 5:55 PM, Tamas K Lengyel wrote: On Thu, Oct 25, 2018 at 8:24 AM Razvan Cojocaru wrote: > > On 10/24/18 8:52 PM, Tamas K Lengyel wrote: >> On Wed, Oct 24, 2018 at 11:31 AM Tamas K Lengyel >> wrote: >>> >>> On Wed, Oct 24, 2018 at 11:20 AM Razvan Cojocaru >>> wrote: On 10/24/18 8:09 PM, Tamas K Lengyel wrote: > On Tue, Oct 23, 2018 at 6:37 AM Razvan Cojocaru > wrote: >> >> Tamas, could you please give this a spin? >> >> https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take2 >> >> It _should_ solve the crashes. > > Indeed, I no longer see the crash. However, there might be some > locking issue present because the whole system freezes up shortly > after starting DRAKVUF on a domain - within a couple seconds. I mean > Xen itself locks up: no response on the serial, dom0 screen frozen, > etc. Do you have any type of log / backtrace / way I could reproduce it without Drakvuf? All the ways I've tested it were fine (including xen-access). >>> >>> I don't have a standalone test that produces that error. With DRAKVUF >>> it is easily reproducible though. If you have a Windows guest >>> installed, setting up DRAKVUF should really not be much trouble. With >>> xen-access it indeed doesn't lock up but since the guest is pretty >>> much unresponsive during that test I can't verify whether the VGA >>> issue is now resolved or not. Also the xen-access tests are fairly >>> limited and don't use all aspects of altp2m. >>> >> >> What I see from the DRAKVUF log is that the last thing it prints is >> sending a vm_event response that both enables singlestepping and >> switches altp2m view. This looks to be consistent. It didn't matter if >> the guest had 1 or 2 vCPUs, the freeze occurs just the same. It's >> definitely racey because it doesn't happen right away, the system >> works as expected for a couple seconds. > > After having to install clang because my GCC couldn't build Drakvuf: > > ../../src/plugins/plugins.h:188:1: sorry, unimplemented: non-trivial > designated initializers not supported Please follow the instruction for compiling it, clang is a requirement. I don't even know how you got pass the ./configure stage without clang being installed. You could also just copy-paste things from the travis script directly: https://github.com/tklengyel/drakvuf/blob/master/.travis.yml#L51 > > then rekall via pip, then having to mount my Windows disk to do "rekal > peinfo", I finally gave up when "rekall fetch_pdb" couldn't find the > debug files on the Microsoft server. :) If your version if Windows is that brand new then yes, Microsoft takes a couple days to publish their debug information and you will just have to wait or use an older version of Windows. > > So if you could find a way to reproduce the issue with a simple > libxc-based application alone (or at least with something > libvmi-related, which I do have set up), I'd really appreciate it. > > Or maybe try to hack around with patch no 3 of the series (for a start, > just revert it and see if the problem persists - of course the display > will freeze) and see if there's an easy fix? Unfortunately I won't have time to do either of these any time soon. If you are having that much trouble setting it up I can perhaps send you a pre-compiled version with a version of Windows for which Microsoft already published the debug info for. >>> >>> It's a Windows 7 x64 guest. But the problem was that the right command >>> line is: >>> >>> rekall fetch_pdb ntkrnlmp >>> >>> instead of the suggested "rekall fetch_pdb ntkrpamp" on the drakvuf.com >>> website. >> >> The kernel filename is specific to the version of Windows you have >> installed. The instructions specify _an example_ for the 32-bit >> version of Windows 7 and you will need to adjust it according to the >> kernel filename. For 64-bit it is ntkrnlmp. The instruction explicitly >> say that you need to use the PDB filename that was printed for your >> specific kernel version. >> >>> >>> I'll try to continue - in any case should I have more trouble I'll >>> contact you privately so as not to spam the list. Just wanted to leave >>> this here in case someone else has this problem in the hope that it's >>> useful. >> >> Of course, also please feel free to open an issue on github if you run >> into something that's blocking you. Chances are if you run into it, >> others would too :) > > We can chalk the freeze issue
Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
On Thu, Oct 25, 2018 at 9:02 AM Razvan Cojocaru wrote: > > On 10/25/18 5:55 PM, Tamas K Lengyel wrote: > > On Thu, Oct 25, 2018 at 8:24 AM Razvan Cojocaru > > wrote: > >> > >> On 10/24/18 8:52 PM, Tamas K Lengyel wrote: > >>> On Wed, Oct 24, 2018 at 11:31 AM Tamas K Lengyel > >>> wrote: > > On Wed, Oct 24, 2018 at 11:20 AM Razvan Cojocaru > wrote: > > > > On 10/24/18 8:09 PM, Tamas K Lengyel wrote: > >> On Tue, Oct 23, 2018 at 6:37 AM Razvan Cojocaru > >> wrote: > >>> > >>> Tamas, could you please give this a spin? > >>> > >>> https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take2 > >>> > >>> It _should_ solve the crashes. > >> > >> Indeed, I no longer see the crash. However, there might be some > >> locking issue present because the whole system freezes up shortly > >> after starting DRAKVUF on a domain - within a couple seconds. I mean > >> Xen itself locks up: no response on the serial, dom0 screen frozen, > >> etc. > > > > Do you have any type of log / backtrace / way I could reproduce it > > without Drakvuf? All the ways I've tested it were fine (including > > xen-access). > > I don't have a standalone test that produces that error. With DRAKVUF > it is easily reproducible though. If you have a Windows guest > installed, setting up DRAKVUF should really not be much trouble. With > xen-access it indeed doesn't lock up but since the guest is pretty > much unresponsive during that test I can't verify whether the VGA > issue is now resolved or not. Also the xen-access tests are fairly > limited and don't use all aspects of altp2m. > > >>> > >>> What I see from the DRAKVUF log is that the last thing it prints is > >>> sending a vm_event response that both enables singlestepping and > >>> switches altp2m view. This looks to be consistent. It didn't matter if > >>> the guest had 1 or 2 vCPUs, the freeze occurs just the same. It's > >>> definitely racey because it doesn't happen right away, the system > >>> works as expected for a couple seconds. > >> > >> After having to install clang because my GCC couldn't build Drakvuf: > >> > >> ../../src/plugins/plugins.h:188:1: sorry, unimplemented: non-trivial > >> designated initializers not supported > > > > Please follow the instruction for compiling it, clang is a > > requirement. I don't even know how you got pass the ./configure stage > > without clang being installed. You could also just copy-paste things > > from the travis script directly: > > https://github.com/tklengyel/drakvuf/blob/master/.travis.yml#L51 > > > >> > >> then rekall via pip, then having to mount my Windows disk to do "rekal > >> peinfo", I finally gave up when "rekall fetch_pdb" couldn't find the > >> debug files on the Microsoft server. :) > > > > If your version if Windows is that brand new then yes, Microsoft takes > > a couple days to publish their debug information and you will just > > have to wait or use an older version of Windows. > > > >> > >> So if you could find a way to reproduce the issue with a simple > >> libxc-based application alone (or at least with something > >> libvmi-related, which I do have set up), I'd really appreciate it. > >> > >> Or maybe try to hack around with patch no 3 of the series (for a start, > >> just revert it and see if the problem persists - of course the display > >> will freeze) and see if there's an easy fix? > > > > Unfortunately I won't have time to do either of these any time soon. > > If you are having that much trouble setting it up I can perhaps send > > you a pre-compiled version with a version of Windows for which > > Microsoft already published the debug info for. > > It's a Windows 7 x64 guest. But the problem was that the right command > line is: > > rekall fetch_pdb ntkrnlmp > > instead of the suggested "rekall fetch_pdb ntkrpamp" on the drakvuf.com > website. The kernel filename is specific to the version of Windows you have installed. The instructions specify _an example_ for the 32-bit version of Windows 7 and you will need to adjust it according to the kernel filename. For 64-bit it is ntkrnlmp. The instruction explicitly say that you need to use the PDB filename that was printed for your specific kernel version. > > I'll try to continue - in any case should I have more trouble I'll > contact you privately so as not to spam the list. Just wanted to leave > this here in case someone else has this problem in the hope that it's > useful. Of course, also please feel free to open an issue on github if you run into something that's blocking you. Chances are if you run into it, others would too :) Thanks, Tamas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
On 10/25/18 5:55 PM, Tamas K Lengyel wrote: > On Thu, Oct 25, 2018 at 8:24 AM Razvan Cojocaru > wrote: >> >> On 10/24/18 8:52 PM, Tamas K Lengyel wrote: >>> On Wed, Oct 24, 2018 at 11:31 AM Tamas K Lengyel >>> wrote: On Wed, Oct 24, 2018 at 11:20 AM Razvan Cojocaru wrote: > > On 10/24/18 8:09 PM, Tamas K Lengyel wrote: >> On Tue, Oct 23, 2018 at 6:37 AM Razvan Cojocaru >> wrote: >>> >>> Tamas, could you please give this a spin? >>> >>> https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take2 >>> >>> It _should_ solve the crashes. >> >> Indeed, I no longer see the crash. However, there might be some >> locking issue present because the whole system freezes up shortly >> after starting DRAKVUF on a domain - within a couple seconds. I mean >> Xen itself locks up: no response on the serial, dom0 screen frozen, >> etc. > > Do you have any type of log / backtrace / way I could reproduce it > without Drakvuf? All the ways I've tested it were fine (including > xen-access). I don't have a standalone test that produces that error. With DRAKVUF it is easily reproducible though. If you have a Windows guest installed, setting up DRAKVUF should really not be much trouble. With xen-access it indeed doesn't lock up but since the guest is pretty much unresponsive during that test I can't verify whether the VGA issue is now resolved or not. Also the xen-access tests are fairly limited and don't use all aspects of altp2m. >>> >>> What I see from the DRAKVUF log is that the last thing it prints is >>> sending a vm_event response that both enables singlestepping and >>> switches altp2m view. This looks to be consistent. It didn't matter if >>> the guest had 1 or 2 vCPUs, the freeze occurs just the same. It's >>> definitely racey because it doesn't happen right away, the system >>> works as expected for a couple seconds. >> >> After having to install clang because my GCC couldn't build Drakvuf: >> >> ../../src/plugins/plugins.h:188:1: sorry, unimplemented: non-trivial >> designated initializers not supported > > Please follow the instruction for compiling it, clang is a > requirement. I don't even know how you got pass the ./configure stage > without clang being installed. You could also just copy-paste things > from the travis script directly: > https://github.com/tklengyel/drakvuf/blob/master/.travis.yml#L51 > >> >> then rekall via pip, then having to mount my Windows disk to do "rekal >> peinfo", I finally gave up when "rekall fetch_pdb" couldn't find the >> debug files on the Microsoft server. :) > > If your version if Windows is that brand new then yes, Microsoft takes > a couple days to publish their debug information and you will just > have to wait or use an older version of Windows. > >> >> So if you could find a way to reproduce the issue with a simple >> libxc-based application alone (or at least with something >> libvmi-related, which I do have set up), I'd really appreciate it. >> >> Or maybe try to hack around with patch no 3 of the series (for a start, >> just revert it and see if the problem persists - of course the display >> will freeze) and see if there's an easy fix? > > Unfortunately I won't have time to do either of these any time soon. > If you are having that much trouble setting it up I can perhaps send > you a pre-compiled version with a version of Windows for which > Microsoft already published the debug info for. It's a Windows 7 x64 guest. But the problem was that the right command line is: rekall fetch_pdb ntkrnlmp instead of the suggested "rekall fetch_pdb ntkrpamp" on the drakvuf.com website. I'll try to continue - in any case should I have more trouble I'll contact you privately so as not to spam the list. Just wanted to leave this here in case someone else has this problem in the hope that it's useful. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
On Thu, Oct 25, 2018 at 8:24 AM Razvan Cojocaru wrote: > > On 10/24/18 8:52 PM, Tamas K Lengyel wrote: > > On Wed, Oct 24, 2018 at 11:31 AM Tamas K Lengyel > > wrote: > >> > >> On Wed, Oct 24, 2018 at 11:20 AM Razvan Cojocaru > >> wrote: > >>> > >>> On 10/24/18 8:09 PM, Tamas K Lengyel wrote: > On Tue, Oct 23, 2018 at 6:37 AM Razvan Cojocaru > wrote: > > > > Tamas, could you please give this a spin? > > > > https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take2 > > > > It _should_ solve the crashes. > > Indeed, I no longer see the crash. However, there might be some > locking issue present because the whole system freezes up shortly > after starting DRAKVUF on a domain - within a couple seconds. I mean > Xen itself locks up: no response on the serial, dom0 screen frozen, > etc. > >>> > >>> Do you have any type of log / backtrace / way I could reproduce it > >>> without Drakvuf? All the ways I've tested it were fine (including > >>> xen-access). > >> > >> I don't have a standalone test that produces that error. With DRAKVUF > >> it is easily reproducible though. If you have a Windows guest > >> installed, setting up DRAKVUF should really not be much trouble. With > >> xen-access it indeed doesn't lock up but since the guest is pretty > >> much unresponsive during that test I can't verify whether the VGA > >> issue is now resolved or not. Also the xen-access tests are fairly > >> limited and don't use all aspects of altp2m. > >> > > > > What I see from the DRAKVUF log is that the last thing it prints is > > sending a vm_event response that both enables singlestepping and > > switches altp2m view. This looks to be consistent. It didn't matter if > > the guest had 1 or 2 vCPUs, the freeze occurs just the same. It's > > definitely racey because it doesn't happen right away, the system > > works as expected for a couple seconds. > > After having to install clang because my GCC couldn't build Drakvuf: > > ../../src/plugins/plugins.h:188:1: sorry, unimplemented: non-trivial > designated initializers not supported Please follow the instruction for compiling it, clang is a requirement. I don't even know how you got pass the ./configure stage without clang being installed. You could also just copy-paste things from the travis script directly: https://github.com/tklengyel/drakvuf/blob/master/.travis.yml#L51 > > then rekall via pip, then having to mount my Windows disk to do "rekal > peinfo", I finally gave up when "rekall fetch_pdb" couldn't find the > debug files on the Microsoft server. :) If your version if Windows is that brand new then yes, Microsoft takes a couple days to publish their debug information and you will just have to wait or use an older version of Windows. > > So if you could find a way to reproduce the issue with a simple > libxc-based application alone (or at least with something > libvmi-related, which I do have set up), I'd really appreciate it. > > Or maybe try to hack around with patch no 3 of the series (for a start, > just revert it and see if the problem persists - of course the display > will freeze) and see if there's an easy fix? Unfortunately I won't have time to do either of these any time soon. If you are having that much trouble setting it up I can perhaps send you a pre-compiled version with a version of Windows for which Microsoft already published the debug info for. Tamas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
On 10/24/18 8:52 PM, Tamas K Lengyel wrote: > On Wed, Oct 24, 2018 at 11:31 AM Tamas K Lengyel > wrote: >> >> On Wed, Oct 24, 2018 at 11:20 AM Razvan Cojocaru >> wrote: >>> >>> On 10/24/18 8:09 PM, Tamas K Lengyel wrote: On Tue, Oct 23, 2018 at 6:37 AM Razvan Cojocaru wrote: > > Tamas, could you please give this a spin? > > https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take2 > > It _should_ solve the crashes. Indeed, I no longer see the crash. However, there might be some locking issue present because the whole system freezes up shortly after starting DRAKVUF on a domain - within a couple seconds. I mean Xen itself locks up: no response on the serial, dom0 screen frozen, etc. >>> >>> Do you have any type of log / backtrace / way I could reproduce it >>> without Drakvuf? All the ways I've tested it were fine (including >>> xen-access). >> >> I don't have a standalone test that produces that error. With DRAKVUF >> it is easily reproducible though. If you have a Windows guest >> installed, setting up DRAKVUF should really not be much trouble. With >> xen-access it indeed doesn't lock up but since the guest is pretty >> much unresponsive during that test I can't verify whether the VGA >> issue is now resolved or not. Also the xen-access tests are fairly >> limited and don't use all aspects of altp2m. >> > > What I see from the DRAKVUF log is that the last thing it prints is > sending a vm_event response that both enables singlestepping and > switches altp2m view. This looks to be consistent. It didn't matter if > the guest had 1 or 2 vCPUs, the freeze occurs just the same. It's > definitely racey because it doesn't happen right away, the system > works as expected for a couple seconds. After having to install clang because my GCC couldn't build Drakvuf: ../../src/plugins/plugins.h:188:1: sorry, unimplemented: non-trivial designated initializers not supported then rekall via pip, then having to mount my Windows disk to do "rekal peinfo", I finally gave up when "rekall fetch_pdb" couldn't find the debug files on the Microsoft server. :) So if you could find a way to reproduce the issue with a simple libxc-based application alone (or at least with something libvmi-related, which I do have set up), I'd really appreciate it. Or maybe try to hack around with patch no 3 of the series (for a start, just revert it and see if the problem persists - of course the display will freeze) and see if there's an easy fix? Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
On Wed, Oct 24, 2018 at 11:31 AM Tamas K Lengyel wrote: > > On Wed, Oct 24, 2018 at 11:20 AM Razvan Cojocaru > wrote: > > > > On 10/24/18 8:09 PM, Tamas K Lengyel wrote: > > > On Tue, Oct 23, 2018 at 6:37 AM Razvan Cojocaru > > > wrote: > > >> > > >> Tamas, could you please give this a spin? > > >> > > >> https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take2 > > >> > > >> It _should_ solve the crashes. > > > > > > Indeed, I no longer see the crash. However, there might be some > > > locking issue present because the whole system freezes up shortly > > > after starting DRAKVUF on a domain - within a couple seconds. I mean > > > Xen itself locks up: no response on the serial, dom0 screen frozen, > > > etc. > > > > Do you have any type of log / backtrace / way I could reproduce it > > without Drakvuf? All the ways I've tested it were fine (including > > xen-access). > > I don't have a standalone test that produces that error. With DRAKVUF > it is easily reproducible though. If you have a Windows guest > installed, setting up DRAKVUF should really not be much trouble. With > xen-access it indeed doesn't lock up but since the guest is pretty > much unresponsive during that test I can't verify whether the VGA > issue is now resolved or not. Also the xen-access tests are fairly > limited and don't use all aspects of altp2m. > What I see from the DRAKVUF log is that the last thing it prints is sending a vm_event response that both enables singlestepping and switches altp2m view. This looks to be consistent. It didn't matter if the guest had 1 or 2 vCPUs, the freeze occurs just the same. It's definitely racey because it doesn't happen right away, the system works as expected for a couple seconds. Tamas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
On Wed, Oct 24, 2018 at 11:20 AM Razvan Cojocaru wrote: > > On 10/24/18 8:09 PM, Tamas K Lengyel wrote: > > On Tue, Oct 23, 2018 at 6:37 AM Razvan Cojocaru > > wrote: > >> > >> Tamas, could you please give this a spin? > >> > >> https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take2 > >> > >> It _should_ solve the crashes. > > > > Indeed, I no longer see the crash. However, there might be some > > locking issue present because the whole system freezes up shortly > > after starting DRAKVUF on a domain - within a couple seconds. I mean > > Xen itself locks up: no response on the serial, dom0 screen frozen, > > etc. > > Do you have any type of log / backtrace / way I could reproduce it > without Drakvuf? All the ways I've tested it were fine (including > xen-access). I don't have a standalone test that produces that error. With DRAKVUF it is easily reproducible though. If you have a Windows guest installed, setting up DRAKVUF should really not be much trouble. With xen-access it indeed doesn't lock up but since the guest is pretty much unresponsive during that test I can't verify whether the VGA issue is now resolved or not. Also the xen-access tests are fairly limited and don't use all aspects of altp2m. Tamas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
On 10/24/18 8:09 PM, Tamas K Lengyel wrote: > On Tue, Oct 23, 2018 at 6:37 AM Razvan Cojocaru > wrote: >> >> Tamas, could you please give this a spin? >> >> https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take2 >> >> It _should_ solve the crashes. > > Indeed, I no longer see the crash. However, there might be some > locking issue present because the whole system freezes up shortly > after starting DRAKVUF on a domain - within a couple seconds. I mean > Xen itself locks up: no response on the serial, dom0 screen frozen, > etc. Do you have any type of log / backtrace / way I could reproduce it without Drakvuf? All the ways I've tested it were fine (including xen-access). Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
On Tue, Oct 23, 2018 at 6:37 AM Razvan Cojocaru wrote: > > Tamas, could you please give this a spin? > > https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take2 > > It _should_ solve the crashes. Indeed, I no longer see the crash. However, there might be some locking issue present because the whole system freezes up shortly after starting DRAKVUF on a domain - within a couple seconds. I mean Xen itself locks up: no response on the serial, dom0 screen frozen, etc. Tamas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Fix VGA logdirty related display freezes with altp2m
Tamas, could you please give this a spin? https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take2 It _should_ solve the crashes. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
On Mon, Oct 22, 2018 at 4:15 PM Razvan Cojocaru wrote: > > With the config fixed it boots but when I run DRAKVUF on the domain I > get the following crash: > > (XEN) [ Xen-4.12-unstable x86_64 debug=y Not tainted ] > (XEN) CPU:0 > (XEN) RIP:e008:[<7bdb630c>] 7bdb630c > (XEN) RFLAGS: 00010282 CONTEXT: hypervisor (d0v5) > (XEN) rax: ee138470 rbx: rcx: > 8000b098 > (XEN) rdx: 0cf8 rsi: rdi: > 00046d2ef000 > (XEN) rbp: rsp: 83005da27a10 r8: > 0cf8 > (XEN) r9: 0cf8 r10: 83005da27ab8 r11: > 83005da27a08 > (XEN) r12: r13: r14: > 0065 > (XEN) r15: 05a7 cr0: 80050033 cr4: > 00372660 > (XEN) cr3: 00046d2ef000 cr2: ee138470 > (XEN) fsb: 7fe46d97bbc0 gsb: 880467f4 gss: > > (XEN) ds: es: fs: gs: ss: e010 cs: e008 > (XEN) Xen code around <7bdb630c> (7bdb630c): > (XEN) 80 74 0b 05 70 84 00 00 00 00 00 00 e0 80 3d 7a 34 00 00 00 > 75 64 48 > (XEN) Xen stack trace from rsp=83005da27a10:(XEN) Xen stack trace > from rsp=83005da27a10: > (XEN) 0065 83005da27a50 > 82d08037aafc > (XEN)fffe 82d08037ae14 > 83005da27a90 > (XEN)00372660 00046d2ef000 000393e91000 > 82d0809602b0 > (XEN)00fe 82d0802a3b98 > 83005da27ab8 > (XEN)83005da27b08 82d0802a3511 82d08046b028 > 83005da27b08 > (XEN)82d0802a3511 83005da27fff 13880292 > 82d0808176a0 > (XEN) 82d08023b889 0292 > 82d08046b028 > (XEN)82d080451ac8 82d080454af2 05a7 > 83005da27b78 > (XEN)82d080251d6f 82d080250fcd 0028 > 83005da27b88 > (XEN)83005da27b38 e010 82d080454c73 > 82d080451ac8 > (XEN)82d080454af2 05a7 0030 > 83005da27bf8 > (XEN)82d080454c73 83005da27be8 82d0802aaebc > 82d08033f3dc > (XEN)82d080451ac8 82d08037d969 82d08037d95d > 82d08037d969 > (XEN)0b0f82d08037d95d 82d08037d969 83005fe5b000 > > (XEN) 83005da27fff > 7cffa25d83e7 > (XEN)82d08037da2d deadbeefdeadf00d 83018caf2530 > 83005da27d38 > (XEN)83040a492830 83005da27cc8 83040bab2880 > > (XEN) deadbeefdeadf00d deadbeefdeadf00d > > (XEN) 830451835000 > 83040a492000 > (XEN)0006 82d08033f3da e008 > 00010282 > (XEN) Xen call trace: > (XEN)[<7bdb630c>] 7bdb630c > (XEN) > (XEN) Pagetable walk from ee138470: > (XEN) L4[0x000] = 00046d2ee063 > (XEN) L3[0x003] = 5da11063 > (XEN) L2[0x170] = > (XEN) > (XEN) > (XEN) Panic on CPU 0: > (XEN) FATAL PAGE FAULT > (XEN) [error_code=0002] > (XEN) Faulting linear address: ee138470 > (XEN) > (XEN) > (XEN) Reboot in five seconds... > >>> This one I'm not sure about. What does your introspection agent do at > >>> that point? > >> > >> This crash is bizarre. Xen has most likely followed a corrupt function > >> pointer, because none of Xen's .text section live just below the 2G > >> boundary > >> > > > > It's reproducible and happens immediately after a successful call to > > xc_altp2m_set_domain_state to enable altp2m. > > That can't be all that's needed. I assure you I've tested this with much > more that just calling xc_altp2m_set_domain_state() with no crashes at > all. Something else must happen as well. > > Could you write a simple C test application that does the minimum > ammount of work needed to produce this crash? Not the same error but another crash when just using xen-access with altp2m_exec: (XEN) Assertion '!p2m->sync.logdirty_ranges' failed at p2m-ept.c:1447 (XEN) [ Xen-4.12-unstable x86_64 debug=y Not tainted ] (XEN) CPU:7 (XEN) RIP:e008:[] p2m_init_altp2m_ept+0xf8/0x101 (XEN) RFLAGS: 00010282 CONTEXT: hypervisor (d0v1) (XEN) rax:
Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
With the config fixed it boots but when I run DRAKVUF on the domain I get the following crash: (XEN) [ Xen-4.12-unstable x86_64 debug=y Not tainted ] (XEN) CPU:0 (XEN) RIP:e008:[<7bdb630c>] 7bdb630c (XEN) RFLAGS: 00010282 CONTEXT: hypervisor (d0v5) (XEN) rax: ee138470 rbx: rcx: 8000b098 (XEN) rdx: 0cf8 rsi: rdi: 00046d2ef000 (XEN) rbp: rsp: 83005da27a10 r8: 0cf8 (XEN) r9: 0cf8 r10: 83005da27ab8 r11: 83005da27a08 (XEN) r12: r13: r14: 0065 (XEN) r15: 05a7 cr0: 80050033 cr4: 00372660 (XEN) cr3: 00046d2ef000 cr2: ee138470 (XEN) fsb: 7fe46d97bbc0 gsb: 880467f4 gss: (XEN) ds: es: fs: gs: ss: e010 cs: e008 (XEN) Xen code around <7bdb630c> (7bdb630c): (XEN) 80 74 0b 05 70 84 00 00 00 00 00 00 e0 80 3d 7a 34 00 00 00 75 64 48 (XEN) Xen stack trace from rsp=83005da27a10:(XEN) Xen stack trace from rsp=83005da27a10: (XEN) 0065 83005da27a50 82d08037aafc (XEN)fffe 82d08037ae14 83005da27a90 (XEN)00372660 00046d2ef000 000393e91000 82d0809602b0 (XEN)00fe 82d0802a3b98 83005da27ab8 (XEN)83005da27b08 82d0802a3511 82d08046b028 83005da27b08 (XEN)82d0802a3511 83005da27fff 13880292 82d0808176a0 (XEN) 82d08023b889 0292 82d08046b028 (XEN)82d080451ac8 82d080454af2 05a7 83005da27b78 (XEN)82d080251d6f 82d080250fcd 0028 83005da27b88 (XEN)83005da27b38 e010 82d080454c73 82d080451ac8 (XEN)82d080454af2 05a7 0030 83005da27bf8 (XEN)82d080454c73 83005da27be8 82d0802aaebc 82d08033f3dc (XEN)82d080451ac8 82d08037d969 82d08037d95d 82d08037d969 (XEN)0b0f82d08037d95d 82d08037d969 83005fe5b000 (XEN) 83005da27fff 7cffa25d83e7 (XEN)82d08037da2d deadbeefdeadf00d 83018caf2530 83005da27d38 (XEN)83040a492830 83005da27cc8 83040bab2880 (XEN) deadbeefdeadf00d deadbeefdeadf00d (XEN) 830451835000 83040a492000 (XEN)0006 82d08033f3da e008 00010282 (XEN) Xen call trace: (XEN)[<7bdb630c>] 7bdb630c (XEN) (XEN) Pagetable walk from ee138470: (XEN) L4[0x000] = 00046d2ee063 (XEN) L3[0x003] = 5da11063 (XEN) L2[0x170] = (XEN) (XEN) (XEN) Panic on CPU 0: (XEN) FATAL PAGE FAULT (XEN) [error_code=0002] (XEN) Faulting linear address: ee138470 (XEN) (XEN) (XEN) Reboot in five seconds... >>> This one I'm not sure about. What does your introspection agent do at >>> that point? >> >> This crash is bizarre. Xen has most likely followed a corrupt function >> pointer, because none of Xen's .text section live just below the 2G boundary >> > > It's reproducible and happens immediately after a successful call to > xc_altp2m_set_domain_state to enable altp2m. That can't be all that's needed. I assure you I've tested this with much more that just calling xc_altp2m_set_domain_state() with no crashes at all. Something else must happen as well. Could you write a simple C test application that does the minimum ammount of work needed to produce this crash? Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
On Mon, Oct 22, 2018 at 3:22 PM Andrew Cooper wrote:
>
> On 22/10/2018 22:17, Razvan Cojocaru wrote:
> > On 10/22/18 11:48 PM, Tamas K Lengyel wrote:
> >> On Thu, Oct 18, 2018 at 3:12 PM Razvan Cojocaru
> >> wrote:
> >>> On 10/18/18 11:08 PM, Tamas K Lengyel wrote:
> On Thu, Oct 18, 2018 at 4:09 AM Razvan Cojocaru
> wrote:
> > Hello,
> >
> > This series aims to prevent the display from freezing when
> > enabling altp2m and switching to a new view (and assorted problems
> > when resizing the display).
> >
> > The first patch propagates ept.ad changes to all active altp2ms,
> > and the second one allocates a new logdirty rangeset for each
> > new altp2m, and propagates (under lock) changes to all p2ms.
> >
> > The first patch is the same as:
> > [PATCH V4] x86/altp2m: propagate ept.ad changes to all active altp2ms
> > but as it is now required for the second one to apply cleanly, it
> > has been resent as part of this series.
> >
> > [PATCH 1/2] x86/altp2m: propagate ept.ad changes to all active altp2ms
> > [PATCH 2/2] x86/altp2m: fix display frozen when switching to a new
> Hi Razvan,
> I would be happy to give this a spin, can you push it as a git branch
> somewhere?
> >>> Sure, here you go:
> >>>
> >>> https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take1
> >> I ran into this crash when my config incorrectly pointed to a
> >> non-valid disk location:
> >>
> >> (XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475
> >> (XEN) [ Xen-4.12-unstable x86_64 debug=y Not tainted ]
> >> (XEN) CPU:4
> >> (XEN) RIP:e008:[] p2m_uninit_altp2m_ept+0x29/0x2b
> >> (XEN) RFLAGS: 00010246 CONTEXT: hypervisor
> >> (XEN) rax: 83046d27802c rbx: 8304558dd880 rcx:
> >> (XEN) rdx: 83046d277fff rsi: 004680c0 rdi:
> >> (XEN) rbp: 83046d277d60 rsp: 83046d277d50 r8: 82d0809304a0
> >> (XEN) r9: 00455940 r10: 82e008d01000 r11: 0017
> >> (XEN) r12: 8304558dd880 r13: 8304558df830 r14: 8304558df000
> >> (XEN) r15: fff8 cr0: 8005003b cr4: 003526e0
> >> (XEN) cr3: 5da16000 cr2: 880456cd6e80
> >> (XEN) fsb: gsb: 880467f4 gss:
> >> (XEN) ds: 002b es: 002b fs: gs: ss: e010 cs: e008
> >> (XEN) Xen code around (p2m_uninit_altp2m_ept+0x29/0x2b):
> >> (XEN) 00 48 83 c4 08 5b 5d c3 <0f> 0b 55 48 89 e5 41 56 41 55 41 54 53 48
> >> 8d 05
> >> (XEN) Xen call trace:
> >> (XEN)[] p2m_uninit_altp2m_ept+0x29/0x2b
> >> (XEN)[] p2m.c#p2m_teardown_altp2m+0x36/0x52
> >> (XEN)[] p2m_final_teardown+0x11/0x28
> >> (XEN)[] paging_final_teardown+0x2e/0x3c
> >> (XEN)[] arch_domain_destroy+0x50/0xa1
> >> (XEN)[] domain.c#complete_domain_destroy+0x86/0x159
> >> (XEN)[] rcupdate.c#rcu_process_callbacks+0xa5/0x1cf
> >> (XEN)[] softirq.c#__do_softirq+0x71/0x9a
> >> (XEN)[] do_softirq+0x13/0x15
> >> (XEN)[] domain.c#idle_loop+0x63/0xb9
> >> (XEN)
> >> (XEN)
> >> (XEN)
> >> (XEN) Panic on CPU 4:
> >> (XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475
> >> (XEN)
> > Right, that one I've also come across now, that will be fixed in the
> > next series as a result of doing what Andrew has suggested, which is to say:
> >
> > "Please make all destroy functions idempotent. i.e.
> >
> > if ( p2m->sync.logdirty_ranges )
> > {
> > rangeset_destroy(p2m->sync.logdirty_ranges);
> > p2m->sync.logdirty_ranges = NULL;
> > }
> >
> > and use this destroy function in the cleanup path of init()."
>
> Indeed.
>
> >
> >> With the config fixed it boots but when I run DRAKVUF on the domain I
> >> get the following crash:
> >>
> >> (XEN) [ Xen-4.12-unstable x86_64 debug=y Not tainted ]
> >> (XEN) CPU:0
> >> (XEN) RIP:e008:[<7bdb630c>] 7bdb630c
> >> (XEN) RFLAGS: 00010282 CONTEXT: hypervisor (d0v5)
> >> (XEN) rax: ee138470 rbx: rcx: 8000b098
> >> (XEN) rdx: 0cf8 rsi: rdi: 00046d2ef000
> >> (XEN) rbp: rsp: 83005da27a10 r8: 0cf8
> >> (XEN) r9: 0cf8 r10: 83005da27ab8 r11: 83005da27a08
> >> (XEN) r12: r13: r14: 0065
> >> (XEN) r15: 05a7 cr0: 80050033 cr4: 00372660
> >> (XEN) cr3: 00046d2ef000 cr2: ee138470
> >> (XEN) fsb: 7fe46d97bbc0 gsb: 880467f4 gss:
> >> (XEN) ds: es: fs: gs: ss: e010 cs: e008
> >> (XEN) Xen code around <7bdb630c> (7bdb630c):
> >> (XEN) 80 74 0b 05 70 84 00 00 00 00 00 00 e0 80 3d 7a 34 00 00 00
Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
On 22/10/2018 22:17, Razvan Cojocaru wrote:
> On 10/22/18 11:48 PM, Tamas K Lengyel wrote:
>> On Thu, Oct 18, 2018 at 3:12 PM Razvan Cojocaru
>> wrote:
>>> On 10/18/18 11:08 PM, Tamas K Lengyel wrote:
On Thu, Oct 18, 2018 at 4:09 AM Razvan Cojocaru
wrote:
> Hello,
>
> This series aims to prevent the display from freezing when
> enabling altp2m and switching to a new view (and assorted problems
> when resizing the display).
>
> The first patch propagates ept.ad changes to all active altp2ms,
> and the second one allocates a new logdirty rangeset for each
> new altp2m, and propagates (under lock) changes to all p2ms.
>
> The first patch is the same as:
> [PATCH V4] x86/altp2m: propagate ept.ad changes to all active altp2ms
> but as it is now required for the second one to apply cleanly, it
> has been resent as part of this series.
>
> [PATCH 1/2] x86/altp2m: propagate ept.ad changes to all active altp2ms
> [PATCH 2/2] x86/altp2m: fix display frozen when switching to a new
Hi Razvan,
I would be happy to give this a spin, can you push it as a git branch
somewhere?
>>> Sure, here you go:
>>>
>>> https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take1
>> I ran into this crash when my config incorrectly pointed to a
>> non-valid disk location:
>>
>> (XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475
>> (XEN) [ Xen-4.12-unstable x86_64 debug=y Not tainted ]
>> (XEN) CPU:4
>> (XEN) RIP:e008:[] p2m_uninit_altp2m_ept+0x29/0x2b
>> (XEN) RFLAGS: 00010246 CONTEXT: hypervisor
>> (XEN) rax: 83046d27802c rbx: 8304558dd880 rcx:
>> (XEN) rdx: 83046d277fff rsi: 004680c0 rdi:
>> (XEN) rbp: 83046d277d60 rsp: 83046d277d50 r8: 82d0809304a0
>> (XEN) r9: 00455940 r10: 82e008d01000 r11: 0017
>> (XEN) r12: 8304558dd880 r13: 8304558df830 r14: 8304558df000
>> (XEN) r15: fff8 cr0: 8005003b cr4: 003526e0
>> (XEN) cr3: 5da16000 cr2: 880456cd6e80
>> (XEN) fsb: gsb: 880467f4 gss:
>> (XEN) ds: 002b es: 002b fs: gs: ss: e010 cs: e008
>> (XEN) Xen code around (p2m_uninit_altp2m_ept+0x29/0x2b):
>> (XEN) 00 48 83 c4 08 5b 5d c3 <0f> 0b 55 48 89 e5 41 56 41 55 41 54 53 48
>> 8d 05
>> (XEN) Xen call trace:
>> (XEN)[] p2m_uninit_altp2m_ept+0x29/0x2b
>> (XEN)[] p2m.c#p2m_teardown_altp2m+0x36/0x52
>> (XEN)[] p2m_final_teardown+0x11/0x28
>> (XEN)[] paging_final_teardown+0x2e/0x3c
>> (XEN)[] arch_domain_destroy+0x50/0xa1
>> (XEN)[] domain.c#complete_domain_destroy+0x86/0x159
>> (XEN)[] rcupdate.c#rcu_process_callbacks+0xa5/0x1cf
>> (XEN)[] softirq.c#__do_softirq+0x71/0x9a
>> (XEN)[] do_softirq+0x13/0x15
>> (XEN)[] domain.c#idle_loop+0x63/0xb9
>> (XEN)
>> (XEN)
>> (XEN)
>> (XEN) Panic on CPU 4:
>> (XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475
>> (XEN)
> Right, that one I've also come across now, that will be fixed in the
> next series as a result of doing what Andrew has suggested, which is to say:
>
> "Please make all destroy functions idempotent. i.e.
>
> if ( p2m->sync.logdirty_ranges )
> {
> rangeset_destroy(p2m->sync.logdirty_ranges);
> p2m->sync.logdirty_ranges = NULL;
> }
>
> and use this destroy function in the cleanup path of init()."
Indeed.
>
>> With the config fixed it boots but when I run DRAKVUF on the domain I
>> get the following crash:
>>
>> (XEN) [ Xen-4.12-unstable x86_64 debug=y Not tainted ]
>> (XEN) CPU:0
>> (XEN) RIP:e008:[<7bdb630c>] 7bdb630c
>> (XEN) RFLAGS: 00010282 CONTEXT: hypervisor (d0v5)
>> (XEN) rax: ee138470 rbx: rcx: 8000b098
>> (XEN) rdx: 0cf8 rsi: rdi: 00046d2ef000
>> (XEN) rbp: rsp: 83005da27a10 r8: 0cf8
>> (XEN) r9: 0cf8 r10: 83005da27ab8 r11: 83005da27a08
>> (XEN) r12: r13: r14: 0065
>> (XEN) r15: 05a7 cr0: 80050033 cr4: 00372660
>> (XEN) cr3: 00046d2ef000 cr2: ee138470
>> (XEN) fsb: 7fe46d97bbc0 gsb: 880467f4 gss:
>> (XEN) ds: es: fs: gs: ss: e010 cs: e008
>> (XEN) Xen code around <7bdb630c> (7bdb630c):
>> (XEN) 80 74 0b 05 70 84 00 00 00 00 00 00 e0 80 3d 7a 34 00 00 00 75
>> 64 48
>> (XEN) Xen stack trace from rsp=83005da27a10:(XEN) Xen stack trace
>> from rsp=83005da27a10:
>> (XEN) 0065 83005da27a50 82d08037aafc
>> (XEN)fffe 82d08037ae14
Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
On Thu, Oct 18, 2018 at 3:12 PM Razvan Cojocaru wrote: > > On 10/18/18 11:08 PM, Tamas K Lengyel wrote: > > On Thu, Oct 18, 2018 at 4:09 AM Razvan Cojocaru > > wrote: > >> > >> Hello, > >> > >> This series aims to prevent the display from freezing when > >> enabling altp2m and switching to a new view (and assorted problems > >> when resizing the display). > >> > >> The first patch propagates ept.ad changes to all active altp2ms, > >> and the second one allocates a new logdirty rangeset for each > >> new altp2m, and propagates (under lock) changes to all p2ms. > >> > >> The first patch is the same as: > >> [PATCH V4] x86/altp2m: propagate ept.ad changes to all active altp2ms > >> but as it is now required for the second one to apply cleanly, it > >> has been resent as part of this series. > >> > >> [PATCH 1/2] x86/altp2m: propagate ept.ad changes to all active altp2ms > >> [PATCH 2/2] x86/altp2m: fix display frozen when switching to a new > > > > Hi Razvan, > > I would be happy to give this a spin, can you push it as a git branch > > somewhere? > > Sure, here you go: > > https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take1 I ran into this crash when my config incorrectly pointed to a non-valid disk location: (XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475 (XEN) [ Xen-4.12-unstable x86_64 debug=y Not tainted ] (XEN) CPU:4 (XEN) RIP:e008:[] p2m_uninit_altp2m_ept+0x29/0x2b (XEN) RFLAGS: 00010246 CONTEXT: hypervisor (XEN) rax: 83046d27802c rbx: 8304558dd880 rcx: (XEN) rdx: 83046d277fff rsi: 004680c0 rdi: (XEN) rbp: 83046d277d60 rsp: 83046d277d50 r8: 82d0809304a0 (XEN) r9: 00455940 r10: 82e008d01000 r11: 0017 (XEN) r12: 8304558dd880 r13: 8304558df830 r14: 8304558df000 (XEN) r15: fff8 cr0: 8005003b cr4: 003526e0 (XEN) cr3: 5da16000 cr2: 880456cd6e80 (XEN) fsb: gsb: 880467f4 gss: (XEN) ds: 002b es: 002b fs: gs: ss: e010 cs: e008 (XEN) Xen code around (p2m_uninit_altp2m_ept+0x29/0x2b): (XEN) 00 48 83 c4 08 5b 5d c3 <0f> 0b 55 48 89 e5 41 56 41 55 41 54 53 48 8d 05 (XEN) Xen call trace: (XEN)[] p2m_uninit_altp2m_ept+0x29/0x2b (XEN)[] p2m.c#p2m_teardown_altp2m+0x36/0x52 (XEN)[] p2m_final_teardown+0x11/0x28 (XEN)[] paging_final_teardown+0x2e/0x3c (XEN)[] arch_domain_destroy+0x50/0xa1 (XEN)[] domain.c#complete_domain_destroy+0x86/0x159 (XEN)[] rcupdate.c#rcu_process_callbacks+0xa5/0x1cf (XEN)[] softirq.c#__do_softirq+0x71/0x9a (XEN)[] do_softirq+0x13/0x15 (XEN)[] domain.c#idle_loop+0x63/0xb9 (XEN) (XEN) (XEN) (XEN) Panic on CPU 4: (XEN) Assertion 'p2m->sync.logdirty_ranges' failed at p2m-ept.c:1475 (XEN) With the config fixed it boots but when I run DRAKVUF on the domain I get the following crash: (XEN) [ Xen-4.12-unstable x86_64 debug=y Not tainted ] (XEN) CPU:0 (XEN) RIP:e008:[<7bdb630c>] 7bdb630c (XEN) RFLAGS: 00010282 CONTEXT: hypervisor (d0v5) (XEN) rax: ee138470 rbx: rcx: 8000b098 (XEN) rdx: 0cf8 rsi: rdi: 00046d2ef000 (XEN) rbp: rsp: 83005da27a10 r8: 0cf8 (XEN) r9: 0cf8 r10: 83005da27ab8 r11: 83005da27a08 (XEN) r12: r13: r14: 0065 (XEN) r15: 05a7 cr0: 80050033 cr4: 00372660 (XEN) cr3: 00046d2ef000 cr2: ee138470 (XEN) fsb: 7fe46d97bbc0 gsb: 880467f4 gss: (XEN) ds: es: fs: gs: ss: e010 cs: e008 (XEN) Xen code around <7bdb630c> (7bdb630c): (XEN) 80 74 0b 05 70 84 00 00 00 00 00 00 e0 80 3d 7a 34 00 00 00 75 64 48 (XEN) Xen stack trace from rsp=83005da27a10:(XEN) Xen stack trace from rsp=83005da27a10: (XEN) 0065 83005da27a50 82d08037aafc (XEN)fffe 82d08037ae14 83005da27a90 (XEN)00372660 00046d2ef000 000393e91000 82d0809602b0 (XEN)00fe 82d0802a3b98 83005da27ab8 (XEN)83005da27b08 82d0802a3511 82d08046b028 83005da27b08 (XEN)82d0802a3511 83005da27fff 13880292 82d0808176a0 (XEN) 82d08023b889 0292 82d08046b028 (XEN)82d080451ac8 82d080454af2 05a7 83005da27b78 (XEN)82d080251d6f 82d080250fcd 0028 83005da27b88 (XEN)83005da27b38 e010 82d080454c73 82d080451ac8 (XEN)82d080454af2 05a7 0030 83005da27bf8
Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
On 10/18/18 11:08 PM, Tamas K Lengyel wrote: > On Thu, Oct 18, 2018 at 4:09 AM Razvan Cojocaru > wrote: >> >> Hello, >> >> This series aims to prevent the display from freezing when >> enabling altp2m and switching to a new view (and assorted problems >> when resizing the display). >> >> The first patch propagates ept.ad changes to all active altp2ms, >> and the second one allocates a new logdirty rangeset for each >> new altp2m, and propagates (under lock) changes to all p2ms. >> >> The first patch is the same as: >> [PATCH V4] x86/altp2m: propagate ept.ad changes to all active altp2ms >> but as it is now required for the second one to apply cleanly, it >> has been resent as part of this series. >> >> [PATCH 1/2] x86/altp2m: propagate ept.ad changes to all active altp2ms >> [PATCH 2/2] x86/altp2m: fix display frozen when switching to a new > > Hi Razvan, > I would be happy to give this a spin, can you push it as a git branch > somewhere? Sure, here you go: https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take1 Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m
On Thu, Oct 18, 2018 at 4:09 AM Razvan Cojocaru wrote: > > Hello, > > This series aims to prevent the display from freezing when > enabling altp2m and switching to a new view (and assorted problems > when resizing the display). > > The first patch propagates ept.ad changes to all active altp2ms, > and the second one allocates a new logdirty rangeset for each > new altp2m, and propagates (under lock) changes to all p2ms. > > The first patch is the same as: > [PATCH V4] x86/altp2m: propagate ept.ad changes to all active altp2ms > but as it is now required for the second one to apply cleanly, it > has been resent as part of this series. > > [PATCH 1/2] x86/altp2m: propagate ept.ad changes to all active altp2ms > [PATCH 2/2] x86/altp2m: fix display frozen when switching to a new Hi Razvan, I would be happy to give this a spin, can you push it as a git branch somewhere? Thanks, Tamas ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Fix VGA logdirty related display freezes with altp2m
Hello, This series aims to prevent the display from freezing when enabling altp2m and switching to a new view (and assorted problems when resizing the display). The first patch propagates ept.ad changes to all active altp2ms, and the second one allocates a new logdirty rangeset for each new altp2m, and propagates (under lock) changes to all p2ms. The first patch is the same as: [PATCH V4] x86/altp2m: propagate ept.ad changes to all active altp2ms but as it is now required for the second one to apply cleanly, it has been resent as part of this series. [PATCH 1/2] x86/altp2m: propagate ept.ad changes to all active altp2ms [PATCH 2/2] x86/altp2m: fix display frozen when switching to a new Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
