All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: "Andrea Parri (Microsoft)" <parri.andrea@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>,
	KY Srinivasan <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Stephen Hemminger <sthemmin@microsoft.com>,
	Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
	Michael Kelley <mikelley@microsoft.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Peter Anvin <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	iommu@lists.linux.dev, linux-hyperv@vger.kernel.org,
	x86@kernel.org
Subject: Re: [RFC PATCH 2/2] dma-direct: Fix dma_direct_{alloc,free}() for Hyperv-V IVMs
Date: Thu, 7 Jul 2022 07:58:40 +0200	[thread overview]
Message-ID: <20220707055840.GA13401@lst.de> (raw)
In-Reply-To: <20220706195027.76026-3-parri.andrea@gmail.com>

On Wed, Jul 06, 2022 at 09:50:27PM +0200, Andrea Parri (Microsoft) wrote:
> @@ -305,6 +306,21 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>  		ret = page_address(page);
>  		if (dma_set_decrypted(dev, ret, size))
>  			goto out_free_pages;
> +#ifdef CONFIG_HAS_IOMEM
> +		/*
> +		 * Remap the pages in the unencrypted physical address space
> +		 * when dma_unencrypted_base is set (e.g., for Hyper-V AMD
> +		 * SEV-SNP isolated guests).
> +		 */
> +		if (dma_unencrypted_base) {
> +			phys_addr_t ret_pa = virt_to_phys(ret);
> +
> +			ret_pa += dma_unencrypted_base;
> +			ret = memremap(ret_pa, size, MEMREMAP_WB);
> +			if (!ret)
> +				goto out_encrypt_pages;
> +		}
> +#endif


So:

this needs to move into dma_set_decrypted, otherwise we don't handle
the dma_alloc_pages case (never mind that this is pretty unreadable).

Which then again largely duplicates the code in swiotlb.  So I think
what we need here is a low-level helper that does the
set_memory_decrypted and memremap.  I'm not quite sure where it
should go, but maybe some of the people involved with memory
encryption might have good ideas.  unencrypted_base should go with
it and then both swiotlb and dma-direct can call it.

> +	/*
> +	 * If dma_unencrypted_base is set, the virtual address returned by
> +	 * dma_direct_alloc() is in the vmalloc address range.
> +	 */
> +	if (!dma_unencrypted_base && is_vmalloc_addr(cpu_addr)) {
>  		vunmap(cpu_addr);
>  	} else {
>  		if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED))
>  			arch_dma_clear_uncached(cpu_addr, size);
> +#ifdef CONFIG_HAS_IOMEM
> +		if (dma_unencrypted_base) {
> +			memunmap(cpu_addr);
> +			/* re-encrypt the pages using the original address */
> +			cpu_addr = page_address(pfn_to_page(PHYS_PFN(
> +					dma_to_phys(dev, dma_addr))));
> +		}
> +#endif
>  		if (dma_set_encrypted(dev, cpu_addr, size))

Same on the unmap side.  It might also be worth looking into reordering
the checks in some form instead o that raw dma_unencrypted_base check
before the unmap.

  reply	other threads:[~2022-07-07  5:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-06 19:50 [RFC PATCH 0/2] dma_direct_{alloc,free}() for Hyper-V IVMs Andrea Parri (Microsoft)
2022-07-06 19:50 ` [RFC PATCH 1/2] swiotlb,dma-direct: Move swiotlb_unencrypted_base to direct.c Andrea Parri (Microsoft)
2022-07-06 19:50 ` [RFC PATCH 2/2] dma-direct: Fix dma_direct_{alloc,free}() for Hyperv-V IVMs Andrea Parri (Microsoft)
2022-07-07  5:58   ` Christoph Hellwig [this message]
2022-07-07 14:20     ` Andrea Parri

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=20220707055840.GA13401@lst.de \
    --to=hch@lst.de \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=decui@microsoft.com \
    --cc=haiyangz@microsoft.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=iommu@lists.linux.dev \
    --cc=kys@microsoft.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mikelley@microsoft.com \
    --cc=mingo@redhat.com \
    --cc=parri.andrea@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=sthemmin@microsoft.com \
    --cc=tglx@linutronix.de \
    --cc=wei.liu@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.