linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
To: Vishal Annapurve <vannapurve@google.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	pbonzini@redhat.com, rientjes@google.com, seanjc@google.com,
	erdemaktas@google.com, ackerleytng@google.com, jxgao@google.com,
	sagis@google.com, oupton@google.com, peterx@redhat.com,
	vkuznets@redhat.com, dmatlack@google.com, pgonda@google.com,
	michael.roth@amd.com, kirill@shutemov.name,
	thomas.lendacky@amd.com, dave.hansen@linux.intel.com,
	linux-coco@lists.linux.dev, chao.p.peng@linux.intel.com,
	isaku.yamahata@gmail.com, andrew.jones@linux.dev, corbet@lwn.net,
	hch@lst.de, m.szyprowski@samsung.com, rostedt@goodmis.org,
	iommu@lists.linux.dev
Subject: Re: [RFC V1 5/5] x86: CVMs: Ensure that memory conversions happen at 2M alignment
Date: Fri, 2 Feb 2024 09:00:07 +0100	[thread overview]
Message-ID: <3313c886-e964-48c3-8277-b47cb1955de9@linux.microsoft.com> (raw)
In-Reply-To: <CAGtprH8r0kYYqGoumsVeZq42cX8CN3cchkuRYhQULqtb-1nKww@mail.gmail.com>

On 02/02/2024 06:08, Vishal Annapurve wrote:
> On Thu, Feb 1, 2024 at 5:32 PM Jeremi Piotrowski
> <jpiotrowski@linux.microsoft.com> wrote:
>>
>> On 01/02/2024 04:46, Vishal Annapurve wrote:
>>> On Wed, Jan 31, 2024 at 10:03 PM Dave Hansen <dave.hansen@intel.com> wrote:
>>>>
>>>> On 1/11/24 21:52, Vishal Annapurve wrote:
>>>>> @@ -2133,8 +2133,10 @@ static int __set_memory_enc_pgtable(unsigned long addr, int numpages, bool enc)
>>>>>       int ret;
>>>>>
>>>>>       /* Should not be working on unaligned addresses */
>>>>> -     if (WARN_ONCE(addr & ~PAGE_MASK, "misaligned address: %#lx\n", addr))
>>>>> -             addr &= PAGE_MASK;
>>>>> +     if (WARN_ONCE(addr & ~HPAGE_MASK, "misaligned address: %#lx\n", addr)
>>>>> +             || WARN_ONCE((numpages << PAGE_SHIFT) & ~HPAGE_MASK,
>>>>> +                     "misaligned numpages: %#lx\n", numpages))
>>>>> +             return -EINVAL;
>>>>
>>>> This series is talking about swiotlb and DMA, then this applies a
>>>> restriction to what I *thought* was a much more generic function:
>>>> __set_memory_enc_pgtable().  What prevents this function from getting
>>>> used on 4k mappings?
>>>>
>>>>
>>>
>>> The end goal here is to limit the conversion granularity to hugepage
>>> sizes. SWIOTLB allocations are the major source of unaligned
>>> allocations(and so the conversions) that need to be fixed before
>>> achieving this goal.
>>>
>>> This change will ensure that conversion fails for unaligned ranges, as
>>> I don't foresee the need for 4K aligned conversions apart from DMA
>>> allocations.
>>
>> Hi Vishal,
>>
>> This assumption is wrong. set_memory_decrypted is called from various
>> parts of the kernel: kexec, sev-guest, kvmclock, hyperv code. These conversions
>> are for non-DMA allocations that need to be done at 4KB granularity
>> because the data structures in question are page sized.
>>
>> Thanks,
>> Jeremi
> 
> Thanks Jeremi for pointing out these usecases.
> 
> My brief analysis for these call sites:
> 1) machine_kexec_64.c, realmode/init.c, kvm/mmu/mmu.c - shared memory
> allocation/conversion happens when host side memory encryption
> (CC_ATTR_HOST_MEM_ENCRYPT) is enabled.
> 2) kernel/kvmclock.c -  Shared memory allocation can be made to align
> 2M even if the memory needed is lesser.
> 3) drivers/virt/coco/sev-guest/sev-guest.c,
> drivers/virt/coco/tdx-guest/tdx-guest.c - Shared memory allocation can
> be made to align 2M even if the memory needed is lesser.
> 
> I admit I haven't analyzed hyperv code in context of these changes,
> but will take a better look to see if the calls for memory conversion
> here can fit the category of "Shared memory allocation can be made to
> align 2M even if the memory needed is lesser".
> 
> Agree that this patch should be modified to look something like
> (subject to more changes on the call sites)

