Re: [RFC PATCH 20/21] pci: Allow encrypted MMIO mapping via sysfs

[Alexey Kardashevskiy <aik@amd.com>]

On 24/8/24 08:37, Bjorn Helgaas wrote:
> On Fri, Aug 23, 2024 at 11:21:34PM +1000, Alexey Kardashevskiy wrote:
>> Add another resource#d_enc to allow mapping MMIO as
>> an encrypted/private region.
>>
>> Unlike resourceN_wc, the node is added always as ability to
>> map MMIO as private depends on negotiation with the TSM which
>> happens quite late.
> 
> Capitalize subject prefix.
> 
> Wrap to fill 75 columns.
> 
>> +++ b/include/linux/pci.h
>> @@ -2085,7 +2085,7 @@ pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
>>    */
>>   int pci_mmap_resource_range(struct pci_dev *dev, int bar,
>>   			    struct vm_area_struct *vma,
>> -			    enum pci_mmap_state mmap_state, int write_combine);
>> +			    enum pci_mmap_state mmap_state, int write_combine, int enc);
> 
> This interface is only used in drivers/pci and look like it should be
> moved to drivers/pci/pci.h.
> 
>> @@ -46,6 +46,15 @@ int pci_mmap_resource_range(struct pci_dev *pdev, int bar,
>>   
>>   	vma->vm_ops = &pci_phys_vm_ops;
>>   
>> +	/*
>> +	 * Calling remap_pfn_range() directly as io_remap_pfn_range()
>> +	 * enforces shared mapping.
> 
> s/Calling/Call/
> 
> Needs some additional context about why io_remap_pfn_range() can't be
> used here.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f8f6ae5d077a9bdaf5cbf2ac960a5d1a04b47482 
added this.

"IO devices do not understand encryption, so this memory must always be 
decrypted" it says.

But devices do understand encryption so forcing decryption is not 
wanted. What additional context is missing here, that "shared" means 
"non-encrypted"? Thanks,



> 
>> +	 */
>> +	if (enc)
>> +		return remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
>> +				       vma->vm_end - vma->vm_start,
>> +				       vma->vm_page_prot);
>> +
>>   	return io_remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
>>   				  vma->vm_end - vma->vm_start,
>>   				  vma->vm_page_prot);

-- 
Alexey