On 11/15/19 11:39 AM, Andreas Kinzler wrote: > On 15.11.2019 12:29, George Dunlap wrote: >> On 11/15/19 11:17 AM, Andreas Kinzler wrote: >>> I do not understand a central point: No matter why and/or how a fake >>> topology is presented by Xen, why did the older generation Ryzen 2xxx >>> work and Ryzen 3xxx doesn't? What is the change in AMD(!) not Xen that >>> causes the one to work and the other to fail? >> The CPU features that the guest sees are a mix of the real underlying >> features and changes made by Xen. Xen and/or the hardware will behave > > Why not analyze the bits in detail? I already posted the complete CPUID > for 3700X > (https://lists.xenproject.org/archives/html/xen-devel/2019-09/msg02189.html). > > > @Steven: >> If this is helpful, I can probably provide the same from: >> * Ryzen 2700x >> * Ryzen 3900x > Can you post for 2700X? > > Then someone with detailed knowledge could compare the two?
What would be the purpose? The code is going to look like this -- https://gitlab.com/xen-project/xen/blob/staging/xen/arch/x86/cpu/common.c -- an impenetrable maze of "switch" and "if" statements based on individual bits or features or models. *Somewhere* in Window's version of that code, there's a path which is triggered by Ryzen-3xxx-Xen-with-Fake-HT but not triggered by Ryzen-2xxx-with-Xen-Fake-HT, or Ryzen-3xxx-Xen-without-Fake-HT. And suppose we found exactly the bits which triggered it, what then? We could flip just that bit; but that would make the resulting CPUID even *more* weird, and likely to trigger something else in the future. The solution this patch proposes doesn't make the CPUID topology "normal", but it certainly makes it a lot less weird, which is a better place to be. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
