On 15/11/2019 15:23, George Dunlap wrote: > On 11/15/19 2:59 PM, Andrew Cooper wrote: >> On 15/11/2019 14:55, George Dunlap wrote: >>>>> + p->basic.htt = false; >>>> I think everything below here indeed simply undoes what said old >>>> commit did, but I can't match up this one. And together with the >>>> question of whether instead leaving it alone, cmp_legacy then >>>> would have the same question raised. >>> This is based on a XenServer patch which reverts the entire commit, and >>> has been maintained in the patchqueue since the commit made it upstream, >>> AFAICT. So I'll let someone from that team comment on the wherefores; >>> but as I said, it's by far the best tested option we're going to get. >> Yes. It is a revert of c/s ca2eee92df44 (Xen 3.4, and maintained >> forwards until now) because it broke migration across that changeset. >> >> It is also this exact version of the revert which has been tested and >> confirmed to fix the Ryzen 3xxx fixes. >> >> A separate experiment tried playing with only the flags, via >> cpuid="host:htt=0,cmp_legacy=1" and this did not resolve the crashes. > Is that because the "revert" still clears cmp_legacy, rather than > setting it to 1? > > I think what Jan was getting at was that ca2eee92df44 *sets* htt and > *clears* cmp_legacy, but previous to that commit, htt and cmp_legacy > weren't changed, they were simply left alone. When reverting this > patch, why do we not simply leave it alone, as was done before, rather > than actively clearing them?
You also need to account for the accumulated bugfixes of the code since ca2eee92df44. > I think it's a good question to ask, but unless there is a known issue > with what the patch does, I think it's far less risky just to take the > version which has been tested. In short, yes I believe the behaviour is deliberate, although I don't have the bug tickets to hand to remember exactly what went wrong. The only other possibility (and perhaps is better, now that it is possible) is to foward those two bits from the host policy. They are set in the guest policy due to (still) not having a split between default and max (another issue in the queue to be fixed). ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
