On 28/09/2022 11:38, Jan Beulich wrote: > As an alternative I'd like to propose the introduction of a bit (or multiple > ones, see below) augmenting the hypercall number, to control the flavor of the > buffers used for every individual hypercall. This would likely involve the > introduction of a new hypercall page (or multiple ones if more than one bit is > to be used), to retain the present abstraction where it is the hypervisor > which > actually fills these pages.
There are other concerns which need to be accounted for. Encrypted VMs cannot use a hypercall page; they don't trust the hypervisor in the first place, and the hypercall page is (specifically) code injection. So the sensible new ABI cannot depend on a hypercall table. Also, rewriting the hypercall page on migrate turns out not to have been the most clever idea, and only works right now because the instructions are the same length in the variations for each mode. Also continuations need to change to avoid userspace liveness problems, and existing hypercalls that we do have need splitting between things which are actually privileged operations (within the guest context) and things which are logical control operations, so the kernel can expose the latter to userspace without retaining the gaping root hole which is /dev/xen/privcmd, and a blocker to doing UEFI Secureboot. So yes, starting some new clean(er) interface from hypercall 64 is the plan, but it very much does not want to be a simple mirror of the existing 0-63 with a differing calling convention. ~Andrew
