* an assertion triggered when running Xen on a HSW desktop
@ 2019-01-15 8:04 Chao Gao
2019-01-15 8:18 ` Roger Pau Monné
0 siblings, 1 reply; 15+ messages in thread
From: Chao Gao @ 2019-01-15 8:04 UTC (permalink / raw)
To: xen-devel, Paul Durrant
The output of lscpu is:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 60
Stepping: 3
CPU MHz: 3528.421
BogoMIPS: 7183.36
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 8192K
NUMA node0 CPU(s): 0-7
Serial console output is:
(XEN) Xen version 4.12-unstable (root@) (gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0) debug=y Tue Jan 15 07:25:29 UTC 2019
(XEN) Latest ChangeSet: Mon Dec 17 09:22:59 2018 +0000 git:a5b0eb3636
(XEN) Console output is synchronous.
(XEN) Bootloader: GRUB 2.02-2ubuntu8.2
(XEN) Command line: dom0=pvh iommu=no-intremap console=com1 com1=115200,8n1 sync_console noreboot=true placeholder
(XEN) Xen image load base address: 0
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN) Found 2 MBR signatures
(XEN) Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009d800 (usable)
(XEN) 000000000009d800 - 00000000000a0000 (reserved)
(XEN) 00000000000e0000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 00000000cee8c000 (usable)
(XEN) 00000000cee8c000 - 00000000cee93000 (ACPI NVS)
(XEN) 00000000cee93000 - 00000000cf2c9000 (usable)
(XEN) 00000000cf2c9000 - 00000000cf760000 (reserved)
(XEN) 00000000cf760000 - 00000000d7eeb000 (usable)
(XEN) 00000000d7eeb000 - 00000000d8000000 (reserved)
(XEN) 00000000d8000000 - 00000000d8760000 (usable)
(XEN) 00000000d8760000 - 00000000d8800000 (reserved)
(XEN) 00000000d8800000 - 00000000d8fae000 (usable)
(XEN) 00000000d8fae000 - 00000000d9000000 (ACPI data)
(XEN) 00000000d9000000 - 00000000da71c000 (usable)
(XEN) 00000000da71c000 - 00000000da800000 (ACPI NVS)
(XEN) 00000000da800000 - 00000000dbe11000 (usable)
(XEN) 00000000dbe11000 - 00000000dc000000 (reserved)
(XEN) 00000000dd000000 - 00000000df200000 (reserved)
(XEN) 00000000f8000000 - 00000000fc000000 (reserved)
(XEN) 00000000fec00000 - 00000000fec01000 (reserved)
(XEN) 00000000fed00000 - 00000000fed04000 (reserved)
(XEN) 00000000fed1c000 - 00000000fed20000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000ff000000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 000000021ee00000 (usable)
(XEN) New Xen image base address: 0xdb800000
(XEN) ACPI: RSDP 000F0490, 0024 (r2 DELL )
(XEN) ACPI: XSDT D8FEE088, 0094 (r1 DELL CBX3 1072009 AMI 10013)
(XEN) ACPI: FACP D8FF9B30, 010C (r5 DELL CBX3 1072009 AMI 10013)
(XEN) ACPI: DSDT D8FEE1B0, B97E (r2 DELL CBX3 14 INTL 20091112)
(XEN) ACPI: FACS DA7FE080, 0040
(XEN) ACPI: APIC D8FF9C40, 0092 (r3 DELL CBX3 1072009 AMI 10013)
(XEN) ACPI: FPDT D8FF9CD8, 0044 (r1 DELL CBX3 1072009 AMI 10013)
(XEN) ACPI: SLIC D8FF9D20, 0176 (r3 DELL CBX3 1072009 MSFT 10013)
(XEN) ACPI: LPIT D8FF9E98, 005C (r1 DELL CBX3 0 AMI. 5)
(XEN) ACPI: SSDT D8FF9EF8, 0539 (r1 PmRef Cpu0Ist 3000 INTL 20120711)
(XEN) ACPI: SSDT D8FFA438, 0AD8 (r1 PmRef CpuPm 3000 INTL 20120711)
(XEN) ACPI: SSDT D8FFAF10, 01C7 (r1 PmRef LakeTiny 3000 INTL 20120711)
(XEN) ACPI: HPET D8FFB0D8, 0038 (r1 DELL CBX3 1072009 AMI. 5)
(XEN) ACPI: SSDT D8FFB110, 036D (r1 SataRe SataTabl 1000 INTL 20120711)
(XEN) ACPI: MCFG D8FFB480, 003C (r1 DELL CBX3 1072009 MSFT 97)
(XEN) ACPI: SSDT D8FFB4C0, 34D6 (r1 SaSsdt SaSsdt 3000 INTL 20091112)
(XEN) ACPI: ASF! D8FFE998, 00A5 (r32 INTEL HCG 1 TFSM F4240)
(XEN) ACPI: DMAR D8FFEA40, 00B8 (r1 INTEL HSW 1 INTL 1)
(XEN) System RAM: 8100MB (8294548kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000021ee00000
(XEN) Domain heap initialised
(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw 000306c3)
(XEN) found SMP MP-table at 000fd970
(XEN) DMI 2.7 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1808 (32 bits)
(XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0]
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1804,1:0], pm1x_evt[1:1800,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - da7fe080/0000000000000000, using 32
(XEN) ACPI: wakeup_vec[da7fe08c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 8, 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) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f
(XEN) PCI: MCFG area at f8000000 reserved in E820
(XEN) PCI: Using MCFG for segment 0000 bus 00-3f
(XEN) ERST table was not found
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 8 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 1528 MSI/MSI-X
(XEN) Not enabling x2APIC: depends on iommu_supports_eim.
(XEN) xstate: size: 0x340 and states: 0x7
(XEN) mce_intel.c:780: MCA Capability: firstbank 0, extended MCE MSR 0, BCAST, CMCI
(XEN) CPU0: Intel machine check reporting enabled
(XEN) Speculative mitigation facilities:
(XEN) Hardware features: IBRS/IBPB STIBP L1D_FLUSH SSBD
(XEN) Compiled-in support: INDIRECT_THUNK SHADOW_PAGING
(XEN) Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS- SSBD-, Other: IBPB L1D_FLUSH
(XEN) L1TF: believed vulnerable, maxphysaddr L1D 46, CPUID 39, Safe address 8000000000
(XEN) Support for HVM VMs: MSR_SPEC_CTRL RSB EAGER_FPU
(XEN) Support for PV VMs: MSR_SPEC_CTRL RSB EAGER_FPU
(XEN) XPTI (64-bit PV only): Dom0 enabled, DomU enabled (with PCID)
(XEN) PV L1TF shadowing: Dom0 disabled, DomU enabled
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN) load_precision_shift: 18
(XEN) load_window_shift: 30
(XEN) underload_balance_tolerance: 0
(XEN) overload_balance_tolerance: -3
(XEN) runqueues arrangement: socket
(XEN) cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Adding cpu 0 to runqueue 0
(XEN) First cpu on runqueue, activating
(XEN) Platform timer is 14.318MHz HPET
(XEN) Detected 3591.700 MHz processor.
(XEN) Initing memory sharing.
(XEN) alt table ffff82d080474d70 -> ffff82d080476bbc
(XEN) spurious 8259A interrupt: IRQ7.
(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 not enabled.
(XEN) Intel VT-d Posted Interrupt not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN) - Dom0 mode: Relaxed
(XEN) Interrupt remapping disabled
(XEN) nr_sockets: 1
(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=0 pin2=0
(XEN) TSC_DEADLINE disabled due to Errata; please update microcode to version 0x22 (or later)
(XEN) Allocated console ring of 64 KiB.
(XEN) mwait-idle: MWAIT substates: 0x42120
(XEN) mwait-idle: v0.4.1 model 0x3c
(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) - VMCS shadowing
(XEN) - VM Functions
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Adding cpu 1 to runqueue 0
(XEN) Adding cpu 2 to runqueue 0
(XEN) Adding cpu 3 to runqueue 0
(XEN) Adding cpu 4 to runqueue 0
(XEN) Adding cpu 5 to runqueue 0
(XEN) Adding cpu 6 to runqueue 0
(XEN) Adding cpu 7 to runqueue 0
(XEN) Brought up 8 CPUs
(XEN) build-id: 44bda4bae3576bb69548249accd210761d1dd3b9
(XEN) Running stub recovery selftests...
(XEN) traps.c:1574: GPF (0000): ffff82d0bffff041 [ffff82d0bffff041] -> ffff82d08038a412
(XEN) traps.c:755: Trap 12: ffff82d0bffff040 [ffff82d0bffff040] -> ffff82d08038a412
(XEN) traps.c:1094: Trap 3: ffff82d0bffff041 [ffff82d0bffff041] -> ffff82d08038a412
(XEN) ACPI sleep modes: S3
(XEN) VPMU: disabled
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) Dom0 has maximum 792 PIRQs
(XEN) NX (Execute Disable) protection active
(XEN) *** Building a PVH Dom0 ***
(XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at iommu.c:323
(XEN) ----[ Xen-4.12-unstable x86_64 debug=y Tainted: C ]----
(XEN) CPU: 0
(XEN) RIP: e008:[<ffff82d08025ccbc>] iommu_map+0xba/0x176
(XEN) RFLAGS: 0000000000010202 CONTEXT: hypervisor
(XEN) rax: 0000000000000000 rbx: 0000000000000007 rcx: 0000000000000003
(XEN) rdx: 000000000020f081 rsi: 0000000000000001 rdi: ffff830215242000
(XEN) rbp: ffff82d080497bb8 rsp: ffff82d080497b58 r8: 0000000000000000
(XEN) r9: ffff82d080497bd4 r10: 0180000000000000 r11: 7fffffffffffffff
(XEN) r12: ffff830215242000 r13: 0000000000000000 r14: 0000000000000001
(XEN) r15: 0000000000000001 cr0: 000000008005003b cr4: 00000000001526e0
(XEN) cr3: 00000000dbc8d000 cr2: 0000000000000000
(XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
(XEN) Xen code around <ffff82d08025ccbc> (iommu_map+0xba/0x176):
(XEN) 41 89 c5 e9 a2 00 00 00 <0f> 0b 0f 0b 41 89 c5 41 80 bc 24 c0 01 00 00 00
(XEN) Xen stack trace from rsp=ffff82d080497b58:
(XEN) 0000000000000020 0000000000000000 ffff82d080497ba8 ffff82d08023d489
(XEN) 0000000000000001 ffff82e0041e1000 ffff830215242000 ffff82e0041e1020
(XEN) ffff830215242000 0000000000000000 0000000000000001 0000000000000001
(XEN) ffff82d080497c08 ffff82d0804182d8 ffff82d080497c08 0000000100000000
(XEN) 000000000000009d 0000000000000000 0000000000000001 ffff82d080444c68
(XEN) 000000000020b43e ffff830215242000 ffff82d080497d58 ffff82d08043716c
(XEN) ffff82d080497fff 0000000100000000 ffff82d08046cbc0 ffff83000009bf40
(XEN) 0000000001e33000 ffff83000009bf30 ffff830213525000 000000000010b43e
(XEN) ffff82d00000000b 00000000000001f4 0000000000100000 0000001f15242000
(XEN) 00ff82d080497cb8 ffff82d08020a8e4 ffff82d0805cf02c ffff82d08048f740
(XEN) 0000000000000092 ffff82d08023dddb ffff82d080497fff ffff82d08048f740
(XEN) ffff82d080497cc8 ffff82d08023de2e ffff82d080497ce8 ffff82d08024016b
(XEN) ffff82d080497ce8 ffff82d08023de78 ffff82d080497d08 ffff82d080240205
(XEN) ffff82d0805a3880 ffff82d0805a3880 ffff82d080497d48 ffff82d08023d489
(XEN) ffff8302152e1550 ffff83000009bf30 0000000001e33000 ffff83000009bf30
(XEN) 0000000001e33000 ffff83000009bf40 ffff82d08046cbc0 ffff830215242000
(XEN) ffff82d080497d98 ffff82d08043e53c ffff82d080497d98 ffff82d08046cbc0
(XEN) ffff8302152e1550 0000000000000001 ffff82d0805d00d0 0000000000000008
(XEN) ffff82d080497ee8 ffff82d08042d8ef 0000000000000000 0000000000000002
(XEN) 0000000000000002 0000000000000002 0000000000000002 0000000000000002
(XEN) Xen call trace:
(XEN) [<ffff82d08025ccbc>] iommu_map+0xba/0x176
(XEN) [<ffff82d0804182d8>] iommu_hwdom_init+0xef/0x220
(XEN) [<ffff82d08043716c>] dom0_construct_pvh+0x189/0x129e
(XEN) [<ffff82d08043e53c>] construct_dom0+0xd4/0xb14
(XEN) [<ffff82d08042d8ef>] __start_xen+0x2710/0x2830
(XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at iommu.c:323
(XEN) ****************************************
(XEN)
(XEN) Manual reset required ('noreboot' specified)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: an assertion triggered when running Xen on a HSW desktop
2019-01-15 8:04 an assertion triggered when running Xen on a HSW desktop Chao Gao
@ 2019-01-15 8:18 ` Roger Pau Monné
2019-01-15 9:11 ` Chao Gao
2019-01-15 9:20 ` Paul Durrant
0 siblings, 2 replies; 15+ messages in thread
From: Roger Pau Monné @ 2019-01-15 8:18 UTC (permalink / raw)
To: Chao Gao; +Cc: xen-devel, Paul Durrant
On Tue, Jan 15, 2019 at 04:04:40PM +0800, Chao Gao wrote:
[...]
> (XEN) Xen version 4.12-unstable (root@) (gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0) debug=y Tue Jan 15 07:25:29 UTC 2019
> (XEN) Latest ChangeSet: Mon Dec 17 09:22:59 2018 +0000 git:a5b0eb3636
[...]
> (XEN) *** Building a PVH Dom0 ***
> (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at iommu.c:323
> (XEN) ----[ Xen-4.12-unstable x86_64 debug=y Tainted: C ]----
> (XEN) CPU: 0
> (XEN) RIP: e008:[<ffff82d08025ccbc>] iommu_map+0xba/0x176
> (XEN) RFLAGS: 0000000000010202 CONTEXT: hypervisor
> (XEN) rax: 0000000000000000 rbx: 0000000000000007 rcx: 0000000000000003
> (XEN) rdx: 000000000020f081 rsi: 0000000000000001 rdi: ffff830215242000
> (XEN) rbp: ffff82d080497bb8 rsp: ffff82d080497b58 r8: 0000000000000000
> (XEN) r9: ffff82d080497bd4 r10: 0180000000000000 r11: 7fffffffffffffff
> (XEN) r12: ffff830215242000 r13: 0000000000000000 r14: 0000000000000001
> (XEN) r15: 0000000000000001 cr0: 000000008005003b cr4: 00000000001526e0
> (XEN) cr3: 00000000dbc8d000 cr2: 0000000000000000
> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000
> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
> (XEN) Xen code around <ffff82d08025ccbc> (iommu_map+0xba/0x176):
> (XEN) 41 89 c5 e9 a2 00 00 00 <0f> 0b 0f 0b 41 89 c5 41 80 bc 24 c0 01 00 00 00
> (XEN) Xen stack trace from rsp=ffff82d080497b58:
> (XEN) 0000000000000020 0000000000000000 ffff82d080497ba8 ffff82d08023d489
> (XEN) 0000000000000001 ffff82e0041e1000 ffff830215242000 ffff82e0041e1020
> (XEN) ffff830215242000 0000000000000000 0000000000000001 0000000000000001
> (XEN) ffff82d080497c08 ffff82d0804182d8 ffff82d080497c08 0000000100000000
> (XEN) 000000000000009d 0000000000000000 0000000000000001 ffff82d080444c68
> (XEN) 000000000020b43e ffff830215242000 ffff82d080497d58 ffff82d08043716c
> (XEN) ffff82d080497fff 0000000100000000 ffff82d08046cbc0 ffff83000009bf40
> (XEN) 0000000001e33000 ffff83000009bf30 ffff830213525000 000000000010b43e
> (XEN) ffff82d00000000b 00000000000001f4 0000000000100000 0000001f15242000
> (XEN) 00ff82d080497cb8 ffff82d08020a8e4 ffff82d0805cf02c ffff82d08048f740
> (XEN) 0000000000000092 ffff82d08023dddb ffff82d080497fff ffff82d08048f740
> (XEN) ffff82d080497cc8 ffff82d08023de2e ffff82d080497ce8 ffff82d08024016b
> (XEN) ffff82d080497ce8 ffff82d08023de78 ffff82d080497d08 ffff82d080240205
> (XEN) ffff82d0805a3880 ffff82d0805a3880 ffff82d080497d48 ffff82d08023d489
> (XEN) ffff8302152e1550 ffff83000009bf30 0000000001e33000 ffff83000009bf30
> (XEN) 0000000001e33000 ffff83000009bf40 ffff82d08046cbc0 ffff830215242000
> (XEN) ffff82d080497d98 ffff82d08043e53c ffff82d080497d98 ffff82d08046cbc0
> (XEN) ffff8302152e1550 0000000000000001 ffff82d0805d00d0 0000000000000008
> (XEN) ffff82d080497ee8 ffff82d08042d8ef 0000000000000000 0000000000000002
> (XEN) 0000000000000002 0000000000000002 0000000000000002 0000000000000002
> (XEN) Xen call trace:
> (XEN) [<ffff82d08025ccbc>] iommu_map+0xba/0x176
> (XEN) [<ffff82d0804182d8>] iommu_hwdom_init+0xef/0x220
> (XEN) [<ffff82d08043716c>] dom0_construct_pvh+0x189/0x129e
> (XEN) [<ffff82d08043e53c>] construct_dom0+0xd4/0xb14
> (XEN) [<ffff82d08042d8ef>] __start_xen+0x2710/0x2830
> (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at iommu.c:323
> (XEN) ****************************************
Oh, this was added by Paul quite recently. You seem to be using a
rather old commit (a5b0eb3636), is there any reason for using such an
old baseline?
In order to fix this you likely need to update your base changeset to
something newer that contains:
commit ae7fc10d2ca5c22e04b8a28becbd1fbf8b44e83a
Author: Roger Pau Monne <roger.pau@citrix.com>
Date: Fri Dec 28 12:18:56 2018 +0100
x86/dom0: take alignment into account when populating p2m in PVH mode
Current code that allocates memory and populates the p2m for PVH Dom0
doesn't take the address alignment into account, this can lead to high
order allocations that start on a non-aligned address to be broken
down into lower order entries on the p2m page tables.
Fix this by taking into account the p2m page sizes and alignment
requirements when allocating the memory and populating the p2m.
AFAICT the above commit should fix the issue, just updating to current
staging branch should be enough.
Paul, I wonder however whether the ASSERT is expected here, this
interface used to work correctly without the alignment requirements,
and 725bf00a8 changed the requirements of the function, which might
make some previously valid calls now trigger the assert. FTR I agree
we should use aligned regions, but the addition of the assert can be
dangerous given it changes the valid inputs of the function and also
affects the p2m functions that ultimately call the iommu code.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: an assertion triggered when running Xen on a HSW desktop
2019-01-15 8:18 ` Roger Pau Monné
@ 2019-01-15 9:11 ` Chao Gao
2019-01-15 9:44 ` Paul Durrant
2019-01-15 9:20 ` Paul Durrant
1 sibling, 1 reply; 15+ messages in thread
From: Chao Gao @ 2019-01-15 9:11 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: xen-devel, Paul Durrant
On Tue, Jan 15, 2019 at 09:18:25AM +0100, Roger Pau Monné wrote:
>On Tue, Jan 15, 2019 at 04:04:40PM +0800, Chao Gao wrote:
>[...]
>> (XEN) Xen version 4.12-unstable (root@) (gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0) debug=y Tue Jan 15 07:25:29 UTC 2019
>> (XEN) Latest ChangeSet: Mon Dec 17 09:22:59 2018 +0000 git:a5b0eb3636
>[...]
>> (XEN) *** Building a PVH Dom0 ***
>> (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at iommu.c:323
>> (XEN) ----[ Xen-4.12-unstable x86_64 debug=y Tainted: C ]----
>> (XEN) CPU: 0
>> (XEN) RIP: e008:[<ffff82d08025ccbc>] iommu_map+0xba/0x176
>> (XEN) RFLAGS: 0000000000010202 CONTEXT: hypervisor
>> (XEN) rax: 0000000000000000 rbx: 0000000000000007 rcx: 0000000000000003
>> (XEN) rdx: 000000000020f081 rsi: 0000000000000001 rdi: ffff830215242000
>> (XEN) rbp: ffff82d080497bb8 rsp: ffff82d080497b58 r8: 0000000000000000
>> (XEN) r9: ffff82d080497bd4 r10: 0180000000000000 r11: 7fffffffffffffff
>> (XEN) r12: ffff830215242000 r13: 0000000000000000 r14: 0000000000000001
>> (XEN) r15: 0000000000000001 cr0: 000000008005003b cr4: 00000000001526e0
>> (XEN) cr3: 00000000dbc8d000 cr2: 0000000000000000
>> (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000
>> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
>> (XEN) Xen code around <ffff82d08025ccbc> (iommu_map+0xba/0x176):
>> (XEN) 41 89 c5 e9 a2 00 00 00 <0f> 0b 0f 0b 41 89 c5 41 80 bc 24 c0 01 00 00 00
>> (XEN) Xen stack trace from rsp=ffff82d080497b58:
>> (XEN) 0000000000000020 0000000000000000 ffff82d080497ba8 ffff82d08023d489
>> (XEN) 0000000000000001 ffff82e0041e1000 ffff830215242000 ffff82e0041e1020
>> (XEN) ffff830215242000 0000000000000000 0000000000000001 0000000000000001
>> (XEN) ffff82d080497c08 ffff82d0804182d8 ffff82d080497c08 0000000100000000
>> (XEN) 000000000000009d 0000000000000000 0000000000000001 ffff82d080444c68
>> (XEN) 000000000020b43e ffff830215242000 ffff82d080497d58 ffff82d08043716c
>> (XEN) ffff82d080497fff 0000000100000000 ffff82d08046cbc0 ffff83000009bf40
>> (XEN) 0000000001e33000 ffff83000009bf30 ffff830213525000 000000000010b43e
>> (XEN) ffff82d00000000b 00000000000001f4 0000000000100000 0000001f15242000
>> (XEN) 00ff82d080497cb8 ffff82d08020a8e4 ffff82d0805cf02c ffff82d08048f740
>> (XEN) 0000000000000092 ffff82d08023dddb ffff82d080497fff ffff82d08048f740
>> (XEN) ffff82d080497cc8 ffff82d08023de2e ffff82d080497ce8 ffff82d08024016b
>> (XEN) ffff82d080497ce8 ffff82d08023de78 ffff82d080497d08 ffff82d080240205
>> (XEN) ffff82d0805a3880 ffff82d0805a3880 ffff82d080497d48 ffff82d08023d489
>> (XEN) ffff8302152e1550 ffff83000009bf30 0000000001e33000 ffff83000009bf30
>> (XEN) 0000000001e33000 ffff83000009bf40 ffff82d08046cbc0 ffff830215242000
>> (XEN) ffff82d080497d98 ffff82d08043e53c ffff82d080497d98 ffff82d08046cbc0
>> (XEN) ffff8302152e1550 0000000000000001 ffff82d0805d00d0 0000000000000008
>> (XEN) ffff82d080497ee8 ffff82d08042d8ef 0000000000000000 0000000000000002
>> (XEN) 0000000000000002 0000000000000002 0000000000000002 0000000000000002
>> (XEN) Xen call trace:
>> (XEN) [<ffff82d08025ccbc>] iommu_map+0xba/0x176
>> (XEN) [<ffff82d0804182d8>] iommu_hwdom_init+0xef/0x220
>> (XEN) [<ffff82d08043716c>] dom0_construct_pvh+0x189/0x129e
>> (XEN) [<ffff82d08043e53c>] construct_dom0+0xd4/0xb14
>> (XEN) [<ffff82d08042d8ef>] __start_xen+0x2710/0x2830
>> (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
>> (XEN)
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 0:
>> (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at iommu.c:323
>> (XEN) ****************************************
>
>Oh, this was added by Paul quite recently. You seem to be using a
>rather old commit (a5b0eb3636), is there any reason for using such an
>old baseline?
I was using the master branch. Your patch below did fix this issue.
Thanks
Chao
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: an assertion triggered when running Xen on a HSW desktop
2019-01-15 8:18 ` Roger Pau Monné
2019-01-15 9:11 ` Chao Gao
@ 2019-01-15 9:20 ` Paul Durrant
1 sibling, 0 replies; 15+ messages in thread
From: Paul Durrant @ 2019-01-15 9:20 UTC (permalink / raw)
To: Roger Pau Monne, Chao Gao; +Cc: xen-devel
> -----Original Message-----
> From: Roger Pau Monne
> Sent: 15 January 2019 08:18
> To: Chao Gao <chao.gao@intel.com>
> Cc: xen-devel@lists.xenproject.org; Paul Durrant <Paul.Durrant@citrix.com>
> Subject: Re: [Xen-devel] an assertion triggered when running Xen on a HSW
> desktop
>
> On Tue, Jan 15, 2019 at 04:04:40PM +0800, Chao Gao wrote:
> [...]
> > (XEN) Xen version 4.12-unstable (root@) (gcc (Ubuntu 7.3.0-
> 27ubuntu1~18.04) 7.3.0) debug=y Tue Jan 15 07:25:29 UTC 2019
> > (XEN) Latest ChangeSet: Mon Dec 17 09:22:59 2018 +0000 git:a5b0eb3636
> [...]
> > (XEN) *** Building a PVH Dom0 ***
> > (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at
> iommu.c:323
> > (XEN) ----[ Xen-4.12-unstable x86_64 debug=y Tainted: C ]----
> > (XEN) CPU: 0
> > (XEN) RIP: e008:[<ffff82d08025ccbc>] iommu_map+0xba/0x176
> > (XEN) RFLAGS: 0000000000010202 CONTEXT: hypervisor
> > (XEN) rax: 0000000000000000 rbx: 0000000000000007 rcx:
> 0000000000000003
> > (XEN) rdx: 000000000020f081 rsi: 0000000000000001 rdi:
> ffff830215242000
> > (XEN) rbp: ffff82d080497bb8 rsp: ffff82d080497b58 r8:
> 0000000000000000
> > (XEN) r9: ffff82d080497bd4 r10: 0180000000000000 r11:
> 7fffffffffffffff
> > (XEN) r12: ffff830215242000 r13: 0000000000000000 r14:
> 0000000000000001
> > (XEN) r15: 0000000000000001 cr0: 000000008005003b cr4:
> 00000000001526e0
> > (XEN) cr3: 00000000dbc8d000 cr2: 0000000000000000
> > (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss:
> 0000000000000000
> > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
> > (XEN) Xen code around <ffff82d08025ccbc> (iommu_map+0xba/0x176):
> > (XEN) 41 89 c5 e9 a2 00 00 00 <0f> 0b 0f 0b 41 89 c5 41 80 bc 24 c0 01
> 00 00 00
> > (XEN) Xen stack trace from rsp=ffff82d080497b58:
> > (XEN) 0000000000000020 0000000000000000 ffff82d080497ba8
> ffff82d08023d489
> > (XEN) 0000000000000001 ffff82e0041e1000 ffff830215242000
> ffff82e0041e1020
> > (XEN) ffff830215242000 0000000000000000 0000000000000001
> 0000000000000001
> > (XEN) ffff82d080497c08 ffff82d0804182d8 ffff82d080497c08
> 0000000100000000
> > (XEN) 000000000000009d 0000000000000000 0000000000000001
> ffff82d080444c68
> > (XEN) 000000000020b43e ffff830215242000 ffff82d080497d58
> ffff82d08043716c
> > (XEN) ffff82d080497fff 0000000100000000 ffff82d08046cbc0
> ffff83000009bf40
> > (XEN) 0000000001e33000 ffff83000009bf30 ffff830213525000
> 000000000010b43e
> > (XEN) ffff82d00000000b 00000000000001f4 0000000000100000
> 0000001f15242000
> > (XEN) 00ff82d080497cb8 ffff82d08020a8e4 ffff82d0805cf02c
> ffff82d08048f740
> > (XEN) 0000000000000092 ffff82d08023dddb ffff82d080497fff
> ffff82d08048f740
> > (XEN) ffff82d080497cc8 ffff82d08023de2e ffff82d080497ce8
> ffff82d08024016b
> > (XEN) ffff82d080497ce8 ffff82d08023de78 ffff82d080497d08
> ffff82d080240205
> > (XEN) ffff82d0805a3880 ffff82d0805a3880 ffff82d080497d48
> ffff82d08023d489
> > (XEN) ffff8302152e1550 ffff83000009bf30 0000000001e33000
> ffff83000009bf30
> > (XEN) 0000000001e33000 ffff83000009bf40 ffff82d08046cbc0
> ffff830215242000
> > (XEN) ffff82d080497d98 ffff82d08043e53c ffff82d080497d98
> ffff82d08046cbc0
> > (XEN) ffff8302152e1550 0000000000000001 ffff82d0805d00d0
> 0000000000000008
> > (XEN) ffff82d080497ee8 ffff82d08042d8ef 0000000000000000
> 0000000000000002
> > (XEN) 0000000000000002 0000000000000002 0000000000000002
> 0000000000000002
> > (XEN) Xen call trace:
> > (XEN) [<ffff82d08025ccbc>] iommu_map+0xba/0x176
> > (XEN) [<ffff82d0804182d8>] iommu_hwdom_init+0xef/0x220
> > (XEN) [<ffff82d08043716c>] dom0_construct_pvh+0x189/0x129e
> > (XEN) [<ffff82d08043e53c>] construct_dom0+0xd4/0xb14
> > (XEN) [<ffff82d08042d8ef>] __start_xen+0x2710/0x2830
> > (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
> > (XEN)
> > (XEN)
> > (XEN) ****************************************
> > (XEN) Panic on CPU 0:
> > (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at
> iommu.c:323
> > (XEN) ****************************************
>
> Oh, this was added by Paul quite recently. You seem to be using a
> rather old commit (a5b0eb3636), is there any reason for using such an
> old baseline?
>
> In order to fix this you likely need to update your base changeset to
> something newer that contains:
>
> commit ae7fc10d2ca5c22e04b8a28becbd1fbf8b44e83a
> Author: Roger Pau Monne <roger.pau@citrix.com>
> Date: Fri Dec 28 12:18:56 2018 +0100
>
> x86/dom0: take alignment into account when populating p2m in PVH mode
>
> Current code that allocates memory and populates the p2m for PVH Dom0
> doesn't take the address alignment into account, this can lead to high
> order allocations that start on a non-aligned address to be broken
> down into lower order entries on the p2m page tables.
>
> Fix this by taking into account the p2m page sizes and alignment
> requirements when allocating the memory and populating the p2m.
>
> AFAICT the above commit should fix the issue, just updating to current
> staging branch should be enough.
>
> Paul, I wonder however whether the ASSERT is expected here, this
> interface used to work correctly without the alignment requirements,
> and 725bf00a8 changed the requirements of the function, which might
> make some previously valid calls now trigger the assert. FTR I agree
> we should use aligned regions, but the addition of the assert can be
> dangerous given it changes the valid inputs of the function and also
> affects the p2m functions that ultimately call the iommu code.
Well, no-one should really be passing an arbitrary order into any function so we need to catch whatever it is. XenServer has a similar issue so I'll be investigating that shortly.
Paul
>
> Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: an assertion triggered when running Xen on a HSW desktop
2019-01-15 9:11 ` Chao Gao
@ 2019-01-15 9:44 ` Paul Durrant
2019-01-15 10:16 ` Jan Beulich
0 siblings, 1 reply; 15+ messages in thread
From: Paul Durrant @ 2019-01-15 9:44 UTC (permalink / raw)
To: 'Chao Gao', Roger Pau Monne; +Cc: xen-devel
> -----Original Message-----
[snip]
> >> (XEN) Xen call trace:
> >> (XEN) [<ffff82d08025ccbc>] iommu_map+0xba/0x176
> >> (XEN) [<ffff82d0804182d8>] iommu_hwdom_init+0xef/0x220
> >> (XEN) [<ffff82d08043716c>] dom0_construct_pvh+0x189/0x129e
> >> (XEN) [<ffff82d08043e53c>] construct_dom0+0xd4/0xb14
> >> (XEN) [<ffff82d08042d8ef>] __start_xen+0x2710/0x2830
> >> (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
> >> (XEN)
> >> (XEN)
> >> (XEN) ****************************************
> >> (XEN) Panic on CPU 0:
> >> (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at
> iommu.c:323
> >> (XEN) ****************************************
> >
> >Oh, this was added by Paul quite recently. You seem to be using a
> >rather old commit (a5b0eb3636), is there any reason for using such an
> >old baseline?
>
> I was using the master branch. Your patch below did fix this issue.
>
Given this failure and the fact that valid orders differ between different architectures, I propose we change the argument to the iommu_map/unmap wrapper functions from an order to a count, thus making it clear that there is no alignment restriction.
Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: an assertion triggered when running Xen on a HSW desktop
2019-01-15 9:44 ` Paul Durrant
@ 2019-01-15 10:16 ` Jan Beulich
2019-01-15 10:27 ` Roger Pau Monné
0 siblings, 1 reply; 15+ messages in thread
From: Jan Beulich @ 2019-01-15 10:16 UTC (permalink / raw)
To: Paul Durrant; +Cc: xen-devel, Chao Gao, Roger Pau Monne
>>> On 15.01.19 at 10:44, <Paul.Durrant@citrix.com> wrote:
>> -----Original Message-----
> [snip]
>> >> (XEN) Xen call trace:
>> >> (XEN) [<ffff82d08025ccbc>] iommu_map+0xba/0x176
>> >> (XEN) [<ffff82d0804182d8>] iommu_hwdom_init+0xef/0x220
>> >> (XEN) [<ffff82d08043716c>] dom0_construct_pvh+0x189/0x129e
>> >> (XEN) [<ffff82d08043e53c>] construct_dom0+0xd4/0xb14
>> >> (XEN) [<ffff82d08042d8ef>] __start_xen+0x2710/0x2830
>> >> (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
>> >> (XEN)
>> >> (XEN)
>> >> (XEN) ****************************************
>> >> (XEN) Panic on CPU 0:
>> >> (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at
>> iommu.c:323
>> >> (XEN) ****************************************
>> >
>> >Oh, this was added by Paul quite recently. You seem to be using a
>> >rather old commit (a5b0eb3636), is there any reason for using such an
>> >old baseline?
>>
>> I was using the master branch. Your patch below did fix this issue.
>
> Given this failure and the fact that valid orders differ between different
> architectures, I propose we change the argument to the iommu_map/unmap
> wrapper functions from an order to a count, thus making it clear that there
> is no alignment restriction.
But the whole idea is for there to be an alignment restriction, such
that it is easy to determine whether large page mappings can be
used to satisfy the request. What's the exact case where a caller
absolutely has to pass in a mis-aligned (dfn,size) tuple?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: an assertion triggered when running Xen on a HSW desktop
2019-01-15 10:16 ` Jan Beulich
@ 2019-01-15 10:27 ` Roger Pau Monné
2019-01-15 10:42 ` Andrew Cooper
2019-01-15 10:49 ` Jan Beulich
0 siblings, 2 replies; 15+ messages in thread
From: Roger Pau Monné @ 2019-01-15 10:27 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Paul Durrant, Chao Gao
On Tue, Jan 15, 2019 at 03:16:01AM -0700, Jan Beulich wrote:
> >>> On 15.01.19 at 10:44, <Paul.Durrant@citrix.com> wrote:
> >> -----Original Message-----
> > [snip]
> >> >> (XEN) Xen call trace:
> >> >> (XEN) [<ffff82d08025ccbc>] iommu_map+0xba/0x176
> >> >> (XEN) [<ffff82d0804182d8>] iommu_hwdom_init+0xef/0x220
> >> >> (XEN) [<ffff82d08043716c>] dom0_construct_pvh+0x189/0x129e
> >> >> (XEN) [<ffff82d08043e53c>] construct_dom0+0xd4/0xb14
> >> >> (XEN) [<ffff82d08042d8ef>] __start_xen+0x2710/0x2830
> >> >> (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
> >> >> (XEN)
> >> >> (XEN)
> >> >> (XEN) ****************************************
> >> >> (XEN) Panic on CPU 0:
> >> >> (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at
> >> iommu.c:323
> >> >> (XEN) ****************************************
> >> >
> >> >Oh, this was added by Paul quite recently. You seem to be using a
> >> >rather old commit (a5b0eb3636), is there any reason for using such an
> >> >old baseline?
> >>
> >> I was using the master branch. Your patch below did fix this issue.
> >
> > Given this failure and the fact that valid orders differ between different
> > architectures, I propose we change the argument to the iommu_map/unmap
> > wrapper functions from an order to a count, thus making it clear that there
> > is no alignment restriction.
>
> But the whole idea is for there to be an alignment restriction, such
> that it is easy to determine whether large page mappings can be
> used to satisfy the request. What's the exact case where a caller
> absolutely has to pass in a mis-aligned (dfn,size) tuple?
Taking PVH Dom0 builder as an example, it's possible to have a RAM
region that starts on a 4K only aligned address. The natural operation
in that case would be to try to allocate a memory region as big as
possible up to the next 2MB boundary. Hence it would be valid to
attempt to populate this 4K only aligned address using an order > 0
and < 9 (2MB order). The alternative here if the asserts are not
removed would be to open-code a loop in the caller that iterates
creating a bunch of order 0 mappings up to the 2MB boundary. The
overhead in that case would be quite big, so I don't think we want to
go down that route (also we would end up with a bunch of loops in the
callers).
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: an assertion triggered when running Xen on a HSW desktop
2019-01-15 10:27 ` Roger Pau Monné
@ 2019-01-15 10:42 ` Andrew Cooper
2019-01-15 10:52 ` Jan Beulich
2019-01-15 10:49 ` Jan Beulich
1 sibling, 1 reply; 15+ messages in thread
From: Andrew Cooper @ 2019-01-15 10:42 UTC (permalink / raw)
To: Roger Pau Monné, Jan Beulich; +Cc: xen-devel, Paul Durrant, Chao Gao
On 15/01/2019 10:27, Roger Pau Monné wrote:
> On Tue, Jan 15, 2019 at 03:16:01AM -0700, Jan Beulich wrote:
>>>>> On 15.01.19 at 10:44, <Paul.Durrant@citrix.com> wrote:
>>>> -----Original Message-----
>>> [snip]
>>>>>> (XEN) Xen call trace:
>>>>>> (XEN) [<ffff82d08025ccbc>] iommu_map+0xba/0x176
>>>>>> (XEN) [<ffff82d0804182d8>] iommu_hwdom_init+0xef/0x220
>>>>>> (XEN) [<ffff82d08043716c>] dom0_construct_pvh+0x189/0x129e
>>>>>> (XEN) [<ffff82d08043e53c>] construct_dom0+0xd4/0xb14
>>>>>> (XEN) [<ffff82d08042d8ef>] __start_xen+0x2710/0x2830
>>>>>> (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
>>>>>> (XEN)
>>>>>> (XEN)
>>>>>> (XEN) ****************************************
>>>>>> (XEN) Panic on CPU 0:
>>>>>> (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at
>>>> iommu.c:323
>>>>>> (XEN) ****************************************
>>>>> Oh, this was added by Paul quite recently. You seem to be using a
>>>>> rather old commit (a5b0eb3636), is there any reason for using such an
>>>>> old baseline?
>>>> I was using the master branch. Your patch below did fix this issue.
>>> Given this failure and the fact that valid orders differ between different
>>> architectures, I propose we change the argument to the iommu_map/unmap
>>> wrapper functions from an order to a count, thus making it clear that there
>>> is no alignment restriction.
>> But the whole idea is for there to be an alignment restriction, such
>> that it is easy to determine whether large page mappings can be
>> used to satisfy the request. What's the exact case where a caller
>> absolutely has to pass in a mis-aligned (dfn,size) tuple?
> Taking PVH Dom0 builder as an example, it's possible to have a RAM
> region that starts on a 4K only aligned address. The natural operation
> in that case would be to try to allocate a memory region as big as
> possible up to the next 2MB boundary. Hence it would be valid to
> attempt to populate this 4K only aligned address using an order > 0
> and < 9 (2MB order). The alternative here if the asserts are not
> removed would be to open-code a loop in the caller that iterates
> creating a bunch of order 0 mappings up to the 2MB boundary. The
> overhead in that case would be quite big, so I don't think we want to
> go down that route (also we would end up with a bunch of loops in the
> callers).
Given the PVH Dom0 building issues which Roger and I worked on over the
Christmas period, there is a human-noticeable difference in construction
time when the caller is doing a loop over order 0 pages, vs an order 8
allocation, and that was for a total of 4Mb of RAM.
A dfn/count interface is actually more flexible than a dfn/order,
because it doesn't require the caller to know the superpage orders of
the underlying implementation to create efficient mappings.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: an assertion triggered when running Xen on a HSW desktop
2019-01-15 10:27 ` Roger Pau Monné
2019-01-15 10:42 ` Andrew Cooper
@ 2019-01-15 10:49 ` Jan Beulich
2019-01-15 11:07 ` Roger Pau Monné
1 sibling, 1 reply; 15+ messages in thread
From: Jan Beulich @ 2019-01-15 10:49 UTC (permalink / raw)
To: Roger Pau Monne; +Cc: xen-devel, Paul Durrant, Chao Gao
>>> On 15.01.19 at 11:27, <roger.pau@citrix.com> wrote:
> On Tue, Jan 15, 2019 at 03:16:01AM -0700, Jan Beulich wrote:
>> >>> On 15.01.19 at 10:44, <Paul.Durrant@citrix.com> wrote:
>> >> -----Original Message-----
>> > [snip]
>> >> >> (XEN) Xen call trace:
>> >> >> (XEN) [<ffff82d08025ccbc>] iommu_map+0xba/0x176
>> >> >> (XEN) [<ffff82d0804182d8>] iommu_hwdom_init+0xef/0x220
>> >> >> (XEN) [<ffff82d08043716c>] dom0_construct_pvh+0x189/0x129e
>> >> >> (XEN) [<ffff82d08043e53c>] construct_dom0+0xd4/0xb14
>> >> >> (XEN) [<ffff82d08042d8ef>] __start_xen+0x2710/0x2830
>> >> >> (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
>> >> >> (XEN)
>> >> >> (XEN)
>> >> >> (XEN) ****************************************
>> >> >> (XEN) Panic on CPU 0:
>> >> >> (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at
>> >> iommu.c:323
>> >> >> (XEN) ****************************************
>> >> >
>> >> >Oh, this was added by Paul quite recently. You seem to be using a
>> >> >rather old commit (a5b0eb3636), is there any reason for using such an
>> >> >old baseline?
>> >>
>> >> I was using the master branch. Your patch below did fix this issue.
>> >
>> > Given this failure and the fact that valid orders differ between different
>> > architectures, I propose we change the argument to the iommu_map/unmap
>> > wrapper functions from an order to a count, thus making it clear that there
>
>> > is no alignment restriction.
>>
>> But the whole idea is for there to be an alignment restriction, such
>> that it is easy to determine whether large page mappings can be
>> used to satisfy the request. What's the exact case where a caller
>> absolutely has to pass in a mis-aligned (dfn,size) tuple?
>
> Taking PVH Dom0 builder as an example, it's possible to have a RAM
> region that starts on a 4K only aligned address. The natural operation
> in that case would be to try to allocate a memory region as big as
> possible up to the next 2MB boundary. Hence it would be valid to
> attempt to populate this 4K only aligned address using an order > 0
> and < 9 (2MB order). The alternative here if the asserts are not
> removed would be to open-code a loop in the caller that iterates
> creating a bunch of order 0 mappings up to the 2MB boundary. The
> overhead in that case would be quite big, so I don't think we want to
> go down that route (also we would end up with a bunch of loops in the
> callers).
I'm afraid I'm now more confused than before: If there's a RAM
region aligned to no better than 4k, how can this possibly be
populated with an order-greater-than-zero allocation? And even
if I re-phrased your reply to mean an arbitrary alignment / order
less than 9, then populating this with such a smaller order is still
fine, and requesting the IOMMU mapping with that smaller order
is still not going to trip the ASSERT() in question.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: an assertion triggered when running Xen on a HSW desktop
2019-01-15 10:42 ` Andrew Cooper
@ 2019-01-15 10:52 ` Jan Beulich
2019-01-15 10:55 ` Paul Durrant
0 siblings, 1 reply; 15+ messages in thread
From: Jan Beulich @ 2019-01-15 10:52 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Chao Gao, Paul Durrant, xen-devel, Roger Pau Monne
>>> On 15.01.19 at 11:42, <andrew.cooper3@citrix.com> wrote:
> On 15/01/2019 10:27, Roger Pau Monné wrote:
>> On Tue, Jan 15, 2019 at 03:16:01AM -0700, Jan Beulich wrote:
>>>>>> On 15.01.19 at 10:44, <Paul.Durrant@citrix.com> wrote:
>>>>> -----Original Message-----
>>>> [snip]
>>>>>>> (XEN) Xen call trace:
>>>>>>> (XEN) [<ffff82d08025ccbc>] iommu_map+0xba/0x176
>>>>>>> (XEN) [<ffff82d0804182d8>] iommu_hwdom_init+0xef/0x220
>>>>>>> (XEN) [<ffff82d08043716c>] dom0_construct_pvh+0x189/0x129e
>>>>>>> (XEN) [<ffff82d08043e53c>] construct_dom0+0xd4/0xb14
>>>>>>> (XEN) [<ffff82d08042d8ef>] __start_xen+0x2710/0x2830
>>>>>>> (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
>>>>>>> (XEN)
>>>>>>> (XEN)
>>>>>>> (XEN) ****************************************
>>>>>>> (XEN) Panic on CPU 0:
>>>>>>> (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at
>>>>> iommu.c:323
>>>>>>> (XEN) ****************************************
>>>>>> Oh, this was added by Paul quite recently. You seem to be using a
>>>>>> rather old commit (a5b0eb3636), is there any reason for using such an
>>>>>> old baseline?
>>>>> I was using the master branch. Your patch below did fix this issue.
>>>> Given this failure and the fact that valid orders differ between different
>>>> architectures, I propose we change the argument to the iommu_map/unmap
>>>> wrapper functions from an order to a count, thus making it clear that there
>>>> is no alignment restriction.
>>> But the whole idea is for there to be an alignment restriction, such
>>> that it is easy to determine whether large page mappings can be
>>> used to satisfy the request. What's the exact case where a caller
>>> absolutely has to pass in a mis-aligned (dfn,size) tuple?
>> Taking PVH Dom0 builder as an example, it's possible to have a RAM
>> region that starts on a 4K only aligned address. The natural operation
>> in that case would be to try to allocate a memory region as big as
>> possible up to the next 2MB boundary. Hence it would be valid to
>> attempt to populate this 4K only aligned address using an order > 0
>> and < 9 (2MB order). The alternative here if the asserts are not
>> removed would be to open-code a loop in the caller that iterates
>> creating a bunch of order 0 mappings up to the 2MB boundary. The
>> overhead in that case would be quite big, so I don't think we want to
>> go down that route (also we would end up with a bunch of loops in the
>> callers).
>
> Given the PVH Dom0 building issues which Roger and I worked on over the
> Christmas period, there is a human-noticeable difference in construction
> time when the caller is doing a loop over order 0 pages, vs an order 8
> allocation, and that was for a total of 4Mb of RAM.
>
> A dfn/count interface is actually more flexible than a dfn/order,
> because it doesn't require the caller to know the superpage orders of
> the underlying implementation to create efficient mappings.
The caller not having to know the implementation supported
super page orders is pretty desirable indeed. But afaics
iommu_map() already allows for this, and even if it didn't this
would not require switching from order to count as function
parameter.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: an assertion triggered when running Xen on a HSW desktop
2019-01-15 10:52 ` Jan Beulich
@ 2019-01-15 10:55 ` Paul Durrant
2019-01-15 11:51 ` Jan Beulich
0 siblings, 1 reply; 15+ messages in thread
From: Paul Durrant @ 2019-01-15 10:55 UTC (permalink / raw)
To: 'Jan Beulich', Andrew Cooper; +Cc: xen-devel, Chao Gao, Roger Pau Monne
> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 15 January 2019 10:53
> To: Andrew Cooper <Andrew.Cooper3@citrix.com>
> Cc: Paul Durrant <Paul.Durrant@citrix.com>; Roger Pau Monne
> <roger.pau@citrix.com>; Chao Gao <chao.gao@intel.com>; xen-devel <xen-
> devel@lists.xenproject.org>
> Subject: Re: [Xen-devel] an assertion triggered when running Xen on a HSW
> desktop
>
> >>> On 15.01.19 at 11:42, <andrew.cooper3@citrix.com> wrote:
> > On 15/01/2019 10:27, Roger Pau Monné wrote:
> >> On Tue, Jan 15, 2019 at 03:16:01AM -0700, Jan Beulich wrote:
> >>>>>> On 15.01.19 at 10:44, <Paul.Durrant@citrix.com> wrote:
> >>>>> -----Original Message-----
> >>>> [snip]
> >>>>>>> (XEN) Xen call trace:
> >>>>>>> (XEN) [<ffff82d08025ccbc>] iommu_map+0xba/0x176
> >>>>>>> (XEN) [<ffff82d0804182d8>] iommu_hwdom_init+0xef/0x220
> >>>>>>> (XEN) [<ffff82d08043716c>] dom0_construct_pvh+0x189/0x129e
> >>>>>>> (XEN) [<ffff82d08043e53c>] construct_dom0+0xd4/0xb14
> >>>>>>> (XEN) [<ffff82d08042d8ef>] __start_xen+0x2710/0x2830
> >>>>>>> (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
> >>>>>>> (XEN)
> >>>>>>> (XEN)
> >>>>>>> (XEN) ****************************************
> >>>>>>> (XEN) Panic on CPU 0:
> >>>>>>> (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))'
> failed at
> >>>>> iommu.c:323
> >>>>>>> (XEN) ****************************************
> >>>>>> Oh, this was added by Paul quite recently. You seem to be using a
> >>>>>> rather old commit (a5b0eb3636), is there any reason for using such
> an
> >>>>>> old baseline?
> >>>>> I was using the master branch. Your patch below did fix this issue.
> >>>> Given this failure and the fact that valid orders differ between
> different
> >>>> architectures, I propose we change the argument to the
> iommu_map/unmap
> >>>> wrapper functions from an order to a count, thus making it clear that
> there
> >>>> is no alignment restriction.
> >>> But the whole idea is for there to be an alignment restriction, such
> >>> that it is easy to determine whether large page mappings can be
> >>> used to satisfy the request. What's the exact case where a caller
> >>> absolutely has to pass in a mis-aligned (dfn,size) tuple?
> >> Taking PVH Dom0 builder as an example, it's possible to have a RAM
> >> region that starts on a 4K only aligned address. The natural operation
> >> in that case would be to try to allocate a memory region as big as
> >> possible up to the next 2MB boundary. Hence it would be valid to
> >> attempt to populate this 4K only aligned address using an order > 0
> >> and < 9 (2MB order). The alternative here if the asserts are not
> >> removed would be to open-code a loop in the caller that iterates
> >> creating a bunch of order 0 mappings up to the 2MB boundary. The
> >> overhead in that case would be quite big, so I don't think we want to
> >> go down that route (also we would end up with a bunch of loops in the
> >> callers).
> >
> > Given the PVH Dom0 building issues which Roger and I worked on over the
> > Christmas period, there is a human-noticeable difference in construction
> > time when the caller is doing a loop over order 0 pages, vs an order 8
> > allocation, and that was for a total of 4Mb of RAM.
> >
> > A dfn/count interface is actually more flexible than a dfn/order,
> > because it doesn't require the caller to know the superpage orders of
> > the underlying implementation to create efficient mappings.
>
> The caller not having to know the implementation supported
> super page orders is pretty desirable indeed. But afaics
> iommu_map() already allows for this, and even if it didn't this
> would not require switching from order to count as function
> parameter.
I guess the question is whether we want to allow arbitrary alignment of the memory passed into iommu_map() or not. If we do then I think a count parameter makes more sense.
Paul
>
> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: an assertion triggered when running Xen on a HSW desktop
2019-01-15 10:49 ` Jan Beulich
@ 2019-01-15 11:07 ` Roger Pau Monné
2019-01-15 11:50 ` Jan Beulich
0 siblings, 1 reply; 15+ messages in thread
From: Roger Pau Monné @ 2019-01-15 11:07 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Paul Durrant, Chao Gao
On Tue, Jan 15, 2019 at 03:49:07AM -0700, Jan Beulich wrote:
> >>> On 15.01.19 at 11:27, <roger.pau@citrix.com> wrote:
> > On Tue, Jan 15, 2019 at 03:16:01AM -0700, Jan Beulich wrote:
> >> >>> On 15.01.19 at 10:44, <Paul.Durrant@citrix.com> wrote:
> >> >> -----Original Message-----
> >> > [snip]
> >> >> >> (XEN) Xen call trace:
> >> >> >> (XEN) [<ffff82d08025ccbc>] iommu_map+0xba/0x176
> >> >> >> (XEN) [<ffff82d0804182d8>] iommu_hwdom_init+0xef/0x220
> >> >> >> (XEN) [<ffff82d08043716c>] dom0_construct_pvh+0x189/0x129e
> >> >> >> (XEN) [<ffff82d08043e53c>] construct_dom0+0xd4/0xb14
> >> >> >> (XEN) [<ffff82d08042d8ef>] __start_xen+0x2710/0x2830
> >> >> >> (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
> >> >> >> (XEN)
> >> >> >> (XEN)
> >> >> >> (XEN) ****************************************
> >> >> >> (XEN) Panic on CPU 0:
> >> >> >> (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at
> >> >> iommu.c:323
> >> >> >> (XEN) ****************************************
> >> >> >
> >> >> >Oh, this was added by Paul quite recently. You seem to be using a
> >> >> >rather old commit (a5b0eb3636), is there any reason for using such an
> >> >> >old baseline?
> >> >>
> >> >> I was using the master branch. Your patch below did fix this issue.
> >> >
> >> > Given this failure and the fact that valid orders differ between different
> >> > architectures, I propose we change the argument to the iommu_map/unmap
> >> > wrapper functions from an order to a count, thus making it clear that there
> >
> >> > is no alignment restriction.
> >>
> >> But the whole idea is for there to be an alignment restriction, such
> >> that it is easy to determine whether large page mappings can be
> >> used to satisfy the request. What's the exact case where a caller
> >> absolutely has to pass in a mis-aligned (dfn,size) tuple?
> >
> > Taking PVH Dom0 builder as an example, it's possible to have a RAM
> > region that starts on a 4K only aligned address. The natural operation
> > in that case would be to try to allocate a memory region as big as
> > possible up to the next 2MB boundary. Hence it would be valid to
> > attempt to populate this 4K only aligned address using an order > 0
> > and < 9 (2MB order). The alternative here if the asserts are not
> > removed would be to open-code a loop in the caller that iterates
> > creating a bunch of order 0 mappings up to the 2MB boundary. The
> > overhead in that case would be quite big, so I don't think we want to
> > go down that route (also we would end up with a bunch of loops in the
> > callers).
>
> I'm afraid I'm now more confused than before: If there's a RAM
> region aligned to no better than 4k, how can this possibly be
> populated with an order-greater-than-zero allocation?
Why not? You can request a memory chunk of order 5 from
alloc_domheap_pages for example and pass that to
guest_physmap_add_page. That would be a perfectly fine operation to do
in order to reach a memory address that's aligned to a 2MB boundary.
The other option as said above is to force the caller to then have a
loop that performs a bunch of order 0 guest_physmap_add_page until it
reaches a 2MB aligned address.
> And even
> if I re-phrased your reply to mean an arbitrary alignment / order
> less than 9, then populating this with such a smaller order is still
> fine, and requesting the IOMMU mapping with that smaller order
> is still not going to trip the ASSERT() in question.
But the caller is then forced to iterate over the region and populate
it with order 0 calls to guest_physmap_add_page, which introduces a
lot of overhead.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: an assertion triggered when running Xen on a HSW desktop
2019-01-15 11:07 ` Roger Pau Monné
@ 2019-01-15 11:50 ` Jan Beulich
2019-01-15 11:59 ` Andrew Cooper
0 siblings, 1 reply; 15+ messages in thread
From: Jan Beulich @ 2019-01-15 11:50 UTC (permalink / raw)
To: Roger Pau Monne; +Cc: xen-devel, Paul Durrant, Chao Gao
>>> On 15.01.19 at 12:07, <roger.pau@citrix.com> wrote:
> On Tue, Jan 15, 2019 at 03:49:07AM -0700, Jan Beulich wrote:
>> >>> On 15.01.19 at 11:27, <roger.pau@citrix.com> wrote:
>> > On Tue, Jan 15, 2019 at 03:16:01AM -0700, Jan Beulich wrote:
>> >> >>> On 15.01.19 at 10:44, <Paul.Durrant@citrix.com> wrote:
>> >> >> -----Original Message-----
>> >> > [snip]
>> >> >> >> (XEN) Xen call trace:
>> >> >> >> (XEN) [<ffff82d08025ccbc>] iommu_map+0xba/0x176
>> >> >> >> (XEN) [<ffff82d0804182d8>] iommu_hwdom_init+0xef/0x220
>> >> >> >> (XEN) [<ffff82d08043716c>] dom0_construct_pvh+0x189/0x129e
>> >> >> >> (XEN) [<ffff82d08043e53c>] construct_dom0+0xd4/0xb14
>> >> >> >> (XEN) [<ffff82d08042d8ef>] __start_xen+0x2710/0x2830
>> >> >> >> (XEN) [<ffff82d0802000f3>] __high_start+0x53/0x55
>> >> >> >> (XEN)
>> >> >> >> (XEN)
>> >> >> >> (XEN) ****************************************
>> >> >> >> (XEN) Panic on CPU 0:
>> >> >> >> (XEN) Assertion 'IS_ALIGNED(dfn_x(dfn), (1ul << page_order))' failed at
>> >> >> iommu.c:323
>> >> >> >> (XEN) ****************************************
>> >> >> >
>> >> >> >Oh, this was added by Paul quite recently. You seem to be using a
>> >> >> >rather old commit (a5b0eb3636), is there any reason for using such an
>> >> >> >old baseline?
>> >> >>
>> >> >> I was using the master branch. Your patch below did fix this issue.
>> >> >
>> >> > Given this failure and the fact that valid orders differ between different
>
>> >> > architectures, I propose we change the argument to the iommu_map/unmap
>> >> > wrapper functions from an order to a count, thus making it clear that
> there
>> >
>> >> > is no alignment restriction.
>> >>
>> >> But the whole idea is for there to be an alignment restriction, such
>> >> that it is easy to determine whether large page mappings can be
>> >> used to satisfy the request. What's the exact case where a caller
>> >> absolutely has to pass in a mis-aligned (dfn,size) tuple?
>> >
>> > Taking PVH Dom0 builder as an example, it's possible to have a RAM
>> > region that starts on a 4K only aligned address. The natural operation
>> > in that case would be to try to allocate a memory region as big as
>> > possible up to the next 2MB boundary. Hence it would be valid to
>> > attempt to populate this 4K only aligned address using an order > 0
>> > and < 9 (2MB order). The alternative here if the asserts are not
>> > removed would be to open-code a loop in the caller that iterates
>> > creating a bunch of order 0 mappings up to the 2MB boundary. The
>> > overhead in that case would be quite big, so I don't think we want to
>> > go down that route (also we would end up with a bunch of loops in the
>> > callers).
>>
>> I'm afraid I'm now more confused than before: If there's a RAM
>> region aligned to no better than 4k, how can this possibly be
>> populated with an order-greater-than-zero allocation?
>
> Why not? You can request a memory chunk of order 5 from
> alloc_domheap_pages for example and pass that to
> guest_physmap_add_page. That would be a perfectly fine operation to do
> in order to reach a memory address that's aligned to a 2MB boundary.
I think it is never a good idea to request chunks of larger
alignment (and hence higher order) than is necessary.
I still don't understand the second sentence in this context though,
so I guess I must still be missing something.
>> And even
>> if I re-phrased your reply to mean an arbitrary alignment / order
>> less than 9, then populating this with such a smaller order is still
>> fine, and requesting the IOMMU mapping with that smaller order
>> is still not going to trip the ASSERT() in question.
>
> But the caller is then forced to iterate over the region and populate
> it with order 0 calls to guest_physmap_add_page, which introduces a
> lot of overhead.
How is the overhead going to be any smaller if it's not the caller
but iommu_map() to do the looping?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: an assertion triggered when running Xen on a HSW desktop
2019-01-15 10:55 ` Paul Durrant
@ 2019-01-15 11:51 ` Jan Beulich
0 siblings, 0 replies; 15+ messages in thread
From: Jan Beulich @ 2019-01-15 11:51 UTC (permalink / raw)
To: Andrew Cooper, Paul Durrant; +Cc: xen-devel, Chao Gao, Roger Pau Monne
>>> On 15.01.19 at 11:55, <Paul.Durrant@citrix.com> wrote:
> I guess the question is whether we want to allow arbitrary alignment of the
> memory passed into iommu_map() or not. If we do then I think a count
> parameter makes more sense.
Agreed. Till now I simply don't see the use case.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: an assertion triggered when running Xen on a HSW desktop
2019-01-15 11:50 ` Jan Beulich
@ 2019-01-15 11:59 ` Andrew Cooper
0 siblings, 0 replies; 15+ messages in thread
From: Andrew Cooper @ 2019-01-15 11:59 UTC (permalink / raw)
To: xen-devel
On 15/01/2019 11:50, Jan Beulich wrote:
>
>>> And even
>>> if I re-phrased your reply to mean an arbitrary alignment / order
>>> less than 9, then populating this with such a smaller order is still
>>> fine, and requesting the IOMMU mapping with that smaller order
>>> is still not going to trip the ASSERT() in question.
>> But the caller is then forced to iterate over the region and populate
>> it with order 0 calls to guest_physmap_add_page, which introduces a
>> lot of overhead.
> How is the overhead going to be any smaller if it's not the caller
> but iommu_map() to do the looping?
Because the calculation of how/when to change superpage level is far
simpler when you've got a mapped table in your hand.
You're also reducing the quantity of validation logic, and the absolute
number of spinlocks which need to taken/released for a single arbitrary
sized map. Furthermore, with the legacy mapping interface currently
being used, you also reduce the quantity of IO-TLB Flushing.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-01-15 11:59 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-15 8:04 an assertion triggered when running Xen on a HSW desktop Chao Gao
2019-01-15 8:18 ` Roger Pau Monné
2019-01-15 9:11 ` Chao Gao
2019-01-15 9:44 ` Paul Durrant
2019-01-15 10:16 ` Jan Beulich
2019-01-15 10:27 ` Roger Pau Monné
2019-01-15 10:42 ` Andrew Cooper
2019-01-15 10:52 ` Jan Beulich
2019-01-15 10:55 ` Paul Durrant
2019-01-15 11:51 ` Jan Beulich
2019-01-15 10:49 ` Jan Beulich
2019-01-15 11:07 ` Roger Pau Monné
2019-01-15 11:50 ` Jan Beulich
2019-01-15 11:59 ` Andrew Cooper
2019-01-15 9:20 ` Paul Durrant
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.