From: Michael Kelley <mhklinux@outlook.com>
To: "Suthikulpanit, Suravee" <suravee.suthikulpanit@amd.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"joro@8bytes.org" <joro@8bytes.org>
Cc: "thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
"vasant.hegde@amd.com" <vasant.hegde@amd.com>,
"michael.roth@amd.com" <michael.roth@amd.com>,
"jon.grimm@amd.com" <jon.grimm@amd.com>,
"rientjes@google.com" <rientjes@google.com>
Subject: RE: [PATCH 0/9] iommu/amd: Add AMD IOMMU emulation support for SEV-SNP guest kernel
Date: Tue, 14 May 2024 21:34:59 +0000 [thread overview]
Message-ID: <SN6PR02MB4157B333B126909197590DE0D4E32@SN6PR02MB4157.namprd02.prod.outlook.com> (raw)
In-Reply-To: <24a4eb65-5e1b-44f9-a8ae-71f5f8f26ceb@amd.com>
From: Suthikulpanit, Suravee <suravee.suthikulpanit@amd.com> Sent: Tuesday, May 14, 2024 12:02 PM
>
> On 5/14/2024 3:05 AM, Michael Kelley wrote:
> > From: Suravee Suthikulpanit<suravee.suthikulpanit@amd.com> Sent: Tuesday, April
> 30, 2024 8:24 AM
> >> To boot a VM w/ x2APIC ID > 255, guest interrupt remapping emulation
> >> is required.
> >
> > Top-level question: Is there a reason the MSI extended destination ID mechanism is
> > insufficient to avoid the need for interrupt remapping? (see function pointer
> > "msi_ext_dest_id"). I'm unclear on whether it is or not. If it is not sufficient, perhaps
> > you could explain why.
>
> In case of running a Linux VM w/ QEMU/KVM as hypervisor, the
> qemu-system-x86_64 option kvm-msi-ext-dest-id=on would allow booting the
> VM w/ x2APIC ID > 255. However, for other hypervisor, it might not
> support this feature.
Two observations:
1) KVM, Hyper-V, and Xen all have support for MSI extended destination ID.
Is it reasonable to make it a requirement that any hypervisor supporting
SEV/SEV-ES/SEV-SNP guests must also support MSI extended destination ID
if the guest is to run with more than 255 vCPUs? With that requirement,
you don't need any interrupt remapping or IOMMU emulation.
2) It would help to be more explicit about the basic premise of this patch
set. I *think* the idea is that KVM/QEMU already supports an emulated
AMD IOMMU in a normal VM. That emulation depends on QEMU having
access to data structures in guest memory (just like a physical AMD IOMMU
would). But with SEV/SEV-ES/SEV-SNP, guest memory is encrypted and
QEMU doesn't have the access. So this patch set changes the IOMMU
related data structures to be allocated in decrypted guest memory. Of
course, as Jason has pointed out, this would seem to open the guest to
security risks from a compromised hypervisor/VMM, negating what
SEV* is trying to provide as guest confidentiality.
My #1 above might be a lot less risky from a security perspective.
>
> >> For SEV guest, this can be achieved using an emulated
> >> AMD IOMMU.
> > You've used "SEV" here and in several other places. I think you intend this to be
> > the more specific "SEV-SNP", and exclude SEV and SEV-ES. For avoid any confusion,
> > I'd suggest using "SEV-SNP" throughout if that's what you mean.
>
> Actually, The CC_ATTR_GUEST_MEM_ENCRYPT attribute is true for all SEV
> guests, so this will enable IOMMU emulation for all SEV guests.
>
If that's the case, I'd suggest updating the Subject: line of this cover letter
to not be specific to SEV-SNP, and to call out in the text that's your intent
for the patch set to work for all SEV* flavors. Also, the commit messages
throughout the patch set sometimes reference "SNP" and sometimes "SEV".
That's confusing if your intent is applicability to all SEV* flavors.
Michael
prev parent reply other threads:[~2024-05-14 21:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 15:24 [PATCH 0/9] iommu/amd: Add AMD IOMMU emulation support for SEV-SNP guest kernel Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 1/9] iommu/amd: Introduce helper functions for managing IOMMU memory Suravee Suthikulpanit
2024-05-01 16:17 ` Jason Gunthorpe
2024-05-13 18:59 ` Suthikulpanit, Suravee
2024-05-13 23:13 ` Jason Gunthorpe
2024-04-30 15:24 ` [PATCH 2/9] iommu/amd: Convert Device Table pointer to use struct amd_iommu_mem Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 3/9] iommu/amd: Convert Command Buffer " Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 4/9] iommu/amd: Convert Completion-Wait Semaphore " Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 5/9] iommu/amd: Convert Event Log " Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 6/9] iommu/amd: Convert PPR Log pointer to use the " Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 7/9] iommu/amd: Remove iommu_alloc_4k_pages() helper function Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 8/9] iommu/amd: Decrypt interrupt remapping table for AMD IOMMU emulation in SEV guest Suravee Suthikulpanit
2024-04-30 15:24 ` [PATCH 9/9] iommu/amd: Set default domain to IDENTITY_DOMAIN when running " Suravee Suthikulpanit
2024-05-01 14:17 ` Jason Gunthorpe
2024-05-13 12:17 ` Suthikulpanit, Suravee
2024-05-13 23:10 ` Jason Gunthorpe
2024-05-13 20:05 ` [PATCH 0/9] iommu/amd: Add AMD IOMMU emulation support for SEV-SNP guest kernel Michael Kelley
2024-05-14 19:02 ` Suthikulpanit, Suravee
2024-05-14 21:34 ` Michael Kelley [this message]
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=SN6PR02MB4157B333B126909197590DE0D4E32@SN6PR02MB4157.namprd02.prod.outlook.com \
--to=mhklinux@outlook.com \
--cc=iommu@lists.linux.dev \
--cc=jon.grimm@amd.com \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=rientjes@google.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 read-only IMAP folder(s) and NNTP newsgroup(s).