linux-kernel - Re: [PATCH v10 00/30] Add KVM LoongArch support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 21 May 2023 19:17:47 +0800
From:   Xi Ruoyao <xry111@...111.site>
To:     WANG Xuerui <kernel@...0n.name>, maobibo <maobibo@...ngson.cn>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Huacai Chen <chenhuacai@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
        Mark Brown <broonie@...nel.org>,
        Alex Deucher <alexander.deucher@....com>,
        Oliver Upton <oliver.upton@...ux.dev>,
        Tianrui Zhao <zhaotianrui@...ngson.cn>
Subject: Re: [PATCH v10 00/30] Add KVM LoongArch support

On Sun, 2023-05-21 at 18:22 +0800, WANG Xuerui wrote:

/* snip */

> (BTW, how do people usually deal with pre-release hardware wit 
> documentation not out yet? I suppose similar situations like this should 
> turn up fairly often.)

Intel normally releases the doc much earlier than shipping the hardware
to customers.  For example, the x86 Linear Address Masking doc has been
released in 2020 (allowing Linus himself to hack the LAM code in kernel
:), but AFAIK there is no Intel CPU models released with LAM support yet
(at least my Raptor Lake does not indicate LAM in cpuid, or maybe I'm
missing the latest server models?)

For other vendors I'm not sure.

> Aside from this, there's another point: use of undocumented instructions 
> in raw form with ".word". This currently doesn't work in LLVM/Clang, 

Hmm, is it an inherent limitation of Clang or it's simply not
implemented for LoongArch yet?  On x86_64 I tried ".byte 0x90" in the
inline assembly and Clang correctly emits a nop instruction.

> thus will slightly set back the ongoing ClangBuiltLinux enablement 
> effort (currently all such usages in arch/loongarch are related to 
> "invtlb" which has perfect support, and can be removed). AFAIK, such 
> practice dates back to the LoongISA times, when the Loongson extended 
> opcodes weren't supported by the upstream MIPS toolchains for some 
> reason; but LoongArch is independent and not bounded by anyone else now, 
> so it's better in terms of maintainability to just add the instructions 
> to the toolchains. People will not be inconvenienced by having to use 
> bleeding-edge LoongArch toolchains because upstream LoongArch devs have 
> always been doing this.

Or it may be resolved by some fancy #ifdef directives.

-- 
Xi Ruoyao <xry111@...111.site>
School of Aerospace Science and Technology, Xidian University