On 8/23/21 7:36 AM, Brijesh Singh wrote:

On 8/23/21 9:20 AM, Dave Hansen wrote:

quoted

On 8/20/21 8:58 AM, Brijesh Singh wrote:

quoted

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