[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



# 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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.