No, this patch is still built on the wrong assumptions. You're trying
to alter a generic function in the guest for the constraints of a very
specific hypervisor + host userspace + memory backend combination.
That's not right.

Is the numpages check supposed to ensure that the guest *only* toggles
visibility in chunks of 2MB? Then you're exposing more memory to the host
than the guest intends.

If you must - focus on getting swiotlb conversions to happen at the desired
granularity but don't try to force every single conversion to be >4K.

Thanks,
Jeremi


> 
> =============
> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> index e9b448d1b1b7..8c608d6913c4 100644
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@ -2132,10 +2132,15 @@ static int __set_memory_enc_pgtable(unsigned
> long addr, int numpages, bool enc)
>         struct cpa_data cpa;
>         int ret;
> 
>         /* Should not be working on unaligned addresses */
>         if (WARN_ONCE(addr & ~PAGE_MASK, "misaligned address: %#lx\n", addr))
>                 addr &= PAGE_MASK;
> 
> +       if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
> +               (WARN_ONCE(addr & ~HPAGE_MASK, "misaligned address:
> %#lx\n", addr)
> +                       || WARN_ONCE((numpages << PAGE_SHIFT) & ~HPAGE_MASK,
> +                               "misaligned numpages: %#lx\n", numpages)))
> +               return -EINVAL;
> +
>         memset(&cpa, 0, sizeof(cpa));
>         cpa.vaddr = &addr;
>         cpa.numpages = numpages;


  reply	other threads:[~2024-02-02  8:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-12  5:52 [RFC V1 0/5] x86: CVMs: Align memory conversions to 2M granularity Vishal Annapurve
2024-01-12  5:52 ` [RFC V1 1/5] swiotlb: Support allocating DMA memory from SWIOTLB Vishal Annapurve
2024-02-14 14:49   ` Kirill A. Shutemov
2024-02-15  3:33     ` Vishal Annapurve
2024-02-15  9:44       ` Alexander Graf
2024-02-15 20:26         ` Michael Kelley
2024-02-24 17:07           ` Vishal Annapurve
2024-02-24 22:02             ` Michael Kelley
2024-03-05 17:19         ` Vishal Annapurve
2024-01-12  5:52 ` [RFC V1 2/5] swiotlb: Allow setting up default alignment of SWIOTLB region Vishal Annapurve
2024-01-12  5:52 ` [RFC V1 3/5] x86: CVMs: Enable dynamic swiotlb by default for CVMs Vishal Annapurve
2024-02-01 12:20   ` Jeremi Piotrowski
2024-02-02  4:40     ` Vishal Annapurve
2024-01-12  5:52 ` [RFC V1 4/5] x86: CVMs: Allow allocating all DMA memory from SWIOTLB Vishal Annapurve
2024-01-31 16:17   ` Dave Hansen
2024-02-01  3:41     ` Vishal Annapurve
2024-01-12  5:52 ` [RFC V1 5/5] x86: CVMs: Ensure that memory conversions happen at 2M alignment Vishal Annapurve
2024-01-31 16:33   ` Dave Hansen
2024-02-01  3:46     ` Vishal Annapurve
2024-02-01 12:02       ` Jeremi Piotrowski
2024-02-02  5:08         ` Vishal Annapurve
2024-02-02  8:00           ` Jeremi Piotrowski [this message]
2024-02-02 16:22             ` Vishal Annapurve
2024-02-02 16:35               ` Dave Hansen
2024-02-03  5:19                 ` Vishal Annapurve
2024-01-30 16:42 ` [RFC V1 0/5] x86: CVMs: Align memory conversions to 2M granularity Vishal Annapurve
2024-01-31 16:52 ` Dave Hansen
2024-02-01  5:44   ` Vishal Annapurve

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3313c886-e964-48c3-8277-b47cb1955de9@linux.microsoft.com \
    --to=jpiotrowski@linux.microsoft.com \
    --cc=ackerleytng@google.com \
    --cc=andrew.jones@linux.dev \
    --cc=chao.p.peng@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dmatlack@google.com \
    --cc=erdemaktas@google.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux.dev \
    --cc=isaku.yamahata@gmail.com \
    --cc=jxgao@google.com \
    --cc=kirill@shutemov.name \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=michael.roth@amd.com \
    --cc=oupton@google.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=pgonda@google.com \
    --cc=rientjes@google.com \
    --cc=rostedt@goodmis.org \
    --cc=sagis@google.com \
    --cc=seanjc@google.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vannapurve@google.com \
    --cc=vkuznets@redhat.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).