On Mon, Jun 20, 2022 at 12:51 PM Andrew Jones <drjones@xxxxxxxxxx> wrote: > > On Sat, Jun 18, 2022 at 12:09:11AM +0000, Sean Christopherson wrote: > > On Fri, Jun 17, 2022, Colton Lewis wrote: > > > On Thu, Jun 16, 2022 at 02:10:06PM +0200, Andrew Jones wrote: > > > > We probably want to ensure all architectures are good with this. afaict, > > > > riscv only expects 6 args and uses UCALL_MAX_ARGS to cap the ucall inputs, > > > > for example. > > > > > > All architectures use UCALL_MAX_ARGS for that. Are you saying there > > > might be limitations beyond the value of the macro? If so, who should > > > verify whether this is ok? > > > > I thought there were architectural limitations too, but I believe I was thinking > > of vcpu_args_set(), where the number of params is limited by the function call > > ABI, e.g. the number of registers. > > > > Unless there's something really, really subtle going on, all architectures pass > > the actual ucall struct purely through memory. Actually, that code is ripe for > > deduplication, and amazingly it doesn't conflict with Colton's series. Patches > > incoming... > > > > RISC-V uses sbi_ecall() for their implementation of ucall(). CC'ing Anup > for confirmation, but if I understand the SBI spec correctly, then inputs > are limited to registers a0-a5. Yes, we only have 6 parameters in ucall() since it is based on SBI spec. Actually, a6 and a7 are used to identify the type of SBI call (i.e. extension and function number) whereas a0-a5 are function parameters. Regards, Anup > > Thanks, > drew > _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
