linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Kalra, Ashish" <ashish.kalra@amd.com>
To: Jason Gunthorpe <jgg@ziepe.ca>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
	joro@8bytes.org, robin.murphy@arm.com, thomas.lendacky@amd.com,
	vasant.hegde@amd.com, jon.grimm@amd.com
Subject: Re: [PATCH 1/4] iommu/amd: Introduce Protection-domain flag VFIO
Date: Thu, 19 Jan 2023 02:54:43 -0600	[thread overview]
Message-ID: <90762dee-1559-58ac-220d-a13635d5032e@amd.com> (raw)
In-Reply-To: <Y8F53dzdebKLTlOy@ziepe.ca>

Hello Jason,

On 1/13/2023 9:33 AM, Jason Gunthorpe wrote:
> On Tue, Jan 10, 2023 at 08:31:34AM -0600, Suravee Suthikulpanit wrote:
>> Currently, to detect if a domain is enabled with VFIO support, the driver
>> checks if the domain has devices attached and check if the domain type is
>> IOMMU_DOMAIN_UNMANAGED.
> 
> NAK
> 
> If you need weird HW specific stuff like this then please implement it
> properly in iommufd, not try and randomly guess what things need from
> the domain type.
> 
> All this confidential computing stuff needs a comprehensive solution,
> not some piecemeal mess. How can you even use a CC guest with VFIO in
> the upstream kernel? Hmm?
> 

Currently all guest devices are untrusted - whether they are emulated, 
virtio or passthrough. In the current use case of VFIO 
device-passthrough to an SNP guest, the pass-through device will perform 
DMA to un-encrypted or shared guest memory, in the same way as virtio or 
emulated devices.

This fix is prompted by an issue reported by Nvidia, they are trying to 
do PCIe device passthrough to SNP guest. The memory allocated for DMA is 
through dma_alloc_coherent() in the SNP guest and during DMA I/O an 
RMP_PAGE_FAULT is observed on the host.

These dma_alloc_coherent() calls map into page state change hypercalls 
into the host to change guest page state from encrypted to shared in the 
RMP table.

Following is a link to issue discussed above:
https://github.com/AMDESE/AMDSEV/issues/109

Now, to set individual 4K entries to different shared/private mappings 
in NPT or host page tables for large page entries, the RMP and NPT/host 
page table large page entries are split to 4K pte’s.

The same split is required in iommu page table entries to remain in sync 
with the corresponding RMP table entry. If the iommu entry is covering a 
range with a large page entry and the individual 4K mappings in that 
range have now changed, the RMP checks during IOMMU page table walk will 
cause a RMP page fault to be signaled.

The fix is to force 4K page size for IOMMU page tables for SNP guests.

This patch-set adds support to detect if a domain belongs to an 
SNP-enabled guest. This way it can set default page size of a domain to 
4K only for SNP-enabled guest and allow non-SNP guest to use larger page 
size.

Hopefully, this explains the usage case for this patch-set.

Thanks,
Ashish



  reply	other threads:[~2023-01-19  8:56 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-10 14:31 [PATCH 0/4] iommu/amd: Force SNP-enabled VFIO domain to 4K page size Suravee Suthikulpanit
2023-01-10 14:31 ` [PATCH 1/4] iommu/amd: Introduce Protection-domain flag VFIO Suravee Suthikulpanit
2023-01-11  3:31   ` kernel test robot
2023-01-13 15:33   ` Jason Gunthorpe
2023-01-19  8:54     ` Kalra, Ashish [this message]
2023-01-19 17:44       ` Jason Gunthorpe
2023-01-20 15:12         ` Kalra, Ashish
2023-01-20 16:13           ` Jason Gunthorpe
2023-01-20 17:01             ` Kalra, Ashish
2023-01-20 17:50               ` Jason Gunthorpe
2023-01-20 19:55                 ` Kalra, Ashish
2023-01-20 22:42                   ` Tom Lendacky
2023-01-21  0:09                     ` Jason Gunthorpe
2023-01-10 14:31 ` [PATCH 2/4] iommu/amd: Introduce structure amd_iommu_svm_ops.is_snp_guest() Suravee Suthikulpanit
2023-01-10 14:31 ` [PATCH 3/4] iommu: Introduce IOMMU call-back for processing struct KVM assigned to VFIO Suravee Suthikulpanit
2023-01-10 15:11   ` Robin Murphy
2023-01-17  4:20     ` Suthikulpanit, Suravee
2023-01-17 12:51       ` Robin Murphy
2023-01-13 15:35   ` Jason Gunthorpe
2023-01-17  5:31     ` Suthikulpanit, Suravee
2023-01-17 14:19       ` Jason Gunthorpe
2023-01-10 14:31 ` [PATCH 4/4] iommu/amd: Force SNP-enabled VFIO domain to 4K page size Suravee Suthikulpanit
2023-01-17 13:10   ` Eric van Tassell
2023-01-16 13:17 ` [PATCH 0/4] " Eric van Tassell

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=90762dee-1559-58ac-220d-a13635d5032e@amd.com \
    --to=ashish.kalra@amd.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=jon.grimm@amd.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vasant.hegde@amd.com \
    /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).