On Wed, 29 Apr 2015 12:42:21 -0400 Stefan Berger <stef...@linux.vnet.ibm.com> wrote:
> On 04/29/2015 05:06 AM, Igor Mammedov wrote: > > On Wed, 22 Apr 2015 14:18:55 -0400 > > Stefan Berger <stef...@linux.vnet.ibm.com> wrote: > > > >> On 04/22/2015 03:00 AM, Igor Mammedov wrote: > >>> On Thu, 16 Apr 2015 10:05:35 -0400 > >>> Stefan Berger <stef...@linux.vnet.ibm.com> wrote: > >>> > >>>> On 04/16/2015 09:35 AM, Igor Mammedov wrote: > >>>>> On Wed, 15 Apr 2015 18:38:43 -0400 > > [...] > >>>>> Is it possible to use MMIO region instead of allocating tpm_ppi_anchor > >>>>> and tpm_ppi in BIOS memory? > >>>> MMIO region of what? Of the TIS? The TIS doesn't have memory locations > >>>> 'just to keep bytes' and they would be cleared upon machine reset / > >>>> reboot. > >>>> > >>>> The purpose of the PPI interface is to leave an opcode for the BIOS to > >>>> act upon after a reset. So we have to write it into memory that doesn't > >>>> get cleared upon reboot. Also, the BIOS leaves a result in memory so we > >>>> can read the result code in the OS via sysfs entry. > >>> it doesn't matter where opcodes are stored though, they could be stored > >>> on QEMU's TPM device (i.e. inside TPM owned MMIO region). That way QEMU > >>> will know in advance where opcodes are stored and build ACPI tables > >>> with correct address without any need for scanning memory. > >> It only matters that these opcodes survive a machine reboot. Some > >> devices get reset on the way > >> and the choices of suitable NVRAM are limited. > >> > >> Ok, so we could extend the TPM TIS model with a buffer that can hold > >> these opcodes. > >> At the moment I think I need 3 bytes. Future specifications may require > >> more. We can > >> make room for this in the TIS from offset 0xf90-0xfff where we can put > >> vendor > >> specific extensions. Maybe we just stick it into locality 4 -> 0xfed4 > >> 4f90 to 0xfed4 4fff > >> and don't reset that memory area ? > > yep > > > So we can do it this way ... > > > > > >> The only thing that speaks against this is that this would not work if > >> SeaBIOS was not > >> running on QEMU but on bare metal -- if that was to be a concern at all. > >> The current > >> solution tried to address this as well, but it would require coreboot > >> support and the > >> last time I tested this on my Chromebook it looks like an anchor created > >> but SeaBIOS > >> is not found after a reboot anymore, so it would require some form of > >> cooperation > >> from coreboot to enable this. So if we ditch this, we can go with a > >> buffer in the MMIO. > > Coreboot would probably require different ACPI buffer read/write functions, > > the rest could stay the same. > > Yes, understood. > > >> > >> > >>> Although it's just another workaround around split brain problem where > >>> QEMU owned ACPI tables have to know about guest (BIOS) provided address. > >>> > >>> > >>>> I had previously tried using NVRAM of the TPM to leave that opcode (and > >>>> result) , but this doesn't work well due to protection restrictions of > >>>> the TPM's NVRAM locations and using the Linux TSS for example non-root > >>>> users could then write an opcode into the NVRAM of the TPM (there are > >>>> TPM commands to write to the TPM's NVRAM locations and tpm-tools has > >>>> tools to write to these locations) that the machine then ends up acting > >>>> upon without the admin of the machine wanting that. So, that's not a > >>>> choice, either. > >>>> > >>>> > >>>>> That would simplify BIOS part a bit and significantly simplify ACPI code > >>>>> as most of it is dealing with figuring out address of tpm_ppi. > >>>> Wished it would, but I don't see a way to make it easier. > >>> Since ACPI implementation for handling opcodes doesn't interface/depend > >>> on TPM device and interfaces only with BIOS it should also be BIOS owned. > >>> Cleaner way could be installing an additional BIOS generated table > >>> (with correct ADDR) to QEMU provided ACPI tables set. > >> Would that be a custom table? Do we need changes for this in the OS > >> or can that table be found via ACPI? > > It would be just additional SSDT, no OS changes are required. > > what you'll need to do is to extend QEMU supplied RSDT to include > > pointer to additional SSDT. > > I'm not sure where ACPI tables come from in case of coreboot though. > > > >>> That also would be reusable with coreboot since you will have shared > >>> ACPI impl. in SeaBIOS without need to duplicate it in QEMU/coreboot. > >> Can you sketch the ACPI code necessary to convey the SeaBIOS / coreboot > >> allocated memory address ? How do we write the SeaBIOS allocated > >> address into the ACPI code? > > grep for acpi_pci64_start in SeaBIOS code, > > it should give rough idea how to do it. > > > > [...] > > > > ... or we can do it this way. Which way now ? My preference is the TIS > path, because it seems easier. > > > Now what I am seeing in SeaBIOS is that another SSDT is being built. > Would this then be an > additional SSDT or would it replace the TPM's SSDT that we're now > supplying from QEMU. perhaps an additional SSDT that has only Seabios specific AML which doesn't interact with TIS device. > > 2 choices now -- which one to take? I'd try installing extra SSDT table first as a cleanest way (seabios only) and if it fails fallback to TIS path. > > Stefan >
