[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 10/13] x86/Swiotlb: Add Swiotlb bounce buffer remap function for HV IVM



On Wed, Jul 28, 2021 at 10:52:25AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan <Tianyu.Lan@xxxxxxxxxxxxx>
> 
> In Isolation VM with AMD SEV, bounce buffer needs to be accessed via
> extra address space which is above shared_gpa_boundary
> (E.G 39 bit address line) reported by Hyper-V CPUID ISOLATION_CONFIG.
> The access physical address will be original physical address +
> shared_gpa_boundary. The shared_gpa_boundary in the AMD SEV SNP
> spec is called virtual top of memory(vTOM). Memory addresses below
> vTOM are automatically treated as private while memory above
> vTOM is treated as shared.
> 
> Use dma_map_decrypted() in the swiotlb code, store remap address returned
> and use the remap address to copy data from/to swiotlb bounce buffer.
> 
> Signed-off-by: Tianyu Lan <Tianyu.Lan@xxxxxxxxxxxxx>
> ---
>  include/linux/swiotlb.h |  4 ++++
>  kernel/dma/swiotlb.c    | 11 ++++++++---
>  2 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> index f507e3eacbea..584560ecaa8e 100644
> --- a/include/linux/swiotlb.h
> +++ b/include/linux/swiotlb.h
> @@ -72,6 +72,9 @@ extern enum swiotlb_force swiotlb_force;
>   * @end:     The end address of the swiotlb memory pool. Used to do a quick
>   *           range check to see if the memory was in fact allocated by this
>   *           API.
> + * @vaddr:   The vaddr of the swiotlb memory pool. The swiotlb
> + *           memory pool may be remapped in the memory encrypted case and 
> store
> + *           virtual address for bounce buffer operation.
>   * @nslabs:  The number of IO TLB blocks (in groups of 64) between @start and
>   *           @end. For default swiotlb, this is command line adjustable via
>   *           setup_io_tlb_npages.
> @@ -89,6 +92,7 @@ extern enum swiotlb_force swiotlb_force;
>  struct io_tlb_mem {
>       phys_addr_t start;
>       phys_addr_t end;
> +     void *vaddr;
>       unsigned long nslabs;
>       unsigned long used;
>       unsigned int index;
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 1fa81c096c1d..6866e5784b53 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -194,8 +194,13 @@ static void swiotlb_init_io_tlb_mem(struct io_tlb_mem 
> *mem, phys_addr_t start,
>               mem->slots[i].alloc_size = 0;
>       }
>  
> -     set_memory_decrypted((unsigned long)vaddr, bytes >> PAGE_SHIFT);
> -     memset(vaddr, 0, bytes);
> +     mem->vaddr = dma_map_decrypted(vaddr, bytes);
> +     if (!mem->vaddr) {
> +             pr_err("Failed to decrypt memory.\n");

I am wondering if it would be worth returning an error code in this
function instead of just printing an error?

For this patch I think it is Ok, but perhaps going forward this would be
better done as I am thinking - is there some global guest->hyperv
reporting mechanism so that if this fails - it ends up being bubbled up
to the HyperV console-ish?

And ditto for other hypervisors?


> +             return;
> +     }
> +
> +     memset(mem->vaddr, 0, bytes);
>  }
>  
>  int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int 
> verbose)
> @@ -360,7 +365,7 @@ static void swiotlb_bounce(struct device *dev, 
> phys_addr_t tlb_addr, size_t size
>       phys_addr_t orig_addr = mem->slots[index].orig_addr;
>       size_t alloc_size = mem->slots[index].alloc_size;
>       unsigned long pfn = PFN_DOWN(orig_addr);
> -     unsigned char *vaddr = phys_to_virt(tlb_addr);
> +     unsigned char *vaddr = mem->vaddr + tlb_addr - mem->start;
>       unsigned int tlb_offset;
>  
>       if (orig_addr == INVALID_PHYS_ADDR)
> -- 
> 2.25.1
> 



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.