On 15/11/2022 08:49, Jan Beulich wrote: > On 15.11.2022 01:35, Andrew Cooper wrote: >> I was really hoping to avoid this, but its now too late in the 4.17 freeze >> and >> we still don't have working fixes. >> >> The in-Xen calculations for assistance capabilities are buggy. For the >> avoidance of doubt, the original intention was to be able to control every >> aspect of a APIC acceleration so we could comprehensively test Xen's support, >> as it has proved to be buggy time and time again. >> >> Even after a protracted discussion on what the new API ought to mean, >> attempts >> to apply it to the existing logic have been unsuccessful, proving that the >> API/ABI is too complicated for most people to reason about. > Like Roger I'm still having trouble seeing what ABI you're talking > about here. Yes, there are internal handling issues, but that's hardly > "ABI". And as Roger indicated before, anything domctl/sysctl isn't > stable anyway.
It absolutely is stable when it it extends beyond domctl/sysctl into the libxl API, two different xl config files, and Xen command line (for PVH dom0). domctl/sysctl are the very least of the problem. >> This reverts most of: >> 2ce11ce249a3981bac50914c6a90f681ad7a4222 >> 6b2b9b3405092c3ad38d7342988a584b8efa674c > plus (as per Fixes: tags) > > 399bcbf281bd936d1eff7f7d1054ab49115c3a44 > 0823d57d71c7023bea94d483f69f7b5e62820102 > > which I think want mentioning here as well despite, like stated for the > main commits, parts are left in place. > >> leaving in place the non-APIC specific changes (minimal as they are). >> >> This takes us back to the behaviour of Xen 4.16 where APIC acceleration is >> configured on a per system basis. >> >> This work will be revisited in due course. >> >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > Provisional upon Roger not objecting (i.e. him at least remaining > neutral), and preferably with the above remarks addressed: > Acked-by: Jan Beulich <jbeul...@suse.com> Thanks. ~Andrew
