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).
