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

[Steven Haigh <netwiz@crc.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3061 bytes --]

# 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@crc.id.au     💻 https://www.crc.id.au
📞 +613 9001 6090       📱 +614 1293 5897


On Fri, Oct 25, 2019 at 10:28, Jan Beulich <jbeulich@suse.com> 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@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel


[-- Attachment #2: xen-output.log.gz --]
[-- Type: application/gzip, Size: 11252 bytes --]

[-- Attachment #3: Type: text/plain, Size: 157 bytes --]

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