From: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
To: Thomas Gleixner <tglx@linutronix.de>, Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org,
Brijesh Singh <brijesh.singh@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
"Kalra, Ashish" <ashish.kalra@amd.com>,
linux-crypto@vger.kernel.org,
"Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>,
linux-acpi@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org
Subject: Re: [PATCH v3 0/8] Support ACPI PSP on Hyper-V
Date: Tue, 11 Apr 2023 17:10:29 +0200 [thread overview]
Message-ID: <fc6a807a-1bbe-d56d-caa9-ec0687ef6cff@linux.microsoft.com> (raw)
In-Reply-To: <8d39a9a1-4b7b-08fe-7b09-2ff0a419468f@linux.microsoft.com>
On 4/5/2023 9:56 AM, Jeremi Piotrowski wrote:
> On 4/3/2023 8:20 AM, Thomas Gleixner wrote:
>> On Sun, Apr 02 2023 at 17:44, Borislav Petkov wrote:
>>> On Fri, Mar 24, 2023 at 06:10:09PM +0100, Jeremi Piotrowski wrote:
>>>> Since the AMD PSP is a privileged device, there is a desire to not have to trust the
>>>> ACPI stack,
>>>
>>> And yet you do:
>>>
>>> + err = acpi_parse_aspt(&res[0], &pdata);
>>> + if (err)
>>> + return err;
>>>
>>> You don't trust the ACPI stack, and yet you're parsing an ACPI table?!?!
>>> You have to make up your mind here.
>>>
>>> Btw, you still haven't answered my question about doing:
>>>
>>> devm_request_irq(dev, 9, ..)
>>>
>>> where 9 is the default ACPI interrupt.
>>>
>>> You can have some silly table tell you what to map or you can simply map
>>> IRQ 9 and be done with it. In this second case you can *really* not
>>> trust ACPI because you know which IRQ it is
>
> Will respond to this mail directly.
>
>>
>> The real problem here is that the information provided about the overall
>> design and requirements is close to zero. All we heard so far is hand
>> waving about not trusting PCI and ACPI.
>
> That's not a fair characterization Thomas, but I will turn the other cheek.
>
>>
>> Jeremi, can you please describe exactly what the design and constraints
>> are in understandable and coherent sentences?
>>
>
> Here goes, I will keep it as simple as I can.
>
> The goal of these patches is to operate all the hardware interfaces required
> to run AMD SEV-SNP VMs, but in the context of a Linux VM running on top of
> Hyper-V. This Linux VM is called the SNP-host VM. All the patches I submit
> target the SNP-host VM kernel, which uses KVM to bring up SEV-SNP VMs. To get
> SEV-SNP working you need to combine this work with AMD's KVM SEV-SNP patches.
> I posted two patch sets: one that extends AMD's patches, and one that is
> independent of them (this one here) that could be merged sooner.
>
> Here are the design constraints:
> 1. the interfaces exposed to the SNP-host VM to operate SEV-SNP match real
> hardware interface specifications defined by AMD. This is because we are
> emulating/virtualizing a hardware feature, and not some made up virtual
> thing.
>
> 2. the SNP-host VM may run either Windows(Hyper-V) or Linux, so the SEV-SNP
> interfaces need to be supported by both.
>
> 3. Hyper-V Generation 2 VMs do not have a PCI bus. The SNP-host VM must be a
> Hyper-V Gen 2 VM.
>
> One of the components needed to operate SEV-SNP is the Platform Security
> Processor (PSP), aka AMD Secure Processor (ASP). The PSP is the root-of-trust on
> AMD systems. The PSP is specified as being discoverable either on the PCI bus,
> or through the presence of an ACPI table with the "ASPT" (AMD Secure Processor
> Table) signature.
>
> Here goes the design:
> Constraint 1 means that only the two specified ways of discovering and
> configuring a PSP inside the SNP-host VM were in the running: PCI or ASPT.
> Constraint 3 means that the PCI version of the PSP is not a viable option.
> Additionally, the ASPT is used on AMD hardware in Microsoft datacenters, which
> means it is supported in Hyper-V (constraint 2). The outcome is that the
> SNP-host VM sees an ASPT.
>
> The ASPT provides the following information: memory range of PSP registers and
> offsets of individual PSP registers inside that memory range. There are 7
> registers:
> - 6 are related to the "command submission" portion of the PSP; the ccp module
> knows how to operate those.
> - the last one, "ACPI CmdResp" register, is used to configure the PSP interrupt
> to the OS.
>
> The PSP interrupt configuration through the "ACPI CmdResp" register takes the
> following information:
> - APIC ID
> - interrupt vector
> - destination mode (physical/logical)
> - message type (fixed/lowest priority)
>
> So to hook this up with the Linux device model I wrote patches that do the
> following:
> Detect the ASPT table, extract information and register a "psp" platform_device
> for the "ccp" module to bind to.
> Create an irq_domain and encapsulate dealing with the PSP interrupt register
> there, so that the "ccp" module has an irq number that it passes to
> request_irq().
>
> There is an "if (hypervisor == Hyper-V)" check before the ASPT table detection.
> Here is the reasoning behind that:
> According to AMD specifications the *same* PSP may be discoverable both through
> ASPT and on the PCI bus. In that case, if the ASPT is to be used the OS is supposed
> to disable the "PCI interface" through the "ACPI CmdResp" register, which will
> result in no PCI-MSI interrupts, BAR writes ignored, BAR reads return all 0xF's.
> I can't verify whether that would work correctly, so in the interest of not
> breaking other users, the ASPT handling is hidden behind the hypervisor check.
> There is nothing Hyper-V specific about any of this code, it supports a hardware
> interface present in server grade hardware and would work on physical hardware if
> when (not if) someone removes the condition.
>
> That's all there is to it.
>
> All the other information I gave is background information that I hoped would
> help better understand the setting. The most relevant piece of information is the
> one that I came across last. You asked "what makes this PSP device special". The PSP
> is the root-of-trust on the system, it controls memory encryption keys, it can
> encrypt/decrypt individual memory pages. SEV-SNP ties together a lot of system components
> and requires enabling support for it in the AMD IOMMU too, which is presumably why
> the PSP gets the same special treatment (as the AMD IOMMU). The ASPT and AMD PSP interrupt
> configuration through the "ACPI CmdResp" register is based on a similar design of the AMD IOMMU.
> The AMD IOMMU is:
> - discovered through the presence of the IVRS ACPI table
> - the MMIO address of the IOMMU is parsed out of the IVRS table
> - if x2APIC support is enabled, the IOMMU interrupts are delivered based on
> programming APIC-ID+vector+destination mode into an interrupt control register
> in IOMMU MMIO space. This causes any PCI-MSI configuration present for the
> IOMMU to be ignored.
> - Linux supports and uses that interrupt delivery mechanism. It is implemented
> as an irq_domain.
>
> Do you think it makes sense to include parts of the above description in cover letter
> commit message?
>
> Thanks,
> Jeremi
Hi Thomas,
Have you had a chance to review this?
Thanks,
Jeremi
next prev parent reply other threads:[~2023-04-11 15:10 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-20 19:19 [PATCH v3 0/8] Support ACPI PSP on Hyper-V Jeremi Piotrowski
2023-03-20 19:19 ` [PATCH v3 1/8] include/acpi: add definition of ASPT table Jeremi Piotrowski
2023-03-20 19:19 ` [PATCH v3 2/8] ACPI: ASPT: Add helper to parse table Jeremi Piotrowski
2023-03-20 19:19 ` [PATCH v3 3/8] x86/psp: Register PSP platform device when ASP table is present Jeremi Piotrowski
2023-03-20 19:25 ` Borislav Petkov
2023-03-20 19:37 ` Jeremi Piotrowski
2023-03-20 20:03 ` Borislav Petkov
2023-03-20 20:18 ` Jeremi Piotrowski
2023-03-20 21:03 ` Borislav Petkov
2023-03-21 14:15 ` Jeremi Piotrowski
2023-03-20 19:19 ` [PATCH v3 4/8] x86/psp: Add IRQ support Jeremi Piotrowski
2023-03-21 10:31 ` Thomas Gleixner
2023-03-21 19:16 ` Jeremi Piotrowski
2023-03-22 10:07 ` Thomas Gleixner
2023-03-28 18:29 ` Jeremi Piotrowski
2023-03-20 19:19 ` [PATCH v3 5/8] crypto: cpp - Bind to psp platform device on x86 Jeremi Piotrowski
2023-03-20 19:19 ` [PATCH v3 6/8] crypto: ccp - Add vdata for platform device Jeremi Piotrowski
2023-03-20 19:19 ` [PATCH v3 7/8] crypto: ccp - Skip DMA coherency check for platform psp Jeremi Piotrowski
2023-03-20 19:19 ` [PATCH v3 8/8] crypto: ccp - Allow platform device to be psp master device Jeremi Piotrowski
2023-03-22 15:46 ` [PATCH v3 0/8] Support ACPI PSP on Hyper-V Borislav Petkov
2023-03-22 17:33 ` Jeremi Piotrowski
2023-03-22 18:15 ` Borislav Petkov
2023-03-23 14:46 ` Jeremi Piotrowski
2023-03-23 15:23 ` Borislav Petkov
2023-03-23 16:11 ` Jeremi Piotrowski
2023-03-23 16:34 ` Borislav Petkov
2023-03-24 17:10 ` Jeremi Piotrowski
2023-04-02 15:44 ` Borislav Petkov
2023-04-03 6:20 ` Thomas Gleixner
2023-04-05 7:56 ` Jeremi Piotrowski
2023-04-11 15:10 ` Jeremi Piotrowski [this message]
2023-04-13 21:53 ` Thomas Gleixner
2023-04-05 8:10 ` Jeremi Piotrowski
2023-04-05 8:50 ` Jeremi Piotrowski
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=fc6a807a-1bbe-d56d-caa9-ec0687ef6cff@linux.microsoft.com \
--to=jpiotrowski@linux.microsoft.com \
--cc=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=brijesh.singh@amd.com \
--cc=dave.hansen@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rafael@kernel.org \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--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 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).