qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Joelle van Dyne
Subject: Re: [PATCH v2 09/11] tpm_tis_sysbus: move DSDT AML generation to device
Date: Fri, 14 Jul 2023 10:39:51 -0700

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.

>
>
> >>
> >> 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.
> >
> >>
> >>
> >>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]