qemu-devel
[Top][All Lists]
Advanced

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

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


From: Kevin O'Connor
Subject: Re: [Qemu-devel] [PATCH v3 3/6] Support Physical Presence Interface Spec
Date: Tue, 2 Jun 2015 11:18:31 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

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?

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



reply via email to

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