[PATCH v1] x86: Support ZHAOXIN padlock instructions

[Mayshao-oc]

> > 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

Hi Haochen:

    Thanks for your patience. I got it.
    For the Zhaoxin platforms, we can guarantee the CPUID information is correct. For example, if cpuid return edx bit[3] that xstore, rep xstore, and rep xrng2 instructions are present, then these instructions exist.So no illegal inst GP will generate.
    For the VIA platforms, GCC does not detect features for VIA CPUs(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758), so I think gcc will never generate any padlock instructions on these platforms.  
    So practically, there is no need for gcc to reject these instructions.

BR
Mayshao