Re: Proposal for physical address based hypercalls

["dpsmith.dev" <dpsmith.dev@xxxxxxxxx>]

On 9/28/22 06:38, Jan Beulich wrote:
> For quite some time we've been talking about replacing the present virtual
> address based hypercall interface with one using physical addresses.  This is in
> particular a prerequisite to being able to support guests with encrypted
> memory, as for such guests we cannot perform the page table walks necessary to
> translate virtual to (guest-)physical addresses.  But using (guest) physical
> addresses is also expected to help performance of non-PV guests (i.e. all Arm
> ones plus HVM/PVH on x86), because of the no longer necessary address
> translation.
Greetings Jan,

I think there are multiple issues in play here, but the two major ones 
are 1.) eliminating the use of guest virtual addresses and 2.) handling 
the change in the security model for hypercalls from encrypted VMs. As 
Andy was pointing out, attempting to address (1) in a backwards 
compatible approach will likely not arrive at a solution that can 
address issue (2). IMHO, the only result from teaching the existing ABI 
to speak GPAs instead of VAs will be to break current and new kernels of 
the habit of using VAs. Beyond that I do not see how it will do anything 
to prepare current OS kernels for running as encrypted VMs, at least for 
AMD since that is the specification I have been focused on studying the 
last couple of months.
As for ABIv2, I understand and can appreciate Andy's desired approach. 
Recently, especially with the hardware changes being introduced by SEV, 
I would like to have considered a naive and more radical approach. 
Currently hypercalls function using a more ioctl style. I would like to 
suggest that a packet style interface similar to netlink be considered. 
There are many benefits to adopting this type of interface that could be 
covered in a larger RFC if there was any sense of willingness to 
consider it. As a glimpse, a few benefits would be that arbitrary 
buffers, continuations/asynchronous calls, and multi-call are all 
natural consequence. It would also allow advanced extensions, such as an 
optional PF_RING-like interface for zero-copy messaging from guest 
user-space to hypervisor. While a packet interface could easily co-exist 
with the existing ioctl-style interface, it would be a paradigm shift 
from the past, though I feel ABIv2 was already going to be such a shift. 
Anyway, just my 2¢.
V/r,
DPS