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]

Message-ID: <90b2fc60-af26-4ba6-f775-7db2514a62f4@xen0n.name>
Date:   Mon, 22 May 2023 10:37:26 +0800
From:   WANG Xuerui <kernel@...0n.name>
To:     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>,
        Xi Ruoyao <xry111@...111.site>,
        Tianrui Zhao <zhaotianrui@...ngson.cn>
Subject: Re: [PATCH v10 00/30] Add KVM LoongArch support

On 2023/5/22 09:39, maobibo wrote:
> 
> 
> 在 2023/5/21 18:22, WANG Xuerui 写道:
>> On 2023/5/18 10:56, maobibo 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.)
> Manual is actually one issue, however it does not prevent the review
> process. There are some drivers for *fruit* devices, I can not find
> the hw manual also.  With the manual, it helps to review and points
> out the further and detailed issues.

There's a *slight* difference: the certain vendor you've mentioned is 
historically uncooperative in providing the documentation, so outside 
contributors had to reverse-engineer and document the HW themselves; but 
in Loongson's case, you *are* the vendor, so you are probably in a 
position that can make everyone's life easier by at least pushing for 
the docs release...

>>
>> Aside from this, there's another point: use of undocumented instructions in raw form with ".word". This currently doesn't work in LLVM/Clang <snip>
> As for one new architecture, it is normal to use .word or .insn, instruction
> will update for the first few years and also compiler may be not supported
> timely. The other arch has the same phenomenon if you grep "\.insn", also
> llvm on LoongArch supports ".word" directives.
> 
> After three or five years, we will remove these ".insn" macro when hw and
> compiler is matured.

Sorry for the confusion at my side; `.word` certainly works, what 
doesn't work currently seems to be the `parse_r` helper. I know because 
I've tried in the last week with latest LLVM/Clang snapshot. And you 
can't write ergonomic inline asm with proper register allocator 
awareness without the helper; the LoongArch assembler isn't capable of 
assembling in a certain encoding format. With RISC-V `.insn` you can do 
things like `.insn r 0xNN, 0, 0, a0, a1, a2`, but you cannot simply e.g. 
express gcsrxchg with `.insn DJK 0x05000000, a0, a1, a2` because no such 
instruction format convention has been standardized. (The notation 
demonstrated here is taken from [1].)

In any case, it seems best to at least wait for the documentation 
release a little bit, or you should state clearly that this is not going 
to happen soon, so people can properly manage their expectation and 
prioritize. (For example, if I know docs and/or assembler support for 
the virtualization extension won't come soon, then I'd work on 
supporting the .word idiom before other things. Otherwise there are more 
important things than that.)

[1]: https://github.com/loongson/LoongArch-Documentation/pull/56

-- 
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/