[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] FW: vTPM detaching issue
On 06/29/2016 03:51 AM, Xu, Quan wrote: On June 15, 2016 7:49 PM, < wei.liu2@xxxxxxxxxx > 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 to6):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/statetoken=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 outThis. 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 removeI 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@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |