* vTPM detaching issue
@ 2016-06-13 15:10 Andrea Genuise
2016-06-14 8:29 ` Xu, Quan
2016-06-14 9:15 ` Wei Liu
0 siblings, 2 replies; 7+ messages in thread
From: Andrea Genuise @ 2016-06-13 15:10 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 3157 bytes --]
I'm not sure if this is a bug or my fault, but when I create a domain
with a vTPM attached, detaching it sometimes causes the following error
to be thrown (I post the command sequence):
[root@localhost ~]# xl create /etc/xen/vtpmmgr-stubdom
Parsing config from /etc/xen/vtpmmgr-stubdom
[root@localhost ~]# xl create /etc/xen/vtpm1
Parsing config from /etc/xen/vtpm1
[root@localhost ~]# xl create /etc/xen/dom1_ima
Parsing config from /etc/xen/dom1_ima
[root@localhost ~]# xl vtpm-detach dom1 vtpm1
[root@localhost ~]# xl destroy dom1
[root@localhost ~]# xl vtpm-detach vtpm1 vtpmmgr
libxl: error: libxl_device.c:952:device_backend_callback: unable to
remove device with path /local/domain/18/backend/vtpm/19/0
libxl: error: libxl.c:1995:device_addrm_aocomplete: unable to remove
vtpm with id 0
libxl_device_vtpm_remove failed.
Sometimes the error is raised while detaching vtpmmgr from vtpm (as
reported), other times while detaching vtpm from domain. I think
this could be a synchronization problem.
I report some info:
[root@localhost ~]# xl info
host : localhost.localdomain
release : 3.18.25-19.without_tpm.el7.centos.x86_64
version : #1 SMP Sun Apr 10 18:10:14 CEST 2016
machine : x86_64
nr_cpus : 2
max_cpu_id : 3
nr_nodes : 1
cores_per_socket : 2
threads_per_core : 1
cpu_mhz : 2394
hw_caps :
bfebfbff:20100800:00000000:00000900:0408e3fd:00000000:00000001:00000000
virt_caps : hvm hvm_directio
total_memory : 3996
free_memory : 2888
sharing_freed_memory : 0
sharing_used_memory : 0
outstanding_claims : 0
free_cpus : 0
xen_major : 4
xen_minor : 6
xen_extra : .1-5.el7
xen_version : 4.6.1-5.el7
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler : credit
xen_pagesize : 4096
platform_params : virt_start=0xffff800000000000
xen_changeset : Tue Mar 29 11:02:43 2016 +0100 git:8210a62-dirty
xen_commandline : placeholder dom0_mem=1024M,max:1024M cpuinfo
com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all
cc_compiler : gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
cc_compile_by : mockbuild
cc_compile_domain : centos.org
cc_compile_date : Tue Mar 29 12:15:50 UTC 2016
xend_config_format : 4
[root@localhost ~]# cat /etc/xen/vtpmmgr-stubdom
name = "vtpmmgr"
kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
memory=16
disk=["file:/srv/xen/vtpmmgr-stubdom.img,hda,w"]
iomem=["fed40,5"]
[root@localhost ~]# cat /etc/xen/vtpm1
name="vtpm1"
kernel="/usr/lib/xen/boot/vtpm-stubdom.gz"
memory=8
disk=["file:/srv/xen/vtpm1.img,hda,w"]
vtpm=["backend=vtpmmgr,uuid=8aca22b3-768a-41e7-b2cb-123d23901996"]
[root@localhost ~]# cat /etc/xen/dom1_ima
kernel = "/srv/xen/vmlinuz-xen"
ramdisk = "/srv/xen/initrd-xen"
name = "dom1"
memory = "512"
disk = [ 'tap:aio:/srv/xen/dom1.img,xvda1,w' ]
vcpus=1
root = '/dev/xvda1 ro'
extra = 'ima_tcb'
vtpm=['backend=vtpm1']
[-- Attachment #1.2: Type: text/html, Size: 3639 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: vTPM detaching issue
2016-06-13 15:10 vTPM detaching issue Andrea Genuise
@ 2016-06-14 8:29 ` Xu, Quan
2016-06-14 9:15 ` Wei Liu
1 sibling, 0 replies; 7+ messages in thread
From: Xu, Quan @ 2016-06-14 8:29 UTC (permalink / raw)
To: Andrea Genuise, xen-devel; +Cc: dgdegra
On June 13, 2016 11:11 PM, Andrea Genuise <and.genuise@gmail.com> wrote:
> I'm not sure if this is a bug or my fault, but when I create a domain
> with a vTPM attached, detaching it sometimes causes the following error
> to be thrown (I post the command sequence):
>
I am afraid this is not a bug. As 'xl vtpm-detach' is to - destroy a domain's virtual TPM device.
Based on your record, ...
> [root@localhost ~]# xl create /etc/xen/vtpmmgr-stubdom
> Parsing config from /etc/xen/vtpmmgr-stubdom
> [root@localhost ~]# xl create /etc/xen/vtpm1
> Parsing config from /etc/xen/vtpm1
> [root@localhost ~]# xl create /etc/xen/dom1_ima
> Parsing config from /etc/xen/dom1_ima
> [root@localhost ~]# xl vtpm-detach dom1 vtpm1
... here, you have detached vtpm on success.
> [root@localhost ~]# xl destroy dom1
> [root@localhost ~]# xl vtpm-detach vtpm1 vtpmmgr
IMO, vtpm-detach doesn't support between vtpm stubdom and vtpmmgr stubdom.
Thanks
Quan Xu
> libxl: error: libxl_device.c:952:device_backend_callback: unable to
> remove device with path /local/domain/18/backend/vtpm/19/0
> libxl: error: libxl.c:1995:device_addrm_aocomplete: unable to remove
> vtpm with id 0
> libxl_device_vtpm_remove failed.
>
> Sometimes the error is raised while detaching vtpmmgr from vtpm (as
> reported), other times while detaching vtpm from domain. I think
> this could be a synchronization problem.
>
> I report some info:
>
> [root@localhost ~]# xl info
> host : localhost.localdomain
> release : 3.18.25-19.without_tpm.el7.centos.x86_64
> version : #1 SMP Sun Apr 10 18:10:14 CEST 2016
> machine : x86_64
> nr_cpus : 2
> max_cpu_id : 3
> nr_nodes : 1
> cores_per_socket : 2
> threads_per_core : 1
> cpu_mhz : 2394
> hw_caps : bfebfbff:20100800:00000000:00000900:0408e3fd:00000000:00000001:00000000
> virt_caps : hvm hvm_directio
> total_memory : 3996
> free_memory : 2888
> sharing_freed_memory : 0
> sharing_used_memory : 0
> outstanding_claims : 0
> free_cpus : 0
> xen_major : 4
> xen_minor : 6
> xen_extra : .1-5.el7
> xen_version : 4.6.1-5.el7
> xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler : credit
> xen_pagesize : 4096
> platform_params : virt_start=0xffff800000000000
> xen_changeset : Tue Mar 29 11:02:43 2016 +0100 git:8210a62-dirty
> xen_commandline : placeholder dom0_mem=1024M,max:1024M cpuinfo com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all
> cc_compiler : gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
> cc_compile_by : mockbuild
> cc_compile_domain : centos.org
> cc_compile_date : Tue Mar 29 12:15:50 UTC 2016
> xend_config_format : 4
>
> [root@localhost ~]# cat /etc/xen/vtpmmgr-stubdom
> name = "vtpmmgr"
> kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
> memory=16
> disk=["file:/srv/xen/vtpmmgr-stubdom.img,hda,w"]
> iomem=["fed40,5"]
>
> [root@localhost ~]# cat /etc/xen/vtpm1
> name="vtpm1"
> kernel="/usr/lib/xen/boot/vtpm-stubdom.gz"
> memory=8
> disk=["file:/srv/xen/vtpm1.img,hda,w"]
> vtpm=["backend=vtpmmgr,uuid=8aca22b3-768a-41e7-b2cb-123d23901996"]
>
> [root@localhost ~]# cat /etc/xen/dom1_ima
> kernel = "/srv/xen/vmlinuz-xen"
> ramdisk = "/srv/xen/initrd-xen"
> name = "dom1"
> memory = "512"
> disk = [ 'tap:aio:/srv/xen/dom1.img,xvda1,w' ]
> vcpus=1
> root = '/dev/xvda1 ro'
> extra = 'ima_tcb'
> vtpm=['backend=vtpm1']
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: vTPM detaching issue
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
1 sibling, 1 reply; 7+ messages in thread
From: Wei Liu @ 2016-06-14 9:15 UTC (permalink / raw)
To: Andrea Genuise; +Cc: dgdegra, Wei Liu, quan.xu, xen-devel
On Mon, Jun 13, 2016 at 05:10:35PM +0200, Andrea Genuise wrote:
> I'm not sure if this is a bug or my fault, but when I create a domain
> with a vTPM attached, detaching it sometimes causes the following error
> to be thrown (I post the command sequence):
>
> [root@localhost ~]# xl create /etc/xen/vtpmmgr-stubdom
> Parsing config from /etc/xen/vtpmmgr-stubdom
> [root@localhost ~]# xl create /etc/xen/vtpm1
> Parsing config from /etc/xen/vtpm1
> [root@localhost ~]# xl create /etc/xen/dom1_ima
> Parsing config from /etc/xen/dom1_ima
> [root@localhost ~]# xl vtpm-detach dom1 vtpm1
> [root@localhost ~]# xl destroy dom1
> [root@localhost ~]# xl vtpm-detach vtpm1 vtpmmgr
> libxl: error: libxl_device.c:952:device_backend_callback: unable to
> remove device with path /local/domain/18/backend/vtpm/19/0
> libxl: error: libxl.c:1995:device_addrm_aocomplete: unable to remove
> vtpm with id 0
> libxl_device_vtpm_remove failed.
>
Can you try xl -vvv vtpm-detach to get more information?
Also CC VTPM maintainers.
> Sometimes the error is raised while detaching vtpmmgr from vtpm (as
> reported), other times while detaching vtpm from domain. I think
> this could be a synchronization problem.
>
> I report some info:
>
> [root@localhost ~]# xl info
> host : localhost.localdomain
> release : 3.18.25-19.without_tpm.el7.centos.x86_64
> version : #1 SMP Sun Apr 10 18:10:14 CEST 2016
> machine : x86_64
> nr_cpus : 2
> max_cpu_id : 3
> nr_nodes : 1
> cores_per_socket : 2
> threads_per_core : 1
> cpu_mhz : 2394
> hw_caps :
> bfebfbff:20100800:00000000:00000900:0408e3fd:00000000:00000001:00000000
> virt_caps : hvm hvm_directio
> total_memory : 3996
> free_memory : 2888
> sharing_freed_memory : 0
> sharing_used_memory : 0
> outstanding_claims : 0
> free_cpus : 0
> xen_major : 4
> xen_minor : 6
> xen_extra : .1-5.el7
> xen_version : 4.6.1-5.el7
> xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler : credit
> xen_pagesize : 4096
> platform_params : virt_start=0xffff800000000000
> xen_changeset : Tue Mar 29 11:02:43 2016 +0100 git:8210a62-dirty
> xen_commandline : placeholder dom0_mem=1024M,max:1024M cpuinfo
> com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all
> cc_compiler : gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
> cc_compile_by : mockbuild
> cc_compile_domain : centos.org
> cc_compile_date : Tue Mar 29 12:15:50 UTC 2016
> xend_config_format : 4
>
> [root@localhost ~]# cat /etc/xen/vtpmmgr-stubdom
> name = "vtpmmgr"
> kernel="/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
> memory=16
> disk=["file:/srv/xen/vtpmmgr-stubdom.img,hda,w"]
> iomem=["fed40,5"]
>
> [root@localhost ~]# cat /etc/xen/vtpm1
> name="vtpm1"
> kernel="/usr/lib/xen/boot/vtpm-stubdom.gz"
> memory=8
> disk=["file:/srv/xen/vtpm1.img,hda,w"]
> vtpm=["backend=vtpmmgr,uuid=8aca22b3-768a-41e7-b2cb-123d23901996"]
>
> [root@localhost ~]# cat /etc/xen/dom1_ima
> kernel = "/srv/xen/vmlinuz-xen"
> ramdisk = "/srv/xen/initrd-xen"
> name = "dom1"
> memory = "512"
> disk = [ 'tap:aio:/srv/xen/dom1.img,xvda1,w' ]
> vcpus=1
> root = '/dev/xvda1 ro'
> extra = 'ima_tcb'
> vtpm=['backend=vtpm1']
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: vTPM detaching issue
2016-06-14 9:15 ` Wei Liu
@ 2016-06-14 10:32 ` Andrea Genuise
2016-06-15 11:48 ` Wei Liu
0 siblings, 1 reply; 7+ messages in thread
From: Andrea Genuise @ 2016-06-14 10:32 UTC (permalink / raw)
To: Wei Liu; +Cc: dgdegra, quan.xu, xen-devel
On 14/06/2016 10:29, Xu, Quan wrote:
> On June 13, 2016 11:11 PM, Andrea Genuise <and.genuise@gmail.com> wrote:
>> I'm not sure if this is a bug or my fault, but when I create a domain
>> with a vTPM attached, detaching it sometimes causes the following error
>> to be thrown (I post the command sequence):
>>
> I am afraid this is not a bug. As 'xl vtpm-detach' is to - destroy a domain's virtual TPM device.
> Based on your record, ...
>
>> [root@localhost ~]# xl create /etc/xen/vtpmmgr-stubdom
>> Parsing config from /etc/xen/vtpmmgr-stubdom
>> [root@localhost ~]# xl create /etc/xen/vtpm1
>> Parsing config from /etc/xen/vtpm1
>> [root@localhost ~]# xl create /etc/xen/dom1_ima
>> Parsing config from /etc/xen/dom1_ima
>> [root@localhost ~]# xl vtpm-detach dom1 vtpm1
> ... here, you have detached vtpm on success.
>
>> [root@localhost ~]# xl destroy dom1
>> [root@localhost ~]# xl vtpm-detach vtpm1 vtpmmgr
> IMO, vtpm-detach doesn't support between vtpm stubdom and vtpmmgr stubdom.
>
> Thanks
> Quan Xu
This was just a case, see my new record below.
On 14/06/2016 11:15, Wei Liu wrote:
> On Mon, Jun 13, 2016 at 05:10:35PM +0200, Andrea Genuise wrote:
>> I'm not sure if this is a bug or my fault, but when I create a domain
>> with a vTPM attached, detaching it sometimes causes the following error
>> to be thrown (I post the command sequence):
>>
>> [root@localhost ~]# xl create /etc/xen/vtpmmgr-stubdom
>> Parsing config from /etc/xen/vtpmmgr-stubdom
>> [root@localhost ~]# xl create /etc/xen/vtpm1
>> Parsing config from /etc/xen/vtpm1
>> [root@localhost ~]# xl create /etc/xen/dom1_ima
>> Parsing config from /etc/xen/dom1_ima
>> [root@localhost ~]# xl vtpm-detach dom1 vtpm1
>> [root@localhost ~]# xl destroy dom1
>> [root@localhost ~]# xl vtpm-detach vtpm1 vtpmmgr
>> libxl: error: libxl_device.c:952:device_backend_callback: unable to
>> remove device with path /local/domain/18/backend/vtpm/19/0
>> libxl: error: libxl.c:1995:device_addrm_aocomplete: unable to remove
>> vtpm with id 0
>> libxl_device_vtpm_remove failed.
>>
> Can you try xl -vvv vtpm-detach to get more information?
>
> Also CC VTPM maintainers.
I tried it, here is the output:
[root@localhost ~]# xl create /etc/xen/vtpmmgr-stubdom
Parsing config from /etc/xen/vtpmmgr-stubdom
[root@localhost ~]# xl create /etc/xen/vtpm1
Parsing config from /etc/xen/vtpm1
[root@localhost ~]# xl create /etc/xen/dom1_ima
Parsing config from /etc/xen/dom1_ima
[root@localhost ~]# xl -vvv vtpm-detach dom1 vtpm1
libxl: debug: libxl.c:4184:libxl_device_vtpm_remove: ao 0x1c4bb60: create:
how=(nil) callback=(nil) poller=0x1c4bda0
libxl: debug: libxl_event.c:639:libxl__ev_xswatch_register: watch
w=0x1c4c1f0
wpath=/local/domain/748/backend/vtpm/749/0/state token=3/0: register
slotnum=3
libxl: debug: libxl.c:4184:libxl_device_vtpm_remove: ao 0x1c4bb60:
inprogress:
poller=0x1c4bda0, flags=i
libxl: debug: libxl_event.c:576:watchfd_callback: watch w=0x1c4c1f0
wpath=/local/domain/748/backend/vtpm/749/0/state token=3/0: event
epath=/local/domain/748/backend/vtpm/749/0/state
libxl: debug: libxl_event.c:884:devstate_callback: backend
/local/domain/748/backend/vtpm/749/0/state wanted state 6 still waiting
state 5
libxl: debug: libxl_event.c:576:watchfd_callback: watch w=0x1c4c1f0
wpath=/local/domain/748/backend/vtpm/749/0/state token=3/0: event
epath=/local/domain/748/backend/vtpm/749/0/state
libxl: debug: libxl_event.c:884:devstate_callback: backend
/local/domain/748/backend/vtpm/749/0/state wanted state 6 still waiting
state 2
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
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
libxl: debug: libxl_event.c:639:libxl__ev_xswatch_register: watch
w=0x1c4c1f0 wpath=/local/domain/748/backend/vtpm/749/0/state token=3/1:
register slotnum=3
libxl: debug: libxl_event.c:576:watchfd_callback: watch w=0x1c4c1f0
wpath=/local/domain/748/backend/vtpm/749/0/state token=3/1: event
epath=/local/domain/748/backend/vtpm/749/0/state
libxl: debug: libxl_event.c:884:devstate_callback: backend
/local/domain/748/backend/vtpm/749/0/state wanted state 6 still waiting
state 5
libxl: debug: libxl_event.c:576:watchfd_callback: watch w=0x1c4c1f0
wpath=/local/domain/748/backend/vtpm/749/0/state token=3/1: event
epath=/local/domain/748/backend/vtpm/749/0/state
libxl: debug: libxl_event.c:872:devstate_callback: backend
/local/domain/748/backend/vtpm/749/0/state wanted state 6 but it was removed
libxl: debug: libxl_event.c:677:libxl__ev_xswatch_deregister: watch
w=0x1c4c1f0
wpath=/local/domain/748/backend/vtpm/749/0/state token=3/1: deregister
slotnum=3
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: error: libxl_device.c:952:device_backend_callback: unable to remove
device with path /local/domain/748/backend/vtpm/749/0
libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch
w=0x1c4c2f0:
deregister unregistered
libxl: error: libxl.c:1995:device_addrm_aocomplete: unable to remove
vtpm with
id 0
libxl: debug: libxl_event.c:1874:libxl__ao_complete: ao 0x1c4bb60: complete,
rc=-6
libxl: debug: libxl_event.c:545:watchfd_callback: watch
epath=/local/domain/748/backend/vtpm/749/0/state token=3/1: empty slot
libxl: debug: libxl_event.c:1843:libxl__ao__destroy: ao 0x1c4bb60: destroy
libxl_device_vtpm_remove failed.
xc: debug: hypercall buffer: total allocations:24 total releases:24
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:15 misses:2 toobig:7
[root@localhost ~]# xl destroy dom1
[root@localhost ~]# xl -vvv vtpm-detach vtpm1 vtpmmgr
libxl: debug: libxl.c:4184:libxl_device_vtpm_remove: ao 0x138ab60: create:
how=(nil) callback=(nil) poller=0x138ada0
libxl: debug: libxl_event.c:639:libxl__ev_xswatch_register: watch
w=0x138b1f0
wpath=/local/domain/747/backend/vtpm/748/0/state token=3/0: register
slotnum=3
libxl: debug: libxl.c:4184:libxl_device_vtpm_remove: ao 0x138ab60:
inprogress:
poller=0x138ada0, flags=i
libxl: debug: libxl_event.c:576:watchfd_callback: watch w=0x138b1f0
wpath=/local/domain/747/backend/vtpm/748/0/state token=3/0: event
epath=/local/domain/747/backend/vtpm/748/0/state
libxl: debug: libxl_event.c:884:devstate_callback: backend
/local/domain/747/backend/vtpm/748/0/state wanted state 6 still waiting
state 5
libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
/local/domain/747/backend/vtpm/748/0/state (hoping for state change to 6):
xswait timeout (path=/local/domain/747/backend/vtpm/748/0/state)
libxl: debug: libxl_event.c:677:libxl__ev_xswatch_deregister: watch
w=0x138b1f0
wpath=/local/domain/747/backend/vtpm/748/0/state token=3/0: deregister
slotnum=3
libxl: debug: libxl_event.c:867:devstate_callback: backend
/local/domain/747/backend/vtpm/748/0/state wanted state 6 timed out
libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch
w=0x138b1f0:
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=0x138b1f0:
deregister unregistered
libxl: debug: libxl_device.c:943:device_backend_callback: Timeout reached,
initiating forced remove
libxl: debug: libxl_event.c:639:libxl__ev_xswatch_register: watch
w=0x138b1f0
wpath=/local/domain/747/backend/vtpm/748/0/state token=3/1: register
slotnum=3
libxl: debug: libxl_event.c:576:watchfd_callback: watch w=0x138b1f0
wpath=/local/domain/747/backend/vtpm/748/0/state token=3/1: event
epath=/local/domain/747/backend/vtpm/748/0/state
libxl: debug: libxl_event.c:884:devstate_callback: backend
/local/domain/747/backend/vtpm/748/0/state wanted state 6 still waiting
state 5
libxl: debug: libxl_event.c:576:watchfd_callback: watch w=0x138b1f0
wpath=/local/domain/747/backend/vtpm/748/0/state token=3/1: event
epath=/local/domain/747/backend/vtpm/748/0/state
libxl: debug: libxl_event.c:880:devstate_callback: backend
/local/domain/747/backend/vtpm/748/0/state wanted state 6 ok
libxl: debug: libxl_event.c:677:libxl__ev_xswatch_deregister: watch
w=0x138b1f0
wpath=/local/domain/747/backend/vtpm/748/0/state token=3/1: deregister
slotnum=3
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=0x138b1f0:
deregister unregistered
libxl: debug: libxl_device.c:992:device_hotplug: Backend domid 747, domid 0,
assuming driver domains
libxl: debug: libxl_event.c:639:libxl__ev_xswatch_register: watch
w=0x138b2f0
wpath=/local/domain/747/backend/vtpm/748/0 token=3/2: register slotnum=3
libxl: debug: libxl_event.c:551:watchfd_callback: watch w=0x138b2f0
epath=/local/domain/747/backend/vtpm/748/0/state token=3/1: counter != 2
libxl: debug: libxl_event.c:576:watchfd_callback: watch w=0x138b2f0
wpath=/local/domain/747/backend/vtpm/748/0 token=3/2: event
epath=/local/domain/747/backend/vtpm/748/0
libxl: debug: libxl_event.c:677:libxl__ev_xswatch_deregister: watch
w=0x138b2f0
wpath=/local/domain/747/backend/vtpm/748/0 token=3/2: deregister slotnum=3
libxl: debug: libxl_event.c:1874:libxl__ao_complete: ao 0x138ab60:
complete, rc=0
libxl: debug: libxl_event.c:1843:libxl__ao__destroy: ao 0x138ab60: destroy
xc: debug: hypercall buffer: total allocations:22 total releases:22
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:14 misses:2 toobig:6
[root@localhost ~]# xl destroy vtpm1
[root@localhost ~]# xl destroy vtpmmgr
Thanks,
Andrea Genuise
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: vTPM detaching issue
2016-06-14 10:32 ` Andrea Genuise
@ 2016-06-15 11:48 ` Wei Liu
2016-06-29 7:51 ` FW: " Xu, Quan
0 siblings, 1 reply; 7+ messages in thread
From: Wei Liu @ 2016-06-15 11:48 UTC (permalink / raw)
To: Andrea Genuise; +Cc: dgdegra, Wei Liu, quan.xu, xen-devel
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.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* FW: vTPM detaching issue
2016-06-15 11:48 ` Wei Liu
@ 2016-06-29 7:51 ` Xu, Quan
2016-06-29 15:28 ` Daniel De Graaf
0 siblings, 1 reply; 7+ messages in thread
From: Xu, Quan @ 2016-06-29 7:51 UTC (permalink / raw)
To: dgdegra; +Cc: Andrea Genuise, Wei Liu, Xu, Quan, xen-devel
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: FW: vTPM detaching issue
2016-06-29 7:51 ` FW: " Xu, Quan
@ 2016-06-29 15:28 ` Daniel De Graaf
0 siblings, 0 replies; 7+ messages in thread
From: Daniel De Graaf @ 2016-06-29 15:28 UTC (permalink / raw)
To: Xu, Quan; +Cc: Andrea Genuise, Wei Liu, xen-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-06-29 15:28 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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).