xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: "Xu, Quan" <quan.xu@intel.com>
Cc: Andrea Genuise <and.genuise@gmail.com>,
	Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: FW:  vTPM detaching issue
Date: Wed, 29 Jun 2016 11:28:58 -0400	[thread overview]
Message-ID: <3e324eaa-1477-a0b4-6c83-9f71424b3f7c@tycho.nsa.gov> (raw)
In-Reply-To: <945CA011AD5F084CBEA3E851C0AB28894B8F7991@SHSMSX101.ccr.corp.intel.com>

On 06/29/2016 03:51 AM, Xu, Quan wrote:
> On June 15, 2016 7:49 PM, < wei.liu2@citrix.com > wrote:
>> On Tue, Jun 14, 2016 at 12:32:19PM +0200, Andrea Genuise wrote:
>> [...]
>>> libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
>>> /local/domain/748/backend/vtpm/749/0/state (hoping for state change to
>> 6):
>>> xswait timeout (path=/local/domain/748/backend/vtpm/749/0/state)
>>> libxl: debug: libxl_event.c:677:libxl__ev_xswatch_deregister: watch
>>> w=0x1c4c1f0 wpath=/local/domain/748/backend/vtpm/749/0/state
>> token=3/0:
>>> deregister slotnum=3
>>> libxl: debug: libxl_event.c:867:devstate_callback: backend
>>> /local/domain/748/backend/vtpm/749/0/state wanted state 6  timed out
>> This. The toolstack is waiting for the state to change to 6. But that never
>> happened.
>>> libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch
>>> w=0x1c4c1f0: deregister unregistered
>>> libxl: debug: libxl_device.c:937:device_backend_callback: calling
>>> device_backend_cleanup
>>> libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch
>>> w=0x1c4c1f0: deregister unregistered
>>> libxl: debug: libxl_device.c:943:device_backend_callback: Timeout
>>> reached, initiating forced remove
>> I think this is due to interaction between frontend and backend, but I'm not an
>> expert on vtpm so I don't have further comment.
> Daniel,  are you following this issue?  --Quan

I am, but I haven't had a chance to look at what is happening with the state
changes.  There are few, if any, use cases that actually need the ability to
remove a vTPM without destroying the client domain (or the driver domain),
so I don't think this ever got tested.  I am guessing that the minios and/or
Linux driver is missing a state change step.

Daniel De Graaf
National Security Agency

Xen-devel mailing list

      reply	other threads:[~2016-06-29 15:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-13 15:10 vTPM detaching issue Andrea Genuise
2016-06-14  8:29 ` Xu, Quan
2016-06-14  9:15 ` Wei Liu
2016-06-14 10:32   ` Andrea Genuise
2016-06-15 11:48     ` Wei Liu
2016-06-29  7:51       ` FW: " Xu, Quan
2016-06-29 15:28         ` Daniel De Graaf [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3e324eaa-1477-a0b4-6c83-9f71424b3f7c@tycho.nsa.gov \
    --to=dgdegra@tycho.nsa.gov \
    --cc=and.genuise@gmail.com \
    --cc=quan.xu@intel.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).