[PATCH v1] x86: Support ZHAOXIN padlock instructions

[Jiang, Haochen]

> From: Mayshao-oc <Mayshao-oc@zhaoxin.com>
> Sent: Monday, December 16, 2024 2:48 PM
> >
> > A quick reminder. From documentation, it seems that Zhaoxin is going to extend
> > the usage for old bits for new instructions. If you are only using inline asm in the
> > future (and I suppose so since I did not get PadLock in GCC code base from my quick
> > search), it should be ok. But there will be a potential issue for illegal instruction on
> > HW if the assumption is wrong since I don't see a way to reject those insts.
> Hi Haochen:
>         Thanks for your comments,but I am a little confused.Why it is ok to be
> used as inline assembly,
> and there will be an issue if gcc generates it? Could you please give an example
> to illustrate
> your idea?

Let's assume that you enabled the new insts with new intrins in GCC. Then for example,
when we are building a source file with GCC and -march=native on an old machine
has PadLock bit set, GCC will also enable the new insts since they are combined. Then if
you used the new intrins, GCC could not reject the code the machine does not support.
HW will throw out illegal inst at the end of the day. This is not an expected behavior for
compiler. Compiler should reject that intrin at the beginning.

On the other hand, inline assembly in a source file won't check CPUID when compiling
with GCC. User should use asm at their own risk and have the knowledge the asm they
wrote is valid or not. They should not expect compiler reject inline assembly.

But as I said, if you are not going to add new intrins, it seems no problem for the CPUID.

Thx,
Haochen