Re: [PATCH v2 09/11] tpm_tis_sysbus: move DSDT AML generation to device

[Joelle van Dyne]

On Fri, Jul 14, 2023 at 10:43 AM Stefan Berger <stefanb@linux.ibm.com> wrote:
>
>
>
> On 7/14/23 13:39, Joelle van Dyne wrote:
> > On Fri, Jul 14, 2023 at 10:37 AM Stefan Berger <stefanb@linux.ibm.com> 
> > wrote:
> >>
> >>
> >>
> >> On 7/14/23 13:29, Joelle van Dyne wrote:
> >>> On Fri, Jul 14, 2023 at 9:19 AM Stefan Berger <stefanb@linux.ibm.com> 
> >>> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> I don't know whether we would want multiple devices. tpm_find() usage is 
> >>>> certainly not prepared for multiple devices.
> >>> Sorry, "multiple TPM interfaces" here does not mean "at the same
> >>> time". Will clarify the description.
> >>>
> >>>>
> >>>>
> >>>> Good for the consolidation.
> >>>>
> >>>>
> >>>> Does moving the TIS to a different address help on aarch64?
> >>> That was the first thing we tried and no it doesn't help.
> >>
> >> I would remove it if we don't have a known alternative address that makes 
> >> it work. If we do, I think we should document it in tpm.rst.
> > "It" is referring to tpm-tis-device? Note that it does work fine with Linux 
> > VMs.
>
> yes, tpm_tis_sysbus and I know it works with Liunux but I see this discussion 
> here around Win 11 on aarch64. Why do we need to user another address than 
> the standard address if for Win 11 on aarch64 it doesn't get it to work.
The standard address won't work for Linux either.

TPM TIS on standard address on ARM64 Virt machines = collision with
DRAM, will not instantiate
TPM TIS on SysBus with dynamically allocated address = works on Linux,
cannot start on Windows

>
> >
> >>
> >>
> >>>>
> >>>> Can the size really be an option? I don't see it useful and if one gave 
> >>>> the wrong size it may break things.
> >>> It was added for consistency (otherwise we have to determine the size
> >>> by looking at the interface everywhere). Also, it is possible for the
> >>> size to be larger than the constant. For example, Apple Silicon uses
> >>> 16KiB page sizes and we may decide to force the device to be 16KiB
> >>> aligned (not sure if this is needed yet while we still track down why
> >>> the dual mapping was not working). In that case, we would need to
> >>> inform the OS of the true region size to prevent any overlap issues.
> >>> Both baseaddr and size should be provided only by the plug handler in
> >>> the virt machine, otherwise things may break even if we get rid of
> >>> size and have just an incorrect baseaddr.
> >>>
> >>>>
> >>>>
> >>>>