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? 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. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
