[PATCH 4/6] virt: bao: Add Bao I/O dispatcher driver

[João Peixoto]

On 1/14/26 20:32, Andrew Jones wrote:
> On Wed, Jan 07, 2026 at 04:28:27PM +0000,joaopeixoto at osyx.tech wrote:
> ...
>> diff --git a/arch/riscv/include/asm/bao.h b/arch/riscv/include/asm/bao.h
>> index 35658f37e1bd..f04e6cd33fa9 100644
>> --- a/arch/riscv/include/asm/bao.h
>> +++ b/arch/riscv/include/asm/bao.h
>> @@ -14,6 +14,7 @@
>>   #define __ASM_RISCV_BAO_H
>>   
>>   #include <asm/sbi.h>
>> +#include <linux/bao.h>
>>   
>>   #define BAO_SBI_EXT_ID 0x08000ba0
>>   
>> @@ -28,4 +29,33 @@ static inline unsigned long bao_ipcshmem_hypercall(unsigned long hypercall_id,
>>   	return ret.error;
>>   }
>>   
>> +static inline unsigned long
>> +bao_remio_hypercall(struct bao_remio_hypercall_ctx *ctx)
>> +{
>> +	register uintptr_t a0 asm("a0") = (uintptr_t)(ctx->dm_id);
>> +	register uintptr_t a1 asm("a1") = (uintptr_t)(ctx->addr);
>> +	register uintptr_t a2 asm("a2") = (uintptr_t)(ctx->op);
>> +	register uintptr_t a3 asm("a3") = (uintptr_t)(ctx->value);
>> +	register uintptr_t a4 asm("a4") = (uintptr_t)(ctx->request_id);
>> +	register uintptr_t a5 asm("a5") = (uintptr_t)(0);
>> +	register uintptr_t a6 asm("a6") = (uintptr_t)(BAO_REMIO_HYPERCALL_ID);
>> +	register uintptr_t a7 asm("a7") = (uintptr_t)(0x08000ba0);
>                                                        ^ BAO_SBI_EXT_ID
>
> Using the experimental extension ID space would be fine for an RFC, but
> this can't be merged until an SBI implementation ID for Bao is added to
> the RISC-V SBI spec. Then the Bao EID would be '0xA000000 | <Bao-IMP-ID>'
Understood. For now the RISC-V backend uses the experimental extension 
space,
and I have made that explicit: BAO_SBI_EXT_ID carries a comment noting a
permanent EID must be assigned through the SBI spec before RISC-V can be
considered stable, and I am marking this revision RFC for that reason. I 
will
start the process of getting a Bao implementation ID registered and 
switch to
'0xA000000 | <Bao-IMP-ID>' once it is assigned.
> I think we'll also need to discuss whether or not firmware/hypervisor-
> specific extensions are exempt from all rules in chapter 3 of the SBI
> spec other than a7 being the EID. If not, then this function should
> just call __sbi_ecall() and the Bao hypercalls will not be allowed to
> modify any registers except a0 and a1.
>
>> +
>> +	asm volatile("ecall"
>> +		     : "+r"(a0), "+r"(a1), "+r"(a2), "+r"(a3), "+r"(a4),
>> +		       "+r"(a5), "+r"(a6), "+r"(a7)
>> +		     : "r"(a0), "r"(a1), "r"(a2), "r"(a3), "r"(a4), "r"(a5),
>> +		       "r"(a6), "r"(a7)
>> +		     : "memory");
>> +
>> +	ctx->addr = a2;
>> +	ctx->op = a3;
>> +	ctx->value = a4;
>> +	ctx->access_width = a5;
>> +	ctx->request_id = a6;
>> +	ctx->npend_req = a7;
>> +
>> +	return a0;
>> +}
> Thanks,
> drew
Good point, and I would value your view before I respin the ABI. The Remote
I/O hypercall currently returns several values in a2-a7, which does violate
the calling convention if Bao extensions must follow chapter 3. If they 
must,
I will change the hypervisor-side ABI so the call only returns via a0/a1 and
move the extra results into a shared-memory region, then switch the helper
to __sbi_ecall(). Since that is a hypervisor ABI change I would rather agree
the direction first. Do you know of precedent for hypervisor/firmware
extensions being exempted here, or should I assume the full chapter-3 rules
apply?

(Separately, I removed the redundant input constraints from the ecall asm -
the operands are already "+r", so the extra "r" inputs were unnecessary.)