On Mon, Jun 20, 2022 at 09:21:11AM +0200, Andrew Jones 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. Ah, never mind... I see SBI is limited to 6 registers, but of course it only needs one register to pass the uc address... We can make UCALL_MAX_ARGS whatever we want. Thanks, drew _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
