On 15/11/2019 12:44, Andreas Kinzler wrote: > On 15.11.2019 13:10, George Dunlap wrote: >> 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). >>> >>> Then someone with detailed knowledge could compare the two? >> What would be the purpose? >> The code is going to look like this -- >> an impenetrable maze of "switch" and "if" statements based on >> individual bits or features or models. *Somewhere* in Window's >> versionof that code, there's a path which is triggered by > > As of this moment all of this is just an assumption - you might very > well be right, but it could also be something totally different. What > if the CPUID is nearly identical? This would lead to the conclusion > that the problem has completely different root causes.
The problem is that Xen's "messing around with topology" is, and has always been, incorrect. It does not match the rules given in the SDM/APM. None of this code is going to survive the rewrite making the presented topology actually follow the architectural rules. However, for 4.13, we are trying to find the least invasive hack possible to cause windows not to explode. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
