Re: [PATCH for-4.17] x86/hvm: Revert per-domain APIC acceleration support

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

> 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.cooper3@xxxxxxxxxx>

Provisional upon Roger not objecting (i.e. him at least remaining
neutral), and preferably with the above remarks addressed:
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan