[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal for physical address based hypercalls



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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.