x86/monitor: fix violations of MISRA C:2012 Rule 7.2
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.
Signed-off-by: Gianluca Luparini <gianluca.luparini@bugseng.com> Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
xen/public: fix violations of MISRA C:2012 Rule 7.2
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type.
For the sake of uniformity, the following changes are made:
- add the 'U' suffix to integer constants before the '?' operator
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type.
For the sake of uniformity, the following changes are made:
- add the 'U' suffix to all first macro's arguments in 'boot.c'
- add the 'U' suffix near '0x3fffffff' in 'runtime.c'
xen/device-tree: fix violations of MISRA C:2012 Rule 7.2
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.
AMD/IOMMU: fix violations of MISRA C:2012 Rule 7.2
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.
x86/cpufreq: fix violations of MISRA C:2012 Rule 7.2
The xen sources contains violations of MISRA C:2012 Rule 7.2 whose
headline states:
"A 'u' or 'U' suffix shall be applied to all integer constants
that are represented in an unsigned type".
Add the 'U' suffix to integers literals with unsigned type and also to other
literals used in the same contexts or near violations, when their positive
nature is immediately clear. The latter changes are done for the sake of
uniformity.
x86/emul: fix violations of MISRA C:2012 Rule 8.3 on parameter names
The headline of MISRA C:2012 Rule 8.3 states that:
"All declarations of an object or function shall use the same names and
type qualifiers".
Change parameter names to meet the following requirements:
1) keep consistency between declarations and the corresponding
definitions thus fixing violations of the Rule 8.3;
2) use the globally-adopted shorthands (e.g., 's' to denote a 'state');
3) keep adjacent declarations consistent with respect to the parameter
names that are used.
Commit 9473d9a24182 set the ASK mode without checking if there was a
`vga` option provided in the command line. This breaks existing
behavior, so exit early without changes if `vga` is not present in the
command line.
Fixes: 9473d9a24182 ('cmdline: parse multiple instances of the vga option') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
cmdline: parse multiple instances of the vga option
Parse all instances of the vga= option on the command line, in order
to always enforce the last selection on the command line.
Note that it's not safe to parse just the last occurrence of the vga=
option, as then a command line with `vga=current vga=keep` would
result in current being ignored.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
multiboot2: do not set StdOut mode unconditionally
Only initialize StdOut if the current StdOut mode is unusable. This
avoids forcefully switching StdOut to the maximum supported
resolution, and thus very likely changing the GOP mode without having
first parsed the command line options.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
multiboot2: parse vga= option when setting GOP mode
Introduce support for passing the command line to the efi_multiboot2()
helper, and parse the vga= option if present.
Add support for the 'gfx' and 'current' vga options, ignore the 'keep'
option, and print a warning message about other options not being
currently implemented.
Note that the multboot2 command line string must always be
zero-terminated according to the multiboot2 specification, and hence
there's no need to pass the string size to efi_multiboot2().
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Thu, 6 Jul 2023 07:06:27 +0000 (09:06 +0200)]
xenstore: talloc.h needs to include stdarg.h
talloc_vasprintf() has a va_list type parameter, so this type needs to
be defined (independent of the particular libc implementation).
Fixes: 63b6419d2a2d ("tools/xenstore: split out rest of live update control code") Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com>
x86/microcode: Allow reading microcode revision even if it can't be updated
microcode_update_one() currently assumes all microcode handlers are set or
none are. That won't be the case in a future patch, as apply_microcode()
may not be set while the others are. Hence, this patch allows reading the
microcode revision even if updating it is unavailable.
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Wed, 21 Jun 2023 20:44:37 +0000 (21:44 +0100)]
xen/types: Rework stdint vs __{u,s}$N types
Xen uses the stdint types. Rearrange the types headers to define the
compatibility __{u,s}$N types in terms of the stdint types, not the other way
around.
All supported compilers on architectures other than x86 support the stdint
__*_TYPE__ macros. Move these into a new xen/stdint.h to avoid them being
duplicated in each architecture. For the very old x86 compilers, synthesize
suitable types using GCC internals.
This cleanup has the side effect of removing all use of the undocumented
__signed__ GCC keyword. This is a vestigial remnant of `gcc -traditional`
mode for dialetcs of C prior to the introduction of the signed keyword.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Julien Grall <jgrall@amazon.com>
Andrew Cooper [Mon, 26 Jun 2023 15:36:36 +0000 (16:36 +0100)]
treewide: Avoid including asm/types.h
We're about to rearrange the common and arch types.h split. While most
users already include <xen/types.h>, a few do not and some files fail to
compile as a result.
Almost all logic is going to have types very early in the include chain. Drop
the include entirely from C files, and swap to the common types.h in headers.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Julien Grall <jgrall@amazon.com>
Andrew Cooper [Wed, 21 Jun 2023 20:36:54 +0000 (21:36 +0100)]
xen/types: Drop #ifdefary for __{SIZE,PTRDIFF}_TYPE__
All supported compilers have these types.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
On Arm, it is not possible to use ACPI without UEFI. In fact disabling
UEFI but not ACPI will lead to a compilation error:
ld: prelink.o: in function `acpi_os_get_root_pointer':
/builds/xen-project/people/andyhhp/xen/xen/drivers/acpi/osl.c:73:
undefined reference to `efi'
/builds/xen-project/people/andyhhp/xen/xen/drivers/acpi/osl.c:73:(.init.text+0x8ac0):
relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against
undefined symbol `efi'
So make the dependency clear in the Kconfig.
This was spotted by the randconfig build in gitlab CI.
Fixes: 12314be5749e ("xen/arm: make ARM_EFI selectable for Arm64") Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Nicola Vetrini [Thu, 29 Jun 2023 10:06:16 +0000 (12:06 +0200)]
xen/arm: smmuv3: fix violations of MISRA C:2012 Rule 3.1
In the file `xen/drivers/passthrough/arm/smmu-v3.c' there are a few occurrences
of nested '//' character sequences inside C-style comment blocks, which violate
Rule 3.1.
The patch aims to resolve those by replacing the nested comments with
equivalent constructs that do not violate the rule.
xen/include: avoid using a compiler extension for BUILD_BUG_ON_ZERO
Redefine BUILD_BUG_ON_ZERO to avoid using a compiler extension
that gives an acceptable semantics to C99 undefined behavior 58
("A structure or union is defined as containing no named members
(6.7.2.1)").
The first definition includes an additional named field of type
char.
The chosen ill-formed construct for the second definition is a struct
with a named bitfield of width 0 when the condition is true,
which prevents the UB without using the compiler extension while keeping
the semantic of the construct.
The choice of the bitwise AND operation to bring the result to 0
when cond is false boils down to possibly better portability.
Anthony PERARD [Wed, 5 Jul 2023 06:25:03 +0000 (08:25 +0200)]
build: define ARCH and SRCARCH later
Defining ARCH and SRCARCH later in xen/Makefile allows to switch to
immediate evaluation variable type.
ARCH and SRCARCH depend on value defined in Config.mk and aren't used
for e.g. TARGET_SUBARCH or TARGET_ARCH, and not before they're needed in
a sub-make or a rule.
This will help reduce the number of times the shell rune is been
run.
With GNU make 4.4, the number of execution of the command present in
these $(shell ) increased greatly. This is probably because as of make
4.4, exported variable are also added to the environment of $(shell )
construct.
Also, `make -d` shows a lot of these:
Makefile:39: not recursively expanding SRCARCH to export to shell function
Makefile:38: not recursively expanding ARCH to export to shell function
Reported-by: Jason Andryuk <jandryuk@gmail.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Tested-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
xen/riscv: move extern of cpu0_boot_stack to header
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Jan Beulich [Wed, 5 Jul 2023 06:17:13 +0000 (08:17 +0200)]
libelf: make L1_MFN_VALID note known
We still don't use it (in the tool stack), and its values (plural) also
aren't fetched correctly, but it is odd to continue to see the
hypervisor log "ELF: note: unknown (0xd)" when loading a Linux Dom0.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Julien Grall <jgrall@amazon.com>
Wei Chen [Mon, 26 Jun 2023 03:33:53 +0000 (11:33 +0800)]
xen/arm: make ARM_EFI selectable for Arm64
Currently, ARM_EFI will mandatorily selected by Arm64.
Even if the user knows for sure that their images will not
start in the EFI environment, they can't disable the EFI
support for Arm64. This means there will be about 3K lines
unused code in their images.
So in this patch, we make ARM_EFI selectable for Arm64, and
based on that, we can use CONFIG_ARM_EFI to gate the EFI
specific code in head.S for those images that will not be
booted in EFI environment.
Wei Chen [Mon, 26 Jun 2023 03:33:52 +0000 (11:33 +0800)]
xen/arm: remove xen_phys_start and xenheap_phys_end from config.h
These two variables are stale variables, they only have declarations
in config.h, they don't have any definition and no any code is using
these two variables. So in this patch, we remove them from config.h.
Henry Wang [Thu, 29 Jun 2023 22:18:00 +0000 (06:18 +0800)]
xen/arm: vgic: Add missing 'U' in VGIC_ICFG_MASK for shifted constant
With UBSAN on some arm64 platforms, e.g. FVP_Base_RevC-2xAEMvA, the
following splat will be printed while Dom0 is booting:
```
(XEN) ==================================================================
(XEN) UBSAN: Undefined behaviour in arch/arm/vgic.c:372:15
(XEN) left shift of 1 by 31 places cannot be represented in type 'int'
(XEN) Xen WARN at common/ubsan/ubsan.c:172
(XEN) ----[ Xen-4.18-unstable arm64 debug=y ubsan=y Not tainted ]----
```
This is because there is a device node in the device tree with 0xf
as the interrupts property. Example of the device tree node is shown
below:
```
ethernet@202000000 {
compatible = "smsc,lan91c111";
reg = <0x2 0x2000000 0x10000>;
interrupts = <0xf>;
};
```
and this value is passed to vgic_get_virq_type() as "index" then "intr"
in VGIC_ICFG_MASK.
Add the missing 'U' in VGIC_ICFG_MASK as a fix, and this should also
addressing MISRA Rule 7.2:
A "u" or "U" suffix shall be applied to all integer constants that
are represented in an unsigned type
Signed-off-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Hongda Deng <hongda.deng@arm.com>
Luca Fancellu [Thu, 8 Jun 2023 13:59:13 +0000 (14:59 +0100)]
tools/python: Fix memory leak on error path
Commit 56a7aaa16bfe introduced a memory leak on the error path for a
Py_BuildValue built object that on some newly introduced error path
has not the correct reference count handling, fix that by decrementing
the refcount in these path.
Fixes: 56a7aaa16bfe ("tools: add physinfo arch_capabilities handling for Arm") Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Luca Fancellu [Thu, 8 Jun 2023 13:59:12 +0000 (14:59 +0100)]
tools: Fix ifdef for aarch64 that should include also arm
Commit 56a7aaa16bfe introduced some SVE related code that is protected by
'#if defined(__aarch64__)', the issue is that this doesn't take into
consideration when the toolstack is compiled for an arm32 Dom0 running on
an arm64 platform, it should be able to create SVE enabled guests but with
the current code it's not.
So fix the issue by compiling the code when the toolstack is compiled for
both arm32 and arm64.
Fixes: 56a7aaa16bfe ("tools: add physinfo arch_capabilities handling for Arm") Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Per the Arm Arm, (Armv7 DDI406C.d A3.8.3 and Armv8 DDI 0487J.a B2.3.12):
"The DMB and DSB memory barriers affect reads and writes to the memory
system generated by load/store instructions and data or unified cache
maintenance operations being executed by the processor. Instruction
fetches or accesses caused by a hardware translation table access are
not explicit accesses."
Note that second sentence is not part of the newer Armv8 spec. But the
interpretation is not much different.
The updated entry will not be used until xen_pt_update() completes.
So rather than adding the ISB after write_pte() in create_xen_table()
and xen_pt-update_entry(), add it in xen_pt_update().
Also document the reasoning of the deferral after each write_pte() calls.
Fixes: 07d11f63d03e ("xen/arm: mm: Avoid flushing the TLBs when mapping are inserted") Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Per the Arm Arm, (Armv7 DDI406C.d A3.8.3 and Armv8 DDI 0487J.a B2.3.12):
"The DMB and DSB memory barriers affect reads and writes to the memory
system generated by load/store instructions and data or unified cache
maintenance operations being executed by the processor. Instruction
fetches or accesses caused by a hardware translation table access are
not explicit accesses."
Note that second sentence is not part of the newer Armv8 spec. But the
interpretation is not much different.
As the entry created by arch_pmap_map() will be used soon after
pmap_map() returns, we want to ensure the DSB in write_pte() has
completed. So add an ISB.
Fixes: 4f17357b52f6 ("xen/arm: add Persistent Map (PMAP) infrastructure") Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
xen/arm: page: Consolidate write_pte() and clarify the documentation
The implementation of write_pte() is pretty much the same on arm32
and arm64. So it would be good to consolidate it as this would help
to clarify the requirements when using the helper.
Take the opportunity to switch from assembly to call macros. Note there
is a difference on arm32 because the option was not specified. But this
meant 'sy' (system wide).
Futhermore, the requirements for the ISB is incomplete. Per the Arm Arm,
(Armv7 DDI406C.d A3.8.3 and Armv8 DDI 0487J.a B2.3.12), DSB will only
affect explicit accesses. So an ISB is necessary after DSB to ensure
the completion. Having an ISB after each update to the page-tables is
probably too much, so let the caller add the instruction when it is
convenient.
Lastly, the barrier in write_pte() may be too restrictive but I haven't
yet find the proper section(s) in the Arm Arm.
Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
----
I am a bit split on whether we should add an ISB in write_pte(). It
would make easier for the developper, but would likely force a pipeline
flush too often.
It might also be possible to drop the ISB (and even DSB) when updating
stage-2 PTE (Linux already does it, see 120798d2e7d1). But I am not sure
this is worth it in Xen.
xen/arm64: head: Add missing isb in setup_fixmap()
On older version of the Arm Arm (ARM DDI 0487E.a, B2-125) there were
the following paragraph:
"DMB and DSB instructions affect reads and writes to the memory system
generated by Load/Store instructions and data or unified cache
maintenance instructions being executed by the PE. Instruction fetches
or accesses caused by a hardware translation table access are not
explicit accesses."
Newer revision (e.g. ARM DDI 0487J.a) doesn't have the second sentence
(it might be somewhere else in the Arm Arm). But the interpretation is
not much different.
In setup_fixmap(), we write the fixmap area and may be used soon after,
for instance, to write to the UART. IOW, there could be hardware
translation table access. So we need to ensure the 'dsb' has completed
before continuing. Therefore add an 'isb'.
Fixes: 2b11c3646105 ("xen/arm64: head: Remove 1:1 mapping as soon as it is not used") Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
xen/arm32: head: Add mising isb in switch_to_runtime_mapping()
Per the Arm Arm (ARM DDI 0406C.d A3.8.3):
"The DMB and DSB memory barriers affect reads and writes to the memory
system generated by load/store instructions and data or unified cache
maintenance operations being executed by the processor. Instruction
fetches or accesses caused by a hardware translation table access are
not explicit accesses."
The function switch_to_runtime_mapping() is responsible to map the
Xen at its runtime address if we were using the temporary area before
jumping returning using a runtime address. So we need to ensure the
'dsb' has completed before continuing. Therefore add an 'isb'.
Fixes: fbd9b5fb4c26 ("xen/arm32: head: Remove restriction where to load Xen") Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
xen/arm32: head: Add missing isb in setup_fixmap()
Per the Arm Arm (ARM DDI 0406C.d A3.8.3):
"The DMB and DSB memory barriers affect reads and writes to the memory
system generated by load/store instructions and data or unified cache
maintenance operations being executed by the processor. Instruction
fetches or accesses caused by a hardware translation table access are
not explicit accesses."
In setup_fixmap(), we write the fixmap area and may be used soon after,
for instance, to write to the UART. IOW, there could be hardware
translation table access. So we need to ensure the 'dsb' has completed
before continuing. Therefore add an 'isb'.
Fixes: e79999e587d7 ("xen/arm32: head: Remove 1:1 mapping as soon as it is not used") Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Tested-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
UBSAN has been enabled a few years ago on x86 but was never
enabled on Arm because the final binary is bigger than 2MB (
the maximum we can currently handled).
With the recent rework, it is now possible to grow Xen over 2MB.
So there is no more roadblock to enable Xen other than increasing
the reserved area.
On my setup, for arm32, the final binaray was very close to 4MB.
Furthermore, one may want to enable UBSAN and GCOV which would put
the binary well-over 4MB (both features require for some space).
Therefore, increase the size to 8MB which should us some margin.
Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>o
xen/arm: Rework the code mapping Xen to avoid relying on the size of Xen
At the moment, the maximum size of Xen binary we can support is 2MB.
This is what we reserved in the virtual address but also what all
the code in Xen relies on as we only allocate one L3 page-table.
When feature like UBSAN (will be enabled in a follow-up patch) and GCOV
are enabled, the binary will be way over 2MB.
The code is now reworked so it doesn't rely on a specific size but
will instead look at the reversed size and compute the number of
page-table to allocate/map.
While at it, replace any reference to 4KB mappings with a more
generic word because the page-size may change in the future.
Also fix the typo s/tlb/tbl/ in code move in arm32/head.S
At the moment, we are mapping the size of the reserved area for Xen
(i.e. 2MB) even if the binary is smaller. We don't exactly know what's
after Xen, so it is not a good idea to map more than necessary for a
couple of reasons:
* We would need to use break-before-make if the extra PTE needs to
be updated to point to another region
* The extra area mapped may be mapped again by Xen with different
memory attribute. This would result to attribute mismatch.
Therefore, rework the logic in create_page_tables() to map only what's
necessary.
Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
At the moment, we are mapping the size of the reserved area for Xen
(i.e. 2MB) even if the binary is smaller. We don't exactly know what's
after Xen, so it is not a good idea to map more than necessary for a
couple of reasons:
* We would need to use break-before-make if the extra PTE needs to
be updated to point to another region
* The extra area mapped may be mapped again by Xen with different
memory attribute. This would result to attribute mismatch.
Therefore, rework the logic in create_page_tables() to map only what's
necessary. To simplify the logic, we also want to make sure _end
is page-aligned. So align the symbol in the linker and add an assert
to catch any change.
Lastly, take the opportunity to confirm that _start is equal to
XEN_VIRT_START as the assembly is using both interchangeably.
Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
xen/arm: grant-table: Correct the prototype of the arch helpers
Both the stub and the x86 prototypes for replace_grant_host_mapping()
and create_grant_host_mapping() will define the first parameter (and
third for the former) as uint64_t. Yet Arm will define it as
'unsigned long'.
While there are no differences for 64-bit, for 32-bit it means
that the address should be truncated as 32-bit guest could support
up to 40-bit addresses.
So replace 'unsigned long' with 'uint64_t' for the first parameter
(and third parameter for replace_grant_host_mapping()).
Signed-off-by: Julien Grall <jgrall@amazon.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Tested-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Andrew Cooper [Thu, 29 Jun 2023 10:23:27 +0000 (11:23 +0100)]
xen: Correct comments after renaming xen_{dom,sys}ctl_cpu_policy fields
Fixes: 21e3ef57e040 ("x86: Rename {domctl,sysctl}.cpu_policy.{cpuid,msr}_policy fields") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
x86/vlapic: Change parameter names in function definitions
Change parameter names in guest_wrmsr_x2apic() and
guest_wrmsr_apic_base() definitions in order to:
1) keep consistency with parameter names used in guest_* function
declarations;
2) fix violations of MISRA C:2012 Rule 8.3.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86/hvm: Change parameter names of nestedhvm_vcpu_iomap_get() definition
Change parameter names of nestedhvm_vcpu_iomap_get() definition to
those used in the function declaration in order to:
1) improve readability;
2) fix violations of MISRA C:2012 Rule 8.3.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86/hvm: Swap parameter names of hvm_copy_context_and_params() declaration
Swap parameter names 'src' and 'dst' of hvm_copy_context_and_params()
declaration for consistency with the corresponding definition and the
uses of such function.
Also, this fixes a violation of MISRA C:2012 Rule 8.3.
Signed-off-by: Federico Serafini <federico.serafini@bugseng.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
This option hardens Xen by forcing it to write secure (NX-enhanced) PTEs
regardless of the runtime NX feature bit in boot_cpu_data. This prevents an
attacker with partial write support from affecting Xen's PTE generation
logic by overriding the NX feature flag. The patch asserts support for the
NX bit in PTEs at boot time and if so short-circuits the cpu_has_nx macro
to 1.
It has the nice benefit of replacing many instances of runtime checks with
folded constants. This has several knock-on effects that improve codegen,
saving 2.5KiB off the text section.
The config option defaults to OFF for compatibility with previous
behaviour.
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
x86/boot: Clear XD_DISABLE from the early boot path
Intel CPUs have a bit in MSR_IA32_MISC_ENABLE that may prevent the NX bit
from being advertised. Clear it unconditionally if we can't find the NX
feature right away on boot.
The conditions for the MSR being read on early boot are (in this order):
* Long Mode is supported
* NX isn't advertised
* The vendor is Intel
The order of checks has been chosen carefully so a virtualized Xen on a
hypervisor that doesn't emulate that MSR (but supports NX) doesn't triple
fault trying to access the non-existing MSR.
With that done, we can remove the XD_DISABLE checks in the intel-specific
init path (as they are already done in early assembly). Keep a printk to
highlight the fact that NX was forcefully enabled.
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Currently libxl and the x86-emulator tests carry their own versions. Factor
those out into the common macros header so every library can make use of
it. This is required so the following patch can add this macro to a header
used both in Xen and tools/libs.
No functional change.
Signed-off-by: Alejandro Vallejo <alejandro.vallejo@cloud.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
George Dunlap [Fri, 30 Jun 2023 10:25:34 +0000 (11:25 +0100)]
xenalyze: Basic TRC_HVM_EMUL handling
For now, mainly just do volume analysis and get rid of the warnings.
Signed-off-by: George Dunlap <george.dunlap@cloud.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
A recent xentrace highlighted an unhandled corner case in the vcpu
"start-of-day" logic, if the trace starts after the last running ->
non-running transition, but before the first non-running -> running
transition. Because start-of-day wasn't handled, vcpu_next_update()
was expecting p->current to be NULL, and tripping out with the
following error message when it wasn't:
vcpu_next_update: FATAL: p->current not NULL! (d32768dv$p, runstate RUNSTATE_INIT)
where 32768 is the DEFAULT_DOMAIN, and $p is the pcpu number.
Instead of calling vcpu_start() piecemeal throughout
sched_runstate_process(), call it at the top of the function if the
vcpu in question is still in RUNSTATE_INIT, so that we can handle all
the cases in one place.
Sketch out at the top of the function all cases which we need to
handle, and what to do in those cases. Some transitions tell us where
v is running; some transitions tell us about what is (or is not)
running on p; some transitions tell us neither.
If a transition tells us where v is now running, update its state;
otherwise leave it in INIT, in order to avoid having to deal with TSC
skew on start-up.
If a transition tells us what is or is not running on p, update
p->current (either to v or NULL). Otherwise leave it alone.
If neither, do nothing.
Reifying those rules:
- If we're continuing to run, set v to RUNNING, and use p->first_tsc
as the runstate time.
- If we're starting to run, set v to RUNNING, and use ri->tsc as the
runstate time.
- If v is being deschedled, leave v in the INIT state to avoid dealing
with TSC skew; but set p->current to NULL so that whatever is
scheduled next won't trigger the assert in vcpu_next_update().
- If a vcpu is waking up (switching from one non-runnable state to
another non-runnable state), leave v in INIT, and p in whatever
state it's in (which may be the default domain, or some other vcpu
which has already run).
While here, fix the comment above vcpu_start; it's called when the
vcpu state is INIT, not when current is the default domain.
Signed-off-by: George Dunlap <george.dunlap@cloud.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Juergen Gross [Tue, 27 Jun 2023 12:27:46 +0000 (14:27 +0200)]
tools/xenstore: remove no longer needed functions from xs_lib.c
xs_daemon_tdb() in xs_lib.c is no longer used at all, so it can be
removed. xs_domain_dev() and xs_write_all() are not used by xenstored,
so they can be moved to tools/libs/store/xs.c.
xs_daemon_rootdir() is used by xenstored only and it only calls
xs_daemon_rundir(), so replace its use cases with xs_daemon_rundir()
and remove it from xs_lib.c.
xs_daemon_socket_ro() is needed in libxenstore only, so move it to
tools/libs/store/xs.c.
Move functions used by xenstore-client only to xenstore_client.c.
xen/arm: arm32: Allow Xen to boot on unidentified CPUs
Currently if the processor id is not identified (ie it is missing in proc-v7.S)
, then Xen boot fails quite early.
We have removed this restriction as for some CPUs (eg Cortex-R52), there isn't
any special initialization required.
Julien Grall [Thu, 29 Jun 2023 19:57:10 +0000 (20:57 +0100)]
xen/arm32: vfp: Add missing U for shifted constant
When enabling UBSAN on arm32, the following splat will be printed:
(XEN) ================================================================================
(XEN) UBSAN: Undefined behaviour in arch/arm/arm32/vfp.c:75:22
(XEN) left shift of 255 by 24 places cannot be represented in type 'int'
This is referring to the shift in FPSID_IMPLEMENTER_MASK. While we could
only add the U to the value shift there, it would be better to be
consistent and also add it for every value shifted.
This should also addressing MISRA Rule 7.2:
A "u" or "U" suffix shall be applied to all integer constants that
are represented in an unsigned type
Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Julien Grall [Thu, 29 Jun 2023 19:56:18 +0000 (20:56 +0100)]
xen/arm64: head: Rework PRINT() to work when the string is not withing +/- 1MB
The instruction ADR is able to load an address of a symbol that is
within the range +/- 1 MB of the instruction.
While today Xen is quite small (~1MB), it could grow up to 2MB in the
current setup. So there is no guarantee that the instruction can
load the string address (stored in rodata).
So replace the instruction ADR with the pseudo-instruction ADR_L
which is able to handle symbol within the range +/- 4GB.
Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com>
Julien Grall [Thu, 29 Jun 2023 19:55:18 +0000 (20:55 +0100)]
xen/arm64: entry: Don't jump outside of an alternative
The instruction CBNZ can only jump to a pc-relative that is in the
range +/- 1MB.
Alternative instructions replacement are living in a separate
subsection of the init section. This is usually placed towards
the end of the linker. Whereas text is towards the beginning.
While today Xen is quite small (~1MB), it could grow up to
2MB in the current setup. So there is no guarantee that the
target address in the text section will be within the range +/-
1MB of the CBNZ in alternative section.
The easiest solution is to have the target address within the
same section of the alternative. This means that we need to
duplicate a couple of instructions.
Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com>
----
I couldn't come up with a solution that would not change the number
of instructions executed in the entry path.
Julien Grall [Thu, 29 Jun 2023 19:47:12 +0000 (20:47 +0100)]
xen/arm32: head: Remove 'r6' from the clobber list of create_page_tables()
Since commit 62529f16c8a2 ("xen/arm32: head: Use a page mapping for the
1:1 mapping in create_page_tables()"), the register 'r6' is not used
anymore within create_page_tables(). So remove it from the documentation.
Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
Julien Grall [Thu, 29 Jun 2023 19:44:17 +0000 (20:44 +0100)]
xen/arm: Check Xen size when linking
The linker will happily link Xen if it is bigger than what we can handle
(e.g 2MB). This will result to unexpected failure after boot.
This unexpected failure can be prevented by forbidding linking if Xen is
bigger than the area we reserved.
Signed-off-by: Julien Grall <julien@xen.org> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Tested-by: Henry Wang <Henry.Wang@arm.com>
Nicola Vetrini [Thu, 29 Jun 2023 10:06:15 +0000 (12:06 +0200)]
xen/arm: tlbflush: fix violations of MISRA C:2012 Rule 3.1
In the files `xen/arch/arm/include/asm/arm(32|64)/flushtlb.h' there are a
few occurrences of nested '//' character sequences inside C-style comment
blocks, which violate Rule 3.1. The patch aims to resolve those by changing
the inner comments to arm asm comments, delimited by ';' instead.
xen/arm: change parameter names in replace_grant_host_mapping().
In the current version of replace_grant_host_mapping() function, the
declaration (correctly) uses the parameter names 'gpaddr' and
'new_gpaddr', while the definition uses the parameter names 'addr' and
'new_addr'.
Change the parameter names of the definition to 'gpaddr' and
'new_gpaddr' so that it is clear what type of address is expected and
violations of MISRA C:2012 Rule 8.3 are fixed.
In both declaration and definition of function
replace_grant_host_mapping() change the parameter name 'mfn' to 'frame',
thus improving readability and keeping consistency with name used in
create_grant_host_mapping().
xen/arm: make parameter names of function declarations consistent.
Change the parameter names of function declarations to be consistent
with the names used in the corresponding function definitions, thus
fixing violations of MISRA C:2012 Rule 8.3.
xen/arm: vgic: change parameter name in 'init' and 'free' functions.
In the current versions of vcpu_vgic_init() and vcpu_vgic_free(),
the declarations (correctly) use the parameter name 'v' while the
corresponding definitions use the parameter name 'vcpu'.
Since it is common to use 'v' to denote a vCPU, change the parameter
name 'vcpu' of function definitions to 'v', thus fixing violations of
MISRA C:2012 Rule 8.3.
xen/arm: change parameter name 'pa' in ioremap_addr() definition.
In the current version of ioremap_addr() function, the declaration
uses the parameter name 'start' (consistenly with the other ioremap_*
function declarations), while the definition uses the parameter name
'pa'.
Change the parameter name 'pa' of function definition to 'start', thus
fixing a violation of MISRA C:2012 Rule 8.3 and keeping the consistency
with other ioremap_* functions.
xen/arm: change parameter name 'vcpu' in domain() function definition.
In the current version of domain() function, the declaration
(correctly) uses the parameter name 'v' while the definition uses the
parameter name 'vcpu'.
Since it is common to use 'v' to denote a vCPU, change the parameter
name 'vcpu' of function definition to 'v', thus fixing a violation of
MISRA C:2012 Rule 8.3.
xen/arm: change names in function access_guest_memory_by_ipa().
Change the function name 'access_guest_memory_by_ipa' to
'access_guest_memory_by_gpa' and change its formal parameter name from
'ipa' to 'gpa' because of the following:
1) 'gpa' is used more frequently and therefore is preferable;
2) changing parameter name makes the declaration consistent with the
corresponding definition thus fixing a violation of MISRA C:2012 Rule
8.3.
Andrew Cooper [Tue, 20 Jun 2023 16:36:19 +0000 (17:36 +0100)]
x86/vpmu: Simplify is_pmc_quirk
This should be static, and there's no need for a separate (non-init, even)
function to perform a simple equality test. Drop the is_ prefix which is
gramatically questionable, and make it __ro_after_init.
Leave a TODO, because the behaviour is definitely wrong to be applied to all
modern Intel CPUs. The question has been raised on xen-devel previously
without conclusion.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Shawn Anastasio [Wed, 21 Jun 2023 16:59:51 +0000 (11:59 -0500)]
automation: Fix KBUILD_DEFCONFIG for *ppc64le jobs
During an iteration of the initial ppc64le support patchset the default
defconfig was renamed but build.yaml wasn't updated to reflect this. Fix
it up.
Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Shawn Anastasio [Tue, 20 Jun 2023 18:12:47 +0000 (13:12 -0500)]
xen: Add files needed for minimal ppc64le build
Add the build system changes required to build for ppc64le (POWER8+).
As of now the resulting image simply boots to an infinite loop.
$ make XEN_TARGET_ARCH=ppc64 -C xen build
This port targets POWER8+ CPUs running in Little Endian mode specifically,
and does not boot on older machines. Additionally, this initial skeleton
only implements the PaPR/pseries boot protocol which allows it to be
booted in a standard QEMU virtual machine:
Jan Beulich [Wed, 21 Jun 2023 11:45:36 +0000 (13:45 +0200)]
x86/vPIT: account for "counter stopped" time
For an approach like that used in "x86: detect PIT aliasing on ports
other than 0x4[0-3]" [1] to work, channel 2 may not (appear to) continue
counting when "gate" is low. Record the time when "gate" goes low, and
adjust pit_get_{count,out}() accordingly. Additionally for most of the
modes a rising edge of "gate" doesn't mean just "resume counting", but
"initiate counting", i.e. specifically the reloading of the counter with
its init value.
No special handling for state save/load: See the comment near the end of
pit_load().
Along with introducing the get_count() helper to have the calculations
(and the locking check) in a single place, switch pit_get_count()'s d,
counter, and return type to unsigned int.
Andrew Cooper [Wed, 10 May 2023 19:21:12 +0000 (20:21 +0100)]
x86: Use printk_once() instead of opencoding it
Technically our helper post-dates all of these examples, but it's good cleanup
nevertheless. None of these examples should be using fully locked
test_and_set_bool() in the first place.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Andrew Cooper [Tue, 13 Jun 2023 16:06:47 +0000 (17:06 +0100)]
xen/evtchn: Purge ERROR_EXIT{,_DOM}()
These interfere with code legibility by hiding control flow. Expand and drop
them.
* Rearrange the order of actions to write into rc, then render rc in the
gdprintk().
* Drop redundant "rc = rc" assignments
* Switch to using %pd for rendering domains
As a side effect, this fixes several violations of MISRA rule 2.1 (dead code -
the while() following a goto).
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Julien Grall <jgrall@amazon.com>
Michal Orzel [Wed, 7 Jun 2023 09:27:27 +0000 (11:27 +0200)]
xen/arm: pl011: Add SBSA UART device-tree support
We already have all the bits necessary in PL011 driver to support SBSA
UART thanks to commit 032ea8c736d10f02672863c6e369338f948f7ed8 that
enabled it for ACPI. Plumb in the remaining part for device-tree boot:
- add arm,sbsa-uart compatible to pl011_dt_match (no need for a separate
struct and DT_DEVICE_START as SBSA is a subset of PL011),
- from pl011_dt_uart_init(), check for SBSA UART compatible to determine
the UART type in use.
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Henry Wang <Henry.Wang@arm.com>
Michal Orzel [Wed, 7 Jun 2023 09:27:26 +0000 (11:27 +0200)]
xen/arm: pl011: Use correct accessors
At the moment, we use 32-bit only accessors (i.e. readl/writel) to match
the SBSA v2.x requirement. This should not be the default case for normal
PL011 where accesses shall be 8/16-bit (max register size is 16-bit).
There are however implementations of this UART that can only handle 32-bit
MMIO. This is advertised by dt property "reg-io-width" set to 4.
Introduce new struct pl011 member mmio32 and replace pl011_{read/write}
macros with static inline helpers that use 32-bit or 16-bit accessors
(largest-common not to end up using different ones depending on the actual
register size) according to mmio32 value. By default this property is set
to false, unless:
- reg-io-width is specified with value 4,
- SBSA UART is in use.
For now, no changes done for ACPI due to lack of testing possibilities
(i.e. current behavior maintained resulting in 32-bit accesses).
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Tested-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Michal Orzel [Wed, 7 Jun 2023 09:27:25 +0000 (11:27 +0200)]
xen/arm: debug-pl011: Add support for 32-bit only MMIO
There are implementations of PL011 that can only handle 32-bit accesses
as oppose to the normal behavior where accesses are 8/16-bit wide. This
is usually advertised by setting a dt property 'reg-io-width' to 4.
Introduce CONFIG_EARLY_UART_PL011_MMIO32 Kconfig option to be able to
enable the use of 32-bit only accessors in PL011 early printk code.
Define macros PL011_{STRH,STRB,LDRH} to distinguish accessors for normal
case from 32-bit MMIO one and use them in arm32/arm64 pl011 early printk
code.
Update documentation accordingly.
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Tested-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Michal Orzel [Wed, 7 Jun 2023 09:27:24 +0000 (11:27 +0200)]
xen/arm: debug-pl011: Use correct accessors
Although most PL011 UARTs can cope with 32-bit accesses, some of the old
legacy ones might not. PL011 registers are 8/16-bit wide and this shall
be perceived as the normal behavior.
Modify early printk pl011 code for arm32/arm64 to use the correct
accessors depending on the register size (refer ARM DDI 0183G, Table 3.1).
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Tested-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
For Dir 1.1, a document describing all implementation-defined behaviour
(i.e. gcc-specific behavior) will be added to docs/misra, also including
implementation-specific (gcc-specific) appropriate types for bit-field
relevant to Rule 6.1.
Rule 21.21 is lacking an example on gitlab but the rule is
straightforward: we don't use stdlib at all in Xen.
Andrew Cooper [Fri, 16 Jun 2023 16:28:21 +0000 (17:28 +0100)]
x86/boot: Clean up early error asm
The asm forming early error handling is a mix of local and non-local symbols,
and has some pointless comments. Drop the "# Error message" comments,
tweaking the style on modified lines, and make the symbols local.
However, leave behind one real symbol so this logic disassembles nicely
without merging in to acpi_boot_init(), which is the thing that happens to be
immediately prior in my build.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Oleksii Kurochko [Mon, 19 Jun 2023 13:47:37 +0000 (15:47 +0200)]
xen/riscv: introduce reset_stack() function
The reason for reset_stack() introduction is that stack should be
reset twice:
1. Before jumping to C world at the start of _start() function.
2. After jumping from 1:1 mapping world.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
projects / people / aperard / xen-unstable.git / log