|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] regarding vtpm setup
Hello, Thank you for your response. On 4 March 2014 21:39, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote: > On 03/04/2014 08:46 AM, George Dunlap wrote: >> >> On Tue, Mar 4, 2014 at 11:32 AM, Aastha Mehta <aasthakm@xxxxxxxxx> wrote: >>> >>> Hello, >>> >>> On 1 March 2014 19:43, Aastha Mehta <aasthakm@xxxxxxxxx> wrote: >>>> >>>> Hello, >>>> >>>> I am trying to setup vtpmmgr and vtpm on the latest custom built >>>> xen-4.4 and I am following the steps provided at this link - >>>> http://xenbits.xen.org/docs/unstable/misc/vtpm.txt >>>> >>>> When I create the vtpmmgr domain, following is a snippet of the output >>>> that I see: >>>> >>>> ******************* BLKFRONT for device/vbd/768 ********** >>>> backend at /local/domain/0/backend/qdisk/2/768 >>>> Failed to read /local/domain/0/backend/qdisk/2/768/feature-barrier. >>>> 32768 sectors of 512 bytes >>>> ************************** >>>> >>>> and xl dmesg shows the following: >>>> (XEN) event_channel.c:271:d0 EVTCHNOP failure: domain 2, error -22 >>>> (XEN) event_channel.c:271:d0 EVTCHNOP failure: domain 2, error -22 > > > This seems to be an error due to a mismatch in the event channel domain > that is being expected as the backend for some device. Can you share the > domain .cfg contents? > I created the vtpmmgr, the vtpm and the guest again and I do not see these error messages anymore. > >>>> >>>> Next, when I create vtpm domain, following is the snippet of the >>>> output on the vtpm console: >>>> >>>> ******************* BLKFRONT for device/vbd/768 ********** >>>> backend at /local/domain/0/backend/qdisk/3/768 >>>> Failed to read /local/domain/0/backend/qdisk/3/768/feature-barrier. >>>> 16384 sectors of 512 bytes >>>> ************************** >>>> vtpm_cmd.c:155: Info: Requesting Encryption key from backend >>>> vtpm_cmd.c:164: Error: VTPM_LoadHashKey() failed with error code (3) >>>> vtpm_cmd.c:175: Error: VTPM_LoadHashKey failed >>>> tpm_data.c:120: Info: initializing TPM data to default values > > > This is expected on the first run: no keys are available yet. > > >>>> >>>> This is the vtpmmgr output: >>>> >>>> Tpmback:Info Frontend 3/0 connected >>>> INFO[VTPM]: Passthrough: TPM_GetRandom >>>> INFO[VTPM]: Waiting for commands from vTPM's: >>>> INFO[VTPM]: Passthrough: TPM_GetRandom >>>> INFO[VTPM]: Waiting for commands from vTPM's: >>>> ERROR[VTPM]: LoadKey failure: Unrecognized uuid! >>>> c606b894-14e7-44db-bdcc-4ae05d686784 >>>> ERROR[VTPM]: Failed to load key >>>> ERROR in vtpmmgr_LoadHashKey at vtpm_cmd_handler.c:78 code: >>>> TPM_BAD_PARAMETER. > > > Similarly, on the first use of a vTPM, this is expected. > > >>>> INFO[VTPM]: Waiting for commands from vTPM's: >>>> INFO[VTPM]: Registered vtpm c606b894-14e7-44db-bdcc-4ae05d686784 >>>> INFO[VTPM]: Generating a new symmetric key >>>> INFO[VTPM]: Binding encrypted key >>>> INFO[TPM]: TPM_Bind >>>> INFO[VTPM]: Encrypting the uuid table >>>> INFO[TPM]: TPM_Bind >>>> INFO[VTPM]: Saved hash and key for vtpm >>>> c606b894-14e7-44db-bdcc-4ae05d686784 >>>> INFO[VTPM]: Waiting for commands from vTPM's: >>>> INFO[TPM]: TPM_Bind >>>> INFO[VTPM]: Saved hash and key for vtpm >>>> c606b894-14e7-44db-bdcc-4ae05d686784 >>>> INFO[VTPM]: Waiting for commands from vTPM's: >>>> >>>> >>>> This is the xl dmesg output: >>>> (d3) ============= Init TPM BACK ================ >>>> (d3) Thread "tpmback-listener": pointer: 0x2000802fb0, stack: 0x130000 >>>> (d3) ============= Init TPM Front ================ >>>> (d3) Tpmfront:Info Waiting for backend connection.. >>>> (d2) Tpmback:Info Frontend 3/0 connected >>>> (d3) Tpmfront:Info Backend Connected >>>> (d3) Tpmfront:Info Initialization Completed successfully >>>> (d3) ******************* BLKFRONT for device/vbd/768 ********** >>>> (d3) backend at /local/domain/0/backend/qdisk/3/768 >>>> (d3) Failed to read /local/domain/0/backend/qdisk/3/768/feature-barrier. >>>> (d3) 16384 sectors of 512 bytes >>>> (d3) ************************** >>>> (d3) blk_open(device/vbd/768) -> 3 >>>> >>>> >>>> Finally, when I try to create the guest domain, I again see the >>>> following error in xl dmesg: >>>> >>>> (XEN) event_channel.c:271:d0 EVTCHNOP failure: domain 4, error -22 >>>> (XEN) event_channel.c:271:d0 EVTCHNOP failure: domain 4, error -22 >>>> (XEN) event_channel.c:271:d0 EVTCHNOP failure: domain 4, error -22 > > > This might indicate that these errors are caused by xl and not mini-os; > are you trying to use a driver domain that is not running? > Each of these errors showed up on trying to boot the particular domain. Earlier I saw "EVTCHNOP failure: domain 2", which was the vtpmmgr I was trying to create. "EVTCHNOP failure: domain 4" showed up when I was trying to create the guest domain. So, it seemed a bit strange to see these errors when the domain is still booting up (of course it is not running yet). But again, this error does not appear anymore. I don't know if this is something that happens at the time of creating the vtpm and its guest for the first time. > >>>> (d4) mapping kernel into physical memory >>>> (d4) about to get started... >>>> (d3) Tpmback:Info Frontend 4/0 connected >>>> >>>> I have the following config parameters in the dom0 and domU kernels >>>> (ubuntu 12.04): >>>> >>>> dom0 (kernel 3.13.2): >>>> CONFIG_TCG_TPM=y >>>> CONFIG_TCG_XEN=m >>>> >>>> domU (kernel 3.13.5): >>>> CONFIG_TCG_TPM=y >>>> CONFIG_TCG_XEN=y >>>> >>>> I believe the setup is not working correctly. Could someone let me >>>> know what is wrong? Please let me know if I must provide any further >>>> details. > > > Have you tested to see if the vTPM shows up in the guest? If so, can you use > it? > I can see /dev/tpm0 in the guest. And I am able to use the vtpm in the guest So far, I did only tpm_version, but I see messages showing up on the vtpm and the vtpmmgr console. > What do the Xenstore entries for the vtpm devices look like (from > xenstore-ls)? > > Do the event channels there match with the event channel dump (xl debug-key > e)? > I see a lot of entries in xl debug-keys dump. I can match all the event channels in the xenstore entries with the ones from xl debug-keys dump. However, there are some entries in xl debug-keys which I cannot find in xenstore. I do not understand what those are.. The ones that match are appended with "<<". Note, vtpmmgr = domid 2, vtpm = domid 3, guest = domid 4. (XEN) 'e' pressed -> dumping event-channel info (XEN) Event channel information for domain 0: (XEN) Polling vCPUs: {} (XEN) port [p/m/s] (XEN) 1 [0/0/0]: s=5 n=0 x=0 v=0 (XEN) 2 [1/1/0]: s=6 n=0 x=0 (XEN) 3 [0/0/0]: s=6 n=0 x=0 (XEN) 4 [0/0/0]: s=6 n=0 x=0 (XEN) 5 [0/0/0]: s=5 n=0 x=0 v=1 (XEN) 6 [0/0/0]: s=6 n=0 x=0 (XEN) 7 [0/0/0]: s=6 n=0 x=0 (XEN) 8 [0/0/0]: s=5 n=1 x=0 v=0 (XEN) 9 [1/1/0]: s=6 n=1 x=0 (XEN) 10 [0/0/0]: s=6 n=1 x=0 (XEN) 11 [0/0/0]: s=6 n=1 x=0 (XEN) 12 [0/0/0]: s=5 n=1 x=0 v=1 (XEN) 13 [0/0/0]: s=6 n=1 x=0 (XEN) 14 [0/0/0]: s=6 n=1 x=0 (XEN) 15 [0/0/0]: s=5 n=2 x=0 v=0 (XEN) 16 [1/1/0]: s=6 n=2 x=0 (XEN) 17 [0/0/0]: s=6 n=2 x=0 (XEN) 18 [0/0/0]: s=6 n=2 x=0 (XEN) 19 [0/0/0]: s=5 n=2 x=0 v=1 (XEN) 20 [0/0/0]: s=6 n=2 x=0 (XEN) 21 [0/0/0]: s=6 n=2 x=0 (XEN) 22 [0/0/0]: s=5 n=3 x=0 v=0 (XEN) 23 [1/1/0]: s=6 n=3 x=0 (XEN) 24 [0/0/0]: s=6 n=3 x=0 (XEN) 25 [0/0/0]: s=6 n=3 x=0 (XEN) 26 [0/0/0]: s=5 n=3 x=0 v=1 (XEN) 27 [0/0/0]: s=6 n=3 x=0 (XEN) 28 [0/0/0]: s=6 n=3 x=0 (XEN) 29 [0/0/0]: s=3 n=0 x=0 d=0 p=44 (XEN) 30 [0/0/0]: s=5 n=0 x=0 v=9 (XEN) 31 [1/0/0]: s=4 n=2 x=0 p=9 i=9 (XEN) 32 [0/0/0]: s=5 n=0 x=0 v=16 (XEN) 33 [0/1/0]: s=5 n=0 x=0 v=2 (XEN) 34 [0/0/0]: s=4 n=1 x=0 p=16 i=16 (XEN) 35 [0/0/0]: s=4 n=0 x=0 p=23 i=23 (XEN) 36 [0/0/0]: s=4 n=0 x=0 p=278 i=26 (XEN) 37 [0/0/0]: s=4 n=0 x=0 p=12 i=12 (XEN) 38 [0/0/0]: s=4 n=0 x=0 p=1 i=1 (XEN) 39 [0/0/0]: s=4 n=0 x=0 p=8 i=8 (XEN) 40 [0/0/0]: s=4 n=1 x=0 p=277 i=27 (XEN) 41 [0/0/0]: s=4 n=0 x=0 p=276 i=28 (XEN) 42 [0/0/0]: s=4 n=0 x=0 p=275 i=29 (XEN) 43 [0/0/0]: s=4 n=3 x=0 p=274 i=30 (XEN) 44 [0/0/0]: s=3 n=0 x=0 d=0 p=29 (XEN) 45 [0/0/0]: s=5 n=0 x=0 v=3 (XEN) 46 [0/0/0]: s=3 n=0 x=0 d=2 p=1 << (XEN) 47 [0/0/0]: s=3 n=0 x=0 d=2 p=2 (XEN) 48 [0/0/0]: s=3 n=0 x=0 d=2 p=4 << (XEN) 49 [0/0/0]: s=3 n=0 x=0 d=3 p=1 << (XEN) 50 [0/0/0]: s=3 n=0 x=0 d=3 p=2 (XEN) 51 [0/0/0]: s=3 n=0 x=0 d=3 p=5 << (XEN) 52 [0/0/0]: s=3 n=0 x=0 d=4 p=1 << (XEN) 53 [0/0/0]: s=3 n=0 x=0 d=4 p=2 (XEN) 54 [0/0/0]: s=3 n=0 x=0 d=4 p=11 << (XEN) 55 [0/0/0]: s=3 n=0 x=0 d=4 p=12 << (XEN) 56 [0/0/0]: s=3 n=0 x=0 d=4 p=13 << (XEN) 57 [0/0/0]: s=3 n=0 x=0 d=4 p=14 << (XEN) Event channel information for domain 2: (XEN) Polling vCPUs: {} (XEN) port [p/m/s] (XEN) 1 [0/0/0]: s=3 n=0 x=0 d=0 p=46 (XEN) 2 [0/0/0]: s=3 n=0 x=0 d=0 p=47 (XEN) 3 [0/0/0]: s=5 n=0 x=0 v=0 (XEN) 4 [0/0/0]: s=3 n=0 x=0 d=0 p=48 (XEN) 5 [0/0/0]: s=3 n=0 x=0 d=3 p=4 << (XEN) Event channel information for domain 3: (XEN) Polling vCPUs: {} (XEN) port [p/m/s] (XEN) 1 [0/0/0]: s=3 n=0 x=0 d=0 p=49 (XEN) 2 [0/0/0]: s=3 n=0 x=0 d=0 p=50 (XEN) 3 [0/0/0]: s=5 n=0 x=0 v=0 (XEN) 4 [0/0/0]: s=3 n=0 x=0 d=2 p=5 << (XEN) 5 [0/0/0]: s=3 n=0 x=0 d=0 p=51 (XEN) 6 [0/0/0]: s=3 n=0 x=0 d=4 p=10 << (XEN) Event channel information for domain 4: (XEN) Polling vCPUs: {} (XEN) port [p/m/s] (XEN) 1 [0/0/0]: s=3 n=0 x=0 d=0 p=52 (XEN) 2 [0/0/0]: s=3 n=0 x=0 d=0 p=53 (XEN) 3 [0/0/0]: s=5 n=0 x=0 v=0 (XEN) 4 [0/1/0]: s=6 n=0 x=0 (XEN) 5 [0/0/0]: s=6 n=0 x=0 (XEN) 6 [0/0/0]: s=6 n=0 x=0 (XEN) 7 [0/0/0]: s=5 n=0 x=0 v=1 (XEN) 8 [0/0/0]: s=6 n=0 x=0 (XEN) 9 [0/0/0]: s=6 n=0 x=0 (XEN) 10 [0/0/0]: s=3 n=0 x=0 d=3 p=6 << (XEN) 11 [0/0/0]: s=3 n=0 x=0 d=0 p=54 (XEN) 12 [0/0/0]: s=3 n=0 x=0 d=0 p=55 (XEN) 13 [0/0/0]: s=3 n=0 x=0 d=0 p=56 (XEN) 14 [0/0/0]: s=3 n=0 x=0 d=0 p=57 > >>>> >>>> Thanks in advance. >>>> >>>> Regards, >>>> Aastha Mehta. >>> >>> >>> A gentle reminder on this query. Please let me know if this query >>> belongs to the xen-users list and if I should post there. >> >> >> Daniel, any ideas? >> >> (Also, Aastha: pinging is good practice, but most developers only work >> on the weekdays, so AFAICT it's only been one working day since they >> might have seen your initial message.) >> >> -George > > > PS: Due to the interference of snow, I only saw this thread today. > > -- > Daniel De Graaf > National Security Agency Thank you for your help. Regards, Aastha _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |