On Mon, Mar 11, 2024 at 9:26 AM Fuad Tabba <ta...@google.com> wrote: > > Hi, > > On Fri, Mar 8, 2024 at 9:05 PM Manwaring, Derek <dere...@amazon.com> wrote: > > > > On 2024-03-08 at 10:46-0700, David Woodhouse wrote: > > > On Fri, 2024-03-08 at 09:35 -0800, David Matlack wrote: > > > > I think what James is looking for (and what we are also interested > > > > in), is _eliminating_ the ability to access guest memory from the > > > > direct map entirely. And in general, eliminate the ability to access > > > > guest memory in as many ways as possible. > > > > > > Well, pKVM does that... > > > > Yes we've been looking at pKVM and it accomplishes a lot of what we're > > trying > > to do. Our initial inclination is that we want to stick with VHE for the > > lower > > overhead. We also want flexibility across server parts, so we would need to > > get pKVM working on Intel & AMD if we went this route. > > > > Certainly there are advantages of pKVM on the perf side like the in-place > > memory sharing rather than copying as well as on the security side by simply > > reducing the TCB. I'd be interested to hear others' thoughts on pKVM vs > > memfd_secret or general ASI. > > The work we've done for pKVM is still an RFC [*], but there is nothing > in it that limits it to nVHE (at least not intentionally). It should > work with VHE and hVHE as well. On respinning the patch series [*], we > plan on adding support for normal VMs to use guest_memfd() as well in > arm64, mainly for testing, and to make it easier for others to base > their work on it.
Just to clarify, I am referring specifically to the work we did in porting guest_memfd() to pKVM/arm64. pKVM itself works only in nVHE mode. > > Cheers, > /fuad > > [*] https://lore.kernel.org/all/20240222161047.402609-1-ta...@google.com > > > > Derek > >
