On 03/25/2013 06:20 PM, Stefan Berger wrote:
On 03/25/2013 06:05 PM, Anthony Liguori wrote:
Stefan Berger <address@hidden> writes:
[argh, just posted this to qemu-trivial -- it's not trivial]
Hello!
I am posting this message to revive the previous discussions about the
design of vNVRAM / blobstore cc'ing (at least) those that participated
in this discussion 'back then'.
The first goal of the implementation is to provide an vNVRAM storage
for
a software implementation of a TPM to store its different blobs into.
Some of the data that the TPM writes into persistent memory needs to
survive a power down / power up cycle of a virtual machine, therefore
this type of persistent storage is needed. For the vNVRAM not to become
a road-block for VM migration, we would make use of block device
migration and layer the vNVRAM on top of the block device, therefore
using virtual machine images for storing the vNVRAM data.
Besides the TPM blobs the vNVRAM should of course also be able able to
accommodate other use cases where persistent data is stored into
NVRAM,
Well let's focus more on the "blob store". What are the semantics of
this? Is there a max number of blobs? Are the sizes fixed or variable?
How often are new blobs added/removed?
The max number of blobs and frequency of usage depends on the usage
scenario and NVRAM size. But that's probably obvious.
I think we should focus on worst case scenarios where NVRAM is filled up
and used frequently.
One example is that an application can use TSS APIs to define, undefine,
read, and write to the TPM's NVRAM storage. (The TPM owner password is
required to define NVRAM data.) An application could potentially fill
up NVRAM and frequently store, change, retrieve data in various places
within NVRAM. And the data could have various sizes.
For an example of total NVRAM size, Infineon's TPM has 16K of NVRAM.
--
Regards,
Corey Bryant