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
