Re: [PATCH v10 00/30] Add KVM LoongArch support
From: WANG Xuerui
Date: Sun May 21 2023 - 22:37:39 EST
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/