[FMV] Explicit allows different vendors share the bit definition of __riscv_vendor_feature_bits

[cyyself]

In PR #74, we design vendor extension is guarded by vendorID. However, here we missed some cases like:

1. A SoC vendor buys a CPU IP from another CPU IP vendor with some modification to CPU RTL and then fills marchid with itself mvendorid
2. A SoC vendor uses multiple CPU IPs from different vendors for their SoC and customizes the CPU IP to have the same vendor extension, which multiple CPU IPs have different mvendorid

These cases are discussed from Linux Kernel mailing list on hwprobe support for T-HEAD vendor extensions thread. I think their concerns are right.

So we might need to make the __riscv_vendor_feature_bits not guarded by mvendorid. Since this hasn't been specified in the c-api-doc currently, it's not too late to make this change.

[cyyself]

cc @kito-cheng @BeMg @ConchuOD @charlie-rivos @evangreen

[jrtc27]

I agree the current interface is insufficient. One option would be to have __riscv_vendor_feature_bits be a list of (vendor, pointer) pairs, where the pointer points to an individual instance of what __riscv_vendor_feature_bits is today (i.e. the per-vendor bits). But for now we should just remove __riscv_vendor_feature_bits from the spec now and come up with a fixed solution in future.

[kito-cheng]

Yeah, I agree to remove that for now since we don't have any vendor bits yet. so maybe we postpone that a little bit is best way.

@cyyself could you create a PR to drop that? and then we could have few more time to discuss the mechanism.

[cyyself]

Yeah, I agree to remove that for now since we don't have any vendor bits yet. so maybe we postpone that a little bit is best way.

@cyyself could you create a PR to drop that? and then we could have few more time to discuss the mechanism.

OK. But it’s too late at UTC+8. Maybe I will do that tomorrow.

[cyyself]

One option would be to have __riscv_vendor_feature_bits be a list of (vendor, pointer) pairs, where the pointer points to an individual instance of what __riscv_vendor_feature_bits is today (i.e. the per-vendor bits).

A minor concern is that we might need a mechanism to allocate memory for each individual instance for each vendor extension set in an IFUNC resolver, which will be called from __init_riscv_cpu_feature_bits. A simple solution might be to allocate a fixed number of these objects, like 4 or 8, which is enough.