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
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
prev parent 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* 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 \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).