Re: [PATCH 3/9] x86/hyperv: Mark Hyper-V vp assist page unencrypted in SEV-SNP enlightened guest

[Tianyu Lan]

On 6/5/2023 8:13 PM, Vitaly Kuznetsov wrote:
> > @@ -113,6 +114,11 @@ static int hv_cpu_init(unsigned int cpu)
> >   
> >   	}
> >   	if (!WARN_ON(!(*hvp))) {
> > +		if (hv_isolation_type_en_snp()) {
> > +			WARN_ON_ONCE(set_memory_decrypted((unsigned long)(*hvp), 1));
> > +			memset(*hvp, 0, PAGE_SIZE);
> > +		}
> Why do we need to set the page as decrypted here and not when we
> allocate the page (a few lines above)?

If Linux root partition boots in the SEV-SNP guest, the page still needs 
to be decrypted.

> And why do we need to clear it
> _after_  we made it decrypted? In case we care about not leaking the
> stale content to the hypervisor, we should've cleared it_before_, but
> the bigger problem I see is that memset() is problemmatic e.g. for KVM
> which uses enlightened VMCS. You put a CPU offline and then back online
> and this path will be taken. Clearing VP assist page will likely brake
> things. (AFAIU SEV-SNP Hyper-V guests don't expose SVM yet so the
> problem is likely theoretical only, but still).

The page will be made dirt by hardware after decrypting operation and so 
memset the page after that.