On Tue, 8 Jul 2025 at 18:25, Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Tue, Jul 08, 2025, Fuad Tabba wrote: > > > > I don't think we need a flag to preserve memory as I mentioned in [2]. IIUC, > > > > 1) Conversions are always content-preserving for pKVM. > > > > > > No? Perserving contents on private => shared is a security vulnerability waiting > > > to happen. > > > > Actually it is one of the requirements for pKVM as well as its current > > behavior. We would like to preserve contents both ways, private <=> > > shared, since it is required by some of the potential use cases (e.g., > > guest handling video encoding/decoding). > > > > To make it clear, I'm talking about explicit sharing from the guest, > > not relinquishing memory back to the host. In the case of > > relinquishing (and guest teardown), relinquished memory is poisoned > > (zeroed) in pKVM. > > I forget, what's the "explicit sharing" flow look like? E.g. how/when does pKVM > know it's ok to convert memory from private to shared? I think we'd still want > to make data preservation optional, e.g. to avoid potential leakage with setups > where memory is private by default, but a flag in KVM's uAPI might not be a good > fit since whether or not to preserve data is more of a guest decision (or at least > needs to be ok'd by the guest). In pKVM all sharing and unsharing is triggered by the guest via hypercalls. The host cannot unshare. That said, making data preservation optional works for pKVM and is a good idea, for the reasons that you've mentioned. Cheers, /fuad
