Re: [Xen-devel] [PATCH] drivers/tpm-xen: Change vTPM shared page ABI

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 12/11/2012 06:52 AM, Jan Beulich wrote:
>>>> On 10.12.12 at 21:00, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
>> This changes the vTPM shared page ABI from a copy of the Xen network
>> interface to a single-page interface that better reflects the expected
>> behavior of a TPM: only a single request packet can be sent at any given
>> time, and every packet sent generates a single response packet. This
>> protocol change should also increase efficiency as it avoids mapping and
>> unmapping grants when possible.
> 
> Given
> 
> -#define TPMIF_TX_RING_SIZE 1
> 
> where was the problem?

The shared ring still needed to refer to grants and a series of shared pages
for requests and replies, and was implemented by mapping and unmapping grants
on each request.  While a persistent mapping (like being introduced in Linux)
could also have addressed the efficiency issues, redoing the shared page
seemed cleaner.  Redoing the shared page allows potentially supporting TPM
packets up to 1MB in size, although that requires using the extra_pages list
which isn't implemented (most, if not all, users won't use large packets in
order to support hardware TPMs with hard limitations on the packet size).  It
also allows introducing an out-of-band locality field for requests, and the
status field could easily be extended to allow command cancellation - although
that would require a vTPM supporting cancellation; CPU-based vTPMs are fast
enough that cancellation is not needed to meet the timing requirements.

> Also, the patch replaces the old interface by the new one - how
> is that compatible with older implementations?

It is not; we've decided to call this "vtpm2" in xenbus to address this.  From
the condition of the old vtpm code in Xen, there appear to be few users of the
old implementation, even if there are many users of a kernel with the driver
present.
 
> The positive aspect is that the new interface isn't address size
> dependent anymore (and hence mixed size backend/frontend can
> work together, which isn't the case for the original one).
>
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel