Re: [PATCH v4] drivers/tpm: add xen tpmfront interface
From: David Vrabel
Date: Wed Jul 24 2013 - 13:09:39 EST
On 22/07/13 17:20, Daniel De Graaf wrote:
> On 07/22/2013 11:18 AM, David Vrabel wrote:
>> On 01/07/13 22:34, Daniel De Graaf wrote:
>>> This is a complete rewrite of the Xen TPM frontend driver, taking
>>> advantage of a simplified frontend/backend interface and adding support
>>> for cancellation and timeouts. The backend for this driver is provided
>>> by a vTPM stub domain using the interface in Xen 4.3.
>>> --- /dev/null
>>> +++ b/Documentation/xen-tpmfront.txt
>> Suggest putting this in Documentation/tpm/.
>>> --- /dev/null
>>> +++ b/drivers/char/tpm/xen-tpmfront.c
>>> +static void backend_changed(struct xenbus_device *dev,
>>> + enum xenbus_state backend_state)
>>> + int val;
>> Hrm. I don't like how every front/back pair invents their own variation
>> of the state machine.
>> Please document the front and back state machines in
>> xen/include/public/io/tpmif.h (and the correspoding copy in Linux).
> Is there a standard state machine that would allow devices to avoid
> inventing their own?
That would be nice wouldn't it? But, no, there isn't one -- even
netfront and blkfront are different.
> Otherwise, this is what I plan to add to the header:
> * Xenbus state machine
> * Device open:
> * 1. Both ends start in XenbusStateInitialising
> * 2. Backend transitions to InitWait (frontend does not wait on this
> * 3. Frontend populates ring-ref, event-channel, feature-protocol-v2
> * 4. Frontend transitions to Initialised
> * 5. Backend maps grant and event channel, verifies feature-protocol-v2
> * 6. Backend transitions to Connected
> * 7. Frontend verifies feature-protocol-v2, transitions to Connected
> * Device close:
> * 1. State is changed to XenbusStateClosing
> * 2. Frontend transitions to Closed
> * 3. Backend unmaps grant and event, changes state to InitWait
That's good, thanks.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/