On 27/08/2019 11:44, Andrew Cooper wrote: >> I was also uncertain about the new cache_flush_permitted() instance - >> generally I think it wouldn't be too bad if we allowed line flushes in >> all cases, in which case the checks in the ->wbinvd_intercept() handlers >> would suffice (as they did until now). > This is a more general issue which we need to address. To support > encrypted memory in VM's, we must guarantee that WC mappings which the > guest creates are really WC, which means we must not use IPAT or play > any "fall back to WB" games. > > Furthermore, AMD's encrypt-in-place algorithm requires the guest to be > able to use WBINVD.
Based on some feedback, the encrypt-in-place algorithm is only for native situations trying to use SME, where the loading kernel/hypervisor needs to encrypt itself. SEV guests run encrypted from the start, and have no need to encrypt/decrypt in place. The expected way is to copy between an encrypted and non-encrypted buffer in separate GFNs. The WBINVD is to ensure that dirty cache lines aren't corrupted by the WP mapping, and CLFLUSH (or any equivalent full eviction) can be substituted, but for the intended usecase, a single WBINVD is the optimum strategy. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
