Re: [Xen-devel] Debugging Windows HVM crashes on Ryzen 3xxx series CPUs.

[Steven Haigh <netwiz@xxxxxxxxx>]

# patch -p1 < ../000-debug-patch-0.patch
patching file xen/arch/x86/hvm/hvm.c
Hunk #1 succeeded at 3373 (offset 1 line).
patching file xen/arch/x86/hvm/svm/svm.c
Hunk #1 succeeded at 2159 (offset -64 lines).

I've attached the output from around boot all the way until after the 
Windows HVM DomU crashed.
I gzip'ed it, as its a few hundred Kb.
Steven Haigh

📧 netwiz@xxxxxxxxx     💻 https://www.crc.id.au
📞 +613 9001 6090       📱 +614 1293 5897


On Fri, Oct 25, 2019 at 10:28, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> On 25.10.2019 09:00, Steven Haigh wrote:
> >  Further to my last, I downloaded the latest Windows Server 2016 ISO 
> > from
> >  Microsoft.
> >
> >  Filename: 
> > Windows_Server_2016_Datacenter_EVAL_en-us_14393_refresh.ISO
> >  Have attached as much of the log as I could get attempting to boot 
> > from
> >  the ISO and having a blank LV as the install target.
> >
> >  The Windows error message (shown via VNC) is HAL MEMORY ALLOCATION.
> Hmm, that's as if there was still (again?) an issue with CPUID
> handling - iirc the same was observable on maximum-size Rome
> systems prior to df29d03f1d (and its fixup). Below the debugging
> patch I did use at the time, maybe it turns out helpful here too
> (and perhaps you'd really only need the first hunk, I had put in
> the other one just in case anyway).
>
> However this looks to be different from your earlier report,
> where you said you've got some
>
> (XEN) d1v0 VIRIDIAN CRASH: ac 0 a0a0 fffff8065c06bf88 bf8
>
> So I wonder whether there's a new issue masking the old one.
>
> Jan
>
> --- unstable.orig/xen/arch/x86/hvm/hvm.c
> +++ unstable/xen/arch/x86/hvm/hvm.c
> @@ -3372,6 +3372,9 @@ int hvm_vmexit_cpuid(struct cpu_user_reg
>      }
>
>      guest_cpuid(curr, leaf, subleaf, &res);
> +if(regs->ax && (regs->eax >> 16) != 0x4000 && (long)regs->rip < 0) 
> {//temp
> + printk("%pv[%08lx]: %08x:%08x=%08x:%08x:%08x:%08x\n", curr, 
> regs->rip, leaf, subleaf, res.a, res.b, res.c, res.d);
> +}
>      HVMTRACE_6D(CPUID, leaf, subleaf, res.a, res.b, res.c, res.d);
>
>      regs->rax = res.a;
> --- unstable.orig/xen/arch/x86/hvm/svm/svm.c
> +++ unstable/xen/arch/x86/hvm/svm/svm.c
> @@ -2223,7 +2223,13 @@ static void svm_do_msr_access(struct cpu
>
>          rc = hvm_msr_read_intercept(regs->ecx, &msr_content);
>          if ( rc == X86EMUL_OKAY )
> +{//temp
>              msr_split(regs, msr_content);
> + if(regs->ecx == 0xc001100c || regs->ecx == 0xc0011005)
> +  printk("%pv[%08lx]: %08x -> %08x:%08x\n", curr, regs->rip, 
> regs->ecx, regs->edx, regs->eax);
> +} else if(regs->ecx == 0xc001100c || regs->ecx == 0xc0011005) {
> + printk("%pv[%08lx]: %08x -> #GP\n", curr, regs->rip, regs->ecx);
> +}
>      }
>      else
>          rc = hvm_msr_write_intercept(regs->ecx, msr_fold(regs), 
> true);
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/xen-devel

Attachment: xen-output.log.gz
Description: application/gzip

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel