* vTPM Manager shuts down
@ 2013-04-18 11:16 Jordi Cucurull Juan
2013-04-18 14:41 ` Daniel De Graaf
0 siblings, 1 reply; 10+ messages in thread
From: Jordi Cucurull Juan @ 2013-04-18 11:16 UTC (permalink / raw)
To: xen-devel@lists.xen.org; +Cc: Jordi Cucurull Juan
Hi all,
I am trying to set up the development version of Xen with support for
virtual TPMs. I am having an issue starting the vTPM Manager. Basically
I create the vTPM Manager stub domain as detailed in the documentation:
make install-vtpmmgr
dd if=/dev/zero of=/var/xen/vtpmmgr-stubdom.img bs=16M count=1
vim /etc/xen/vtpmmgr-stubdom.cfg
kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz"
memory=16
disk=["file:/var/xen/vtpmmgr-stubdom.img,hda,w"]
name="vtpmmgr"
iomem=["fed40,5"]
xl create -c /etc/xen/vtpmmgr-stubdom.cfg
Nevertheless, when the stub domain is launched it automatically shuts
down (see the trace below). Am I doing something wrong? Is there
something that can produce this behaviour?
Daemon running with PID 6347
Xen Minimal OS!
start_info: 0xa3000(VA)
nr_pages: 0x1000
shared_inf: 0xcaff0000(MA)
pt_base: 0xa6000(VA)
nr_pt_frames: 0x5
mfn_list: 0x9b000(VA)
mod_start: 0x0(VA)
mod_len: 0
flags: 0x0
cmd_line:
stack: 0x5a7a0-0x7a7a0
MM: Init
_text: 0x0(VA)
_etext: 0x397f4(VA)
_erodata: 0x46000(VA)
_edata: 0x48c00(VA)
stack start: 0x5a7a0(VA)
_end: 0x9adc0(VA)
start_pfn: ae
max_pfn: 1000
Mapping memory range 0x400000 - 0x1000000
setting 0x0-0x46000 readonly
skipped 0x1000
MM: Initialise page allocator for b4000(b4000)-1000000(1000000)
MM: done
Demand map pfns at 1001000-2001001000.
Heap resides at 2001002000-4001002000.
Initialising timer interface
Initialising console ... done.
gnttab_table mapped at 0x1001000.
Initialising scheduler
Thread "Idle": pointer: 0x2001002050, stack: 0xd0000
Thread "xenstore": pointer: 0x2001002800, stack: 0xe0000
xenbus initialised on irq 1 mfn 0x224faa
Thread "shutdown": pointer: 0x2001002fb0, stack: 0xf0000
Dummy main: start_info=0x7a8a0
Thread "main": pointer: 0x2001003760, stack: 0x100000
"main"
Shutting down ()
Shutdown requested: 3
Thread "shutdown" exited.
INFO[VTPM]: Starting vTPM manager domain
INFO[VTPM]: Option: Using tpm_tis driver
******************* BLKFRONT for device/vbd/768 **********
backend at /local/domain/0/backend/qdisk/7/768
Failed to read /local/domain/0/backend/qdisk/7/768/feature-barrier.
32768 sectors of 512 bytes
**************************
blk_open(device/vbd/768) -> 3
============= Init TPM BACK ================
Thread "tpmback-listener": pointer: 0x20010043f0, stack: 0xf0000
============= Init TPM TIS Driver ==============
IOMEM Machine Base Address: FED40000
Enabled Localities: 0
Map 1 (fed40, ...) at 0x1006000 failed: -1.
Do_exit called!
base is 0x10fcb8 caller is 0x1f08a
base is 0x10fcd8 caller is 0x28483
base is 0x10fd88 caller is 0x28558
base is 0x10fde8 caller is 0x2706c
base is 0x10fe28 caller is 0x27084
base is 0x10fe38 caller is 0x1bc69
base is 0x10fe78 caller is 0x6f9c
base is 0x10ff38 caller is 0x34e5
base is 0x10ff68 caller is 0x1fbbc
base is 0x10ffe8 caller is 0x33da
Thanks in advance!
Jordi.
--
Jordi Cucurull Juan
Researcher
Scytl Secure Electronic Voting
Plaça Gal·la Placidia, 1-3, 1st floor · 08006 Barcelona
Phone: + 34 934 230 324
Fax + 34 933 251 028
jordi.cucurull@scytl.com
http://www.scytl.com
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: vTPM Manager shuts down 2013-04-18 11:16 vTPM Manager shuts down Jordi Cucurull Juan @ 2013-04-18 14:41 ` Daniel De Graaf 2013-04-18 16:42 ` Jordi Cucurull Juan 2013-05-22 17:59 ` Konrad Rzeszutek Wilk 0 siblings, 2 replies; 10+ messages in thread From: Daniel De Graaf @ 2013-04-18 14:41 UTC (permalink / raw) To: Jordi Cucurull Juan; +Cc: xen-devel@lists.xen.org On 04/18/2013 07:16 AM, Jordi Cucurull Juan wrote: > Hi all, > > I am trying to set up the development version of Xen with support for > virtual TPMs. I am having an issue starting the vTPM Manager. Basically > I create the vTPM Manager stub domain as detailed in the documentation: > > make install-vtpmmgr > dd if=/dev/zero of=/var/xen/vtpmmgr-stubdom.img bs=16M count=1 > vim /etc/xen/vtpmmgr-stubdom.cfg > > kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz" > memory=16 > disk=["file:/var/xen/vtpmmgr-stubdom.img,hda,w"] > name="vtpmmgr" > iomem=["fed40,5"] > > xl create -c /etc/xen/vtpmmgr-stubdom.cfg > > Nevertheless, when the stub domain is launched it automatically shuts > down (see the trace below). Am I doing something wrong? Is there > something that can produce this behaviour? This config matches my (working) config for the vtpmmgr domain, so there's nothing immediately wrong here. The only differences I note are that I am using the kernel blkback (and an LVM partition) for the disk image, which shouldn't make any difference from the stubdom's perspective, and that I have XSM enabled in the hypervisor (and so have a seclabel defined). > Daemon running with PID 6347 > Xen Minimal OS! > start_info: 0xa3000(VA) > nr_pages: 0x1000 > shared_inf: 0xcaff0000(MA) > pt_base: 0xa6000(VA) > nr_pt_frames: 0x5 > mfn_list: 0x9b000(VA) > mod_start: 0x0(VA) > mod_len: 0 > flags: 0x0 > cmd_line: > stack: 0x5a7a0-0x7a7a0 > MM: Init > _text: 0x0(VA) > _etext: 0x397f4(VA) > _erodata: 0x46000(VA) > _edata: 0x48c00(VA) > stack start: 0x5a7a0(VA) > _end: 0x9adc0(VA) > start_pfn: ae > max_pfn: 1000 > Mapping memory range 0x400000 - 0x1000000 > setting 0x0-0x46000 readonly > skipped 0x1000 > MM: Initialise page allocator for b4000(b4000)-1000000(1000000) > MM: done > Demand map pfns at 1001000-2001001000. > Heap resides at 2001002000-4001002000. > Initialising timer interface > Initialising console ... done. > gnttab_table mapped at 0x1001000. > Initialising scheduler > Thread "Idle": pointer: 0x2001002050, stack: 0xd0000 > Thread "xenstore": pointer: 0x2001002800, stack: 0xe0000 > xenbus initialised on irq 1 mfn 0x224faa > Thread "shutdown": pointer: 0x2001002fb0, stack: 0xf0000 > Dummy main: start_info=0x7a8a0 > Thread "main": pointer: 0x2001003760, stack: 0x100000 > "main" > Shutting down () > Shutdown requested: 3 > Thread "shutdown" exited. > INFO[VTPM]: Starting vTPM manager domain > INFO[VTPM]: Option: Using tpm_tis driver > ******************* BLKFRONT for device/vbd/768 ********** > > > backend at /local/domain/0/backend/qdisk/7/768 > Failed to read /local/domain/0/backend/qdisk/7/768/feature-barrier. > 32768 sectors of 512 bytes > ************************** > blk_open(device/vbd/768) -> 3 > ============= Init TPM BACK ================ > Thread "tpmback-listener": pointer: 0x20010043f0, stack: 0xf0000 > ============= Init TPM TIS Driver ============== > IOMEM Machine Base Address: FED40000 > Enabled Localities: 0 > Map 1 (fed40, ...) at 0x1006000 failed: -1. This is apparently the error, although I would expect the iomem line to allow this mapping (-1 is EPERM, assuming it is correctly passing the error number). Does anything appear on the hypervisor's console (xl dmesg) that would correspond with this error? If you can, the output of "xl debug-key q" while the domain is running would be useful. Since it's crashing on startup, this may be difficult to produce - changing the existing sleep(2) in stubdom/vtpmmgr/vtpmmgr.c to a longer time should suffice. The output will go to xl dmesg, and the lines of interest would be: (XEN) General information for domain 5: (XEN) refcnt=3 dying=0 pause_count=0 (XEN) nr_pages=7168 xenheap_pages=5 shared_pages=0 paged_pages=0 dirty_cpus={} max_pages=7424 (XEN) handle=3097d8b9-8d80-4bde-94b6-978c98c37296 vm_assist=00000000 (XEN) Rangesets belonging to domain 5: (XEN) I/O Ports { } (XEN) Interrupts { } (XEN) I/O Memory { fed40 } Note: my config contains "iomem=['fed40,1']" not "iomem=['fed40,5']" so your output will differ there. > Do_exit called! > base is 0x10fcb8 caller is 0x1f08a > base is 0x10fcd8 caller is 0x28483 > base is 0x10fd88 caller is 0x28558 > base is 0x10fde8 caller is 0x2706c > base is 0x10fe28 caller is 0x27084 > base is 0x10fe38 caller is 0x1bc69 > base is 0x10fe78 caller is 0x6f9c > base is 0x10ff38 caller is 0x34e5 > base is 0x10ff68 caller is 0x1fbbc > base is 0x10ffe8 caller is 0x33da > > Thanks in advance! > Jordi. > For future reference, you can resolve these addresses (0x1f08a etc) using gdb $XEN_BUILD_DIR/stubdom/mini-os-x86_64-vtpmmgr/mini-os and then running (gdb) x/i 0x1f08a for each frame. That's not needed this time since the error location is already known: HYPERVISOR_mmu_update failed. -- Daniel De Graaf National Security Agency ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: vTPM Manager shuts down 2013-04-18 14:41 ` Daniel De Graaf @ 2013-04-18 16:42 ` Jordi Cucurull Juan 2013-04-18 21:12 ` Daniel De Graaf 2013-05-22 17:59 ` Konrad Rzeszutek Wilk 1 sibling, 1 reply; 10+ messages in thread From: Jordi Cucurull Juan @ 2013-04-18 16:42 UTC (permalink / raw) To: Daniel De Graaf, xen-devel@lists.xen.org Hi Daniel, Below there is the output of the "xl dmesg". I have executed "xl debug-key q" while keeping the stubdom in pause (sleep(60)). Consider only the last part of it, since at the beginning I have executed the "xl debug-key q" a couple of times without having the stubdom running. Thanks! Jordi. __ __ _ _ _____ _ _ _ \ \/ /___ _ __ | || | |___ / _ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \ | || |_ |_ \ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | |__ _| ___) |__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |_|(_)____/ \__,_|_| |_|___/\__\__,_|_.__/|_|\___| (XEN) Xen version 4.3-unstable (jcucurull@) (gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3)) debug=y Tue Apr 16 18:34:21 CEST 2013 (XEN) Latest ChangeSet: Mon Apr 15 11:28:30 2013 +0200 26850:51303801ea48 (XEN) Bootloader: GNU GRUB 0.97 (XEN) Command line: dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 dom0_vcpus_pin (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds (XEN) EDID info not retrieved because no DDC retrieval method detected (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009bc00 (usable) (XEN) 000000000009bc00 - 00000000000a0000 (reserved) (XEN) 00000000000e0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 0000000020000000 (usable) (XEN) 0000000020000000 - 0000000020200000 (reserved) (XEN) 0000000020200000 - 0000000040000000 (usable) (XEN) 0000000040000000 - 0000000040200000 (reserved) (XEN) 0000000040200000 - 00000000cabdc000 (usable) (XEN) 00000000cabdc000 - 00000000cac25000 (ACPI NVS) (XEN) 00000000cac25000 - 00000000cac33000 (ACPI data) (XEN) 00000000cac33000 - 00000000cac34000 (ACPI NVS) (XEN) 00000000cac34000 - 00000000cac54000 (reserved) (XEN) 00000000cac54000 - 00000000cac76000 (ACPI NVS) (XEN) 00000000cac76000 - 00000000cacfd000 (reserved) (XEN) 00000000cacfd000 - 00000000cacfe000 (ACPI NVS) (XEN) 00000000cacfe000 - 00000000cad10000 (reserved) (XEN) 00000000cad10000 - 00000000cad1e000 (ACPI NVS) (XEN) 00000000cad1e000 - 00000000cad2f000 (reserved) (XEN) 00000000cad2f000 - 00000000cad72000 (ACPI NVS) (XEN) 00000000cad72000 - 00000000cb000000 (usable) (XEN) 00000000cb800000 - 00000000cfa00000 (reserved) (XEN) 00000000fed1c000 - 00000000fed40000 (reserved) (XEN) 00000000ff000000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 000000022e600000 (usable) (XEN) ACPI: RSDP 000FE700, 0024 (r2 HPQOEM) (XEN) ACPI: XSDT CAC25078, 0074 (r1 HPQOEM SLIC-BPC 1072009 AMI 10013) (XEN) ACPI: FACP CAC2CB98, 00F4 (r4 HPQOEM SLIC-BPC 1072009 AMI 10013) (XEN) ACPI: DSDT CAC25180, 7A13 (r2 HPQOEM SLIC-BPC 7 INTL 20051117) (XEN) ACPI: FACS CAD15F80, 0040 (XEN) ACPI: APIC CAC2CC90, 0072 (r3 HPQOEM SLIC-BPC 1072009 AMI 10013) (XEN) ACPI: SSDT CAC2CD08, 0102 (r1 AMICPU PROC 1 MSFT 3000001) (XEN) ACPI: MCFG CAC2CE10, 003C (r1 HPQOEM SLIC-BPC 1072009 MSFT 97) (XEN) ACPI: HPET CAC2CE50, 0038 (r1 HPQOEM SLIC-BPC 1072009 AMI. 4) (XEN) ACPI: ASF! CAC2CE88, 00A0 (r32 INTEL HCG 1 TFSM F4240) (XEN) ACPI: SSDT CAC2CF28, 5270 (r1 COMPAQ WMI 1 MSFT 3000001) (XEN) ACPI: SLIC CAC32198, 0176 (r1 HPQOEM SLIC-BPC 1 0) (XEN) ACPI: TCPA CAC32310, 0032 (r2 APTIO4 NAPAASF 1 MSFT 1000013) (XEN) ACPI: DMAR CAC32348, 00E8 (r1 ALASKA A M I 1 INTL 1) (XEN) System RAM: 8080MB (8273940kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-000000022e600000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000f4c90 (XEN) DMI 2.7 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x408 (XEN) ACPI: SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0] (XEN) ACPI: 32/64X FACS address mismatch in FADT - cad15f80/0000000000000000, using 32 (XEN) ACPI: wakeup_vec[cad15f8c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) Processor #0 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) Processor #2 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) (XEN) Processor #4 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) (XEN) Processor #6 6:10 APIC version 21 (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) (XEN) ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000 (XEN) ERST table was not found (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs) (XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X (XEN) Switched to APIC driver x2apic_cluster. (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3093.102 MHz processor. (XEN) Initing memory sharing. (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) mce_intel.c:717: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0 (XEN) Intel machine check reporting enabled (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff (XEN) PCI: Not using MCFG for segment 0000 bus 00-ff (XEN) Intel VT-d iommu 0 supported page sizes: 4kB. (XEN) Intel VT-d iommu 1 supported page sizes: 4kB. (XEN) Intel VT-d Snoop Control not enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation enabled. (XEN) Intel VT-d Interrupt Remapping enabled. (XEN) Intel VT-d Shared EPT tables not enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping enabled (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) ENABLING IO-APIC IRQs (XEN) -> Using old ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) TSC deadline timer enabled (XEN) Using standard rendezvous (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 32 KiB. (XEN) mwait-idle: MWAIT substates: 0x1120 (XEN) mwait-idle: v0.4 model 0x2a (XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB (XEN) Brought up 4 CPUs (XEN) ACPI sleep modes: S3 (XEN) mcheck_poll: Machine check polling timer started. (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x5be000 (XEN) elf_parse_binary: phdr: paddr=0x15be000 memsz=0xb30e8 (XEN) elf_parse_binary: phdr: paddr=0x1672000 memsz=0x13c80 (XEN) elf_parse_binary: phdr: paddr=0x1686000 memsz=0x63b000 (XEN) elf_parse_binary: memory: 0x1000000 -> 0x1cc1000 (XEN) elf_xen_parse_note: GUEST_OS = "linux" (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6" (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0" (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 (XEN) elf_xen_parse_note: ENTRY = 0xffffffff81686210 (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000 (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb" (XEN) elf_xen_parse_note: PAE_MODE = "yes" (XEN) elf_xen_parse_note: LOADER = "generic" (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1 (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0 (XEN) elf_xen_addr_calc_check: addresses: (XEN) virt_base = 0xffffffff80000000 (XEN) elf_paddr_offset = 0x0 (XEN) virt_offset = 0xffffffff80000000 (XEN) virt_kstart = 0xffffffff81000000 (XEN) virt_kend = 0xffffffff81cc1000 (XEN) virt_entry = 0xffffffff81686210 (XEN) p2m_base = 0xffffffffffffffff (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1cc1000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000220000000->0000000224000000 (235725 pages to be allocated) (XEN) Init. ramdisk: 000000022becd000->000000022e5ff600 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81cc1000 (XEN) Init. ramdisk: ffffffff81cc1000->ffffffff843f3600 (XEN) Phys-Mach map: ffffffff843f4000->ffffffff845f4000 (XEN) Start info: ffffffff845f4000->ffffffff845f44b4 (XEN) Page tables: ffffffff845f5000->ffffffff8461c000 (XEN) Boot stack: ffffffff8461c000->ffffffff8461d000 (XEN) TOTAL: ffffffff80000000->ffffffff84800000 (XEN) ENTRY ADDRESS: ffffffff81686210 (XEN) Dom0 has maximum 1 VCPUs (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff815be000 (XEN) elf_load_binary: phdr 1 at 0xffffffff815be000 -> 0xffffffff816710e8 (XEN) elf_load_binary: phdr 2 at 0xffffffff81672000 -> 0xffffffff81685c80 (XEN) elf_load_binary: phdr 3 at 0xffffffff81686000 -> 0xffffffff8175e000 (XEN) Scrubbing Free RAM: .....................................................................done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 244kB init memory. (XEN) PCI add device 0000:00:00.0 (XEN) PCI add device 0000:00:02.0 (XEN) PCI add device 0000:00:16.0 (XEN) PCI add device 0000:00:16.3 (XEN) PCI add device 0000:00:19.0 (XEN) PCI add device 0000:00:1a.0 (XEN) PCI add device 0000:00:1b.0 (XEN) PCI add device 0000:00:1c.0 (XEN) PCI add device 0000:00:1c.4 (XEN) PCI add device 0000:00:1c.6 (XEN) PCI add device 0000:00:1c.7 (XEN) PCI add device 0000:00:1d.0 (XEN) PCI add device 0000:00:1e.0 (XEN) PCI add device 0000:00:1f.0 (XEN) PCI add device 0000:00:1f.2 (XEN) PCI add device 0000:00:1f.3 (XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'. (XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'. (XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'. (XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'. (XEN) traps.c:3053: GPF (0000): ffff82c4c01898df -> ffff82c4c02243d8 (XEN) traps.c:2495:d0 Domain attempted WRMSR 0000000000000079 from 0x0000000000000000 to 0xffffc90011b61030. (XEN) traps.c:3053: GPF (0000): ffff82c4c01898df -> ffff82c4c02243d8 (XEN) traps.c:2495:d0 Domain attempted WRMSR 0000000000000079 from 0x0000000000000000 to 0xffffc90011bad030. (XEN) traps.c:3053: GPF (0000): ffff82c4c01898df -> ffff82c4c02243d8 (XEN) traps.c:2495:d0 Domain attempted WRMSR 0000000000000079 from 0x0000000000000000 to 0xffffc90011bf4030. (XEN) traps.c:3053: GPF (0000): ffff82c4c01898df -> ffff82c4c02243d8 (XEN) traps.c:2495:d0 Domain attempted WRMSR 0000000000000079 from 0x0000000000000000 to 0xffffc90011886030. (XEN) 'q' pressed -> dumping domain info (now=0x133D:A026F72D) (XEN) General information for domain 0: (XEN) refcnt=3 dying=0 pause_count=0 (XEN) nr_pages=262144 xenheap_pages=6 shared_pages=0 paged_pages=0 dirty_cpus={0} max_pages=4294967295 (XEN) handle=00000000-0000-0000-0000-000000000000 vm_assist=0000000d (XEN) watchdog 0 expires in 16 seconds (XEN) Rangesets belonging to domain 0: (XEN) I/O Ports { 0-1f, 22-3f, 44-60, 62-9f, a2-407, 40c-cfb, d00-ffff } (XEN) Interrupts { 0-279 } (XEN) I/O Memory { 0-febff, fec01-fedff, fee01-ffffffffffffffff } (XEN) Memory pages belonging to domain 0: (XEN) DomPage list too long to display (XEN) XenPage 0000000000225199: caf=c000000000000002, taf=7400000000000002 (XEN) XenPage 0000000000225198: caf=c000000000000001, taf=7400000000000001 (XEN) XenPage 0000000000225197: caf=c000000000000001, taf=7400000000000001 (XEN) XenPage 0000000000225196: caf=c000000000000001, taf=7400000000000001 (XEN) XenPage 00000000000cad73: caf=c000000000000002, taf=7400000000000002 (XEN) XenPage 000000000021cf49: caf=c000000000000002, taf=7400000000000002 (XEN) VCPU information and callbacks for domain 0: (XEN) VCPU0: CPU0 [has=T] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={0} cpu_affinity={0} (XEN) pause_count=0 pause_flags=0 (XEN) No periodic timer (XEN) Notifying guest 0:0 (virq 1, port 4, stat 0/0/0) (XEN) Shared frames 0 -- Saved frames 0 (XEN) 'q' pressed -> dumping domain info (now=0x133E:0F99BE5C) (XEN) General information for domain 0: (XEN) refcnt=3 dying=0 pause_count=0 (XEN) nr_pages=262144 xenheap_pages=6 shared_pages=0 paged_pages=0 dirty_cpus={0} max_pages=4294967295 (XEN) handle=00000000-0000-0000-0000-000000000000 vm_assist=0000000d (XEN) watchdog 0 expires in 14 seconds (XEN) Rangesets belonging to domain 0: (XEN) I/O Ports { 0-1f, 22-3f, 44-60, 62-9f, a2-407, 40c-cfb, d00-ffff } (XEN) Interrupts { 0-279 } (XEN) I/O Memory { 0-febff, fec01-fedff, fee01-ffffffffffffffff } (XEN) Memory pages belonging to domain 0: (XEN) DomPage list too long to display (XEN) XenPage 0000000000225199: caf=c000000000000002, taf=7400000000000002 (XEN) XenPage 0000000000225198: caf=c000000000000001, taf=7400000000000001 (XEN) XenPage 0000000000225197: caf=c000000000000001, taf=7400000000000001 (XEN) XenPage 0000000000225196: caf=c000000000000001, taf=7400000000000001 (XEN) XenPage 00000000000cad73: caf=c000000000000002, taf=7400000000000002 (XEN) XenPage 000000000021cf49: caf=c000000000000002, taf=7400000000000002 (XEN) VCPU information and callbacks for domain 0: (XEN) VCPU0: CPU0 [has=T] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={0} cpu_affinity={0} (XEN) pause_count=0 pause_flags=0 (XEN) No periodic timer (XEN) Notifying guest 0:0 (virq 1, port 4, stat 0/0/0) (XEN) Shared frames 0 -- Saved frames 0 (XEN) 'q' pressed -> dumping domain info (now=0x1379:F55FDF65) (XEN) General information for domain 0: (XEN) refcnt=3 dying=0 pause_count=0 (XEN) nr_pages=262144 xenheap_pages=6 shared_pages=0 paged_pages=0 dirty_cpus={0} max_pages=4294967295 (XEN) handle=00000000-0000-0000-0000-000000000000 vm_assist=0000000d (XEN) watchdog 0 expires in 26 seconds (XEN) Rangesets belonging to domain 0: (XEN) I/O Ports { 0-1f, 22-3f, 44-60, 62-9f, a2-407, 40c-cfb, d00-ffff } (XEN) Interrupts { 0-279 } (XEN) I/O Memory { 0-febff, fec01-fedff, fee01-ffffffffffffffff } (XEN) Memory pages belonging to domain 0: (XEN) DomPage list too long to display (XEN) XenPage 0000000000225199: caf=c000000000000002, taf=7400000000000002 (XEN) XenPage 0000000000225198: caf=c000000000000001, taf=7400000000000001 (XEN) XenPage 0000000000225197: caf=c000000000000001, taf=7400000000000001 (XEN) XenPage 0000000000225196: caf=c000000000000001, taf=7400000000000001 (XEN) XenPage 00000000000cad73: caf=c000000000000002, taf=7400000000000002 (XEN) XenPage 000000000021cf49: caf=c000000000000002, taf=7400000000000002 (XEN) VCPU information and callbacks for domain 0: (XEN) VCPU0: CPU0 [has=T] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={0} cpu_affinity={0} (XEN) pause_count=0 pause_flags=0 (XEN) No periodic timer (XEN) Notifying guest 0:0 (virq 1, port 4, stat 0/0/0) (XEN) Shared frames 0 -- Saved frames 0 (XEN) 'q' pressed -> dumping domain info (now=0x18AC:EC7F30DD) (XEN) General information for domain 0: (XEN) refcnt=3 dying=0 pause_count=0 (XEN) nr_pages=262144 xenheap_pages=6 shared_pages=0 paged_pages=0 dirty_cpus={0} max_pages=4294967295 (XEN) handle=00000000-0000-0000-0000-000000000000 vm_assist=0000000d (XEN) watchdog 0 expires in 25 seconds (XEN) Rangesets belonging to domain 0: (XEN) I/O Ports { 0-1f, 22-3f, 44-60, 62-9f, a2-407, 40c-cfb, d00-ffff } (XEN) Interrupts { 0-279 } (XEN) I/O Memory { 0-febff, fec01-fedff, fee01-ffffffffffffffff } (XEN) Memory pages belonging to domain 0: (XEN) DomPage list too long to display (XEN) XenPage 0000000000225199: caf=c000000000000002, taf=7400000000000002 (XEN) XenPage 0000000000225198: caf=c000000000000001, taf=7400000000000001 (XEN) XenPage 0000000000225197: caf=c000000000000001, taf=7400000000000001 (XEN) XenPage 0000000000225196: caf=c000000000000001, taf=7400000000000001 (XEN) XenPage 00000000000cad73: caf=c000000000000002, taf=7400000000000002 (XEN) XenPage 000000000021cf49: caf=c000000000000002, taf=7400000000000002 (XEN) VCPU information and callbacks for domain 0: (XEN) VCPU0: CPU0 [has=T] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={0} cpu_affinity={0} (XEN) pause_count=0 pause_flags=0 (XEN) No periodic timer (XEN) General information for domain 9: (XEN) refcnt=3 dying=0 pause_count=0 (XEN) nr_pages=4096 xenheap_pages=5 shared_pages=0 paged_pages=0 dirty_cpus={3} max_pages=4352 (XEN) handle=6a617ce0-9628-47bf-b038-46008e2eb57e vm_assist=00000000 (XEN) Rangesets belonging to domain 9: (XEN) I/O Ports { } (XEN) Interrupts { } (XEN) I/O Memory { fed40-fed44 } (XEN) Memory pages belonging to domain 9: (XEN) DomPage list too long to display (XEN) XenPage 000000000020895f: caf=c000000000000002, taf=7400000000000002 (XEN) XenPage 000000000020895e: caf=c000000000000002, taf=7400000000000002 (XEN) XenPage 0000000000206c7f: caf=c000000000000002, taf=7400000000000002 (XEN) XenPage 0000000000206c7e: caf=c000000000000002, taf=7400000000000002 (XEN) XenPage 00000000000caff0: caf=c000000000000002, taf=7400000000000002 (XEN) VCPU information and callbacks for domain 9: (XEN) VCPU0: CPU3 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={3} cpu_affinity={0-3} (XEN) pause_count=0 pause_flags=1 (XEN) 100 Hz periodic timer (period 10 ms) (XEN) Notifying guest 0:0 (virq 1, port 4, stat 0/0/0) (XEN) Notifying guest 9:0 (virq 1, port 0, stat 0/-1/0) (XEN) Shared frames 0 -- Saved frames 0 On 04/18/2013 04:41 PM, Daniel De Graaf wrote: > On 04/18/2013 07:16 AM, Jordi Cucurull Juan wrote: >> Hi all, >> >> I am trying to set up the development version of Xen with support for >> virtual TPMs. I am having an issue starting the vTPM Manager. Basically >> I create the vTPM Manager stub domain as detailed in the documentation: >> >> make install-vtpmmgr >> dd if=/dev/zero of=/var/xen/vtpmmgr-stubdom.img bs=16M count=1 >> vim /etc/xen/vtpmmgr-stubdom.cfg >> >> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz" >> memory=16 >> disk=["file:/var/xen/vtpmmgr-stubdom.img,hda,w"] >> name="vtpmmgr" >> iomem=["fed40,5"] >> >> xl create -c /etc/xen/vtpmmgr-stubdom.cfg >> >> Nevertheless, when the stub domain is launched it automatically shuts >> down (see the trace below). Am I doing something wrong? Is there >> something that can produce this behaviour? > > This config matches my (working) config for the vtpmmgr domain, so > there's > nothing immediately wrong here. The only differences I note are that I am > using the kernel blkback (and an LVM partition) for the disk image, which > shouldn't make any difference from the stubdom's perspective, and that I > have XSM enabled in the hypervisor (and so have a seclabel defined). > >> Daemon running with PID 6347 >> Xen Minimal OS! >> start_info: 0xa3000(VA) >> nr_pages: 0x1000 >> shared_inf: 0xcaff0000(MA) >> pt_base: 0xa6000(VA) >> nr_pt_frames: 0x5 >> mfn_list: 0x9b000(VA) >> mod_start: 0x0(VA) >> mod_len: 0 >> flags: 0x0 >> cmd_line: >> stack: 0x5a7a0-0x7a7a0 >> MM: Init >> _text: 0x0(VA) >> _etext: 0x397f4(VA) >> _erodata: 0x46000(VA) >> _edata: 0x48c00(VA) >> stack start: 0x5a7a0(VA) >> _end: 0x9adc0(VA) >> start_pfn: ae >> max_pfn: 1000 >> Mapping memory range 0x400000 - 0x1000000 >> setting 0x0-0x46000 readonly >> skipped 0x1000 >> MM: Initialise page allocator for b4000(b4000)-1000000(1000000) >> MM: done >> Demand map pfns at 1001000-2001001000. >> Heap resides at 2001002000-4001002000. >> Initialising timer interface >> Initialising console ... done. >> gnttab_table mapped at 0x1001000. >> Initialising scheduler >> Thread "Idle": pointer: 0x2001002050, stack: 0xd0000 >> Thread "xenstore": pointer: 0x2001002800, stack: 0xe0000 >> xenbus initialised on irq 1 mfn 0x224faa >> Thread "shutdown": pointer: 0x2001002fb0, stack: 0xf0000 >> Dummy main: start_info=0x7a8a0 >> Thread "main": pointer: 0x2001003760, stack: 0x100000 >> "main" >> Shutting down () >> Shutdown requested: 3 >> Thread "shutdown" exited. >> INFO[VTPM]: Starting vTPM manager domain >> INFO[VTPM]: Option: Using tpm_tis driver >> ******************* BLKFRONT for device/vbd/768 ********** >> >> >> backend at /local/domain/0/backend/qdisk/7/768 >> Failed to read /local/domain/0/backend/qdisk/7/768/feature-barrier. >> 32768 sectors of 512 bytes >> ************************** >> blk_open(device/vbd/768) -> 3 >> ============= Init TPM BACK ================ >> Thread "tpmback-listener": pointer: 0x20010043f0, stack: 0xf0000 >> ============= Init TPM TIS Driver ============== >> IOMEM Machine Base Address: FED40000 >> Enabled Localities: 0 >> Map 1 (fed40, ...) at 0x1006000 failed: -1. > > This is apparently the error, although I would expect the iomem line > to allow this mapping (-1 is EPERM, assuming it is correctly passing > the error number). Does anything appear on the hypervisor's console > (xl dmesg) that would correspond with this error? > > If you can, the output of "xl debug-key q" while the domain is running > would be useful. Since it's crashing on startup, this may be difficult > to produce - changing the existing sleep(2) in stubdom/vtpmmgr/vtpmmgr.c > to a longer time should suffice. The output will go to xl dmesg, and > the lines of interest would be: > > (XEN) General information for domain 5: > (XEN) refcnt=3 dying=0 pause_count=0 > (XEN) nr_pages=7168 xenheap_pages=5 shared_pages=0 paged_pages=0 > dirty_cpus={} max_pages=7424 > (XEN) handle=3097d8b9-8d80-4bde-94b6-978c98c37296 vm_assist=00000000 > (XEN) Rangesets belonging to domain 5: > (XEN) I/O Ports { } > (XEN) Interrupts { } > (XEN) I/O Memory { fed40 } > > Note: my config contains "iomem=['fed40,1']" not "iomem=['fed40,5']" > so your > output will differ there. > >> Do_exit called! >> base is 0x10fcb8 caller is 0x1f08a >> base is 0x10fcd8 caller is 0x28483 >> base is 0x10fd88 caller is 0x28558 >> base is 0x10fde8 caller is 0x2706c >> base is 0x10fe28 caller is 0x27084 >> base is 0x10fe38 caller is 0x1bc69 >> base is 0x10fe78 caller is 0x6f9c >> base is 0x10ff38 caller is 0x34e5 >> base is 0x10ff68 caller is 0x1fbbc >> base is 0x10ffe8 caller is 0x33da >> >> Thanks in advance! >> Jordi. >> > > For future reference, you can resolve these addresses (0x1f08a etc) using > > gdb $XEN_BUILD_DIR/stubdom/mini-os-x86_64-vtpmmgr/mini-os > > and then running > > (gdb) x/i 0x1f08a > > for each frame. That's not needed this time since the error location is > already known: HYPERVISOR_mmu_update failed. > -- Jordi Cucurull Juan Researcher Scytl Secure Electronic Voting Plaça Gal·la Placidia, 1-3, 1st floor · 08006 Barcelona Phone: + 34 934 230 324 Fax + 34 933 251 028 jordi.cucurull@scytl.com http://www.scytl.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: vTPM Manager shuts down 2013-04-18 16:42 ` Jordi Cucurull Juan @ 2013-04-18 21:12 ` Daniel De Graaf 0 siblings, 0 replies; 10+ messages in thread From: Daniel De Graaf @ 2013-04-18 21:12 UTC (permalink / raw) To: Jordi Cucurull Juan; +Cc: xen-devel@lists.xen.org On 04/18/2013 12:42 PM, Jordi Cucurull Juan wrote: > Hi Daniel, > > Below there is the output of the "xl dmesg". I have executed "xl > debug-key q" while keeping the stubdom in pause (sleep(60)). Consider > only the last part of it, since at the beginning I have executed the "xl > debug-key q" a couple of times without having the stubdom running. > > Thanks! > Jordi. > I see nothing obviously wrong here, and no obvious differences between my tests and your configuration. You may want to look at why the mmap is failing in the hypervisor by adding debug statements or enabling the existing MEM_LOG statements. The error might be in get_page_from_l1e or other functions called from do_mmu_update in xen/arch/x86/mm.c. > > __ __ _ _ _____ _ _ _ > \ \/ /___ _ __ | || | |___ / _ _ _ __ ___| |_ __ _| |__ | | ___ > \ // _ \ '_ \ | || |_ |_ \ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ > / \ __/ | | | |__ _| ___) |__| |_| | | | \__ \ || (_| | |_) | | __/ > /_/\_\___|_| |_| |_|(_)____/ \__,_|_| |_|___/\__\__,_|_.__/|_|\___| > > (XEN) Xen version 4.3-unstable (jcucurull@) (gcc (GCC) 4.4.7 20120313 > (Red Hat 4.4.7-3)) debug=y Tue Apr 16 18:34:21 CEST 2013 > (XEN) Latest ChangeSet: Mon Apr 15 11:28:30 2013 +0200 26850:51303801ea48 > (XEN) Bootloader: GNU GRUB 0.97 > (XEN) Command line: dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 > dom0_vcpus_pin > (XEN) Video information: > (XEN) VGA is text mode 80x25, font 8x16 > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > (XEN) EDID info not retrieved because no DDC retrieval method detected > (XEN) Disc information: > (XEN) Found 1 MBR signatures > (XEN) Found 1 EDD information structures > (XEN) Xen-e820 RAM map: > (XEN) 0000000000000000 - 000000000009bc00 (usable) > (XEN) 000000000009bc00 - 00000000000a0000 (reserved) > (XEN) 00000000000e0000 - 0000000000100000 (reserved) > (XEN) 0000000000100000 - 0000000020000000 (usable) > (XEN) 0000000020000000 - 0000000020200000 (reserved) > (XEN) 0000000020200000 - 0000000040000000 (usable) > (XEN) 0000000040000000 - 0000000040200000 (reserved) > (XEN) 0000000040200000 - 00000000cabdc000 (usable) > (XEN) 00000000cabdc000 - 00000000cac25000 (ACPI NVS) > (XEN) 00000000cac25000 - 00000000cac33000 (ACPI data) > (XEN) 00000000cac33000 - 00000000cac34000 (ACPI NVS) > (XEN) 00000000cac34000 - 00000000cac54000 (reserved) > (XEN) 00000000cac54000 - 00000000cac76000 (ACPI NVS) > (XEN) 00000000cac76000 - 00000000cacfd000 (reserved) > (XEN) 00000000cacfd000 - 00000000cacfe000 (ACPI NVS) > (XEN) 00000000cacfe000 - 00000000cad10000 (reserved) > (XEN) 00000000cad10000 - 00000000cad1e000 (ACPI NVS) > (XEN) 00000000cad1e000 - 00000000cad2f000 (reserved) > (XEN) 00000000cad2f000 - 00000000cad72000 (ACPI NVS) > (XEN) 00000000cad72000 - 00000000cb000000 (usable) > (XEN) 00000000cb800000 - 00000000cfa00000 (reserved) > (XEN) 00000000fed1c000 - 00000000fed40000 (reserved) > (XEN) 00000000ff000000 - 0000000100000000 (reserved) > (XEN) 0000000100000000 - 000000022e600000 (usable) > (XEN) ACPI: RSDP 000FE700, 0024 (r2 HPQOEM) > (XEN) ACPI: XSDT CAC25078, 0074 (r1 HPQOEM SLIC-BPC 1072009 AMI 10013) > (XEN) ACPI: FACP CAC2CB98, 00F4 (r4 HPQOEM SLIC-BPC 1072009 AMI 10013) > (XEN) ACPI: DSDT CAC25180, 7A13 (r2 HPQOEM SLIC-BPC 7 INTL 20051117) > (XEN) ACPI: FACS CAD15F80, 0040 > (XEN) ACPI: APIC CAC2CC90, 0072 (r3 HPQOEM SLIC-BPC 1072009 AMI 10013) > (XEN) ACPI: SSDT CAC2CD08, 0102 (r1 AMICPU PROC 1 MSFT 3000001) > (XEN) ACPI: MCFG CAC2CE10, 003C (r1 HPQOEM SLIC-BPC 1072009 MSFT 97) > (XEN) ACPI: HPET CAC2CE50, 0038 (r1 HPQOEM SLIC-BPC 1072009 AMI. 4) > (XEN) ACPI: ASF! CAC2CE88, 00A0 (r32 INTEL HCG 1 TFSM F4240) > (XEN) ACPI: SSDT CAC2CF28, 5270 (r1 COMPAQ WMI 1 MSFT 3000001) > (XEN) ACPI: SLIC CAC32198, 0176 (r1 HPQOEM SLIC-BPC 1 0) > (XEN) ACPI: TCPA CAC32310, 0032 (r2 APTIO4 NAPAASF 1 MSFT 1000013) > (XEN) ACPI: DMAR CAC32348, 00E8 (r1 ALASKA A M I 1 INTL 1) > (XEN) System RAM: 8080MB (8273940kB) > (XEN) No NUMA configuration found > (XEN) Faking a node at 0000000000000000-000000022e600000 > (XEN) Domain heap initialised > (XEN) found SMP MP-table at 000f4c90 > (XEN) DMI 2.7 present. > (XEN) Using APIC driver default > (XEN) ACPI: PM-Timer IO Port: 0x408 > (XEN) ACPI: SLEEP INFO: pm1x_cnt[404,0], pm1x_evt[400,0] > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > cad15f80/0000000000000000, using 32 > (XEN) ACPI: wakeup_vec[cad15f8c], vec_size[20] > (XEN) ACPI: Local APIC address 0xfee00000 > (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) > (XEN) Processor #0 6:10 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) > (XEN) Processor #2 6:10 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) > (XEN) Processor #4 6:10 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) > (XEN) Processor #6 6:10 APIC version 21 > (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) > (XEN) ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) > (XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23 > (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > (XEN) ACPI: IRQ0 used by override. > (XEN) ACPI: IRQ2 used by override. > (XEN) ACPI: IRQ9 used by override. > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000 > (XEN) ERST table was not found > (XEN) Using ACPI (MADT) for SMP configuration information > (XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs) > (XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X > (XEN) Switched to APIC driver x2apic_cluster. > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) Detected 3093.102 MHz processor. > (XEN) Initing memory sharing. > (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 > (XEN) mce_intel.c:717: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 > extended MCE MSR 0 > (XEN) Intel machine check reporting enabled > (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff > (XEN) PCI: Not using MCFG for segment 0000 bus 00-ff > (XEN) Intel VT-d iommu 0 supported page sizes: 4kB. > (XEN) Intel VT-d iommu 1 supported page sizes: 4kB. > (XEN) Intel VT-d Snoop Control not enabled. > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > (XEN) Intel VT-d Queued Invalidation enabled. > (XEN) Intel VT-d Interrupt Remapping enabled. > (XEN) Intel VT-d Shared EPT tables not enabled. > (XEN) I/O virtualisation enabled > (XEN) - Dom0 mode: Relaxed > (XEN) Interrupt remapping enabled > (XEN) Enabled directed EOI with ioapic_ack_old on! > (XEN) ENABLING IO-APIC IRQs > (XEN) -> Using old ACK method > (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 > (XEN) TSC deadline timer enabled > (XEN) Using standard rendezvous > (XEN) Platform timer is 14.318MHz HPET > (XEN) Allocated console ring of 32 KiB. > (XEN) mwait-idle: MWAIT substates: 0x1120 > (XEN) mwait-idle: v0.4 model 0x2a > (XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff > (XEN) VMX: Supported advanced features: > (XEN) - APIC MMIO access virtualisation > (XEN) - APIC TPR shadow > (XEN) - Extended Page Tables (EPT) > (XEN) - Virtual-Processor Identifiers (VPID) > (XEN) - Virtual NMI > (XEN) - MSR direct-access bitmap > (XEN) - Unrestricted Guest > (XEN) HVM: ASIDs enabled. > (XEN) HVM: VMX enabled > (XEN) HVM: Hardware Assisted Paging (HAP) detected > (XEN) HVM: HAP page sizes: 4kB, 2MB > (XEN) Brought up 4 CPUs > (XEN) ACPI sleep modes: S3 > (XEN) mcheck_poll: Machine check polling timer started. > (XEN) *** LOADING DOMAIN 0 *** > (XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x5be000 > (XEN) elf_parse_binary: phdr: paddr=0x15be000 memsz=0xb30e8 > (XEN) elf_parse_binary: phdr: paddr=0x1672000 memsz=0x13c80 > (XEN) elf_parse_binary: phdr: paddr=0x1686000 memsz=0x63b000 > (XEN) elf_parse_binary: memory: 0x1000000 -> 0x1cc1000 > (XEN) elf_xen_parse_note: GUEST_OS = "linux" > (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6" > (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0" > (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 > (XEN) elf_xen_parse_note: ENTRY = 0xffffffff81686210 > (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000 > (XEN) elf_xen_parse_note: FEATURES = > "!writable_page_tables|pae_pgdir_above_4gb" > (XEN) elf_xen_parse_note: PAE_MODE = "yes" > (XEN) elf_xen_parse_note: LOADER = "generic" > (XEN) elf_xen_parse_note: unknown xen elf note (0xd) > (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1 > (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 > (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0 > (XEN) elf_xen_addr_calc_check: addresses: > (XEN) virt_base = 0xffffffff80000000 > (XEN) elf_paddr_offset = 0x0 > (XEN) virt_offset = 0xffffffff80000000 > (XEN) virt_kstart = 0xffffffff81000000 > (XEN) virt_kend = 0xffffffff81cc1000 > (XEN) virt_entry = 0xffffffff81686210 > (XEN) p2m_base = 0xffffffffffffffff > (XEN) Xen kernel: 64-bit, lsb, compat32 > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1cc1000 > (XEN) PHYSICAL MEMORY ARRANGEMENT: > (XEN) Dom0 alloc.: 0000000220000000->0000000224000000 (235725 pages > to be allocated) > (XEN) Init. ramdisk: 000000022becd000->000000022e5ff600 > (XEN) VIRTUAL MEMORY ARRANGEMENT: > (XEN) Loaded kernel: ffffffff81000000->ffffffff81cc1000 > (XEN) Init. ramdisk: ffffffff81cc1000->ffffffff843f3600 > (XEN) Phys-Mach map: ffffffff843f4000->ffffffff845f4000 > (XEN) Start info: ffffffff845f4000->ffffffff845f44b4 > (XEN) Page tables: ffffffff845f5000->ffffffff8461c000 > (XEN) Boot stack: ffffffff8461c000->ffffffff8461d000 > (XEN) TOTAL: ffffffff80000000->ffffffff84800000 > (XEN) ENTRY ADDRESS: ffffffff81686210 > (XEN) Dom0 has maximum 1 VCPUs > (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff815be000 > (XEN) elf_load_binary: phdr 1 at 0xffffffff815be000 -> 0xffffffff816710e8 > (XEN) elf_load_binary: phdr 2 at 0xffffffff81672000 -> 0xffffffff81685c80 > (XEN) elf_load_binary: phdr 3 at 0xffffffff81686000 -> 0xffffffff8175e000 > (XEN) Scrubbing Free RAM: > .....................................................................done. > (XEN) Initial low memory virq threshold set at 0x4000 pages. > (XEN) Std. Loglevel: All > (XEN) Guest Loglevel: All > (XEN) Xen is relinquishing VGA console. > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch > input to Xen) > (XEN) Freed 244kB init memory. > (XEN) PCI add device 0000:00:00.0 > (XEN) PCI add device 0000:00:02.0 > (XEN) PCI add device 0000:00:16.0 > (XEN) PCI add device 0000:00:16.3 > (XEN) PCI add device 0000:00:19.0 > (XEN) PCI add device 0000:00:1a.0 > (XEN) PCI add device 0000:00:1b.0 > (XEN) PCI add device 0000:00:1c.0 > (XEN) PCI add device 0000:00:1c.4 > (XEN) PCI add device 0000:00:1c.6 > (XEN) PCI add device 0000:00:1c.7 > (XEN) PCI add device 0000:00:1d.0 > (XEN) PCI add device 0000:00:1e.0 > (XEN) PCI add device 0000:00:1f.0 > (XEN) PCI add device 0000:00:1f.2 > (XEN) PCI add device 0000:00:1f.3 > (XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'. > (XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'. > (XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'. > (XEN) Cannot bind IRQ2 to dom0. In use by 'cascade'. > (XEN) traps.c:3053: GPF (0000): ffff82c4c01898df -> ffff82c4c02243d8 > (XEN) traps.c:2495:d0 Domain attempted WRMSR 0000000000000079 from > 0x0000000000000000 to 0xffffc90011b61030. > (XEN) traps.c:3053: GPF (0000): ffff82c4c01898df -> ffff82c4c02243d8 > (XEN) traps.c:2495:d0 Domain attempted WRMSR 0000000000000079 from > 0x0000000000000000 to 0xffffc90011bad030. > (XEN) traps.c:3053: GPF (0000): ffff82c4c01898df -> ffff82c4c02243d8 > (XEN) traps.c:2495:d0 Domain attempted WRMSR 0000000000000079 from > 0x0000000000000000 to 0xffffc90011bf4030. > (XEN) traps.c:3053: GPF (0000): ffff82c4c01898df -> ffff82c4c02243d8 > (XEN) traps.c:2495:d0 Domain attempted WRMSR 0000000000000079 from > 0x0000000000000000 to 0xffffc90011886030. > (XEN) 'q' pressed -> dumping domain info (now=0x133D:A026F72D) > (XEN) General information for domain 0: > (XEN) refcnt=3 dying=0 pause_count=0 > (XEN) nr_pages=262144 xenheap_pages=6 shared_pages=0 paged_pages=0 > dirty_cpus={0} max_pages=4294967295 > (XEN) handle=00000000-0000-0000-0000-000000000000 vm_assist=0000000d > (XEN) watchdog 0 expires in 16 seconds > (XEN) Rangesets belonging to domain 0: > (XEN) I/O Ports { 0-1f, 22-3f, 44-60, 62-9f, a2-407, 40c-cfb, > d00-ffff } > (XEN) Interrupts { 0-279 } > (XEN) I/O Memory { 0-febff, fec01-fedff, fee01-ffffffffffffffff } > (XEN) Memory pages belonging to domain 0: > (XEN) DomPage list too long to display > (XEN) XenPage 0000000000225199: caf=c000000000000002, > taf=7400000000000002 > (XEN) XenPage 0000000000225198: caf=c000000000000001, > taf=7400000000000001 > (XEN) XenPage 0000000000225197: caf=c000000000000001, > taf=7400000000000001 > (XEN) XenPage 0000000000225196: caf=c000000000000001, > taf=7400000000000001 > (XEN) XenPage 00000000000cad73: caf=c000000000000002, > taf=7400000000000002 > (XEN) XenPage 000000000021cf49: caf=c000000000000002, > taf=7400000000000002 > (XEN) VCPU information and callbacks for domain 0: > (XEN) VCPU0: CPU0 [has=T] poll=0 upcall_pend = 00, upcall_mask = 00 > dirty_cpus={0} cpu_affinity={0} > (XEN) pause_count=0 pause_flags=0 > (XEN) No periodic timer > (XEN) Notifying guest 0:0 (virq 1, port 4, stat 0/0/0) > (XEN) Shared frames 0 -- Saved frames 0 > (XEN) 'q' pressed -> dumping domain info (now=0x133E:0F99BE5C) > (XEN) General information for domain 0: > (XEN) refcnt=3 dying=0 pause_count=0 > (XEN) nr_pages=262144 xenheap_pages=6 shared_pages=0 paged_pages=0 > dirty_cpus={0} max_pages=4294967295 > (XEN) handle=00000000-0000-0000-0000-000000000000 vm_assist=0000000d > (XEN) watchdog 0 expires in 14 seconds > (XEN) Rangesets belonging to domain 0: > (XEN) I/O Ports { 0-1f, 22-3f, 44-60, 62-9f, a2-407, 40c-cfb, > d00-ffff } > (XEN) Interrupts { 0-279 } > (XEN) I/O Memory { 0-febff, fec01-fedff, fee01-ffffffffffffffff } > (XEN) Memory pages belonging to domain 0: > (XEN) DomPage list too long to display > (XEN) XenPage 0000000000225199: caf=c000000000000002, > taf=7400000000000002 > (XEN) XenPage 0000000000225198: caf=c000000000000001, > taf=7400000000000001 > (XEN) XenPage 0000000000225197: caf=c000000000000001, > taf=7400000000000001 > (XEN) XenPage 0000000000225196: caf=c000000000000001, > taf=7400000000000001 > (XEN) XenPage 00000000000cad73: caf=c000000000000002, > taf=7400000000000002 > (XEN) XenPage 000000000021cf49: caf=c000000000000002, > taf=7400000000000002 > (XEN) VCPU information and callbacks for domain 0: > (XEN) VCPU0: CPU0 [has=T] poll=0 upcall_pend = 00, upcall_mask = 00 > dirty_cpus={0} cpu_affinity={0} > (XEN) pause_count=0 pause_flags=0 > (XEN) No periodic timer > (XEN) Notifying guest 0:0 (virq 1, port 4, stat 0/0/0) > (XEN) Shared frames 0 -- Saved frames 0 > (XEN) 'q' pressed -> dumping domain info (now=0x1379:F55FDF65) > (XEN) General information for domain 0: > (XEN) refcnt=3 dying=0 pause_count=0 > (XEN) nr_pages=262144 xenheap_pages=6 shared_pages=0 paged_pages=0 > dirty_cpus={0} max_pages=4294967295 > (XEN) handle=00000000-0000-0000-0000-000000000000 vm_assist=0000000d > (XEN) watchdog 0 expires in 26 seconds > (XEN) Rangesets belonging to domain 0: > (XEN) I/O Ports { 0-1f, 22-3f, 44-60, 62-9f, a2-407, 40c-cfb, > d00-ffff } > (XEN) Interrupts { 0-279 } > (XEN) I/O Memory { 0-febff, fec01-fedff, fee01-ffffffffffffffff } > (XEN) Memory pages belonging to domain 0: > (XEN) DomPage list too long to display > (XEN) XenPage 0000000000225199: caf=c000000000000002, > taf=7400000000000002 > (XEN) XenPage 0000000000225198: caf=c000000000000001, > taf=7400000000000001 > (XEN) XenPage 0000000000225197: caf=c000000000000001, > taf=7400000000000001 > (XEN) XenPage 0000000000225196: caf=c000000000000001, > taf=7400000000000001 > (XEN) XenPage 00000000000cad73: caf=c000000000000002, > taf=7400000000000002 > (XEN) XenPage 000000000021cf49: caf=c000000000000002, > taf=7400000000000002 > (XEN) VCPU information and callbacks for domain 0: > (XEN) VCPU0: CPU0 [has=T] poll=0 upcall_pend = 00, upcall_mask = 00 > dirty_cpus={0} cpu_affinity={0} > (XEN) pause_count=0 pause_flags=0 > (XEN) No periodic timer > (XEN) Notifying guest 0:0 (virq 1, port 4, stat 0/0/0) > (XEN) Shared frames 0 -- Saved frames 0 > (XEN) 'q' pressed -> dumping domain info (now=0x18AC:EC7F30DD) > (XEN) General information for domain 0: > (XEN) refcnt=3 dying=0 pause_count=0 > (XEN) nr_pages=262144 xenheap_pages=6 shared_pages=0 paged_pages=0 > dirty_cpus={0} max_pages=4294967295 > (XEN) handle=00000000-0000-0000-0000-000000000000 vm_assist=0000000d > (XEN) watchdog 0 expires in 25 seconds > (XEN) Rangesets belonging to domain 0: > (XEN) I/O Ports { 0-1f, 22-3f, 44-60, 62-9f, a2-407, 40c-cfb, > d00-ffff } > (XEN) Interrupts { 0-279 } > (XEN) I/O Memory { 0-febff, fec01-fedff, fee01-ffffffffffffffff } > (XEN) Memory pages belonging to domain 0: > (XEN) DomPage list too long to display > (XEN) XenPage 0000000000225199: caf=c000000000000002, > taf=7400000000000002 > (XEN) XenPage 0000000000225198: caf=c000000000000001, > taf=7400000000000001 > (XEN) XenPage 0000000000225197: caf=c000000000000001, > taf=7400000000000001 > (XEN) XenPage 0000000000225196: caf=c000000000000001, > taf=7400000000000001 > (XEN) XenPage 00000000000cad73: caf=c000000000000002, > taf=7400000000000002 > (XEN) XenPage 000000000021cf49: caf=c000000000000002, > taf=7400000000000002 > (XEN) VCPU information and callbacks for domain 0: > (XEN) VCPU0: CPU0 [has=T] poll=0 upcall_pend = 00, upcall_mask = 00 > dirty_cpus={0} cpu_affinity={0} > (XEN) pause_count=0 pause_flags=0 > (XEN) No periodic timer > (XEN) General information for domain 9: > (XEN) refcnt=3 dying=0 pause_count=0 > (XEN) nr_pages=4096 xenheap_pages=5 shared_pages=0 paged_pages=0 > dirty_cpus={3} max_pages=4352 > (XEN) handle=6a617ce0-9628-47bf-b038-46008e2eb57e vm_assist=00000000 > (XEN) Rangesets belonging to domain 9: > (XEN) I/O Ports { } > (XEN) Interrupts { } > (XEN) I/O Memory { fed40-fed44 } > (XEN) Memory pages belonging to domain 9: > (XEN) DomPage list too long to display > (XEN) XenPage 000000000020895f: caf=c000000000000002, > taf=7400000000000002 > (XEN) XenPage 000000000020895e: caf=c000000000000002, > taf=7400000000000002 > (XEN) XenPage 0000000000206c7f: caf=c000000000000002, > taf=7400000000000002 > (XEN) XenPage 0000000000206c7e: caf=c000000000000002, > taf=7400000000000002 > (XEN) XenPage 00000000000caff0: caf=c000000000000002, > taf=7400000000000002 > (XEN) VCPU information and callbacks for domain 9: > (XEN) VCPU0: CPU3 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 > dirty_cpus={3} cpu_affinity={0-3} > (XEN) pause_count=0 pause_flags=1 > (XEN) 100 Hz periodic timer (period 10 ms) > (XEN) Notifying guest 0:0 (virq 1, port 4, stat 0/0/0) > (XEN) Notifying guest 9:0 (virq 1, port 0, stat 0/-1/0) > (XEN) Shared frames 0 -- Saved frames 0 > > > On 04/18/2013 04:41 PM, Daniel De Graaf wrote: >> On 04/18/2013 07:16 AM, Jordi Cucurull Juan wrote: >>> Hi all, >>> >>> I am trying to set up the development version of Xen with support for >>> virtual TPMs. I am having an issue starting the vTPM Manager. Basically >>> I create the vTPM Manager stub domain as detailed in the documentation: >>> >>> make install-vtpmmgr >>> dd if=/dev/zero of=/var/xen/vtpmmgr-stubdom.img bs=16M count=1 >>> vim /etc/xen/vtpmmgr-stubdom.cfg >>> >>> kernel="/usr/local/lib/xen/boot/vtpmmgr-stubdom.gz" >>> memory=16 >>> disk=["file:/var/xen/vtpmmgr-stubdom.img,hda,w"] >>> name="vtpmmgr" >>> iomem=["fed40,5"] >>> >>> xl create -c /etc/xen/vtpmmgr-stubdom.cfg >>> >>> Nevertheless, when the stub domain is launched it automatically shuts >>> down (see the trace below). Am I doing something wrong? Is there >>> something that can produce this behaviour? >> >> This config matches my (working) config for the vtpmmgr domain, so >> there's >> nothing immediately wrong here. The only differences I note are that I am >> using the kernel blkback (and an LVM partition) for the disk image, which >> shouldn't make any difference from the stubdom's perspective, and that I >> have XSM enabled in the hypervisor (and so have a seclabel defined). >> >>> Daemon running with PID 6347 >>> Xen Minimal OS! >>> start_info: 0xa3000(VA) >>> nr_pages: 0x1000 >>> shared_inf: 0xcaff0000(MA) >>> pt_base: 0xa6000(VA) >>> nr_pt_frames: 0x5 >>> mfn_list: 0x9b000(VA) >>> mod_start: 0x0(VA) >>> mod_len: 0 >>> flags: 0x0 >>> cmd_line: >>> stack: 0x5a7a0-0x7a7a0 >>> MM: Init >>> _text: 0x0(VA) >>> _etext: 0x397f4(VA) >>> _erodata: 0x46000(VA) >>> _edata: 0x48c00(VA) >>> stack start: 0x5a7a0(VA) >>> _end: 0x9adc0(VA) >>> start_pfn: ae >>> max_pfn: 1000 >>> Mapping memory range 0x400000 - 0x1000000 >>> setting 0x0-0x46000 readonly >>> skipped 0x1000 >>> MM: Initialise page allocator for b4000(b4000)-1000000(1000000) >>> MM: done >>> Demand map pfns at 1001000-2001001000. >>> Heap resides at 2001002000-4001002000. >>> Initialising timer interface >>> Initialising console ... done. >>> gnttab_table mapped at 0x1001000. >>> Initialising scheduler >>> Thread "Idle": pointer: 0x2001002050, stack: 0xd0000 >>> Thread "xenstore": pointer: 0x2001002800, stack: 0xe0000 >>> xenbus initialised on irq 1 mfn 0x224faa >>> Thread "shutdown": pointer: 0x2001002fb0, stack: 0xf0000 >>> Dummy main: start_info=0x7a8a0 >>> Thread "main": pointer: 0x2001003760, stack: 0x100000 >>> "main" >>> Shutting down () >>> Shutdown requested: 3 >>> Thread "shutdown" exited. >>> INFO[VTPM]: Starting vTPM manager domain >>> INFO[VTPM]: Option: Using tpm_tis driver >>> ******************* BLKFRONT for device/vbd/768 ********** >>> >>> >>> backend at /local/domain/0/backend/qdisk/7/768 >>> Failed to read /local/domain/0/backend/qdisk/7/768/feature-barrier. >>> 32768 sectors of 512 bytes >>> ************************** >>> blk_open(device/vbd/768) -> 3 >>> ============= Init TPM BACK ================ >>> Thread "tpmback-listener": pointer: 0x20010043f0, stack: 0xf0000 >>> ============= Init TPM TIS Driver ============== >>> IOMEM Machine Base Address: FED40000 >>> Enabled Localities: 0 >>> Map 1 (fed40, ...) at 0x1006000 failed: -1. >> >> This is apparently the error, although I would expect the iomem line >> to allow this mapping (-1 is EPERM, assuming it is correctly passing >> the error number). Does anything appear on the hypervisor's console >> (xl dmesg) that would correspond with this error? >> >> If you can, the output of "xl debug-key q" while the domain is running >> would be useful. Since it's crashing on startup, this may be difficult >> to produce - changing the existing sleep(2) in stubdom/vtpmmgr/vtpmmgr.c >> to a longer time should suffice. The output will go to xl dmesg, and >> the lines of interest would be: >> >> (XEN) General information for domain 5: >> (XEN) refcnt=3 dying=0 pause_count=0 >> (XEN) nr_pages=7168 xenheap_pages=5 shared_pages=0 paged_pages=0 >> dirty_cpus={} max_pages=7424 >> (XEN) handle=3097d8b9-8d80-4bde-94b6-978c98c37296 vm_assist=00000000 >> (XEN) Rangesets belonging to domain 5: >> (XEN) I/O Ports { } >> (XEN) Interrupts { } >> (XEN) I/O Memory { fed40 } >> >> Note: my config contains "iomem=['fed40,1']" not "iomem=['fed40,5']" >> so your >> output will differ there. >> >>> Do_exit called! >>> base is 0x10fcb8 caller is 0x1f08a >>> base is 0x10fcd8 caller is 0x28483 >>> base is 0x10fd88 caller is 0x28558 >>> base is 0x10fde8 caller is 0x2706c >>> base is 0x10fe28 caller is 0x27084 >>> base is 0x10fe38 caller is 0x1bc69 >>> base is 0x10fe78 caller is 0x6f9c >>> base is 0x10ff38 caller is 0x34e5 >>> base is 0x10ff68 caller is 0x1fbbc >>> base is 0x10ffe8 caller is 0x33da >>> >>> Thanks in advance! >>> Jordi. >>> >> >> For future reference, you can resolve these addresses (0x1f08a etc) using >> >> gdb $XEN_BUILD_DIR/stubdom/mini-os-x86_64-vtpmmgr/mini-os >> >> and then running >> >> (gdb) x/i 0x1f08a >> >> for each frame. That's not needed this time since the error location is >> already known: HYPERVISOR_mmu_update failed. >> -- Daniel De Graaf National Security Agency ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: vTPM Manager shuts down 2013-04-18 14:41 ` Daniel De Graaf 2013-04-18 16:42 ` Jordi Cucurull Juan @ 2013-05-22 17:59 ` Konrad Rzeszutek Wilk 2013-05-22 19:05 ` Ross Philipson 1 sibling, 1 reply; 10+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-05-22 17:59 UTC (permalink / raw) To: Daniel De Graaf; +Cc: Jordi Cucurull Juan, xen-devel@lists.xen.org > (XEN) General information for domain 5: > (XEN) refcnt=3 dying=0 pause_count=0 > (XEN) nr_pages=7168 xenheap_pages=5 shared_pages=0 paged_pages=0 dirty_cpus={} max_pages=7424 > (XEN) handle=3097d8b9-8d80-4bde-94b6-978c98c37296 vm_assist=00000000 > (XEN) Rangesets belonging to domain 5: > (XEN) I/O Ports { } > (XEN) Interrupts { } > (XEN) I/O Memory { fed40 } > > Note: my config contains "iomem=['fed40,1']" not "iomem=['fed40,5']" so your > output will differ there. Is that address (fed40) standard? Are there other TPM devices at other locations? How does one find them? lspci? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: vTPM Manager shuts down 2013-05-22 17:59 ` Konrad Rzeszutek Wilk @ 2013-05-22 19:05 ` Ross Philipson 2013-05-22 19:14 ` Ross Philipson 0 siblings, 1 reply; 10+ messages in thread From: Ross Philipson @ 2013-05-22 19:05 UTC (permalink / raw) To: Konrad Rzeszutek Wilk, Daniel De Graaf Cc: Jordi Cucurull Juan, xen-devel@lists.xen.org > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of Konrad Rzeszutek Wilk > Sent: Wednesday, May 22, 2013 2:00 PM > To: Daniel De Graaf > Cc: Jordi Cucurull Juan; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] vTPM Manager shuts down > > > (XEN) General information for domain 5: > > (XEN) refcnt=3 dying=0 pause_count=0 > > (XEN) nr_pages=7168 xenheap_pages=5 shared_pages=0 paged_pages=0 > dirty_cpus={} max_pages=7424 > > (XEN) handle=3097d8b9-8d80-4bde-94b6-978c98c37296 > vm_assist=00000000 > > (XEN) Rangesets belonging to domain 5: > > (XEN) I/O Ports { } > > (XEN) Interrupts { } > > (XEN) I/O Memory { fed40 } > > > > Note: my config contains "iomem=['fed40,1']" not "iomem=['fed40,5']" > so your > > output will differ there. > > Is that address (fed40) standard? Are there other TPM devices at other > locations? Yes that is defined in the TCG's TPM spec. That is the beginning of the PCRs for locality 0 and they range up to locality 4: FED4_0xxxh - FED4_4xxxh If you search for something like TCG_PCClientTPMSpecification_1-21_1-00_FINAL.pdf you can find that information (chapter 9 is on locality). > How does one find them? lspci? The TPM lives on the LPC bus. Some of its features are exported in sysfs: /sys/class/misc/tpm0 > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: vTPM Manager shuts down 2013-05-22 19:05 ` Ross Philipson @ 2013-05-22 19:14 ` Ross Philipson 2013-05-22 20:54 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 10+ messages in thread From: Ross Philipson @ 2013-05-22 19:14 UTC (permalink / raw) To: Ross Philipson, Konrad Rzeszutek Wilk, Daniel De Graaf Cc: Jordi Cucurull Juan, xen-devel@lists.xen.org > -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of Ross Philipson > Sent: Wednesday, May 22, 2013 3:06 PM > To: Konrad Rzeszutek Wilk; Daniel De Graaf > Cc: Jordi Cucurull Juan; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] vTPM Manager shuts down > > > -----Original Message----- > > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > > bounces@lists.xen.org] On Behalf Of Konrad Rzeszutek Wilk > > Sent: Wednesday, May 22, 2013 2:00 PM > > To: Daniel De Graaf > > Cc: Jordi Cucurull Juan; xen-devel@lists.xen.org > > Subject: Re: [Xen-devel] vTPM Manager shuts down > > > > > (XEN) General information for domain 5: > > > (XEN) refcnt=3 dying=0 pause_count=0 > > > (XEN) nr_pages=7168 xenheap_pages=5 shared_pages=0 paged_pages=0 > > dirty_cpus={} max_pages=7424 > > > (XEN) handle=3097d8b9-8d80-4bde-94b6-978c98c37296 > > vm_assist=00000000 > > > (XEN) Rangesets belonging to domain 5: > > > (XEN) I/O Ports { } > > > (XEN) Interrupts { } > > > (XEN) I/O Memory { fed40 } > > > > > > Note: my config contains "iomem=['fed40,1']" not "iomem=['fed40,5']" > > so your > > > output will differ there. > > > > Is that address (fed40) standard? Are there other TPM devices at other > > locations? > > Yes that is defined in the TCG's TPM spec. That is the beginning of the > PCRs > for locality 0 and they range up to locality 4: FED4_0xxxh - FED4_4xxxh > > If you search for something like TCG_PCClientTPMSpecification_1-21_1- > 00_FINAL.pdf > you can find that information (chapter 9 is on locality). > > > How does one find them? lspci? > > The TPM lives on the LPC bus. Some of its features are exported in > sysfs: > > /sys/class/misc/tpm0 Oh and sorry I sent it before I finished what I was going to say. You can find information about it in ACPI. E.g. this Dell I have has a Broadcom 1.2 TPM: Device (\_SB.PCI0.LPCB.TPM) { Name (_HID, EisaId ("BCM0102")) Name (_CID, 0x310CD041) Name (_STR, Unicode ("TPM 1.2 Device")) Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadOnly, 0xFED40000, // Address Base 0x00005000, // Address Length ) }) ... } > > > > > _______________________________________________ > > 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] 10+ messages in thread
* Re: vTPM Manager shuts down 2013-05-22 19:14 ` Ross Philipson @ 2013-05-22 20:54 ` Konrad Rzeszutek Wilk 2013-05-23 14:35 ` Ross Philipson 0 siblings, 1 reply; 10+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-05-22 20:54 UTC (permalink / raw) To: Ross Philipson Cc: Daniel De Graaf, Jordi Cucurull Juan, xen-devel@lists.xen.org On Wed, May 22, 2013 at 07:14:04PM +0000, Ross Philipson wrote: > > -----Original Message----- > > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > > bounces@lists.xen.org] On Behalf Of Ross Philipson > > Sent: Wednesday, May 22, 2013 3:06 PM > > To: Konrad Rzeszutek Wilk; Daniel De Graaf > > Cc: Jordi Cucurull Juan; xen-devel@lists.xen.org > > Subject: Re: [Xen-devel] vTPM Manager shuts down > > > > > -----Original Message----- > > > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > > > bounces@lists.xen.org] On Behalf Of Konrad Rzeszutek Wilk > > > Sent: Wednesday, May 22, 2013 2:00 PM > > > To: Daniel De Graaf > > > Cc: Jordi Cucurull Juan; xen-devel@lists.xen.org > > > Subject: Re: [Xen-devel] vTPM Manager shuts down > > > > > > > (XEN) General information for domain 5: > > > > (XEN) refcnt=3 dying=0 pause_count=0 > > > > (XEN) nr_pages=7168 xenheap_pages=5 shared_pages=0 paged_pages=0 > > > dirty_cpus={} max_pages=7424 > > > > (XEN) handle=3097d8b9-8d80-4bde-94b6-978c98c37296 > > > vm_assist=00000000 > > > > (XEN) Rangesets belonging to domain 5: > > > > (XEN) I/O Ports { } > > > > (XEN) Interrupts { } > > > > (XEN) I/O Memory { fed40 } > > > > > > > > Note: my config contains "iomem=['fed40,1']" not "iomem=['fed40,5']" > > > so your > > > > output will differ there. > > > > > > Is that address (fed40) standard? Are there other TPM devices at other > > > locations? > > > > Yes that is defined in the TCG's TPM spec. That is the beginning of the > > PCRs > > for locality 0 and they range up to locality 4: FED4_0xxxh - FED4_4xxxh > > > > If you search for something like TCG_PCClientTPMSpecification_1-21_1- > > 00_FINAL.pdf > > you can find that information (chapter 9 is on locality). > > > > > How does one find them? lspci? > > > > The TPM lives on the LPC bus. Some of its features are exported in > > sysfs: > > > > /sys/class/misc/tpm0 > > Oh and sorry I sent it before I finished what I was going to say. You can > find information about it in ACPI. E.g. this Dell I have has a Broadcom > 1.2 TPM: > > Device (\_SB.PCI0.LPCB.TPM) > { > Name (_HID, EisaId ("BCM0102")) > Name (_CID, 0x310CD041) > Name (_STR, Unicode ("TPM 1.2 Device")) > Name (_CRS, ResourceTemplate () > { > Memory32Fixed (ReadOnly, > 0xFED40000, // Address Base > 0x00005000, // Address Length > ) > }) > ... > } Would it make sense to have libxl when creating one of the TPM manager domains to automatically get that info from /sys/class/misc/tpm0? Hm, I guess it wouldn't really work unless you added some new config option called 'vtpm_manager=1' to do this. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: vTPM Manager shuts down 2013-05-22 20:54 ` Konrad Rzeszutek Wilk @ 2013-05-23 14:35 ` Ross Philipson 2013-05-28 20:54 ` Daniel De Graaf 0 siblings, 1 reply; 10+ messages in thread From: Ross Philipson @ 2013-05-23 14:35 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: Daniel De Graaf, Jordi Cucurull Juan, xen-devel@lists.xen.org > -----Original Message----- > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Wednesday, May 22, 2013 4:54 PM > To: Ross Philipson > Cc: Daniel De Graaf; Jordi Cucurull Juan; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] vTPM Manager shuts down > > On Wed, May 22, 2013 at 07:14:04PM +0000, Ross Philipson wrote: > > > -----Original Message----- > > > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > > > bounces@lists.xen.org] On Behalf Of Ross Philipson > > > Sent: Wednesday, May 22, 2013 3:06 PM > > > To: Konrad Rzeszutek Wilk; Daniel De Graaf > > > Cc: Jordi Cucurull Juan; xen-devel@lists.xen.org > > > Subject: Re: [Xen-devel] vTPM Manager shuts down > > > > > > > -----Original Message----- > > > > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > > > > bounces@lists.xen.org] On Behalf Of Konrad Rzeszutek Wilk > > > > Sent: Wednesday, May 22, 2013 2:00 PM > > > > To: Daniel De Graaf > > > > Cc: Jordi Cucurull Juan; xen-devel@lists.xen.org > > > > Subject: Re: [Xen-devel] vTPM Manager shuts down > > > > > > > > > (XEN) General information for domain 5: > > > > > (XEN) refcnt=3 dying=0 pause_count=0 > > > > > (XEN) nr_pages=7168 xenheap_pages=5 shared_pages=0 > paged_pages=0 > > > > dirty_cpus={} max_pages=7424 > > > > > (XEN) handle=3097d8b9-8d80-4bde-94b6-978c98c37296 > > > > vm_assist=00000000 > > > > > (XEN) Rangesets belonging to domain 5: > > > > > (XEN) I/O Ports { } > > > > > (XEN) Interrupts { } > > > > > (XEN) I/O Memory { fed40 } > > > > > > > > > > Note: my config contains "iomem=['fed40,1']" not > "iomem=['fed40,5']" > > > > so your > > > > > output will differ there. > > > > > > > > Is that address (fed40) standard? Are there other TPM devices at > other > > > > locations? > > > > > > Yes that is defined in the TCG's TPM spec. That is the beginning of > the > > > PCRs > > > for locality 0 and they range up to locality 4: FED4_0xxxh - > FED4_4xxxh > > > > > > If you search for something like TCG_PCClientTPMSpecification_1- > 21_1- > > > 00_FINAL.pdf > > > you can find that information (chapter 9 is on locality). > > > > > > > How does one find them? lspci? > > > > > > The TPM lives on the LPC bus. Some of its features are exported in > > > sysfs: > > > > > > /sys/class/misc/tpm0 > > > > Oh and sorry I sent it before I finished what I was going to say. You > can > > find information about it in ACPI. E.g. this Dell I have has a > Broadcom > > 1.2 TPM: > > > > Device (\_SB.PCI0.LPCB.TPM) > > { > > Name (_HID, EisaId ("BCM0102")) > > Name (_CID, 0x310CD041) > > Name (_STR, Unicode ("TPM 1.2 Device")) > > Name (_CRS, ResourceTemplate () > > { > > Memory32Fixed (ReadOnly, > > 0xFED40000, // Address Base > > 0x00005000, // Address Length > > ) > > }) > > ... > > } > > Would it make sense to have libxl when creating one of the TPM manager > domains to automatically get that info from /sys/class/misc/tpm0? Do you mean to get that address? It is pretty well fixed (at least on PC platforms). In fact the tpm_tis Linux driver has it hard coded in its defaults: enum tis_defaults { TIS_MEM_BASE = 0xFED40000, TIS_MEM_LEN = 0x5000, TIS_SHORT_TIMEOUT = 750, /* ms */ TIS_LONG_TIMEOUT = 2000, /* 2 sec */ }; Though the pnp code in tpm_tis can take external values for the memory base. I guess the best place to find the actual value(s) would be in ACPI firmware (reading the _CRS). As to your other question, I guess I never thought about whether there could or would be more than one actual TPM on a platform. I am not sure what that would be used for and it seems like the answer is "no" on the surface but I could be wrong. > > Hm, I guess it wouldn't really work unless you added some new > config option called 'vtpm_manager=1' to do this. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: vTPM Manager shuts down 2013-05-23 14:35 ` Ross Philipson @ 2013-05-28 20:54 ` Daniel De Graaf 0 siblings, 0 replies; 10+ messages in thread From: Daniel De Graaf @ 2013-05-28 20:54 UTC (permalink / raw) To: Ross Philipson Cc: Jordi Cucurull Juan, xen-devel@lists.xen.org, Konrad Rzeszutek Wilk On 05/23/2013 10:35 AM, Ross Philipson wrote: >> -----Original Message----- >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] >> Sent: Wednesday, May 22, 2013 4:54 PM >> To: Ross Philipson >> Cc: Daniel De Graaf; Jordi Cucurull Juan; xen-devel@lists.xen.org >> Subject: Re: [Xen-devel] vTPM Manager shuts down >> >> On Wed, May 22, 2013 at 07:14:04PM +0000, Ross Philipson wrote: >>>> -----Original Message----- >>>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- >>>> bounces@lists.xen.org] On Behalf Of Ross Philipson >>>> Sent: Wednesday, May 22, 2013 3:06 PM >>>> To: Konrad Rzeszutek Wilk; Daniel De Graaf >>>> Cc: Jordi Cucurull Juan; xen-devel@lists.xen.org >>>> Subject: Re: [Xen-devel] vTPM Manager shuts down >>>> >>>>> -----Original Message----- >>>>> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- >>>>> bounces@lists.xen.org] On Behalf Of Konrad Rzeszutek Wilk >>>>> Sent: Wednesday, May 22, 2013 2:00 PM >>>>> To: Daniel De Graaf >>>>> Cc: Jordi Cucurull Juan; xen-devel@lists.xen.org >>>>> Subject: Re: [Xen-devel] vTPM Manager shuts down >>>>> >>>>>> (XEN) General information for domain 5: >>>>>> (XEN) refcnt=3 dying=0 pause_count=0 >>>>>> (XEN) nr_pages=7168 xenheap_pages=5 shared_pages=0 >> paged_pages=0 >>>>> dirty_cpus={} max_pages=7424 >>>>>> (XEN) handle=3097d8b9-8d80-4bde-94b6-978c98c37296 >>>>> vm_assist=00000000 >>>>>> (XEN) Rangesets belonging to domain 5: >>>>>> (XEN) I/O Ports { } >>>>>> (XEN) Interrupts { } >>>>>> (XEN) I/O Memory { fed40 } >>>>>> >>>>>> Note: my config contains "iomem=['fed40,1']" not >> "iomem=['fed40,5']" >>>>> so your >>>>>> output will differ there. >>>>> >>>>> Is that address (fed40) standard? Are there other TPM devices at >> other >>>>> locations? >>>> >>>> Yes that is defined in the TCG's TPM spec. That is the beginning of >> the >>>> PCRs >>>> for locality 0 and they range up to locality 4: FED4_0xxxh - >> FED4_4xxxh >>>> >>>> If you search for something like TCG_PCClientTPMSpecification_1- >> 21_1- >>>> 00_FINAL.pdf >>>> you can find that information (chapter 9 is on locality). >>>> >>>>> How does one find them? lspci? >>>> >>>> The TPM lives on the LPC bus. Some of its features are exported in >>>> sysfs: >>>> >>>> /sys/class/misc/tpm0 >>> >>> Oh and sorry I sent it before I finished what I was going to say. You >> can >>> find information about it in ACPI. E.g. this Dell I have has a >> Broadcom >>> 1.2 TPM: >>> >>> Device (\_SB.PCI0.LPCB.TPM) >>> { >>> Name (_HID, EisaId ("BCM0102")) >>> Name (_CID, 0x310CD041) >>> Name (_STR, Unicode ("TPM 1.2 Device")) >>> Name (_CRS, ResourceTemplate () >>> { >>> Memory32Fixed (ReadOnly, >>> 0xFED40000, // Address Base >>> 0x00005000, // Address Length >>> ) >>> }) >>> ... >>> } >> >> Would it make sense to have libxl when creating one of the TPM manager >> domains to automatically get that info from /sys/class/misc/tpm0? > > Do you mean to get that address? It is pretty well fixed (at least on PC > platforms). In fact the tpm_tis Linux driver has it hard coded in its > defaults: > > enum tis_defaults { > TIS_MEM_BASE = 0xFED40000, > TIS_MEM_LEN = 0x5000, > TIS_SHORT_TIMEOUT = 750, /* ms */ > TIS_LONG_TIMEOUT = 2000, /* 2 sec */ > }; > > Though the pnp code in tpm_tis can take external values for > the memory base. I guess the best place to find the actual value(s) > would be in ACPI firmware (reading the _CRS). The ACPI firmware entry is meant to be present for ease of use in an OS that expects devices to have ACPI entries, not as the primary source of the address. In an environment using TBOOT, for example, this ACPI table may not be trusted to report the address correctly. > As to your other question, I guess I never thought about whether there > could or would be more than one actual TPM on a platform. I am not sure > what that would be used for and it seems like the answer is "no" on the > surface but I could be wrong. The TPM PC Client specification mandates that a TPM 1.2 be located at 0xFED40000 (in section 9.1 of the PC Client Specific TIS 1.21 or 5.2 in version 1.3, among other documents). This prevents multiple TPMs claiming to be a PC Client TPM. In general, having multiple TPMs on a single platform is not a useful configuration because it causes confusion when updating PCRs - which is a primary reason you would want your keys on TPM. >> >> Hm, I guess it wouldn't really work unless you added some new >> config option called 'vtpm_manager=1' to do this. The TPM manager already requires a command-line argument to change the locality (and therefore the address it uses to access the TPM), so it's not useful to try to auto-detect the address in one location while the other is still manual. -- Daniel De Graaf National Security Agency ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-05-28 20:54 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-04-18 11:16 vTPM Manager shuts down Jordi Cucurull Juan 2013-04-18 14:41 ` Daniel De Graaf 2013-04-18 16:42 ` Jordi Cucurull Juan 2013-04-18 21:12 ` Daniel De Graaf 2013-05-22 17:59 ` Konrad Rzeszutek Wilk 2013-05-22 19:05 ` Ross Philipson 2013-05-22 19:14 ` Ross Philipson 2013-05-22 20:54 ` Konrad Rzeszutek Wilk 2013-05-23 14:35 ` Ross Philipson 2013-05-28 20:54 ` 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).