Re: [Qemu-devel] [PATCH v3 3/6] Support Physical Presence Interface Spec

[Stefan Berger <stefanb@linux.vnet.ibm.com>]

On 06/02/2015 11:18 AM, Kevin O'Connor wrote:
> On Tue, Jun 02, 2015 at 04:46:06PM +0200, Michael S. Tsirkin wrote:
>> On Tue, Jun 02, 2015 at 10:28:52AM -0400, Stefan Berger wrote:
>>> How would I mark the DataTableRegion as AddressRangeReserved or would it
>>> automatically be?
>> It's automatically either AddressRangeReserved or AddressRangeNVS.
>> It doesn't look like you have control over which it is.
>> seabios makes it reserved, nvs makes it
> As I understand it, Stefan wants to do something a little unusual
> here.  The goal is to allow the guest OS to send a signal to the BIOS
> on the next boot, because the TPM stuff only allows the BIOS to change
> certain settings immediately after the machine has booted (or
> rebooted).  So, the idea is to allow the guest OS to put some code in
> reserved memory that is at a consistent address so that on a reboot
> seabios can find that code and take the corresponding action.  The
> memory has to be non-volatile across reboots, and it must be someplace
> that can be found prior to it being zero'd or overwritten by any init
> process.
>
> Did I understand this correctly?

Correct.

>
> If so, I don't see how the normal QEMU <-> seabios ACPI table
> deployment mechanism will help here.  SeaBIOS does reserve the space,
> but nothing prevents SeaBIOS from overwriting it before extracting any
> updates from a previous boot.
>
> As an aside, I thought putting the updates in a "reserved area" of the
> TPM chip was a simple solution to this problem.  That way, it's easy
> for the guest OS and SeaBIOS to know where the codes will be stored,
> and no chance any init process will overwrite it by accident.
>
> For reference, the original solution was for SeaBIOS to declare an
> area of reserved memory and do it in such a way that the address would
> be consistent across reboots and would not be overwritten by any init
> process.  The problem with this approach was that the guest OS didn't
> implicitly know where that area of memory was, and it had to "table
> scan" to find the address - that was deemed too ugly.
>
> -Kevin
>