WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-changelog

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

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] [xen-unstable] [Linux] [TPM driver] Resume frontend after checkpointing
From: Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 07 Mar 2007 11:30:19 -0800
Delivery-date: Wed, 07 Mar 2007 11:30:22 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@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

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] [xen-unstable] [Linux] [TPM driver] Resume frontend after checkpointing, Xen patchbot-unstable <=