On 8/23/21 7:36 AM, Brijesh Singh wrote:
> On 8/23/21 9:20 AM, Dave Hansen wrote:
>> On 8/20/21 8:58 AM, Brijesh Singh wrote:
>>> +static int handle_split_page_fault(struct vm_fault *vmf)
>>> +{
>>> + if (!IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT))
>>> + return VM_FAULT_SIGBUS;
>>> +
>>> + __split_huge_pmd(vmf->vma, vmf->pmd, vmf->address, false, NULL);
>>> + return 0;
>>> +}
>>
>> We had a whole conversation the last time this was posted about huge
>> page types *other* than THP. I don't see any comprehension of those
>> types or what would happen if one of those was used with SEV-SNP.
>>
>> What was the result of those review comments?
>
> Based on previous review comments Sean was not keen on KVM having
> perform this detection and abort the guest SEV-SNP VM launch. So, I
> didn't implemented the check and waiting for more discussion before
> going at it.
OK. But, you need to *acknowledge* the situation somewhere. Maybe the
cover letter of the series, maybe in this changelog.
As it stands, it looks like you're simply ignoring _some_ reviewer feedback.
> SEV-SNP guest requires the VMM to register the guest backing pages
> before the VM launch. Personally, I would prefer KVM to check the
> backing page type during the registration and fail to register if its
> hugetlbfs (and others) to avoid us get into situation where we could not
> split the hugepage.
It *has* to be done in KVM, IMNHO.
The core kernel really doesn't know much about SEV. It *really* doesn't
know when its memory is being exposed to a virtualization architecture
that doesn't know how to split TLBs like every single one before it.
This essentially *must* be done at the time that the KVM code realizes
that it's being asked to shove a non-splittable page mapping into the
SEV hardware structures.
The only other alternative is raising a signal from the fault handler
when the page can't be split. That's a *LOT* nastier because it's so
much later in the process.
It's either that, or figure out a way to split hugetlbfs (and DAX)
mappings in a failsafe way.
