RE: [PATCH xenvif] Replace uses of MmAllocatePagesForMdlEx in __AllocatePages()...

["Durrant, Paul" <pdurrant@xxxxxxxxxxxx>]

> -----Original Message-----
> From: Jan Bakuwel <jan.bakuwel@xxxxxxxxx>
> Sent: 17 June 2020 22:11
> To: paul@xxxxxxx; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Durrant, Paul <pdurrant@xxxxxxxxxxxx>
> Subject: RE: [EXTERNAL] [PATCH xenvif] Replace uses of 
> MmAllocatePagesForMdlEx in __AllocatePages()...
> 
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open
> attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> Hi Paul,
> 
> On 18/06/20 3:02 am, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: win-pv-devel <win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf 
> >> Of Paul Durrant
> >> Sent: 16 June 2020 14:03
> >> To: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> >> Cc: Paul Durrant <pdurrant@xxxxxxxxxx>
> >> Subject: [PATCH xenvif] Replace uses of MmAllocatePagesForMdlEx in 
> >> __AllocatePages()...
> >>
> >> From: Paul Durrant <pdurrant@xxxxxxxxxx>
> >>
> >> ... again.
> >>
> >> Commit 4f85d004 "Replace uses of MmAllocatePagesForMdlEx in __AllocatePage"
> >> modified __AllocatePage() (only) to use
> >> MmAllocateContinguousMemorySpecifyCache() as its source of memory. As 
> >> stated
> >> in that commit:
> >>
> >> "Windows appears to have an edge case bug in which zeroing memory using
> >> MmAllocatePAgesForMdlEx (which in Win 10 1803 happens even if you specify
> >> MM_DONT_ZERO_ALLOCATION) can cause a BSOD 139 1e."
> >>
> >> That commit was reverted by e8fe14f6 since it was believed that the bug in
> >> Windows had been fixed. Subsequently, however, the same symptoms have been
> >> seen with recent updates of Server 2019. The stack is generally of the 
> >> form:
> >>
> >> nt!KeBugCheckEx
> >> nt!KiBugCheckDispatch+0x69
> >> nt!KiFastFailDispatch+0xd0
> >> nt!KiRaiseSecurityCheckFailure+0x30e
> >> nt!KiAcquireThreadStateLock+0x11fa90
> >> nt!KeSetIdealProcessorThreadEx+0xd0
> >> nt!MiZeroInParallelWorker+0x115016
> >> nt!MiZeroInParallel+0x11c
> >> nt!MiInitializeMdlBatchPages+0x2ae
> >> nt!MiAllocatePagesForMdl+0x192
> >> nt!MmAllocatePartitionNodePagesForMdlEx+0xc9
> >> nt!MmAllocatePagesForMdlEx+0x4d
> >>
> >> Hence, this patch re-instates the fix originally put in place by 4f85d004
> >> but generalizes it to include AllocatePages() rather than just
> >> AllocatePage().
> >>
> >> Reported-by: Jan Bakuwel <jan.bakuwel@xxxxxxxxx>
> >> Signed-off-by: Paul Durrant <pdurrant@xxxxxxxxxx>
> >> ---
> >>
> >> This fix will also be propogated to all other PV drivers.
> > This is actually failing in xenvbd, trying to allocate 2 pages for the 
> > shared ring, so I'm going to
> try the simpler alternative of
> > continuing to use MmAllocatePagesForMdlEx() but without passing the "don't 
> > zero" flag.
> 
> Many thanks. Will you apply the fix to both 8.2.2 and 9.0 drivers?
> 
> I've raised on issue in the xcp-ng/xcp github repo linking to the mail
> archive of this list, so hopefully the patches will be pulled in there
> as well. The XCP-NG driver (so far) is the only one I can install
> without issues on Windows 2019 Server.
> 

Hi Jan,

  I'll apply the fix for 9.0 and then let it churn through the build system. I 
would appreciate it if you could things when they are ready. I'm not plan to 
apply the fix to the 8.2 branch at this point though.

  Cheers,

    Paul

> Jan