Re: [PATCH v2 0/2] x86/cpuidle: Cannon Lake adjustments

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.04.2020 16:58, Andrew Cooper wrote:
> On 02/04/2020 09:22, Jan Beulich wrote:
>> As requested in reply to v1, this is now a pair of patches with
>> the expectation that only patch 1 would be acked and go in.
>>
>> 1: drop Cannon Lake support
>> 2: support Cannon Lake (again)
> 
> Dropping Cannon Lake support is only of any incremental benefit if we
> drop it from everywhere, and I didn't mean to block this single patch on it.

How would dropping it from everywhere in one go be any better?
I would see a benefit then only if we added code to refuse
booting there.

> Consider either A-by.

I'm sorry to ask, but "either" here is unclear to me: Do you
mean both of the above, or "the first one here or the original
v1 one"? I don't see a point committing this in two pieces, if
the combination of both is fine by you as well.

> However, it would be helpful to consider what we could do for better
> KCONFIG-able CPU support.

Yes, sure. Future work.

> Some downstreams have a separate build for each platform, and some go as
> far as cramming Xen into the boot SPI ROM, so space saving is a very
> important aspect.

Yes.

> On a different front, being able to compile out support for CPUs without
> VMX unrestricted mode, or without CMPXCHG16B would be helpful.

Yes.

> I would certainly like to get CONFIG_{INTEL,AMD} usable even if only so
> randconfig can help keep our interfaces clean.

And yes again.

Jan