lkml.org 
[lkml]   [2023]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v10 00/30] Add KVM LoongArch support
From
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/

\
 
 \ /
  Last update: 2023-05-22 04:38    [W:0.599 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site