Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Borislav Petkov <bp@alien8.de>,
        Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
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
In-Reply-To: <20230402154425.GCZCmi2eiKYO2yYhNs@fat_crate.local>
References: <20230320191956.1354602-1-jpiotrowski@linux.microsoft.com>
 <20230322154655.GDZBsi75f6LnQStxSp@fat_crate.local>
 <1d25221c-eaab-0f97-83aa-8b4fbe3a53ed@linux.microsoft.com>
 <20230322181541.GEZBtFzRAMcH9BAzUe@fat_crate.local>
 <ecf005b1-ddb9-da4c-4526-28df4806426c@linux.microsoft.com>
 <20230323152342.GFZBxu/m3u6aFUDY/7@fat_crate.local>
 <105d019c-2249-5dfd-e032-95944ea6dc8c@linux.microsoft.com>
 <20230323163450.GGZBx/qpnclFnMaf7e@fat_crate.local>
 <c8458bfa-0985-f6a5-52a3-ef96c7669fe6@linux.microsoft.com>
 <20230402154425.GCZCmi2eiKYO2yYhNs@fat_crate.local>
Date:   Mon, 03 Apr 2023 08:20:44 +0200
Message-ID: <877cutsczn.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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.

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.

Jeremi, can you please describe exactly what the design and constraints
are in understandable and coherent sentences?

Thanks,

        tglx