[Xen-changelog] [xen-unstable] [Linux] [TPM driver] Resume frontend after checkpointing

[Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>]

# HG changeset patch
# User kfraser@xxxxxxxxxxxxxxxxxxxxx
# Date 1172851401 0
# Node ID cc18ea7309b3f1a68a90041156e4cc177d78a006
# Parent  1fb5ae0ee4532bcbf4f1e5942efa4e3dcf098640
[Linux] [TPM driver] Resume frontend after checkpointing

This patch implements TPM frontend driver resume after checkpointing a
domain. I also now let the front-end wait for the response from the
TPM until the response is there. A response must come due to the
strict request/response nature of the protocol, but the time until the
responses arrives depends on the type of operation that is executed by
the vTPM. Resending a request is not possible with this type of device.

Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxx>
---
 linux-2.6-xen-sparse/drivers/char/tpm/tpm_xen.c |   34 +++++++++++++-----------
 1 files changed, 19 insertions(+), 15 deletions(-)

diff -r 1fb5ae0ee453 -r cc18ea7309b3 
linux-2.6-xen-sparse/drivers/char/tpm/tpm_xen.c
--- a/linux-2.6-xen-sparse/drivers/char/tpm/tpm_xen.c   Fri Mar 02 16:00:22 
2007 +0000
+++ b/linux-2.6-xen-sparse/drivers/char/tpm/tpm_xen.c   Fri Mar 02 16:03:21 
2007 +0000
@@ -421,7 +421,7 @@ static int tpmfront_suspend(struct xenbu
        mutex_lock(&suspend_lock);
        tp->is_suspended = 1;
 
-       for (ctr = 0; atomic_read(&tp->tx_busy) && ctr <= 300; ctr++) {
+       for (ctr = 0; atomic_read(&tp->tx_busy); ctr++) {
                if ((ctr % 10) == 0)
                        printk("TPM-FE [INFO]: Waiting for outstanding "
                               "request.\n");
@@ -430,17 +430,22 @@ static int tpmfront_suspend(struct xenbu
                 */
                interruptible_sleep_on_timeout(&tp->wait_q, 100);
        }
-       xenbus_switch_state(dev, XenbusStateClosing);
-
-       if (atomic_read(&tp->tx_busy)) {
-               /*
-                * A temporary work-around.
-                */
-               printk("TPM-FE [WARNING]: Resetting busy flag.");
-               atomic_set(&tp->tx_busy, 0);
-       }
-
-       return 0;
+
+       return 0;
+}
+
+static int __tpmfront_suspend_cancel(struct tpm_private *tp)
+{
+       tp->is_suspended = 0;
+       /* unlock, so apps can send again */
+       mutex_unlock(&suspend_lock);
+       return 0;
+}
+
+static int tpmfront_suspend_cancel(struct xenbus_device *dev)
+{
+       struct tpm_private *tp = tpm_private_from_dev(&dev->dev);
+       return __tpmfront_suspend_cancel(tp);
 }
 
 static int tpmfront_resume(struct xenbus_device *dev)
@@ -484,6 +489,7 @@ static struct xenbus_driver tpmfront = {
        .resume = tpmfront_resume,
        .otherend_changed = backend_changed,
        .suspend = tpmfront_suspend,
+       .suspend_cancel = tpmfront_suspend_cancel,
 };
 
 static void __init init_tpm_xenbus(void)
@@ -689,9 +695,7 @@ static void tpmif_set_connected_state(st
         * This also removes the suspend state.
         */
        if (is_connected == 1 && tp->is_suspended == 1) {
-               tp->is_suspended = 0;
-               /* unlock, so apps can resume sending */
-               mutex_unlock(&suspend_lock);
+               __tpmfront_suspend_cancel(tp);
        }
 
        if (is_connected != tp->is_connected) {

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog