On 06/29/2016 03:51 AM, Xu, Quan wrote:
On June 15, 2016 7:49 PM, < wei.l...@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
