* [PATCH 0/7] fix several issues documentation
@ 2018-04-24 6:44 Juergen Gross
2018-04-24 6:44 ` [PATCH 1/7] doc: sort entries of boot parameters correctly Juergen Gross
` (6 more replies)
0 siblings, 7 replies; 14+ messages in thread
From: Juergen Gross @ 2018-04-24 6:44 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
andrew.cooper3, ian.jackson, tim, ross.lagerwall, jbeulich
docs/misc/xen-command-line.markdown has several issues regarding
the sequence of parameters, missing architecture qualifiers, missing
documentation of one parameter, and markdown syntax. Fix all of those.
Some other documents have syntax issues, too, which show up when
trying to do "make all" in the docs directory. Fix those as well.
In case the maintainers are fine with my changes I believe the series
should be included in 4.11. So for the series:
Release-acked-by: Juergen Gross <jgross@suse.com>
Juergen Gross (7):
doc: sort entries of boot parameters correctly
doc: add architecture qualifier to boot parameter entries
doc: add credit2_cap_period_ms boot parameter description
doc: escape underscores in xen-command-line.markdown
doc: correct livepatch.markdown syntax
doc: correct feature-levelling.pandoc syntax
doc: correct intel_psr_cat_cdp.pandoc syntax
docs/features/feature-levelling.pandoc | 2 +-
docs/features/intel_psr_cat_cdp.pandoc | 366 ++++++++++----------
docs/misc/livepatch.markdown | 589 +++++++++++++++------------------
docs/misc/xen-command-line.markdown | 404 +++++++++++-----------
4 files changed, 655 insertions(+), 706 deletions(-)
--
2.13.6
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 1/7] doc: sort entries of boot parameters correctly
2018-04-24 6:44 [PATCH 0/7] fix several issues documentation Juergen Gross
@ 2018-04-24 6:44 ` Juergen Gross
2018-04-26 14:56 ` Jan Beulich
2018-04-24 6:44 ` [PATCH 2/7] doc: add architecture qualifier to boot parameter entries Juergen Gross
` (5 subsequent siblings)
6 siblings, 1 reply; 14+ messages in thread
From: Juergen Gross @ 2018-04-24 6:44 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
andrew.cooper3, ian.jackson, tim, ross.lagerwall, jbeulich
Some of the boot parameters in docs/misc/xen-command-line.markdown are
not in the correct alphabetically order. Correct that.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
docs/misc/xen-command-line.markdown | 226 ++++++++++++++++++------------------
1 file changed, 113 insertions(+), 113 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index b353352adf..d175e6070b 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -133,6 +133,18 @@ resume.
`s3_mode` instructs Xen to set up the boot time (option `vga=`) video
mode during S3 resume.
+### allow\_unsafe
+> `= <boolean>`
+
+> Default: `false`
+
+Force boot on potentially unsafe systems. By default Xen will refuse
+to boot on systems with the following errata:
+
+* AMD Erratum 121. Processors with this erratum are subject to a guest
+ triggerable Denial of Service. Override only if you trust all of
+ your PV guests.
+
### altp2m (Intel)
> `= <boolean>`
@@ -147,18 +159,6 @@ Override Xen's logic for choosing the APIC driver. By default, if
there are more than 8 CPUs, Xen will switch to `bigsmp` over
`default`.
-### allow\_unsafe
-> `= <boolean>`
-
-> Default: `false`
-
-Force boot on potentially unsafe systems. By default Xen will refuse
-to boot on systems with the following errata:
-
-* AMD Erratum 121. Processors with this erratum are subject to a guest
- triggerable Denial of Service. Override only if you trust all of
- your PV guests.
-
### apicv
> `= <boolean>`
@@ -276,17 +276,6 @@ when the RSB gets overwritten. The former control all RSB overwriting, while
the latter two can be used to fine tune overwriting on from HVM context, and
an entry from a native (PV or Xen) context.
-### xenheap\_megabytes (arm32)
-> `= <size>`
-
-> Default: `0` (1/32 of RAM)
-
-Amount of RAM to set aside for the Xenheap. Must be an integer multiple of 32.
-
-By default will use 1/32 of the RAM up to a maximum of 1GB and with a
-minimum of 32M, subject to a suitably aligned and sized contiguous
-region of memory being available.
-
### clocksource
> `= pit | hpet | acpi | tsc`
@@ -658,6 +647,24 @@ trace feature is only enabled in debugging builds of Xen.
Specify the bit width of the DMA heap.
+### dom0
+> `= List of [ pvh | shadow ]`
+
+> Sub-options:
+
+> `pvh`
+
+> Default: `false`
+
+Flag that makes a dom0 boot in PVHv2 mode.
+
+> `shadow`
+
+> Default: `false`
+
+Flag that makes a dom0 use shadow paging. Only works when "pvh" is
+enabled.
+
### dom0\_ioports\_disable
> `= List of <hex>-<hex>`
@@ -750,24 +757,6 @@ affinities to prefer but be not limited to the specified node(s).
Pin dom0 vcpus to their respective pcpus
-### dom0
-> `= List of [ pvh | shadow ]`
-
-> Sub-options:
-
-> `pvh`
-
-> Default: `false`
-
-Flag that makes a dom0 boot in PVHv2 mode.
-
-> `shadow`
-
-> Default: `false`
-
-Flag that makes a dom0 use shadow paging. Only works when "pvh" is
-enabled.
-
### dtuart (ARM)
> `= path [:options]`
@@ -824,6 +813,30 @@ effect the inverse meaning.
>> Allows mapping of RuntimeServices which have no cachability attribute
>> set as UC.
+### ept (Intel)
+> `= List of ( {no-}pml | {no-}ad )`
+
+Controls EPT related features.
+
+> Sub-options:
+
+> `pml`
+
+> Default: `true`
+
+>> PML is a new hardware feature in Intel's Broadwell Server and further
+>> platforms which reduces hypervisor overhead of log-dirty mechanism by
+>> automatically recording GPAs (guest physical addresses) when guest memory
+>> gets dirty, and therefore significantly reducing number of EPT violation
+>> caused by write protection of guest memory, which is a necessity to
+>> implement log-dirty mechanism before PML.
+
+> `ad`
+
+> Default: Hardware dependent
+
+>> Have hardware keep accessed/dirty (A/D) bits updated.
+
### extra\_guest\_irqs
> `= [<domU number>][,<dom0 number>]`
@@ -889,30 +902,6 @@ requirement can be relaxed. This option is particularly useful for nested
virtualization, to allow the L1 hypervisor to use EPT even if the L0 hypervisor
does not provide VM\_ENTRY\_LOAD\_GUEST\_PAT.
-### ept (Intel)
-> `= List of ( {no-}pml | {no-}ad )`
-
-Controls EPT related features.
-
-> Sub-options:
-
-> `pml`
-
-> Default: `true`
-
->> PML is a new hardware feature in Intel's Broadwell Server and further
->> platforms which reduces hypervisor overhead of log-dirty mechanism by
->> automatically recording GPAs (guest physical addresses) when guest memory
->> gets dirty, and therefore significantly reducing number of EPT violation
->> caused by write protection of guest memory, which is a necessity to
->> implement log-dirty mechanism before PML.
-
-> `ad`
-
-> Default: Hardware dependent
-
->> Have hardware keep accessed/dirty (A/D) bits updated.
-
### gdb
> `= com1[H,L] | com2[H,L] | dbgp`
@@ -1013,6 +1002,12 @@ supported only when compiled with XSM on x86.
Control Xens use of the APEI Hardware Error Source Table, should one be found.
+### highmem-start
+> `= <size>`
+
+Specify the memory boundary past which memory will be treated as highmem (x86
+debug hypervisor only).
+
### hmp-unsafe (arm)
> `= <boolean>`
@@ -1076,12 +1071,6 @@ Specify whether guests are to be given access to physical port 80
(often used for debugging purposes), to override the DMI based
detection of systems known to misbehave upon accesses to that port.
-### highmem-start
-> `= <size>`
-
-Specify the memory boundary past which memory will be treated as highmem (x86
-debug hypervisor only).
-
### idle\_latency\_factor
> `= <integer>`
@@ -1274,16 +1263,8 @@ with **crashinfo_maxaddr**.
Specify the threshold below which Xen will inform dom0 that the quantity of
free memory is getting low. Specifying `0` will disable this notification.
-### memop-max-order
-> `= [<domU>][,[<ctldom>][,[<hwdom>][,<ptdom>]]]`
-
-> x86 default: `9,18,12,12`
-> ARM default: `9,18,10,10`
-
-Change the maximum order permitted for allocation (or allocation-like)
-requests issued by the various kinds of domains (in this order:
-ordinary DomU, control domain, hardware domain, and - when supported
-by the platform - DomU with pass-through device assigned).
+### maxcpus
+> `= <integer>`
### max\_cstate
> `= <integer>`
@@ -1294,9 +1275,6 @@ by the platform - DomU with pass-through device assigned).
Specifies the number of interrupts to be use for pin (IO-APIC or legacy PIC)
based interrupts. Any higher IRQs will be available for use via PCI MSI.
-### maxcpus
-> `= <integer>`
-
### max\_lpi\_bits
> `= <integer>`
@@ -1323,6 +1301,17 @@ Specify verbose machine check output.
Specify the maximum address of physical RAM. Any RAM beyond this
limit is ignored by Xen.
+### memop-max-order
+> `= [<domU>][,[<ctldom>][,[<hwdom>][,<ptdom>]]]`
+
+> x86 default: `9,18,12,12`
+> ARM default: `9,18,10,10`
+
+Change the maximum order permitted for allocation (or allocation-like)
+requests issued by the various kinds of domains (in this order:
+ordinary DomU, control domain, hardware domain, and - when supported
+by the platform - DomU with pass-through device assigned).
+
### mmcfg
> `= <boolean>[,amd-fam10]`
@@ -1442,12 +1431,6 @@ All numbers specified must be hexadecimal ones.
This option can be specified more than once (up to 8 times at present).
-### ple\_gap
-> `= <integer>`
-
-### ple\_window
-> `= <integer>`
-
### pku
> `= <boolean>`
@@ -1458,6 +1441,12 @@ Flag to enable Memory Protection Keys.
The protection-key feature provides an additional mechanism by which IA-32e
paging controls access to usermode addresses.
+### ple\_gap
+> `= <integer>`
+
+### ple\_window
+> `= <integer>`
+
### psr (Intel)
> `= List of ( cmt:<boolean> | rmid_max:<integer> | cat:<boolean> | cos_max:<integer> | cdp:<boolean> )`
@@ -1529,21 +1518,6 @@ guest compatibly inside an HVM container.
In this mode, the kernel and initrd passed as modules to the hypervisor are
constructed into a plain unprivileged PV domain.
-### shim\_mem (x86)
-> `= List of ( min:<size> | max:<size> | <size> )`
-
-Set the amount of memory that xen-shim uses. Only has effect if pv-shim mode is
-enabled. Note that this value accounts for the memory used by the shim itself
-plus the free memory slack given to the shim for runtime allocations.
-
-* `min:<size>` specifies the minimum amount of memory. Ignored if greater
- than max.
-* `max:<size>` specifies the maximum amount of memory.
-* `<size>` specifies the exact amount of memory. Overrides both min and max.
-
-By default, the amount of free memory slack given to the shim for runtime usage
-is 1MB.
-
### rcu-idle-timer-period-ms
> `= <integer>`
@@ -1706,6 +1680,21 @@ hypervisors handle SErrors:
All SErrors will crash the whole system. This option will avoid all overhead
of the dsb/isb pairs.
+### shim\_mem (x86)
+> `= List of ( min:<size> | max:<size> | <size> )`
+
+Set the amount of memory that xen-shim uses. Only has effect if pv-shim mode is
+enabled. Note that this value accounts for the memory used by the shim itself
+plus the free memory slack given to the shim for runtime allocations.
+
+* `min:<size>` specifies the minimum amount of memory. Ignored if greater
+ than max.
+* `max:<size>` specifies the maximum amount of memory.
+* `<size>` specifies the exact amount of memory. Overrides both min and max.
+
+By default, the amount of free memory slack given to the shim for runtime usage
+is 1MB.
+
### smap
> `= <boolean> | hvm`
@@ -1845,14 +1834,6 @@ The optional `keep` parameter causes Xen to continue using the vga
console even after dom0 has been started. The default behaviour is to
relinquish control to dom0.
-### viridian-version
-> `= [<major>],[<minor>],[<build>]`
-
-> Default: `6,0,0x1772`
-
-<major>, <minor> and <build> must be integers. The values will be
-encoded in guest CPUID 0x40000002 if viridian enlightenments are enabled.
-
### viridian-spinlock-retry-count
> `= <integer>`
@@ -1861,6 +1842,14 @@ encoded in guest CPUID 0x40000002 if viridian enlightenments are enabled.
Specify the maximum number of retries before an enlightened Windows
guest will notify Xen that it has failed to acquire a spinlock.
+### viridian-version
+> `= [<major>],[<minor>],[<build>]`
+
+> Default: `6,0,0x1772`
+
+<major>, <minor> and <build> must be integers. The values will be
+encoded in guest CPUID 0x40000002 if viridian enlightenments are enabled.
+
### vpid (Intel)
> `= <boolean>`
@@ -1954,6 +1943,17 @@ In the case that x2apic is in use, this option switches between physical and
clustered mode. The default, given no hint from the **FADT**, is cluster
mode.
+### xenheap\_megabytes (arm32)
+> `= <size>`
+
+> Default: `0` (1/32 of RAM)
+
+Amount of RAM to set aside for the Xenheap. Must be an integer multiple of 32.
+
+By default will use 1/32 of the RAM up to a maximum of 1GB and with a
+minimum of 32M, subject to a suitably aligned and sized contiguous
+region of memory being available.
+
### xpti
> `= <boolean>`
--
2.13.6
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 2/7] doc: add architecture qualifier to boot parameter entries
2018-04-24 6:44 [PATCH 0/7] fix several issues documentation Juergen Gross
2018-04-24 6:44 ` [PATCH 1/7] doc: sort entries of boot parameters correctly Juergen Gross
@ 2018-04-24 6:44 ` Juergen Gross
2018-04-26 15:00 ` Jan Beulich
[not found] ` <5AE1E9A702000078001BEDC1@suse.com>
2018-04-24 6:44 ` [PATCH 3/7] doc: add credit2_cap_period_ms boot parameter description Juergen Gross
` (4 subsequent siblings)
6 siblings, 2 replies; 14+ messages in thread
From: Juergen Gross @ 2018-04-24 6:44 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
andrew.cooper3, ian.jackson, tim, ross.lagerwall, jbeulich
Many of the architecture specific boot parameters are not qualified
as such. Correct that.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
docs/misc/xen-command-line.markdown | 168 ++++++++++++++++++------------------
1 file changed, 84 insertions(+), 84 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index d175e6070b..a6b555d0b0 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -110,7 +110,7 @@ domain 0 command line
Specify which ACPI MADT table to parse for APIC information, if more
than one is present.
-### acpi\_pstate\_strict
+### acpi\_pstate\_strict (x86)
> `= <boolean>`
> Default: `false`
@@ -119,12 +119,12 @@ Enforce checking that P-state transitions by the ACPI cpufreq driver
actually result in the nominated frequency to be established. A warning
message will be logged if that isn't the case.
-### acpi\_skip\_timer\_override
+### acpi\_skip\_timer\_override (x86)
> `= <boolean>`
Instruct Xen to ignore timer-interrupt override.
-### acpi\_sleep
+### acpi\_sleep (x86)
> `= s3_bios | s3_mode`
`s3_bios` instructs Xen to invoke video BIOS initialization during S3
@@ -133,7 +133,7 @@ resume.
`s3_mode` instructs Xen to set up the boot time (option `vga=`) video
mode during S3 resume.
-### allow\_unsafe
+### allow\_unsafe (x86)
> `= <boolean>`
> Default: `false`
@@ -152,14 +152,14 @@ to boot on systems with the following errata:
Permit multiple copies of host p2m.
-### apic
+### apic (x86)
> `= bigsmp | default`
Override Xen's logic for choosing the APIC driver. By default, if
there are more than 8 CPUs, Xen will switch to `bigsmp` over
`default`.
-### apicv
+### apicv (Intel)
> `= <boolean>`
> Default: `true`
@@ -168,12 +168,12 @@ Permit Xen to use APIC Virtualisation Extensions. This is an optimisation
available as part of VT-x, and allows hardware to take care of the guests APIC
handling, rather than requiring emulation in Xen.
-### apic\_verbosity
+### apic\_verbosity (x86)
> `= verbose | debug`
Increase the verbosity of the APIC code from the default value.
-### arat
+### arat (x86)
> `= <boolean>`
> Default: `true`
@@ -182,7 +182,7 @@ Permit Xen to use "Always Running APIC Timer" support on compatible hardware
in combination with cpuidle. This option is only expected to be useful for
developers wishing Xen to fall back to older timing methods on newer hardware.
-### asid
+### asid (x86)
> `= <boolean>`
> Default: `true`
@@ -191,7 +191,7 @@ Permit Xen to use Address Space Identifiers. This is an optimisation which
tags the TLB entries with an ID per vcpu. This allows for guest TLB flushes
to be performed without the overhead of a complete TLB flush.
-### async-show-all
+### async-show-all (x86)
> `= <boolean>`
> Default: `false`
@@ -199,7 +199,7 @@ to be performed without the overhead of a complete TLB flush.
Forces all CPUs' full state to be logged upon certain fatal asynchronous
exceptions (watchdog NMIs and unexpected MCEs).
-### ats
+### ats (x86)
> `= <boolean>`
> Default: `false`
@@ -276,7 +276,7 @@ when the RSB gets overwritten. The former control all RSB overwriting, while
the latter two can be used to fine tune overwriting on from HVM context, and
an entry from a native (PV or Xen) context.
-### clocksource
+### clocksource (x86)
> `= pit | hpet | acpi | tsc`
If set, override Xen's default choice for the platform timer.
@@ -287,7 +287,7 @@ the number of allowed CPUs. When running on platforms that can guarantee a
monotonic TSC across sockets you may want to adjust the "tsc" command line
parameter to "stable:socket".
-### cmci-threshold
+### cmci-threshold (Intel)
> `= <integer>`
> Default: `2`
@@ -295,7 +295,7 @@ parameter to "stable:socket".
Specify the event count threshold for raising Corrected Machine Check
Interrupts. Specifying zero disables CMCI handling.
-### cmos-rtc-probe
+### cmos-rtc-probe (x86)
> `= <boolean>`
> Default: `false`
@@ -459,7 +459,7 @@ character, but for xen to keep the console.
> Default: `power`
-### cpu\_type
+### cpu\_type (x86)
> `= arch_perfmon`
If set, force use of the performance counters for oprofile, rather than detecting
@@ -499,7 +499,7 @@ pre-canned cpuid mask to mask the current processor down to appear as
the specified processor. It is important to ensure that all hosts in a
pool appear the same to guests to allow successful live migration.
-### cpuid\_mask\_{{,ext\_}ecx,edx}
+### cpuid\_mask\_{{,ext\_}ecx,edx} (x86)
> `= <integer>`
> Default: `~0` (all bits set)
@@ -529,10 +529,10 @@ These three command line parameters are also used to specify cpuid
masks to help with cpuid levelling across a pool of hosts. See the
description of the other respective options above.
-### cpuidle
+### cpuidle (x86)
> `= <boolean>`
-### cpuinfo
+### cpuinfo (x86)
> `= <boolean>`
### crashinfo\_maxaddr
@@ -647,7 +647,7 @@ trace feature is only enabled in debugging builds of Xen.
Specify the bit width of the DMA heap.
-### dom0
+### dom0 (x86)
> `= List of [ pvh | shadow ]`
> Sub-options:
@@ -665,7 +665,7 @@ Flag that makes a dom0 boot in PVHv2 mode.
Flag that makes a dom0 use shadow paging. Only works when "pvh" is
enabled.
-### dom0\_ioports\_disable
+### dom0\_ioports\_disable (x86)
> `= List of <hex>-<hex>`
Specify a list of IO ports to be excluded from dom0 access.
@@ -738,7 +738,7 @@ Practices](http://wiki.xen.org/wiki/Xen_Best_Practices#Xen_dom0_dedicated_memory
This option doesn't have effect if pv-shim mode is enabled.
-### dom0\_nodes
+### dom0\_nodes (x86)
> `= List of [ <integer> | relaxed | strict ]`
@@ -765,7 +765,7 @@ Pin dom0 vcpus to their respective pcpus
Specify the full path in the device tree for the UART. If the path doesn't
start with `/`, it is assumed to be an alias. The options are device specific.
-### e820-mtrr-clip
+### e820-mtrr-clip (x86)
> `= <boolean>`
Flag that specifies if RAM should be clipped to the highest cacheable
@@ -773,7 +773,7 @@ MTRR.
> Default: `true` on Intel CPUs, otherwise `false`
-### e820-verbose
+### e820-verbose (x86)
> `= <boolean>`
> Default: `false`
@@ -961,7 +961,7 @@ more importance will be printed.
The optional `<rate-limited level>` option instructs which severities
should be rate limited.
-### hap
+### hap (x86)
> `= <boolean>`
> Default: `true`
@@ -969,7 +969,7 @@ should be rate limited.
Flag to globally enable or disable support for Hardware Assisted
Paging (HAP)
-### hap\_1gb
+### hap\_1gb (x86)
> `= <boolean>`
> Default: `true`
@@ -977,7 +977,7 @@ Paging (HAP)
Flag to enable 1 GB host page table support for Hardware Assisted
Paging (HAP).
-### hap\_2mb
+### hap\_2mb (x86)
> `= <boolean>`
> Default: `true`
@@ -1002,7 +1002,7 @@ supported only when compiled with XSM on x86.
Control Xens use of the APEI Hardware Error Source Table, should one be found.
-### highmem-start
+### highmem-start (x86)
> `= <size>`
Specify the memory boundary past which memory will be treated as highmem (x86
@@ -1023,10 +1023,10 @@ supported. See docs/misc/arm/big.LITTLE.txt for more information.
When the hmp-unsafe option is disabled (default), CPUs that are not
identical to the boot CPU will be parked and not used by Xen.
-### hpetbroadcast
+### hpetbroadcast (x86)
> `= <boolean>`
-### hvm\_debug
+### hvm\_debug (x86)
> `= <integer>`
The specified value is a bit mask with the individual bits having the
@@ -1047,7 +1047,7 @@ following meaning:
Recognized in debug builds of the hypervisor only.
-### hvm\_fep
+### hvm\_fep (x86)
> `= <boolean>`
> Default: `false`
@@ -1062,7 +1062,7 @@ As this feature opens up the instruction emulator to arbitrary
instruction from an HVM guest, don't use this in production system. No
security support is provided when this flag is set.
-### hvm\_port80
+### hvm\_port80 (x86)
> `= <boolean>`
> Default: `true`
@@ -1071,10 +1071,10 @@ Specify whether guests are to be given access to physical port 80
(often used for debugging purposes), to override the DMI based
detection of systems known to misbehave upon accesses to that port.
-### idle\_latency\_factor
+### idle\_latency\_factor (x86)
> `= <integer>`
-### ioapic\_ack
+### ioapic\_ack (x86)
> `= old | new`
> Default: `new` unless directed-EOI is supported
@@ -1201,34 +1201,34 @@ Rather than only mapping RAM pages for IOMMU accesses for Dom0, with this
option all pages not marked as unusable in the E820 table will get a mapping
established.
-### irq\_ratelimit
+### irq\_ratelimit (x86)
> `= <integer>`
-### irq\_vector\_map
-### ivrs_hpet[`<hpet>`]
+### irq\_vector\_map (x86)
+### ivrs_hpet[`<hpet>`] (AMD)
> `=[<seg>:]<bus>:<device>.<func>`
Force the use of `[<seg>:]<bus>:<device>.<func>` as device ID of HPET
`<hpet>` instead of the one specified by the IVHD sub-tables of the IVRS
ACPI table.
-### ivrs_ioapic[`<ioapic>`]
+### ivrs_ioapic[`<ioapic>`] (AMD)
> `=[<seg>:]<bus>:<device>.<func>`
Force the use of `[<seg>:]<bus>:<device>.<func>` as device ID of IO-APIC
`<ioapic>` instead of the one specified by the IVHD sub-tables of the IVRS
ACPI table.
-### lapic
+### lapic (x86)
> `= <boolean>`
Force the use of use of the local APIC on a uniprocessor system, even
if left disabled by the BIOS.
-### lapic\_timer\_c2\_ok
+### lapic\_timer\_c2\_ok (x86)
> `= <boolean>`
-### ler
+### ler (x86)
> `= <boolean>`
### loglvl
@@ -1263,19 +1263,19 @@ with **crashinfo_maxaddr**.
Specify the threshold below which Xen will inform dom0 that the quantity of
free memory is getting low. Specifying `0` will disable this notification.
-### maxcpus
+### maxcpus (x86)
> `= <integer>`
-### max\_cstate
+### max\_cstate (x86)
> `= <integer>`
-### max\_gsi\_irqs
+### max\_gsi\_irqs (x86)
> `= <integer>`
Specifies the number of interrupts to be use for pin (IO-APIC or legacy PIC)
based interrupts. Any higher IRQs will be available for use via PCI MSI.
-### max\_lpi\_bits
+### max\_lpi\_bits (arm)
> `= <integer>`
Specifies the number of ARM GICv3 LPI interrupts to allocate on the host,
@@ -1284,18 +1284,18 @@ presented as the number of bits needed to encode it. This must be at least
one pending bit to be allocated.
Defaults to 20 bits (to cover at most 1048576 interrupts).
-### mce
+### mce (x86)
> `= <integer>`
-### mce\_fb
+### mce\_fb (Intel)
> `= <integer>`
-### mce\_verbosity
+### mce\_verbosity (x86)
> `= verbose`
Specify verbose machine check output.
-### mem
+### mem (x86)
> `= <size>`
Specify the maximum address of physical RAM. Any RAM beyond this
@@ -1312,14 +1312,14 @@ requests issued by the various kinds of domains (in this order:
ordinary DomU, control domain, hardware domain, and - when supported
by the platform - DomU with pass-through device assigned).
-### mmcfg
+### mmcfg (x86)
> `= <boolean>[,amd-fam10]`
> Default: `1`
Specify if the MMConfig space should be enabled.
-### mmio-relax
+### mmio-relax (x86)
> `= <boolean> | all`
> Default: `false`
@@ -1328,21 +1328,21 @@ By default, domains may not create cached mappings to MMIO regions.
This option relaxes the check for Domain 0 (or when using `all`, all PV
domains), to permit the use of cacheable MMIO mappings.
-### msi
+### msi (x86)
> `= <boolean>`
> Default: `true`
Force Xen to (not) use PCI-MSI, even if ACPI FADT says otherwise.
-### mtrr.show
+### mtrr.show (x86)
> `= <boolean>`
> Default: `false`
-Print boot time MTRR state (x86 only).
+Print boot time MTRR state.
-### mwait-idle
+### mwait-idle (x86)
> `= <boolean>`
> Default: `true`
@@ -1350,7 +1350,7 @@ Print boot time MTRR state (x86 only).
Use the MWAIT idle driver (with model specific C-state knowledge) instead
of the ACPI based one.
-### nmi
+### nmi (x86)
> `= ignore | dom0 | fatal`
> Default: `fatal` for a debug build, or `dom0` for a non-debug build
@@ -1359,7 +1359,7 @@ Specify what Xen should do in the event of an NMI parity or I/O error.
`ignore` discards the error; `dom0` causes Xen to report the error to
dom0, while 'fatal' causes Xen to print diagnostics and then hang.
-### noapic
+### noapic (x86)
Instruct Xen to ignore any IOAPICs that are present in the system, and
instead continue to use the legacy PIC. This is _not_ recommended with
@@ -1369,14 +1369,14 @@ Because responsibility for APIC setup is shared between Xen and the
domain 0 kernel this option is automatically propagated to the domain
0 command line.
-### noirqbalance
+### noirqbalance (x86)
> `= <boolean>`
Disable software IRQ balancing and affinity. This can be used on
systems such as Dell 1850/2850 that have workarounds in hardware for
IRQ routing issues.
-### nolapic
+### nolapic (x86)
> `= <boolean>`
> Default: `false`
@@ -1398,16 +1398,16 @@ Do not automatically reboot after an error. This is useful for
catching debug output. Defaults to automatically reboot after 5
seconds.
-### nosmp
+### nosmp (x86)
> `= <boolean>`
Disable SMP support. No secondary processors will be booted.
Defaults to booting secondary processors.
-### nr\_irqs
+### nr\_irqs (x86)
> `= <integer>`
-### numa
+### numa (x86)
> `= on | off | fake=<integer> | noacpi`
> Default: `on`
@@ -1431,7 +1431,7 @@ All numbers specified must be hexadecimal ones.
This option can be specified more than once (up to 8 times at present).
-### pku
+### pku (x86)
> `= <boolean>`
> Default: `true`
@@ -1441,10 +1441,10 @@ Flag to enable Memory Protection Keys.
The protection-key feature provides an additional mechanism by which IA-32e
paging controls access to usermode addresses.
-### ple\_gap
+### ple\_gap (Intel)
> `= <integer>`
-### ple\_window
+### ple\_window (Intel)
> `= <integer>`
### psr (Intel)
@@ -1488,7 +1488,7 @@ The following resources are available:
sum of CBMs is fixed, that means actual `cos_max` in use will automatically
reduce to half when CDP is enabled.
-### pv-linear-pt
+### pv-linear-pt (x86)
> `= <boolean>`
> Default: `true`
@@ -1528,7 +1528,7 @@ should be woken up to check if the grace period has completed, and the
callbacks are safe to be executed. Expressed in milliseconds; maximum is
100, and it can't be 0.
-### reboot
+### reboot (x86)
> `= t[riple] | k[bd] | a[cpi] | p[ci] | P[ower] | e[fi] | n[o] [, [w]arm | [c]old]`
> Default: `0`
@@ -1580,7 +1580,7 @@ rmrr=d5d45=0:0:1d.0;0xd5d46-0xd5d48=0:0:1a.0
Note: grub2 requires to escape or use quotations if special characters are used,
namely ';', refer to the grub2 documentation if multiple ranges are specified.
-### ro-hpet
+### ro-hpet (x86)
> `= <boolean>`
> Default: `true`
@@ -1695,7 +1695,7 @@ plus the free memory slack given to the shim for runtime allocations.
By default, the amount of free memory slack given to the shim for runtime usage
is 1MB.
-### smap
+### smap (x86)
> `= <boolean> | hvm`
> Default: `true`
@@ -1703,7 +1703,7 @@ is 1MB.
Flag to enable Supervisor Mode Access Prevention
Use `smap=hvm` to allow SMAP use by HVM guests only.
-### smep
+### smep (x86)
> `= <boolean> | hvm`
> Default: `true`
@@ -1727,7 +1727,7 @@ false disable the quirk workaround, which is also the default.
Flag to force synchronous console output. Useful for debugging, but
not suitable for production environments due to incurred overhead.
-### tboot
+### tboot (x86)
> `= 0x<phys_addr>`
Specify the physical address of the trusted boot shared page.
@@ -1737,7 +1737,7 @@ Specify the physical address of the trusted boot shared page.
Specify the per-cpu trace buffer size in pages.
-### tdt
+### tdt (x86)
> `= <boolean>`
> Default: `true`
@@ -1764,10 +1764,10 @@ pages) must also be specified via the tbuf\_size parameter.
### tmem\_compress
> `= <boolean>`
-### tsc
+### tsc (x86)
> `= unstable | skewed | stable:socket`
-### ucode
+### ucode (x86)
> `= [<integer> | scan]`
Specify how and where to find CPU microcode update blob.
@@ -1789,7 +1789,7 @@ microcode in the cpio name space must be:
- on Intel: kernel/x86/microcode/GenuineIntel.bin
- on AMD : kernel/x86/microcode/AuthenticAMD.bin
-### unrestricted\_guest
+### unrestricted\_guest (Intel)
> `= <boolean>`
### vcpu\_migration\_delay
@@ -1834,7 +1834,7 @@ The optional `keep` parameter causes Xen to continue using the vga
console even after dom0 has been started. The default behaviour is to
relinquish control to dom0.
-### viridian-spinlock-retry-count
+### viridian-spinlock-retry-count (x86)
> `= <integer>`
> Default: `2047`
@@ -1842,7 +1842,7 @@ relinquish control to dom0.
Specify the maximum number of retries before an enlightened Windows
guest will notify Xen that it has failed to acquire a spinlock.
-### viridian-version
+### viridian-version (x86)
> `= [<major>],[<minor>],[<build>]`
> Default: `6,0,0x1772`
@@ -1858,7 +1858,7 @@ encoded in guest CPUID 0x40000002 if viridian enlightenments are enabled.
Use Virtual Processor ID support if available. This prevents the need for TLB
flushes on VM entry and exit, increasing performance.
-### vpmu
+### vpmu (x86)
> `= ( <boolean> | { bts | ipc | arch [, ...] } )`
> Default: `off`
@@ -1894,7 +1894,7 @@ Note that if **watchdog** option is also specified vpmu will be turned off.
As the virtualisation is not 100% safe, don't use the vpmu flag on
production systems (see http://xenbits.xen.org/xsa/advisory-163.html)!
-### vwfi
+### vwfi (arm)
> `= trap | native
> Default: `trap`
@@ -1909,7 +1909,7 @@ vwfi to `native` reduces irq latency significantly. It can also lead to
suboptimal scheduling decisions, but only when the system is
oversubscribed (i.e., in total there are more vCPUs than pCPUs).
-### watchdog
+### watchdog (x86)
> `= force | <boolean>`
> Default: `false`
@@ -1919,7 +1919,7 @@ longer than the **watchdog\_timeout**, a panic occurs. When `force` is
specified, in addition to running an NMI watchdog on each processor,
unknown NMIs will still be processed.
-### watchdog\_timeout
+### watchdog\_timeout (x86)
> `= <integer>`
> Default: `5`
@@ -1927,14 +1927,14 @@ unknown NMIs will still be processed.
Set the NMI watchdog timeout in seconds. Specifying `0` will turn off
the watchdog.
-### x2apic
+### x2apic (x86)
> `= <boolean>`
> Default: `true`
Permit use of x2apic setup for SMP environments.
-### x2apic\_phys
+### x2apic\_phys (x86)
> `= <boolean>`
> Default: `true` if **FADT** mandates physical mode, `false` otherwise.
@@ -1954,7 +1954,7 @@ By default will use 1/32 of the RAM up to a maximum of 1GB and with a
minimum of 32M, subject to a suitably aligned and sized contiguous
region of memory being available.
-### xpti
+### xpti (x86)
> `= <boolean>`
> Default: `false` on AMD hardware
@@ -1963,7 +1963,7 @@ region of memory being available.
Override default selection of whether to isolate 64-bit PV guest page
tables.
-### xsave
+### xsave (x86)
> `= <boolean>`
> Default: `true`
--
2.13.6
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 3/7] doc: add credit2_cap_period_ms boot parameter description
2018-04-24 6:44 [PATCH 0/7] fix several issues documentation Juergen Gross
2018-04-24 6:44 ` [PATCH 1/7] doc: sort entries of boot parameters correctly Juergen Gross
2018-04-24 6:44 ` [PATCH 2/7] doc: add architecture qualifier to boot parameter entries Juergen Gross
@ 2018-04-24 6:44 ` Juergen Gross
2018-04-24 6:44 ` [PATCH 4/7] doc: escape underscores in xen-command-line.markdown Juergen Gross
` (3 subsequent siblings)
6 siblings, 0 replies; 14+ messages in thread
From: Juergen Gross @ 2018-04-24 6:44 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
andrew.cooper3, ian.jackson, tim, ross.lagerwall, jbeulich
credit2_cap_period_ms isn't mentioned in xen-command-line.markdown.
Add a description.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
docs/misc/xen-command-line.markdown | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index a6b555d0b0..ad08f3b645 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -568,6 +568,16 @@ which would otherwise require escaping of the < option
### credit2\_balance\_under
> `= <integer>`
+### credit2\_cap\_period\_ms
+> `= <integer>`
+
+> Default: `10`
+
+Domains subject to a cap receive a replenishment of their runtime budget
+once every cap period interval. Default is 10 ms. The amount of budget
+they receive depends on their cap. For instance, a domain with a 50% cap
+will receive 50% of 10 ms, so 5 ms.
+
### credit2\_load\_precision\_shift
> `= <integer>`
--
2.13.6
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 4/7] doc: escape underscores in xen-command-line.markdown
2018-04-24 6:44 [PATCH 0/7] fix several issues documentation Juergen Gross
` (2 preceding siblings ...)
2018-04-24 6:44 ` [PATCH 3/7] doc: add credit2_cap_period_ms boot parameter description Juergen Gross
@ 2018-04-24 6:44 ` Juergen Gross
2018-04-26 15:06 ` Jan Beulich
2018-04-24 6:44 ` [PATCH 5/7] doc: correct livepatch.markdown syntax Juergen Gross
` (2 subsequent siblings)
6 siblings, 1 reply; 14+ messages in thread
From: Juergen Gross @ 2018-04-24 6:44 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
andrew.cooper3, ian.jackson, tim, ross.lagerwall, jbeulich
Some underscores are not escaped in xen-command-line.markdown.
Correct that.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
docs/misc/xen-command-line.markdown | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index ad08f3b645..713f9a6093 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -258,7 +258,7 @@ extreme care.**
A (negative) boolean value can be specified to turn off all mitigations.
(Use of a positive boolean value is invalid.)
-If Xen was compiled with INDIRECT_THUNK support, `thunk=` can be used to
+If Xen was compiled with INDIRECT\_THUNK support, `thunk=` can be used to
select which of the thunks gets patched into the `__x86_indirect_thunk_%reg`
locations. The default thunk is `retpoline` (generally preferred for Intel
hardware), with the alternatives being `jmp` (a `jmp *%reg` gadget, minimal
@@ -359,7 +359,7 @@ The accepted name keywords for name=value pairs are:
Do note - these values are multiplied by 16.
* `data-bits` - integer between 5 and 8
* `dev` - accepted values are `pci` OR `amt`. If this option
- is used to specify if the serial device is pci-based. The io_base
+ is used to specify if the serial device is pci-based. The io\_base
cannot be specified when `dev=pci` or `dev=amt` is used.
* `io-base` - accepts integer which specified IO base port for UART registers
* `irq` - IRQ number to use
@@ -374,8 +374,8 @@ The accepted name keywords for name=value pairs are:
The following are examples of correct specifications:
com1=115200,8n1,0x3f8,4
- com1=115200,8n1,0x3f8,4,reg_width=4,reg_shift=2
- com1=baud=115200,parity=n,stop_bits=1,io_base=0x3f8,reg_width=4
+ com1=115200,8n1,0x3f8,4,reg\_width=4,reg\_shift=2
+ com1=baud=115200,parity=n,stop\_bits=1,io\_base=0x3f8,reg\_width=4
### conring\_size
> `= <size>`
@@ -1215,14 +1215,14 @@ established.
> `= <integer>`
### irq\_vector\_map (x86)
-### ivrs_hpet[`<hpet>`] (AMD)
+### ivrs\_hpet[`<hpet>`] (AMD)
> `=[<seg>:]<bus>:<device>.<func>`
Force the use of `[<seg>:]<bus>:<device>.<func>` as device ID of HPET
`<hpet>` instead of the one specified by the IVHD sub-tables of the IVRS
ACPI table.
-### ivrs_ioapic[`<ioapic>`] (AMD)
+### ivrs\_ioapic[`<ioapic>`] (AMD)
> `=[<seg>:]<bus>:<device>.<func>`
Force the use of `[<seg>:]<bus>:<device>.<func>` as device ID of IO-APIC
@@ -1257,13 +1257,13 @@ should be rate limited.
### low\_crashinfo
> `= none | min | all`
-> Default: `none` if not specified at all, or to `min` if **low_crashinfo** is present without qualification.
+> Default: `none` if not specified at all, or to `min` if **low\_crashinfo** is present without qualification.
This option is only useful for hosts with a 32bit dom0 kernel, wishing
to use kexec functionality in the case of a crash. It represents
which data structures should be deliberately allocated in low memory,
so the crash kernel may find find them. Should be used in combination
-with **crashinfo_maxaddr**.
+with **crashinfo\_maxaddr**.
### low\_mem\_virq\_limit
> `= <size>`
@@ -1555,7 +1555,7 @@ Specify the host reboot method.
`kbd` instructs Xen to reboot the host via the keyboard controller.
-`acpi` instructs Xen to reboot the host using RESET_REG in the ACPI FADT.
+`acpi` instructs Xen to reboot the host using RESET\_REG in the ACPI FADT.
`pci` instructs Xen to reboot the host using PCI reset register (port CF9).
--
2.13.6
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 5/7] doc: correct livepatch.markdown syntax
2018-04-24 6:44 [PATCH 0/7] fix several issues documentation Juergen Gross
` (3 preceding siblings ...)
2018-04-24 6:44 ` [PATCH 4/7] doc: escape underscores in xen-command-line.markdown Juergen Gross
@ 2018-04-24 6:44 ` Juergen Gross
2018-04-26 15:12 ` Konrad Rzeszutek Wilk
2018-04-24 6:44 ` [PATCH 6/7] doc: correct feature-levelling.pandoc syntax Juergen Gross
2018-04-24 6:44 ` [PATCH 7/7] doc: correct intel_psr_cat_cdp.pandoc syntax Juergen Gross
6 siblings, 1 reply; 14+ messages in thread
From: Juergen Gross @ 2018-04-24 6:44 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
andrew.cooper3, ian.jackson, tim, ross.lagerwall, jbeulich
"make -C docs all" fails due to incorrect markdown syntax in
livepatch.markdown. Correct it.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
docs/misc/livepatch.markdown | 589 ++++++++++++++++++++-----------------------
1 file changed, 272 insertions(+), 317 deletions(-)
diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 54a6b850cb..f3c1320e5a 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -89,33 +89,26 @@ As example we will assume the hypervisor does not have XSA-132 (see
4ff3449f0e9d175ceb9551d3f2aecb59273f639d) and we would like to binary patch
the hypervisor with it. The original code looks as so:
-<pre>
- 48 89 e0 mov %rsp,%rax
- 48 25 00 80 ff ff and $0xffffffffffff8000,%rax
-</pre>
+ 48 89 e0 mov %rsp,%rax
+ 48 25 00 80 ff ff and $0xffffffffffff8000,%rax
while the new patched hypervisor would be:
-<pre>
- 48 c7 45 b8 00 00 00 00 movq $0x0,-0x48(%rbp)
- 48 c7 45 c0 00 00 00 00 movq $0x0,-0x40(%rbp)
- 48 c7 45 c8 00 00 00 00 movq $0x0,-0x38(%rbp)
- 48 89 e0 mov %rsp,%rax
- 48 25 00 80 ff ff and $0xffffffffffff8000,%rax
-</pre>
+ 48 c7 45 c0 00 00 00 00 movq $0x0,-0x40(%rbp)
+ 48 c7 45 c8 00 00 00 00 movq $0x0,-0x38(%rbp)
+ 48 89 e0 mov %rsp,%rax
+ 48 25 00 80 ff ff and $0xffffffffffff8000,%rax
-This is inside the arch_do_domctl. This new change adds 21 extra
+This is inside the arch\_do\_domctl. This new change adds 21 extra
bytes of code which alters all the offsets inside the function. To alter
these offsets and add the extra 21 bytes of code we might not have enough
space in .text to squeeze this in.
As such we could simplify this problem by only patching the site
-which calls arch_do_domctl:
+which calls arch\_do\_domctl:
-<pre>
-do_domctl:
- e8 4b b1 05 00 callq ffff82d08015fbb9 <arch_do_domctl>
-</pre>
+ do_domctl:
+ e8 4b b1 05 00 callq ffff82d08015fbb9 <arch_do_domctl>
with a new address for where the new `arch_do_domctl` would be (this
area would be allocated dynamically).
@@ -123,15 +116,13 @@ area would be allocated dynamically).
Astute readers will wonder what we need to do if we were to patch `do_domctl`
- which is not called directly by hypervisor but on behalf of the guests via
the `compat_hypercall_table` and `hypercall_table`.
-Patching the offset in `hypercall_table` for `do_domctl:
-(ffff82d080103079 <do_domctl>:)
+Patching the offset in `hypercall_table` for `do_domctl`:
+(ffff82d080103079 <do\_domctl>:)
-<pre>
-
- ffff82d08024d490: 79 30
- ffff82d08024d492: 10 80 d0 82 ff ff
-
-</pre>
+
+ ffff82d08024d490: 79 30
+ ffff82d08024d492: 10 80 d0 82 ff ff
+
with the new address where the new `do_domctl` is possible. The other
place where it is used is in `hvm_hypercall64_table` which would need
@@ -164,19 +155,17 @@ CPU branching logic (I-cache, but it is just one unconditional jump).
For this example we will assume that the hypervisor has not been compiled
with fe2e079f642effb3d24a6e1a7096ef26e691d93e (XSA-125: *pre-fill structures
-for certain HYPERVISOR_xen_version sub-ops*) which mem-sets an structure
+for certain HYPERVISOR\_xen\_version sub-ops*) which mem-sets an structure
in `xen_version` hypercall. This function is not called **anywhere** in
the hypervisor (it is called by the guest) but referenced in the
`compat_hypercall_table` and `hypercall_table` (and indirectly called
from that). Patching the offset in `hypercall_table` for the old
-`do_xen_version` (ffff82d080112f9e <do_xen_version>)
-
-</pre>
- ffff82d08024b270 <hypercall_table>:
- ...
- ffff82d08024b2f8: 9e 2f 11 80 d0 82 ff ff
+`do_xen_version` (ffff82d080112f9e <do\_xen\_version>)
-</pre>
+ ffff82d08024b270 <hypercall_table>:
+ ...
+ ffff82d08024b2f8: 9e 2f 11 80 d0 82 ff ff
+
with the new address where the new `do_xen_version` is possible. The other
place where it is used is in `hvm_hypercall64_table` which would need
@@ -184,21 +173,17 @@ to be patched in a similar way. This would require an in-place splicing
of the new virtual address of `do_xen_version`.
An alternative solution would be to patch insert a trampoline in the
-old `do_xen_version' function to directly jump to the new `do_xen_version`.
+old `do_xen_version` function to directly jump to the new `do_xen_version`.
-<pre>
- ffff82d080112f9e do_xen_version:
- ffff82d080112f9e: 48 c7 c0 da ff ff ff mov $0xffffffffffffffda,%rax
- ffff82d080112fa5: 83 ff 09 cmp $0x9,%edi
- ffff82d080112fa8: 0f 87 24 05 00 00 ja ffff82d0801134d2 ; do_xen_version+0x534
-</pre>
+ ffff82d080112f9e do_xen_version:
+ ffff82d080112f9e: 48 c7 c0 da ff ff ff mov $0xffffffffffffffda,%rax
+ ffff82d080112fa5: 83 ff 09 cmp $0x9,%edi
+ ffff82d080112fa8: 0f 87 24 05 00 00 ja ffff82d0801134d2 ; do_xen_version+0x534
with:
-<pre>
- ffff82d080112f9e do_xen_version:
- ffff82d080112f9e: e9 XX YY ZZ QQ jmpq [new do_xen_version]
-</pre>
+ ffff82d080112f9e do_xen_version:
+ ffff82d080112f9e: e9 XX YY ZZ QQ jmpq [new do_xen_version]
which would lessen the amount of patching to just one location.
@@ -208,7 +193,7 @@ new replacement function which required:
* inserting trampoline with new offset in the old function to point to the
new function.
* Optionally we can insert in the old function a trampoline jump to an function
- providing an BUG_ON to catch errant code.
+ providing an BUG\_ON to catch errant code.
The disadvantage of this are that the unconditional jump will consume a small
I-cache penalty. However the simplicity of the patching and higher chance
@@ -260,7 +245,7 @@ Note that every structure has padding. This is added so that the hypervisor
can re-use those fields as it sees fit.
Earlier design attempted to ineptly explain the relations of the ELF sections
-to each other without using proper ELF mechanism (sh_info, sh_link, data
+to each other without using proper ELF mechanism (sh\_info, sh\_link, data
structures using Elf types, etc). This design will explain the structures
and how they are used together and not dig in the ELF format - except mention
that the section names should match the structure names.
@@ -285,27 +270,25 @@ like what the Linux kernel module loader does.
The payload contains at least three sections:
- * `.livepatch.funcs` - which is an array of livepatch_func structures.
+ * `.livepatch.funcs` - which is an array of livepatch\_func structures.
* `.livepatch.depends` - which is an ELF Note that describes what the payload
depends on. **MUST** have one.
* `.note.gnu.build-id` - the build-id of this payload. **MUST** have one.
### .livepatch.funcs
-The `.livepatch.funcs` contains an array of livepatch_func structures
+The `.livepatch.funcs` contains an array of livepatch\_func structures
which describe the functions to be patched:
-<pre>
-struct livepatch_func {
- const char *name;
- void *new_addr;
- void *old_addr;
- uint32_t new_size;
- uint32_t old_size;
- uint8_t version;
- uint8_t opaque[31];
-};
-</pre>
+ struct livepatch_func {
+ const char *name;
+ void *new_addr;
+ void *old_addr;
+ uint32_t new_size;
+ uint32_t old_size;
+ uint8_t version;
+ uint8_t opaque[31];
+ };
The size of the structure is 64 bytes on 64-bit hypervisors. It will be
52 on 32-bit hypervisors.
@@ -362,36 +345,34 @@ being applied and after being reverted:
A simple example of what a payload file can be:
-<pre>
-/* MUST be in sync with hypervisor. */
-struct livepatch_func {
- const char *name;
- void *new_addr;
- void *old_addr;
- uint32_t new_size;
- uint32_t old_size;
- uint8_t version;
- uint8_t pad[31];
-};
-
-/* Our replacement function for xen_extra_version. */
-const char *xen_hello_world(void)
-{
- return "Hello World";
-}
-
-static unsigned char patch_this_fnc[] = "xen_extra_version";
-
-struct livepatch_func livepatch_hello_world = {
- .version = LIVEPATCH_PAYLOAD_VERSION,
- .name = patch_this_fnc,
- .new_addr = xen_hello_world,
- .old_addr = (void *)0xffff82d08013963c, /* Extracted from xen-syms. */
- .new_size = 13, /* To be be computed by scripts. */
- .old_size = 13, /* -----------""--------------- */
-} __attribute__((__section__(".livepatch.funcs")));
-
-</pre>
+ /* MUST be in sync with hypervisor. */
+ struct livepatch_func {
+ const char *name;
+ void *new_addr;
+ void *old_addr;
+ uint32_t new_size;
+ uint32_t old_size;
+ uint8_t version;
+ uint8_t pad[31];
+ };
+
+ /* Our replacement function for xen_extra_version. */
+ const char *xen_hello_world(void)
+ {
+ return "Hello World";
+ }
+
+ static unsigned char patch_this_fnc[] = "xen_extra_version";
+
+ struct livepatch_func livepatch_hello_world = {
+ .version = LIVEPATCH_PAYLOAD_VERSION,
+ .name = patch_this_fnc,
+ .new_addr = xen_hello_world,
+ .old_addr = (void *)0xffff82d08013963c, /* Extracted from xen-syms. */
+ .new_size = 13, /* To be be computed by scripts. */
+ .old_size = 13, /* -----------""--------------- */
+ } __attribute__((__section__(".livepatch.funcs")));
+
Code must be compiled with -fPIC.
@@ -406,10 +387,8 @@ Each entry in this array is eight bytes.
The type definition of the function are as follow:
-<pre>
-typedef void (*livepatch_loadcall_t)(void);
-typedef void (*livepatch_unloadcall_t)(void);
-</pre>
+ typedef void (*livepatch_loadcall_t)(void);
+ typedef void (*livepatch_unloadcall_t)(void);
### .livepatch.depends and .note.gnu.build-id
@@ -423,7 +402,7 @@ which follows the format of an ELF Note. The contents of this
build the hypevisor and payload.
If GNU linker is used then the name is `GNU` and the description
-is a NT_GNU_BUILD_ID type ID. The description can be an SHA1
+is a NT\_GNU\_BUILD\_ID type ID. The description can be an SHA1
checksum, MD5 checksum or any unique value.
The size of these structures varies with the --build-id linker option.
@@ -454,22 +433,20 @@ Furthermore it is possible to have multiple different payloads for the same
function. As such an unique name per payload has to be visible to allow proper manipulation.
The hypercall is part of the `xen_sysctl`. The top level structure contains
-one uint32_t to determine the sub-operations and one padding field which
+one uint32\_t to determine the sub-operations and one padding field which
*MUST* always be zero.
-<pre>
-struct xen_sysctl_livepatch_op {
- uint32_t cmd; /* IN: XEN_SYSCTL_LIVEPATCH_*. */
- uint32_t pad; /* IN: Always zero. */
- union {
- ... see below ...
- } u;
-};
-
-</pre>
+ struct xen_sysctl_livepatch_op {
+ uint32_t cmd; /* IN: XEN_SYSCTL_LIVEPATCH_*. */
+ uint32_t pad; /* IN: Always zero. */
+ union {
+ ... see below ...
+ } u;
+ };
+
while the rest of hypercall specific structures are part of the this structure.
-### Basic type: struct xen_livepatch_name
+### Basic type: struct xen\_livepatch\_name
Most of the hypercalls employ an shared structure called `struct xen_livepatch_name`
which contains:
@@ -480,26 +457,24 @@ which contains:
The structure is as follow:
-<pre>
-/*
- * Uniquely identifies the payload. Should be human readable.
- * Includes the NUL terminator
- */
-#define XEN_LIVEPATCH_NAME_SIZE 128
-struct xen_livepatch_name {
- XEN_GUEST_HANDLE_64(char) name; /* IN, pointer to name. */
- uint16_t size; /* IN, size of name. May be upto
- XEN_LIVEPATCH_NAME_SIZE. */
- uint16_t pad[3]; /* IN: MUST be zero. */
-};
-</pre>
-
-### XEN_SYSCTL_LIVEPATCH_UPLOAD (0)
+ /*
+ * Uniquely identifies the payload. Should be human readable.
+ * Includes the NUL terminator
+ */
+ #define XEN_LIVEPATCH_NAME_SIZE 128
+ struct xen_livepatch_name {
+ XEN_GUEST_HANDLE_64(char) name; /* IN, pointer to name. */
+ uint16_t size; /* IN, size of name. May be upto
+ XEN_LIVEPATCH_NAME_SIZE. */
+ uint16_t pad[3]; /* IN: MUST be zero. */
+ };
+
+### XEN\_SYSCTL\_LIVEPATCH\_UPLOAD (0)
Upload a payload to the hypervisor. The payload is verified
against basic checks and if there are any issues the proper return code
will be returned. The payload is not applied at this time - that is
-controlled by *XEN_SYSCTL_LIVEPATCH_ACTION*.
+controlled by *XEN\_SYSCTL\_LIVEPATCH\_ACTION*.
The caller provides:
@@ -512,21 +487,19 @@ payload. It can be embedded into the ELF payload at creation time
and extracted by tools.
The return value is zero if the payload was succesfully uploaded.
-Otherwise an -XEN_EXX return value is provided. Duplicate `name` are not supported.
+Otherwise an -XEN\_EXX return value is provided. Duplicate `name` are not supported.
The `payload` is the ELF payload as mentioned in the `Payload format` section.
The structure is as follow:
-<pre>
-struct xen_sysctl_livepatch_upload {
- xen_livepatch_name_t name; /* IN, name of the patch. */
- uint64_t size; /* IN, size of the ELF file. */
- XEN_GUEST_HANDLE_64(uint8) payload; /* IN: ELF file. */
-};
-</pre>
+ struct xen_sysctl_livepatch_upload {
+ xen_livepatch_name_t name; /* IN, name of the patch. */
+ uint64_t size; /* IN, size of the ELF file. */
+ XEN_GUEST_HANDLE_64(uint8) payload; /* IN: ELF file. */
+ };
-### XEN_SYSCTL_LIVEPATCH_GET (1)
+### XEN\_SYSCTL\_LIVEPATCH\_GET (1)
Retrieve an status of an specific payload. This caller provides:
@@ -537,33 +510,29 @@ Retrieve an status of an specific payload. This caller provides:
Upon completion the `struct xen_livepatch_status` is updated.
* `status` - indicates the current status of the payload:
- * *LIVEPATCH_STATUS_CHECKED* (1) loaded and the ELF payload safety checks passed.
- * *LIVEPATCH_STATUS_APPLIED* (2) loaded, checked, and applied.
+ * *LIVEPATCH\_STATUS\_CHECKED* (1) loaded and the ELF payload safety checks passed.
+ * *LIVEPATCH\_STATUS\_APPLIED* (2) loaded, checked, and applied.
* No other value is possible.
- * `rc` - -XEN_EXX type errors encountered while performing the last
- LIVEPATCH_ACTION_* operation. The normal values can be zero or -XEN_EAGAIN which
+ * `rc` - -XEN\_EXX type errors encountered while performing the last
+ LIVEPATCH\_ACTION\_\* operation. The normal values can be zero or -XEN\_EAGAIN which
respectively mean: success or operation in progress. Other values
imply an error occurred. If there is an error in `rc`, `status` will **NOT**
have changed.
-The return value of the hypercall is zero on success and -XEN_EXX on failure.
-(Note that the `rc`` value can be different from the return value, as in
-rc=-XEN_EAGAIN and return value can be 0).
+The return value of the hypercall is zero on success and -XEN\_EXX on failure.
+(Note that the `rc` value can be different from the return value, as in
+rc=-XEN\_EAGAIN and return value can be 0).
For example, supposing there is an payload:
-<pre>
- status: LIVEPATCH_STATUS_CHECKED
- rc: 0
-</pre>
+ status: LIVEPATCH_STATUS_CHECKED
+ rc: 0
-We apply an action - LIVEPATCH_ACTION_REVERT - to revert it (which won't work
+We apply an action - LIVEPATCH\_ACTION\_REVERT - to revert it (which won't work
as we have not even applied it. Afterwards we will have:
-<pre>
- status: LIVEPATCH_STATUS_CHECKED
- rc: -XEN_EINVAL
-</pre>
+ status: LIVEPATCH_STATUS_CHECKED
+ rc: -XEN_EINVAL
It has failed but it remains loaded.
@@ -571,21 +540,19 @@ This operation is synchronous and does not require preemption.
The structure is as follow:
-<pre>
-struct xen_livepatch_status {
-#define LIVEPATCH_STATUS_CHECKED 1
-#define LIVEPATCH_STATUS_APPLIED 2
- uint32_t state; /* OUT: LIVEPATCH_STATE_*. */
- int32_t rc; /* OUT: 0 if no error, otherwise -XEN_EXX. */
-};
+ struct xen_livepatch_status {
+ #define LIVEPATCH_STATUS_CHECKED 1
+ #define LIVEPATCH_STATUS_APPLIED 2
+ uint32_t state; /* OUT: LIVEPATCH_STATE_*. */
+ int32_t rc; /* OUT: 0 if no error, otherwise -XEN_EXX. */
+ };
+
+ struct xen_sysctl_livepatch_get {
+ xen_livepatch_name_t name; /* IN, the name of the payload. */
+ xen_livepatch_status_t status; /* IN/OUT: status of the payload. */
+ };
-struct xen_sysctl_livepatch_get {
- xen_livepatch_name_t name; /* IN, the name of the payload. */
- xen_livepatch_status_t status; /* IN/OUT: status of the payload. */
-};
-</pre>
-
-### XEN_SYSCTL_LIVEPATCH_LIST (2)
+### XEN\_SYSCTL\_LIVEPATCH\_LIST (2)
Retrieve an array of abbreviated status and names of payloads that are loaded in the
hypervisor.
@@ -606,20 +573,20 @@ The caller provides:
structures. Caller *MUST* allocate up to `nr` of them.
* `name` - virtual address of where to write the unique name of the payload.
Caller *MUST* allocate up to `nr` of them. Each *MUST* be of
- **XEN_LIVEPATCH_NAME_SIZE** size. Note that **XEN_LIVEPATCH_NAME_SIZE** includes
+ **XEN\_LIVEPATCH\_NAME\_SIZE** size. Note that **XEN\_LIVEPATCH\_NAME\_SIZE** includes
the NUL terminator.
* `len` - virtual address of where to write the length of each unique name
of the payload. Caller *MUST* allocate up to `nr` of them. Each *MUST* be
- of sizeof(uint32_t) (4 bytes).
+ of sizeof(uint32\_t) (4 bytes).
If the hypercall returns an positive number, it is the number (upto `nr`
provided to the hypercall) of the payloads returned, along with `nr` updated
with the number of remaining payloads, `version` updated (it may be the same
across hypercalls - if it varies the data is stale and further calls could
-fail). The `status`, `name`, and `len`' are updated at their designed index
+fail). The `status`, `name`, and `len` are updated at their designed index
value (`idx`) with the returned value of data.
-If the hypercall returns -XEN_E2BIG the `nr` is too big and should be
+If the hypercall returns -XEN\_E2BIG the `nr` is too big and should be
lowered.
If the hypercall returns an zero value there are no more payloads.
@@ -634,61 +601,59 @@ data and start from scratch. It is OK for the toolstack to use the new
The `struct xen_livepatch_status` structure contains an status of payload which includes:
* `status` - indicates the current status of the payload:
- * *LIVEPATCH_STATUS_CHECKED* (1) loaded and the ELF payload safety checks passed.
- * *LIVEPATCH_STATUS_APPLIED* (2) loaded, checked, and applied.
+ * *LIVEPATCH\_STATUS\_CHECKED* (1) loaded and the ELF payload safety checks passed.
+ * *LIVEPATCH\_STATUS\_APPLIED* (2) loaded, checked, and applied.
* No other value is possible.
- * `rc` - -XEN_EXX type errors encountered while performing the last
- LIVEPATCH_ACTION_* operation. The normal values can be zero or -XEN_EAGAIN which
+ * `rc` - -XEN\_EXX type errors encountered while performing the last
+ LIVEPATCH\_ACTION\_\* operation. The normal values can be zero or -XEN\_EAGAIN which
respectively mean: success or operation in progress. Other values
imply an error occurred. If there is an error in `rc`, `status` will **NOT**
have changed.
The structure is as follow:
-<pre>
-struct xen_sysctl_livepatch_list {
- uint32_t version; /* OUT: Hypervisor stamps value.
- If varies between calls, we are
- getting stale data. */
- uint32_t idx; /* IN: Index into hypervisor list. */
- uint32_t nr; /* IN: How many status, names, and len
- should be filled out. Can be zero to get
- amount of payloads and version.
- OUT: How many payloads left. */
- uint32_t pad; /* IN: Must be zero. */
- XEN_GUEST_HANDLE_64(xen_livepatch_status_t) status; /* OUT. Must have enough
- space allocate for nr of them. */
- XEN_GUEST_HANDLE_64(char) id; /* OUT: Array of names. Each member
- MUST XEN_LIVEPATCH_NAME_SIZE in size.
- Must have nr of them. */
- XEN_GUEST_HANDLE_64(uint32) len; /* OUT: Array of lengths of name's.
- Must have nr of them. */
-};
-</pre>
-
-### XEN_SYSCTL_LIVEPATCH_ACTION (3)
+ struct xen_sysctl_livepatch_list {
+ uint32_t version; /* OUT: Hypervisor stamps value.
+ If varies between calls, we are
+ getting stale data. */
+ uint32_t idx; /* IN: Index into hypervisor list. */
+ uint32_t nr; /* IN: How many status, names, and len
+ should be filled out. Can be zero to get
+ amount of payloads and version.
+ OUT: How many payloads left. */
+ uint32_t pad; /* IN: Must be zero. */
+ XEN_GUEST_HANDLE_64(xen_livepatch_status_t) status; /* OUT. Must have enough
+ space allocate for nr of them. */
+ XEN_GUEST_HANDLE_64(char) id; /* OUT: Array of names. Each member
+ MUST XEN_LIVEPATCH_NAME_SIZE in size.
+ Must have nr of them. */
+ XEN_GUEST_HANDLE_64(uint32) len; /* OUT: Array of lengths of name's.
+ Must have nr of them. */
+ };
+
+### XEN\_SYSCTL\_LIVEPATCH\_ACTION (3)
Perform an operation on the payload structure referenced by the `name` field.
The operation request is asynchronous and the status should be retrieved
-by using either **XEN_SYSCTL_LIVEPATCH_GET** or **XEN_SYSCTL_LIVEPATCH_LIST** hypercall.
+by using either **XEN\_SYSCTL\_LIVEPATCH\_GET** or **XEN\_SYSCTL\_LIVEPATCH\_LIST** hypercall.
The caller provides:
- * A 'struct xen_livepatch_name` `name` containing the unique name.
+ * A `struct xen_livepatch_name` `name` containing the unique name.
* `cmd` the command requested:
- * *LIVEPATCH_ACTION_UNLOAD* (1) unload the payload.
+ * *LIVEPATCH\_ACTION\_UNLOAD* (1) unload the payload.
Any further hypercalls against the `name` will result in failure unless
- **XEN_SYSCTL_LIVEPATCH_UPLOAD** hypercall is perfomed with same `name`.
- * *LIVEPATCH_ACTION_REVERT* (2) revert the payload. If the operation takes
- more time than the upper bound of time the `rc` in `xen_livepatch_status'
- retrieved via **XEN_SYSCTL_LIVEPATCH_GET** will be -XEN_EBUSY.
- * *LIVEPATCH_ACTION_APPLY* (3) apply the payload. If the operation takes
- more time than the upper bound of time the `rc` in `xen_livepatch_status'
- retrieved via **XEN_SYSCTL_LIVEPATCH_GET** will be -XEN_EBUSY.
- * *LIVEPATCH_ACTION_REPLACE* (4) revert all applied payloads and apply this
+ **XEN\_SYSCTL\_LIVEPATCH\_UPLOAD** hypercall is perfomed with same `name`.
+ * *LIVEPATCH\_ACTION\_REVERT* (2) revert the payload. If the operation takes
+ more time than the upper bound of time the `rc` in `xen_livepatch_status`
+ retrieved via **XEN\_SYSCTL\_LIVEPATCH\_GET** will be -XEN\_EBUSY.
+ * *LIVEPATCH\_ACTION\_APPLY* (3) apply the payload. If the operation takes
+ more time than the upper bound of time the `rc` in `xen_livepatch_status`
+ retrieved via **XEN\_SYSCTL\_LIVEPATCH\_GET** will be -XEN\_EBUSY.
+ * *LIVEPATCH\_ACTION\_REPLACE* (4) revert all applied payloads and apply this
payload. If the operation takes more time than the upper bound of time
- the `rc` in `xen_livepatch_status' retrieved via **XEN_SYSCTL_LIVEPATCH_GET**
- will be -XEN_EBUSY.
+ the `rc` in `xen_livepatch_status` retrieved via **XEN\_SYSCTL\_LIVEPATCH\_GET**
+ will be -XEN\_EBUSY.
* `time` the upper bound of time (ns) the cmd should take. Zero means to use
the hypervisor default. If within the time the operation does not succeed
the operation would go in error state.
@@ -698,71 +663,65 @@ The return value will be zero unless the provided fields are incorrect.
The structure is as follow:
-<pre>
-#define LIVEPATCH_ACTION_UNLOAD 1
-#define LIVEPATCH_ACTION_REVERT 2
-#define LIVEPATCH_ACTION_APPLY 3
-#define LIVEPATCH_ACTION_REPLACE 4
-struct xen_sysctl_livepatch_action {
- xen_livepatch_name_t name; /* IN, name of the patch. */
- uint32_t cmd; /* IN: LIVEPATCH_ACTION_* */
- uint32_t time; /* IN: If zero then uses */
- /* hypervisor default. */
- /* Or upper bound of time (ns) */
- /* for operation to take. */
-};
-
-</pre>
-
-## State diagrams of LIVEPATCH_ACTION commands.
+ #define LIVEPATCH_ACTION_UNLOAD 1
+ #define LIVEPATCH_ACTION_REVERT 2
+ #define LIVEPATCH_ACTION_APPLY 3
+ #define LIVEPATCH_ACTION_REPLACE 4
+ struct xen_sysctl_livepatch_action {
+ xen_livepatch_name_t name; /* IN, name of the patch. */
+ uint32_t cmd; /* IN: LIVEPATCH_ACTION_* */
+ uint32_t time; /* IN: If zero then uses */
+ /* hypervisor default. */
+ /* Or upper bound of time (ns) */
+ /* for operation to take. */
+ };
+
+
+## State diagrams of LIVEPATCH\_ACTION commands.
There is a strict ordering state of what the commands can be.
-The LIVEPATCH_ACTION prefix has been dropped to easy reading and
-does not include the LIVEPATCH_STATES:
+The LIVEPATCH\_ACTION prefix has been dropped to easy reading and
+does not include the LIVEPATCH\_STATES:
-<pre>
- /->\
- \ /
- UNLOAD <--- CHECK ---> REPLACE|APPLY --> REVERT --\
- \ |
- \-------------------<-------------/
-
-</pre>
-## State transition table of LIVEPATCH_ACTION commands and LIVEPATCH_STATUS.
+ /->\
+ \ /
+ UNLOAD <--- CHECK ---> REPLACE|APPLY --> REVERT --\
+ \ |
+ \-------------------<-------------/
+
+## State transition table of LIVEPATCH\_ACTION commands and LIVEPATCH\_STATUS.
Note that:
- - The CHECKED state is the starting one achieved with *XEN_SYSCTL_LIVEPATCH_UPLOAD* hypercall.
+ - The CHECKED state is the starting one achieved with *XEN\_SYSCTL\_LIVEPATCH\_UPLOAD* hypercall.
- The REVERT operation on success will automatically move to the CHECKED state.
- There are two STATES: CHECKED and APPLIED.
- There are four actions (aka commands): APPLY, REPLACE, REVERT, and UNLOAD.
The state transition table of valid states and action states:
-<pre>
-
-+---------+---------+--------------------------------+-------+--------+
-| ACTION | Current | Result | Next STATE: |
-| ACTION | STATE | |CHECKED|APPLIED |
-+---------+----------+-------------------------------+-------+--------+
-| UNLOAD | CHECKED | Unload payload. Always works. | | |
-| | | No next states. | | |
-+---------+---------+--------------------------------+-------+--------+
-| APPLY | CHECKED | Apply payload (success). | | x |
-+---------+---------+--------------------------------+-------+--------+
-| APPLY | CHECKED | Apply payload (error|timeout) | x | |
-+---------+---------+--------------------------------+-------+--------+
-| REPLACE | CHECKED | Revert payloads and apply new | | x |
-| | | payload with success. | | |
-+---------+---------+--------------------------------+-------+--------+
-| REPLACE | CHECKED | Revert payloads and apply new | x | |
-| | | payload with error. | | |
-+---------+---------+--------------------------------+-------+--------+
-| REVERT | APPLIED | Revert payload (success). | x | |
-+---------+---------+--------------------------------+-------+--------+
-| REVERT | APPLIED | Revert payload (error|timeout) | | x |
-+---------+---------+--------------------------------+-------+--------+
-</pre>
+
+ +---------+---------+--------------------------------+-------+--------+
+ | ACTION | Current | Result | Next STATE: |
+ | ACTION | STATE | |CHECKED|APPLIED |
+ +---------+----------+-------------------------------+-------+--------+
+ | UNLOAD | CHECKED | Unload payload. Always works. | | |
+ | | | No next states. | | |
+ +---------+---------+--------------------------------+-------+--------+
+ | APPLY | CHECKED | Apply payload (success). | | x |
+ +---------+---------+--------------------------------+-------+--------+
+ | APPLY | CHECKED | Apply payload (error|timeout) | x | |
+ +---------+---------+--------------------------------+-------+--------+
+ | REPLACE | CHECKED | Revert payloads and apply new | | x |
+ | | | payload with success. | | |
+ +---------+---------+--------------------------------+-------+--------+
+ | REPLACE | CHECKED | Revert payloads and apply new | x | |
+ | | | payload with error. | | |
+ +---------+---------+--------------------------------+-------+--------+
+ | REVERT | APPLIED | Revert payload (success). | x | |
+ +---------+---------+--------------------------------+-------+--------+
+ | REVERT | APPLIED | Revert payload (error|timeout) | | x |
+ +---------+---------+--------------------------------+-------+--------+
All the other state transitions are invalid.
@@ -770,10 +729,10 @@ All the other state transitions are invalid.
The normal sequence of events is to:
- 1. *XEN_SYSCTL_LIVEPATCH_UPLOAD* to upload the payload. If there are errors *STOP* here.
- 2. *XEN_SYSCTL_LIVEPATCH_GET* to check the `->rc`. If *-XEN_EAGAIN* spin. If zero go to next step.
- 3. *XEN_SYSCTL_LIVEPATCH_ACTION* with *LIVEPATCH_ACTION_APPLY* to apply the patch.
- 4. *XEN_SYSCTL_LIVEPATCH_GET* to check the `->rc`. If in *-XEN_EAGAIN* spin. If zero exit with success.
+ 1. *XEN\_SYSCTL\_LIVEPATCH\_UPLOAD* to upload the payload. If there are errors *STOP* here.
+ 2. *XEN\_SYSCTL\_LIVEPATCH\_GET* to check the `->rc`. If *-XEN\_EAGAIN* spin. If zero go to next step.
+ 3. *XEN\_SYSCTL\_LIVEPATCH\_ACTION* with *LIVEPATCH\_ACTION\_APPLY* to apply the patch.
+ 4. *XEN\_SYSCTL\_LIVEPATCH\_GET* to check the `->rc`. If in *-XEN\_EAGAIN* spin. If zero exit with success.
## Addendum
@@ -807,18 +766,18 @@ minimize the chance of the patch not being applied due to safety
checks failing. Safety checks such as not patching code which
is on the stack - which can lead to corruption.
-#### Rendezvous code instead of stop_machine for patching
+#### Rendezvous code instead of stop\_machine for patching
The hypervisor's time rendezvous code runs synchronously across all CPUs
-every second. Using the stop_machine to patch can stall the time rendezvous
+every second. Using the stop\_machine to patch can stall the time rendezvous
code and result in NMI. As such having the patching be done at the tail
of rendezvous code should avoid this problem.
However the entrance point for that code is
-do_softirq->timer_softirq_action->time_calibration
-which ends up calling on_selected_cpus on remote CPUs.
+do\_softirq->timer\_softirq\_action->time\_calibration
+which ends up calling on\_selected\_cpus on remote CPUs.
-The remote CPUs receive CALL_FUNCTION_VECTOR IPI and execute the
+The remote CPUs receive CALL\_FUNCTION\_VECTOR IPI and execute the
desired function.
#### Before entering the guest code.
@@ -832,7 +791,7 @@ could be adjusted), combined with forcing all other CPUs through the
hypervisor with IPIs, can be utilized to execute lockstep instructions
on all CPUs.
-The approach is similar in concept to stop_machine and the time rendezvous
+The approach is similar in concept to stop\_machine and the time rendezvous
but is time-bound. However the local CPU stack is much shorter and
a lot more deterministic.
@@ -967,10 +926,10 @@ The implementation must also have a mechanism for (in no particular order):
the stack, make sure the payload is built with same compiler as hypervisor).
Specifically we want to make sure that live patching codepaths cannot be patched.
* NOP out the code sequence if `new_size` is zero.
- * Deal with other relocation types: R_X86_64_[8,16,32,32S], R_X86_64_PC[8,16,64]
+ * Deal with other relocation types: R\_X86\_64\_[8,16,32,32S], R\_X86\_64\_PC[8,16,64]
in payload file.
-### Handle inlined __LINE__
+### Handle inlined \_\_LINE\_\_
This problem is related to hotpatch construction
and potentially has influence on the design of the hotpatching
@@ -1030,7 +989,7 @@ Options:
For BUG(), WARN(), etc., the line number is embedded into the bug frame, not
the function itself.
-Similar considerations are true to a lesser extent for __FILE__, but it
+Similar considerations are true to a lesser extent for \_\_FILE\_\_, but it
could be argued that file renaming should be done outside of hotpatches.
## Signature checking requirements.
@@ -1042,49 +1001,47 @@ expecting such that it can properly do signature verification.
The signature is based on the all of the payloads continuously laid out
in memory. The signature is to be appended at the end of the ELF payload
-prefixed with the string `'~Module signature appended~\n'`, followed by
+prefixed with the string '`~Module signature appended~\n`', followed by
an signature header then followed by the signature, key identifier, and signers
name.
Specifically the signature header would be:
-<pre>
-#define PKEY_ALGO_DSA 0
-#define PKEY_ALGO_RSA 1
-
-#define PKEY_ID_PGP 0 /* OpenPGP generated key ID */
-#define PKEY_ID_X509 1 /* X.509 arbitrary subjectKeyIdentifier */
-
-#define HASH_ALGO_MD4 0
-#define HASH_ALGO_MD5 1
-#define HASH_ALGO_SHA1 2
-#define HASH_ALGO_RIPE_MD_160 3
-#define HASH_ALGO_SHA256 4
-#define HASH_ALGO_SHA384 5
-#define HASH_ALGO_SHA512 6
-#define HASH_ALGO_SHA224 7
-#define HASH_ALGO_RIPE_MD_128 8
-#define HASH_ALGO_RIPE_MD_256 9
-#define HASH_ALGO_RIPE_MD_320 10
-#define HASH_ALGO_WP_256 11
-#define HASH_ALGO_WP_384 12
-#define HASH_ALGO_WP_512 13
-#define HASH_ALGO_TGR_128 14
-#define HASH_ALGO_TGR_160 15
-#define HASH_ALGO_TGR_192 16
-
-
-struct elf_payload_signature {
- u8 algo; /* Public-key crypto algorithm PKEY_ALGO_*. */
- u8 hash; /* Digest algorithm: HASH_ALGO_*. */
- u8 id_type; /* Key identifier type PKEY_ID*. */
- u8 signer_len; /* Length of signer's name */
- u8 key_id_len; /* Length of key identifier */
- u8 __pad[3];
- __be32 sig_len; /* Length of signature data */
-};
-
-</pre>
+ #define PKEY_ALGO_DSA 0
+ #define PKEY_ALGO_RSA 1
+
+ #define PKEY_ID_PGP 0 /* OpenPGP generated key ID */
+ #define PKEY_ID_X509 1 /* X.509 arbitrary subjectKeyIdentifier */
+
+ #define HASH_ALGO_MD4 0
+ #define HASH_ALGO_MD5 1
+ #define HASH_ALGO_SHA1 2
+ #define HASH_ALGO_RIPE_MD_160 3
+ #define HASH_ALGO_SHA256 4
+ #define HASH_ALGO_SHA384 5
+ #define HASH_ALGO_SHA512 6
+ #define HASH_ALGO_SHA224 7
+ #define HASH_ALGO_RIPE_MD_128 8
+ #define HASH_ALGO_RIPE_MD_256 9
+ #define HASH_ALGO_RIPE_MD_320 10
+ #define HASH_ALGO_WP_256 11
+ #define HASH_ALGO_WP_384 12
+ #define HASH_ALGO_WP_512 13
+ #define HASH_ALGO_TGR_128 14
+ #define HASH_ALGO_TGR_160 15
+ #define HASH_ALGO_TGR_192 16
+
+
+ struct elf_payload_signature {
+ u8 algo; /* Public-key crypto algorithm PKEY_ALGO_*. */
+ u8 hash; /* Digest algorithm: HASH_ALGO_*. */
+ u8 id_type; /* Key identifier type PKEY_ID*. */
+ u8 signer_len; /* Length of signer's name */
+ u8 key_id_len; /* Length of key identifier */
+ u8 __pad[3];
+ __be32 sig_len; /* Length of signature data */
+ };
+
(Note that this has been borrowed from Linux module signature code.).
@@ -1128,15 +1085,13 @@ at least five bytes if patching in trampoline.
Depending on compiler settings, there are several functions in Xen that
are smaller (without inter-function padding).
-<pre>
-readelf -sW xen-syms | grep " FUNC " | \
- awk '{ if ($3 < 5) print $3, $4, $5, $8 }'
-
-...
-3 FUNC LOCAL wbinvd_ipi
-3 FUNC LOCAL shadow_l1_index
-...
-</pre>
+ readelf -sW xen-syms | grep " FUNC " | \
+ awk '{ if ($3 < 5) print $3, $4, $5, $8 }'
+
+ ...
+ 3 FUNC LOCAL wbinvd_ipi
+ 3 FUNC LOCAL shadow_l1_index
+ ...
A compile-time check for, e.g., a minimum alignment of functions or a
runtime check that verifies symbol size (+ padding to next symbols) for
that in the hypervisor is advised.
--
2.13.6
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 6/7] doc: correct feature-levelling.pandoc syntax
2018-04-24 6:44 [PATCH 0/7] fix several issues documentation Juergen Gross
` (4 preceding siblings ...)
2018-04-24 6:44 ` [PATCH 5/7] doc: correct livepatch.markdown syntax Juergen Gross
@ 2018-04-24 6:44 ` Juergen Gross
2018-04-24 6:44 ` [PATCH 7/7] doc: correct intel_psr_cat_cdp.pandoc syntax Juergen Gross
6 siblings, 0 replies; 14+ messages in thread
From: Juergen Gross @ 2018-04-24 6:44 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
andrew.cooper3, ian.jackson, tim, ross.lagerwall, jbeulich
"make -C docs all" fails due to incorrect markdown syntax in
feature-levelling.pandoc. Correct it.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
docs/features/feature-levelling.pandoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/features/feature-levelling.pandoc b/docs/features/feature-levelling.pandoc
index ef77eb837d..4b2b6df151 100644
--- a/docs/features/feature-levelling.pandoc
+++ b/docs/features/feature-levelling.pandoc
@@ -83,7 +83,7 @@ not trap, leaving Xen no direct ability to control the information returned.
Xen-aware PV software can make use of the 'Forced Emulation Prefix'
-> `ud2a; .ascii 'xen'; cpuid`
+ ud2a; .ascii 'xen'; cpuid
which Xen recognises as a deliberate attempt to get the fully-controlled
`CPUID` information rather than the hardware-reported information. This only
--
2.13.6
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 7/7] doc: correct intel_psr_cat_cdp.pandoc syntax
2018-04-24 6:44 [PATCH 0/7] fix several issues documentation Juergen Gross
` (5 preceding siblings ...)
2018-04-24 6:44 ` [PATCH 6/7] doc: correct feature-levelling.pandoc syntax Juergen Gross
@ 2018-04-24 6:44 ` Juergen Gross
6 siblings, 0 replies; 14+ messages in thread
From: Juergen Gross @ 2018-04-24 6:44 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, sstabellini, wei.liu2, George.Dunlap,
andrew.cooper3, ian.jackson, tim, ross.lagerwall, jbeulich
"make -C docs all" fails due to incorrect markdown syntax in
intel_psr_cat_cdp.pandoc. Correct it.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
docs/features/intel_psr_cat_cdp.pandoc | 366 ++++++++++++++++-----------------
1 file changed, 175 insertions(+), 191 deletions(-)
diff --git a/docs/features/intel_psr_cat_cdp.pandoc b/docs/features/intel_psr_cat_cdp.pandoc
index 04fb256dd9..c619e2cc99 100644
--- a/docs/features/intel_psr_cat_cdp.pandoc
+++ b/docs/features/intel_psr_cat_cdp.pandoc
@@ -104,19 +104,18 @@ PSR infrastructure in Xen.
CAT/CDP defines a range of MSRs to assign different cache access patterns
which are known as CBMs, each CBM is associated with a COS.
- ```
E.g. L2 CAT:
- +----------------------------+----------------+
- IA32_PQR_ASSOC | MSR (per socket) | Address |
- +----+---+-------+ +----------------------------+----------------+
- | |COS| | | IA32_L2_QOS_MASK_0 | 0xD10 |
- +----+---+-------+ +----------------------------+----------------+
- +-------------> | ... | ... |
- +----------------------------+----------------+
- | IA32_L2_QOS_MASK_n | 0xD10+n (n<64) |
- +----------------------------+----------------+
- ```
-
+
+ +----------------------------+----------------+
+ IA32_PQR_ASSOC | MSR (per socket) | Address |
+ +----+---+-------+ +----------------------------+----------------+
+ | |COS| | | IA32_L2_QOS_MASK_0 | 0xD10 |
+ +----+---+-------+ +----------------------------+----------------+
+ +-------------> | ... | ... |
+ +----------------------------+----------------+
+ | IA32_L2_QOS_MASK_n | 0xD10+n (n<64) |
+ +----------------------------+----------------+
+
L3 CAT/CDP uses a range of MSRs from 0xC90 ~ 0xC90+n (n<128).
L2 CAT uses a range of MSRs from 0xD10 ~ 0xD10+n (n<64), following the L3
@@ -132,41 +131,39 @@ PSR infrastructure in Xen.
note that all (and only) contiguous '1' combinations are allowed (e.g. FFFFH,
0FF0H, 003CH, etc.).
- ```
- +----+----+----+----+----+----+----+----+
- | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 |
- +----+----+----+----+----+----+----+----+
- COS0 | A | A | A | A | A | A | A | A | Default Bitmask
- +----+----+----+----+----+----+----+----+
- COS1 | A | A | A | A | A | A | A | A |
- +----+----+----+----+----+----+----+----+
- COS2 | A | A | A | A | A | A | A | A |
- +----+----+----+----+----+----+----+----+
-
- +----+----+----+----+----+----+----+----+
- | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 |
- +----+----+----+----+----+----+----+----+
- COS0 | A | A | A | A | A | A | A | A | Overlapped Bitmask
- +----+----+----+----+----+----+----+----+
- COS1 | | | | | A | A | A | A |
- +----+----+----+----+----+----+----+----+
- COS2 | | | | | | | A | A |
- +----+----+----+----+----+----+----+----+
-
- +----+----+----+----+----+----+----+----+
- | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 |
- +----+----+----+----+----+----+----+----+
- COS0 | A | A | A | A | | | | | Isolated Bitmask
- +----+----+----+----+----+----+----+----+
- COS1 | | | | | A | A | | |
- +----+----+----+----+----+----+----+----+
- COS2 | | | | | | | A | A |
- +----+----+----+----+----+----+----+----+
- ```
+ +----+----+----+----+----+----+----+----+
+ | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 |
+ +----+----+----+----+----+----+----+----+
+ COS0 | A | A | A | A | A | A | A | A | Default Bitmask
+ +----+----+----+----+----+----+----+----+
+ COS1 | A | A | A | A | A | A | A | A |
+ +----+----+----+----+----+----+----+----+
+ COS2 | A | A | A | A | A | A | A | A |
+ +----+----+----+----+----+----+----+----+
+
+ +----+----+----+----+----+----+----+----+
+ | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 |
+ +----+----+----+----+----+----+----+----+
+ COS0 | A | A | A | A | A | A | A | A | Overlapped Bitmask
+ +----+----+----+----+----+----+----+----+
+ COS1 | | | | | A | A | A | A |
+ +----+----+----+----+----+----+----+----+
+ COS2 | | | | | | | A | A |
+ +----+----+----+----+----+----+----+----+
+
+ +----+----+----+----+----+----+----+----+
+ | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 |
+ +----+----+----+----+----+----+----+----+
+ COS0 | A | A | A | A | | | | | Isolated Bitmask
+ +----+----+----+----+----+----+----+----+
+ COS1 | | | | | A | A | | |
+ +----+----+----+----+----+----+----+----+
+ COS2 | | | | | | | A | A |
+ +----+----+----+----+----+----+----+----+
We can get the CBM length through CPUID. The default value of CBM is calcul-
ated by `(1ull << cbm_len) - 1`. That is a fully open bitmask, all ones bitm-
- ask. The COS[0] always stores the default value without change.
+ ask. The COS\[0\] always stores the default value without change.
There is a `IA32_PQR_ASSOC` register which stores the COS ID of the VCPU. HW
enforces cache allocation according to the corresponding CBM.
@@ -209,8 +206,8 @@ PSR infrastructure in Xen.
System administrator can change PSR allocation policy at runtime by tool stack.
Since L2 CAT shares COS with L3 CAT/CDP, a COS corresponds to a 2-tuple, like
- [L2 CBM, L3 CBM] with only-CAT enabled, when CDP is enabled, one COS correspo-
- nds to a 3-tuple, like [L2 CBM, L3 Code_CBM, L3 Data_CBM]. If neither L3 CAT
+ \[L2 CBM, L3 CBM\] with only-CAT enabled, when CDP is enabled, one COS correspo-
+ nds to a 3-tuple, like \[L2 CBM, L3 Code_CBM, L3 Data_CBM\]. If neither L3 CAT
nor L3 CDP is enabled, things would be easier, one COS corresponds to one L2
CBM.
@@ -240,160 +237,146 @@ PSR infrastructure in Xen.
* Hypervisor interfaces:
- 1. Boot line parameter "psr=cat" enables L2 CAT and L3 CAT if hardware suppo-
- rted. "psr=cdp" enables CDP if hardware supported.
-
- 2. SYSCTL:
- - XEN_SYSCTL_PSR_CAT_get_l3_info: Get L3 CAT/CDP information.
- - XEN_SYSCTL_PSR_CAT_get_l2_info: Get L2 CAT information.
-
- 3. DOMCTL:
- - XEN_DOMCTL_PSR_CAT_OP_GET_L3_CBM: Get L3 CBM for a domain.
- - XEN_DOMCTL_PSR_CAT_OP_SET_L3_CBM: Set L3 CBM for a domain.
- - XEN_DOMCTL_PSR_CAT_OP_GET_L3_CODE: Get CDP Code CBM for a domain.
- - XEN_DOMCTL_PSR_CAT_OP_SET_L3_CODE: Set CDP Code CBM for a domain.
- - XEN_DOMCTL_PSR_CAT_OP_GET_L3_DATA: Get CDP Data CBM for a domain.
- - XEN_DOMCTL_PSR_CAT_OP_SET_L3_DATA: Set CDP Data CBM for a domain.
- - XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM: Get L2 CBM for a domain.
- - XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM: Set L2 CBM for a domain.
+> 1. Boot line parameter "psr=cat" enables L2 CAT and L3 CAT if hardware suppo-
+> rted. "psr=cdp" enables CDP if hardware supported.
+>
+> 2. SYSCTL:
+>
+> > * XEN_SYSCTL_PSR_CAT_get_l3_info: Get L3 CAT/CDP information.
+> > * XEN_SYSCTL_PSR_CAT_get_l2_info: Get L2 CAT information.
+>
+> 3. DOMCTL:
+>
+> > * XEN_DOMCTL_PSR_CAT_OP_GET_L3_CBM: Get L3 CBM for a domain.
+> > * XEN_DOMCTL_PSR_CAT_OP_SET_L3_CBM: Set L3 CBM for a domain.
+> > * XEN_DOMCTL_PSR_CAT_OP_GET_L3_CODE: Get CDP Code CBM for a domain.
+> > * XEN_DOMCTL_PSR_CAT_OP_SET_L3_CODE: Set CDP Code CBM for a domain.
+> > * XEN_DOMCTL_PSR_CAT_OP_GET_L3_DATA: Get CDP Data CBM for a domain.
+> > * XEN_DOMCTL_PSR_CAT_OP_SET_L3_DATA: Set CDP Data CBM for a domain.
+> > * XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM: Get L2 CBM for a domain.
+> > * XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM: Set L2 CBM for a domain.
* xl interfaces:
- 1. psr-cat-show -lX domain-id
- Show LX cbm for a domain.
- => XEN_SYSCTL_PSR_CAT_get_l3_info /
- XEN_SYSCTL_PSR_CAT_get_l2_info /
- XEN_DOMCTL_PSR_CAT_OP_GET_L3_CBM /
- XEN_DOMCTL_PSR_CAT_OP_GET_L3_CODE /
- XEN_DOMCTL_PSR_CAT_OP_GET_L3_DATA /
- XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM
-
- 2. psr-cat-set -lX domain-id cbm
- Set LX cbm for a domain.
- => XEN_DOMCTL_PSR_CAT_OP_SET_L3_CBM /
- XEN_DOMCTL_PSR_CAT_OP_SET_L3_CODE /
- XEN_DOMCTL_PSR_CAT_OP_SET_L3_DATA /
- XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM
-
- 3. psr-hwinfo
- Show PSR HW information, including L3 CAT/CDP/L2 CAT
- => XEN_SYSCTL_PSR_CAT_get_l3_info /
- XEN_SYSCTL_PSR_CAT_get_l2_info
-
-* Key data structure:
-
- 1. Feature properties
-
- ```
- static const struct feat_props {
- unsigned int cos_num;
- enum cbm_type type[PSR_MAX_COS_NUM];
- enum cbm_type alt_type;
- bool (*get_feat_info)(const struct feat_node *feat,
- uint32_t data[], unsigned int array_len);
- void (*write_msr)(unsigned int cos, uint32_t val, enum cbm_type type);
- } *feat_props[PSR_SOCKET_FEAT_NUM];
- ```
-
- Every feature has its own properties, e.g. some data and actions. A
- feature property pointer array is declared to save every feature's
- properties.
-
- - Member `cos_num`
-
- `cos_num` is the number of COS registers the feature uses, e.g. L3/L2
- CAT uses 1 register but CDP uses 2 registers.
-
- - Member `type`
-
- `type` is an array to save all 'enum cbm_type' values of the feature.
- It is used with cos_num together to get/write a feature's COS registers
- values one by one.
-
- - Member `alt_type`
-
- `alt_type` is 'alternative type'. When this 'alt_type' is input, the
- feature does some special operations.
-
- - Member `get_feat_info`
-
- `get_feat_info` is used to return feature HW info through sysctl.
-
- - Member `write_msr`
-
- `write_msr` is used to write out feature MSR register.
+> 1. psr-cat-show -lX domain-id
+> Show LX cbm for a domain.
- 2. Feature node
+ => XEN_SYSCTL_PSR_CAT_get_l3_info /
+ XEN_SYSCTL_PSR_CAT_get_l2_info /
+ XEN_DOMCTL_PSR_CAT_OP_GET_L3_CBM /
+ XEN_DOMCTL_PSR_CAT_OP_GET_L3_CODE /
+ XEN_DOMCTL_PSR_CAT_OP_GET_L3_DATA /
+ XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM
+
+> 2. psr-cat-set -lX domain-id cbm
+> Set LX cbm for a domain.
- ```
- struct feat_node {
- unsigned int cos_max;
- unsigned int cbm_len;
- uint32_t cos_reg_val[MAX_COS_REG_CNT];
- };
- ```
+ => XEN_DOMCTL_PSR_CAT_OP_SET_L3_CBM /
+ XEN_DOMCTL_PSR_CAT_OP_SET_L3_CODE /
+ XEN_DOMCTL_PSR_CAT_OP_SET_L3_DATA /
+ XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM
- When a PSR enforcement feature is enabled, it will be added into a
- feature array.
+> 3. psr-hwinfo
+> Show PSR HW information, including L3 CAT/CDP/L2 CAT
- - Member `cos_max`
+ => XEN_SYSCTL_PSR_CAT_get_l3_info /
+ XEN_SYSCTL_PSR_CAT_get_l2_info
- `cos_max` is one of the hardware info of CAT. It means the max number
- of COS registers. As L3 CAT/CDP/L2 CAT all have it, it is declared in
- `feat_node`.
-
- - Member `cbm_len`
-
- `cbm_len` is one of the hardware info of CAT. It means the max number
- of bits to set.
-
- - Member `cos_reg_val`
-
- `cos_reg_val` is an array to maintain the value set in all COS registers
- of the feature. The array is indexed by COS ID.
-
- 3. Per-socket PSR features information structure
-
- ```
- struct psr_socket_info {
- bool feat_init;
- struct feat_node *features[PSR_SOCKET_FEAT_NUM];
- spinlock_t ref_lock;
- unsigned int cos_ref[MAX_COS_REG_CNT];
- DECLARE_BITMAP(dom_ids, DOMID_IDLE + 1);
- };
- ```
-
- We collect all PSR allocation features information of a socket in this
- `struct psr_socket_info`.
-
- - Member `feat_init`
-
- `feat_init` is a flag, to indicate whether the CPU init on a socket
- has been done.
-
- - Member `features`
-
- `features` is a pointer array to save all enabled features poniters
- according to feature position defined in `enum psr_feat_type`.
-
- - Member `ref_lock`
-
- `ref_lock` is a spin lock to protect `cos_ref`.
-
- - Member `cos_ref`
-
- `cos_ref` is an array which maintains the reference of one COS. It maps
- to cos_reg_val[MAX_COS_REG_NUM] in `struct feat_node`. If one COS is
- used by one domain, the corresponding reference will increase by one. If
- a domain releases the COS, the reference will decrease by one. The array
- is indexed by COS ID.
-
- - Member `dom_ids`
+* Key data structure:
- `dom_ids` is a bitmap, every bit corresponds to a domain. Index is
- domain_id. It is used to help restore the cos_id of the domain to 0 when
- a socket is offline and then online again.
+> 1. Feature properties
+>
+> static const struct feat_props {
+> unsigned int cos_num;
+> enum cbm_type type[PSR_MAX_COS_NUM];
+> enum cbm_type alt_type;
+> bool (*get_feat_info)(const struct feat_node *feat,
+> uint32_t data[], unsigned int array_len);
+> void (*write_msr)(unsigned int cos, uint32_t val, enum cbm_type type);
+> } *feat_props[PSR_SOCKET_FEAT_NUM];
+>
+> > Every feature has its own properties, e.g. some data and actions. A
+> > feature property pointer array is declared to save every feature's
+> > properties.
+> >
+> > * Member `cos_num`
+> > `cos_num` is the number of COS registers the feature uses, e.g. L3/L2
+> > CAT uses 1 register but CDP uses 2 registers.
+> >
+> > * Member `type`
+> > `type` is an array to save all 'enum cbm_type' values of the feature.
+> > It is used with cos_num together to get/write a feature's COS registers
+> > values one by one.
+> >
+> > * Member `alt_type`
+> > `alt_type` is 'alternative type'. When this 'alt_type' is input, the
+> > feature does some special operations.
+> >
+> > * Member `get_feat_info`
+> > `get_feat_info` is used to return feature HW info through sysctl.
+> >
+> > * Member `write_msr`
+> > `write_msr` is used to write out feature MSR register.
+>
+> 2. Feature node
+>
+> struct feat_node {
+> unsigned int cos_max;
+> unsigned int cbm_len;
+> uint32_t cos_reg_val[MAX_COS_REG_CNT];
+> };
+>
+> > When a PSR enforcement feature is enabled, it will be added into a
+> > feature array.
+> >
+> > * Member `cos_max`
+> > `cos_max` is one of the hardware info of CAT. It means the max number
+> > of COS registers. As L3 CAT/CDP/L2 CAT all have it, it is declared in
+> > `feat_node`.
+> >
+> > * Member `cbm_len`
+> > `cbm_len` is one of the hardware info of CAT. It means the max number
+> > of bits to set.
+> >
+> > * Member `cos_reg_val`
+> > `cos_reg_val` is an array to maintain the value set in all COS registers
+> > of the feature. The array is indexed by COS ID.
+>
+> 3. Per-socket PSR features information structure
+>
+> struct psr_socket_info {
+> bool feat_init;
+> struct feat_node *features[PSR_SOCKET_FEAT_NUM];
+> spinlock_t ref_lock;
+> unsigned int cos_ref[MAX_COS_REG_CNT];
+> DECLARE_BITMAP(dom_ids, DOMID_IDLE + 1);
+> };
+>
+> > We collect all PSR allocation features information of a socket in this
+> > `struct psr_socket_info`.
+> >
+> > * Member `feat_init`
+> > `feat_init` is a flag, to indicate whether the CPU init on a socket
+> > has been done.
+> >
+> > * Member `features`
+> > `features` is a pointer array to save all enabled features poniters
+> > according to feature position defined in `enum psr_feat_type`.
+> >
+> > * Member `ref_lock`
+> > `ref_lock` is a spin lock to protect `cos_ref`.
+> >
+> > * Member `cos_ref`
+> > `cos_ref` is an array which maintains the reference of one COS. It maps
+> > to cos_reg_val\[MAX_COS_REG_NUM\] in `struct feat_node`. If one COS is
+> > used by one domain, the corresponding reference will increase by one. If
+> > a domain releases the COS, the reference will decrease by one. The array
+> > is indexed by COS ID.
+> >
+> > * Member `dom_ids`
+> > `dom_ids` is a bitmap, every bit corresponds to a domain. Index is
+> > domain_id. It is used to help restore the cos_id of the domain to 0 when
+> > a socket is offline and then online again.
# Limitations
@@ -407,6 +390,7 @@ We can execute above xl commands to verify L2 CAT and L3 CAT/CDP on different
HWs support them.
For example:
+
root@:~$ xl psr-hwinfo --cat
Cache Allocation Technology (CAT): L2
Socket ID : 0
--
2.13.6
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 1/7] doc: sort entries of boot parameters correctly
2018-04-24 6:44 ` [PATCH 1/7] doc: sort entries of boot parameters correctly Juergen Gross
@ 2018-04-26 14:56 ` Jan Beulich
0 siblings, 0 replies; 14+ messages in thread
From: Jan Beulich @ 2018-04-26 14:56 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, Tim Deegan, Ross Lagerwall, xen-devel
>>> On 24.04.18 at 08:44, <jgross@suse.com> wrote:
> Some of the boot parameters in docs/misc/xen-command-line.markdown are
> not in the correct alphabetically order. Correct that.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/7] doc: add architecture qualifier to boot parameter entries
2018-04-24 6:44 ` [PATCH 2/7] doc: add architecture qualifier to boot parameter entries Juergen Gross
@ 2018-04-26 15:00 ` Jan Beulich
[not found] ` <5AE1E9A702000078001BEDC1@suse.com>
1 sibling, 0 replies; 14+ messages in thread
From: Jan Beulich @ 2018-04-26 15:00 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, Tim Deegan, Ross Lagerwall, xen-devel
>>> On 24.04.18 at 08:44, <jgross@suse.com> wrote:
> Many of the architecture specific boot parameters are not qualified
> as such. Correct that.
I think we want to distinguish between ones really only be meaningful for
some architecture vs ones which are currently only implemented for just
one. For example ...
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -110,7 +110,7 @@ domain 0 command line
> Specify which ACPI MADT table to parse for APIC information, if more
> than one is present.
>
> -### acpi\_pstate\_strict
> +### acpi\_pstate\_strict (x86)
> > `= <boolean>`
... I'm no sure P-states are meaningless on ARM. They're certainly a general
ACPI concept, and were similarly used e.g. for IA64.
> @@ -119,12 +119,12 @@ Enforce checking that P-state transitions by the ACPI cpufreq driver
> actually result in the nominated frequency to be established. A warning
> message will be logged if that isn't the case.
>
> -### acpi\_skip\_timer\_override
> +### acpi\_skip\_timer\_override (x86)
> > `= <boolean>`
This one, otoh, is fine to be named x86 only, as it deals with x86
specific BIOS quirks.
> @@ -199,7 +199,7 @@ to be performed without the overhead of a complete TLB flush.
> Forces all CPUs' full state to be logged upon certain fatal asynchronous
> exceptions (watchdog NMIs and unexpected MCEs).
>
> -### ats
> +### ats (x86)
> > `= <boolean>`
ATS is a general PCI concept, so I wouldn't want this option to be tagged
x86 only.
Just to give a few examples.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 4/7] doc: escape underscores in xen-command-line.markdown
2018-04-24 6:44 ` [PATCH 4/7] doc: escape underscores in xen-command-line.markdown Juergen Gross
@ 2018-04-26 15:06 ` Jan Beulich
0 siblings, 0 replies; 14+ messages in thread
From: Jan Beulich @ 2018-04-26 15:06 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, Tim Deegan, Ross Lagerwall, xen-devel
>>> On 24.04.18 at 08:44, <jgross@suse.com> wrote:
> Some underscores are not escaped in xen-command-line.markdown.
> Correct that.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 5/7] doc: correct livepatch.markdown syntax
2018-04-24 6:44 ` [PATCH 5/7] doc: correct livepatch.markdown syntax Juergen Gross
@ 2018-04-26 15:12 ` Konrad Rzeszutek Wilk
2018-04-26 16:06 ` Juergen Gross
0 siblings, 1 reply; 14+ messages in thread
From: Konrad Rzeszutek Wilk @ 2018-04-26 15:12 UTC (permalink / raw)
To: Juergen Gross
Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
ian.jackson, tim, ross.lagerwall, jbeulich, xen-devel
On Tue, Apr 24, 2018 at 08:44:57AM +0200, Juergen Gross wrote:
> "make -C docs all" fails due to incorrect markdown syntax in
> livepatch.markdown. Correct it.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> docs/misc/livepatch.markdown | 589 ++++++++++++++++++++-----------------------
> 1 file changed, 272 insertions(+), 317 deletions(-)
>
> diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
> index 54a6b850cb..f3c1320e5a 100644
> --- a/docs/misc/livepatch.markdown
> +++ b/docs/misc/livepatch.markdown
> @@ -89,33 +89,26 @@ As example we will assume the hypervisor does not have XSA-132 (see
> 4ff3449f0e9d175ceb9551d3f2aecb59273f639d) and we would like to binary patch
> the hypervisor with it. The original code looks as so:
>
> -<pre>
> - 48 89 e0 mov %rsp,%rax
> - 48 25 00 80 ff ff and $0xffffffffffff8000,%rax
> -</pre>
> + 48 89 e0 mov %rsp,%rax
> + 48 25 00 80 ff ff and $0xffffffffffff8000,%rax
>
> while the new patched hypervisor would be:
>
> -<pre>
> - 48 c7 45 b8 00 00 00 00 movq $0x0,-0x48(%rbp)
> - 48 c7 45 c0 00 00 00 00 movq $0x0,-0x40(%rbp)
> - 48 c7 45 c8 00 00 00 00 movq $0x0,-0x38(%rbp)
> - 48 89 e0 mov %rsp,%rax
> - 48 25 00 80 ff ff and $0xffffffffffff8000,%rax
> -</pre>
> + 48 c7 45 c0 00 00 00 00 movq $0x0,-0x40(%rbp)
How come you deleted:
48 c7 45 b8 00 00 00 00 movq $0x0,-0x48(%rbp)
?
It is OK, but I am just curious.
And either way - if you want to add that back in or not - please add
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thank you!
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/7] doc: add architecture qualifier to boot parameter entries
[not found] ` <5AE1E9A702000078001BEDC1@suse.com>
@ 2018-04-26 16:02 ` Juergen Gross
0 siblings, 0 replies; 14+ messages in thread
From: Juergen Gross @ 2018-04-26 16:02 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, Tim Deegan, Ross Lagerwall, xen-devel
On 26/04/18 17:00, Jan Beulich wrote:
>>>> On 24.04.18 at 08:44, <jgross@suse.com> wrote:
>> Many of the architecture specific boot parameters are not qualified
>> as such. Correct that.
>
> I think we want to distinguish between ones really only be meaningful for
> some architecture vs ones which are currently only implemented for just
> one. For example ...
>
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -110,7 +110,7 @@ domain 0 command line
>> Specify which ACPI MADT table to parse for APIC information, if more
>> than one is present.
>>
>> -### acpi\_pstate\_strict
>> +### acpi\_pstate\_strict (x86)
>> > `= <boolean>`
>
> ... I'm no sure P-states are meaningless on ARM. They're certainly a general
> ACPI concept, and were similarly used e.g. for IA64.
This parameter is defined in arch/x86/acpi/cpufreq/cpufreq.c
You might be right for the conceptual part, but the parameter is
just defined on x86 only.
>
>> @@ -119,12 +119,12 @@ Enforce checking that P-state transitions by the ACPI cpufreq driver
>> actually result in the nominated frequency to be established. A warning
>> message will be logged if that isn't the case.
>>
>> -### acpi\_skip\_timer\_override
>> +### acpi\_skip\_timer\_override (x86)
>> > `= <boolean>`
>
> This one, otoh, is fine to be named x86 only, as it deals with x86
> specific BIOS quirks.
>
>> @@ -199,7 +199,7 @@ to be performed without the overhead of a complete TLB flush.
>> Forces all CPUs' full state to be logged upon certain fatal asynchronous
>> exceptions (watchdog NMIs and unexpected MCEs).
>>
>> -### ats
>> +### ats (x86)
>> > `= <boolean>`
>
> ATS is a general PCI concept, so I wouldn't want this option to be tagged
> x86 only.
>
> Just to give a few examples.
I searched for the parameter definitions and did the annotations
according to their actual scope.
Doing otherwise would be just a lie.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 5/7] doc: correct livepatch.markdown syntax
2018-04-26 15:12 ` Konrad Rzeszutek Wilk
@ 2018-04-26 16:06 ` Juergen Gross
0 siblings, 0 replies; 14+ messages in thread
From: Juergen Gross @ 2018-04-26 16:06 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: sstabellini, wei.liu2, George.Dunlap, andrew.cooper3,
ian.jackson, tim, ross.lagerwall, jbeulich, xen-devel
On 26/04/18 17:12, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 24, 2018 at 08:44:57AM +0200, Juergen Gross wrote:
>> "make -C docs all" fails due to incorrect markdown syntax in
>> livepatch.markdown. Correct it.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> docs/misc/livepatch.markdown | 589 ++++++++++++++++++++-----------------------
>> 1 file changed, 272 insertions(+), 317 deletions(-)
>>
>> diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
>> index 54a6b850cb..f3c1320e5a 100644
>> --- a/docs/misc/livepatch.markdown
>> +++ b/docs/misc/livepatch.markdown
>> @@ -89,33 +89,26 @@ As example we will assume the hypervisor does not have XSA-132 (see
>> 4ff3449f0e9d175ceb9551d3f2aecb59273f639d) and we would like to binary patch
>> the hypervisor with it. The original code looks as so:
>>
>> -<pre>
>> - 48 89 e0 mov %rsp,%rax
>> - 48 25 00 80 ff ff and $0xffffffffffff8000,%rax
>> -</pre>
>> + 48 89 e0 mov %rsp,%rax
>> + 48 25 00 80 ff ff and $0xffffffffffff8000,%rax
>>
>> while the new patched hypervisor would be:
>>
>> -<pre>
>> - 48 c7 45 b8 00 00 00 00 movq $0x0,-0x48(%rbp)
>> - 48 c7 45 c0 00 00 00 00 movq $0x0,-0x40(%rbp)
>> - 48 c7 45 c8 00 00 00 00 movq $0x0,-0x38(%rbp)
>> - 48 89 e0 mov %rsp,%rax
>> - 48 25 00 80 ff ff and $0xffffffffffff8000,%rax
>> -</pre>
>> + 48 c7 45 c0 00 00 00 00 movq $0x0,-0x40(%rbp)
>
> How come you deleted:
>
> 48 c7 45 b8 00 00 00 00 movq $0x0,-0x48(%rbp)
> ?
>
> It is OK, but I am just curious.
Oh, sorry. Thanks for noticing. I'll add it back.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2018-04-26 16:06 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-24 6:44 [PATCH 0/7] fix several issues documentation Juergen Gross
2018-04-24 6:44 ` [PATCH 1/7] doc: sort entries of boot parameters correctly Juergen Gross
2018-04-26 14:56 ` Jan Beulich
2018-04-24 6:44 ` [PATCH 2/7] doc: add architecture qualifier to boot parameter entries Juergen Gross
2018-04-26 15:00 ` Jan Beulich
[not found] ` <5AE1E9A702000078001BEDC1@suse.com>
2018-04-26 16:02 ` Juergen Gross
2018-04-24 6:44 ` [PATCH 3/7] doc: add credit2_cap_period_ms boot parameter description Juergen Gross
2018-04-24 6:44 ` [PATCH 4/7] doc: escape underscores in xen-command-line.markdown Juergen Gross
2018-04-26 15:06 ` Jan Beulich
2018-04-24 6:44 ` [PATCH 5/7] doc: correct livepatch.markdown syntax Juergen Gross
2018-04-26 15:12 ` Konrad Rzeszutek Wilk
2018-04-26 16:06 ` Juergen Gross
2018-04-24 6:44 ` [PATCH 6/7] doc: correct feature-levelling.pandoc syntax Juergen Gross
2018-04-24 6:44 ` [PATCH 7/7] doc: correct intel_psr_cat_cdp.pandoc syntax Juergen Gross
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.