Use the same check that's used in dump_irqs().
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/msi.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index 19830528b65a..0c97fbb3fc03 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -17,6
Iterate over the p2m up to the maximum recorded gfn and remove any foreign
mappings, in order to drop the underlying page references and thus don't keep
extra page references if a domain is destroyed while still having foreign
mappings on it's p2m.
The logic is similar to the one used on Arm.
Such information will be needed in order to remove foreign mappings during
teardown for HVM guests.
Right now the introduced counter is not consumed.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Changes since v1:
- Drop max_gfn accounting.
---
xen/arch/x86/include/asm/p2m.h |
create. Also altp2m enablement is different from activation, as
activation does happen during runtime of the domain.
Thanks, Roger.
Roger Pau Monne (3):
xen/x86: account number of foreign mappings in the p2m
xen/x86: enable altp2m at create domain domctl
xen/x86: remove foreign mappings from
Enabling it using an HVM param is fragile, and complicates the logic when
deciding whether options that interact with altp2m can also be enabled.
Leave the HVM param value for consumption by the guest, but prevent it from
being set. Enabling is now done using and additional altp2m specific field
The current check used in fixup_irqs() to decide whether to move around
interrupts is based on the affinity mask, but such mask can have all bits set,
and hence is unlikely to be a subset of the input mask. For example if an
interrupt has an affinity mask of all 1s, any input to fixup_irqs()
Print the CPU affinity masks as numeric ranges instead of plain hexadecimal
bitfields.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/irq.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 80ba8d9fe912..3b951d81bd6d
There's no point in forcing a system wide update of the MTRRs on all processors
when there are no changes to be propagated. On AP startup it's only the AP
that needs to write the system wide MTRR values in order to match the rest of
the already online CPUs.
We have occasionally seen the watchdog
Like it was done recently for libxl, switch to using the auto-generated feature
names by the processing of cpufeatureset.h, this allows removing the open-coded
feature names, and unifies the feature naming with libxl and the hypervisor.
Introduce a newly auto-generated array that contains the
libxl passes some information to libacpi to create the ACPI table for a PVH
guest, and among that information it's a bitmap of which vCPUs are online
which can be less than the maximum number of vCPUs assigned to the domain.
While the population of the bitmap is done correctly for HVM based on
Such information will be needed in order to remove foreign mappings during
teardown for HVM guests.
Right now the introduced counter is not consumed.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- Drop max_gfn accounting.
---
xen/arch/x86/include/asm/p2m.h | 6 ++
1 file changed,
Enabling it using an HVM param is fragile, and complicates the logic when
deciding whether options that interact with altp2m can also be enabled.
Leave the HVM param value for consumption by the guest, but prevent it from
being set. Enabling is now done using the misc_flags field in
Iterate over the p2m up to the maximum recorded gfn and remove any foreign
mappings, in order to drop the underlying page references and thus don't keep
extra page references if a domain is destroyed while still having foreign
mappings on it's p2m.
The logic is similar to the one used on Arm.
create. Also altp2m enablement is different from activation, as
activation does happen during runtime of the domain.
Thanks, Roger.
Roger Pau Monne (3):
xen/x86: account number of foreign mappings in the p2m
xen/x86: enable altp2m at create domain domctl
xen/x86: remove foreign mappings from
Like it was done recently for libxl, switch to using the auto-generated feature
names by the processing of cpufeatureset.h, this allows removing the open-coded
feature names, and unifies the feature naming with libxl and the hypervisor.
Introduce a newly auto-generated array that contains the
Iterate over the p2m based on the maximum recorded gfn and remove any foreign
mappings, in order to drop the underlying page references and thus don't keep
extra page references if a domain is destroyed while still having foreign
mappings on it's p2m.
The logic is similar to the one used on Arm.
on the maximum gfn.
Mostly untested, sending early in case it could be considered for 4.19.
Thanks, Roger.
Roger Pau Monne (2):
xen/x86: account for max guest gfn and number of foreign mappings in
the p2m
xen/x86: remove foreign mappings from the p2m on teardown
CHANGELOG.md
Keep track of the maximum gfn that has ever been populated into the p2m, and
also account for the number of foreign mappings. Such information will be
needed in order to remove foreign mappings during teardown for HVM guests.
Right now the introduced counters are not consumed.
Signed-off-by:
None of the implementations support set_foreign_p2m_entry() yet, neither they
have a p2m walk in domain_relinquish_resources() in order to remove the foreign
mappings from the p2m and thus drop the extra refcounts.
Adjust the arch helpers to return false and introduce a comment that clearly
Like it was done recently for libxl, switch to using the auto-generated feature
names by the processing of cpufeatureset.h, this allows removing the open-coded
feature names, and unifies the feature naming with libxl and the hypervisor.
Note that leaf names need to be kept, as the current
Commit 262fc47ac174 ('xen/balloon: don't use PV mode extra memory for zone
device allocations') removed the addition of the extra memory ranges to the
unpopulated range allocator, using those only for the balloon driver.
This forces the unpopulated allocator to attach hotplug ranges even when
So it can be used by kpatch_process_special_sections() in further changes.
Non functional change.
Signed-off-by: Roger Pau Monné
---
create-diff-object.c | 74 ++--
1 file changed, 37 insertions(+), 37 deletions(-)
diff --git a/create-diff-object.c
When deciding whether there's content to generate a payload also take into
account whether special sections have changed. Initially account for changes
to alternative related section to cause the generation of a livepatch.
Note that accounting for hook sections is already done by
bug_frame related sections exclusively contain addresses that reference back to
the address where the BUG_INSTR is executed. As such, any change to the
contents of bug_frame sections (or it's relocations) will necessarily require a
change in the caller function, as the placement of the BUG_INSTR
The current runes assume that in the list of DWARF tags DW_AT_byte_size will
come after DW_AT_name, but that's not always the case. On one of my builds
I've seen:
DW_AT_name: (indirect string, offset: 0x3c45):
exception_table_entry
DW_AT_declaration : 1
<1>: Abbrev
XenServer uses quite long Xen version names, and encode such in the livepatch
filename, and it's currently running out of space in the file name.
Bump max filename size to 127, so it also matches the patch name length in the
hypervisor interface. Note the size of the buffer is 128 character, and
The current logic to detect changes in special sections elements will only
include group elements that reference function symbols that need including
(either because they have changed or are new).
This works fine in order to detect when a special section element needs
including because of the
Changes to special sections are not accounted for right now. For example a
change that only affects .altinstructions or .ex_table won't be included in the
livepatch payload, if none of the symbols referenced by those sections have
also changed.
Since it's not possible to know which elements in
The purpose of kpatch_regenerate_special_section() is fairly opaque without
spending a good amount of time and having quite a lot of knowledge about what
the special sections contains.
Introduce some comments in order to give context and describe the expected
functionality.
Signed-off-by: Roger
as I could come up with, but
it's hard to figure all the possible changes, plus it's also fairly easy
to inadvertently regress existing functionality.
Thanks, Roger.
Roger Pau Monne (9):
livepatch-build-tools: allow patch file name sizes up to 127
characters
create-diff-object: update
The size of the alt_instr structure in Xen is 14 instead of 12 bytes, adjust
it.
Signed-off-by: Roger Pau Monné
---
create-diff-object.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/create-diff-object.c b/create-diff-object.c
index fed360a9aa68..d8a2afbf2774 100644
---
The check for --force option shouldn't be against 0.
Reported-by: Jan Beulich
Fixes: 62a72092a517 ('livepatch: introduce --force option')
Signed-off-by: Roger Pau Monné
---
tools/misc/xen-livepatch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/misc/xen-livepatch.c
Introduce a xen-livepatch tool --force option, that's propagated into the
hyerpvisor for livepatch operations. The intention is for the option to be
used to bypass some checks that would otherwise prevent the patch from being
loaded.
Re purpose the pad field in xen_sysctl_livepatch_op to be a
Ensure the entries of a payload exception table only apply to text regions in
the payload itself. Since the payload exception table needs to be loaded and
active even before a patch is applied (because hooks might already rely on it),
make sure the exception table (if any) only contains fixups
Hello,
Following series contain some minor bugfixes and improvements for
livepatch logic, both inside the hypervisor and on the command line
tool.
Thanks, Roger.
Roger Pau Monne (4):
xen-livepatch: fix parameter name parsing
livepatch: introduce --force option
livepatch: refuse to resolve
Livepatch payloads containing symbols that belong to init sections can only
lead to page faults later on, as by the time the livepatch is loaded init
sections have already been freed.
Refuse to resolve such symbols and return an error instead.
Note such resolutions are only relevant for symbols
It's incorrect to restrict strncmp to the length of the command line input
parameter, as then a user passing a rune like:
% xen-livepatch up foo.livepatch
Would match against the "upload" command, because the string comparison has
been truncated to the length of the input argument. Use strcmp
It's incorrect to restrict strncmp to the length of the command line input
parameter, as then a user passing a rune like:
% xen-livepatch up foo.livepatch
Would match against the "upload" command, because the string comparison has
been truncated to the length of the input argument. Instead the
Livepatch payloads containing symbols that belong to init sections can only
lead to page faults later on, as by the time the livepatch is loaded init
sections have already been freed.
Refuse to resolve such symbols and return an error instead.
Note such resolutions are only relevant for symbols
Ensure the entries of a payload exception table only apply to text regions in
the payload itself. Since the payload exception table needs to be loaded and
active even before a patch is applied (because hooks might already rely on it),
make sure the exception table (if any) only contains fixups
Introduce a xen-livepatch tool --force option, that's propagated into the
hyerpvisor for livepatch operations. The intention is for the option to be
used to bypass some checks that would otherwise prevent the patch from being
loaded.
Re purpose the pad field in xen_sysctl_livepatch_op to be a
Hello,
Following series contain some minor bugfixes and improvements for
livepatch logic, both inside the hypervisor and on the command line
tool.
Thanks, Roger.
Roger Pau Monne (4):
xen-livepatch: fix parameter name parsing
livepatch: introduce --force option
livepatch: refuse to resolve
Currently the offsets into the boot_video_info struct are manually encoded in
video.S, which is fragile. Generate them in asm-offsets.c and switch the
current code to use those instead.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
---
Changes since
Hello,
Following patches are kind of unconnected after v1, but patch 1/2 is
still a helpful improvement.
Patch 2 fixes the (wrong) reporting of VGA information when Xen is
booted as a PVH guest.
Thanks, Roger.
Roger Pau Monne (2):
x86/video: add boot_video_info offset generation to asm
PVH guests skip real mode VGA detection, and never have a VGA available, hence
the default VGA selection is not applicable, and at worse can cause confusion
when parsing Xen boot log.
Zero the boot_vid_info structure when Xen is booted from the PVH entry point.
This fixes Xen incorrectly
Start by declaring the beginning and end of the init section.
No functional change intended.
Requested-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
xen/arch/arm/mmu/setup.c | 3 +--
xen/arch/x86/setup.c | 3 +--
xen/include/xen/sections.h | 17 +
3 files
Livepatch payloads containing symbols that belong to init sections can only
lead to page faults later on, as by the time the livepatch is loaded init
sections have already been freed.
Refuse to resolve such symbols and return an error instead.
Note such resolutions are only relevant for symbols
Hello,
Previously a single patch, now with a pre-patch to place the init
section markers into a common file.
Thanks, Roger.
Roger Pau Monne (2):
xen: introduce header file with section related symbols
livepatch: refuse to resolve symbols that belong to init sections
xen/arch/arm/mmu
Hello,
Fix patch fixing the printing of whether BHB-entry is used for PV or
HVM, second patch refines a bit the logic to decide whether the lfence
on entry can be elided for the entry points.
Thanks, Roger.
Roger Pau Monne (2):
x86/spec: fix reporting of BHB clearing usage from guest entry
It's currently too restrictive by just checking whether there's a BHB clearing
sequence selected. It should instead check whether BHB clearing is used on
entry from PV or HVM specifically.
Switch to use opt_bhb_entry_{pv,hvm} instead, and then remove cpu_has_bhb_seq
since it no longer has any
Reporting whether the BHB clearing on entry is done for the different domains
types based on cpu_has_bhb_seq is incorrect, as that variable signals whether
there's a BHB clearing sequence selected, but that alone doesn't imply that
such sequence is used from the PV and/or HVM entry points.
Reporting whether the BHB clearing on entry is done for the different domains
types based on cpu_has_bhb_seq is incorrect, as that variable signals whether
there's a BHB clearing sequence selected, but that alone doesn't imply that
such sequence is used from the PV and/or HVM entry points.
The current timeout of 40s seems to be too low for AMD boxes (pinots and
rimavas) in the lab after XSA-455, see:
http://logs.test-lab.xenproject.org/osstest/logs/185303/test-amd64-coresched-amd64-xl/info.html
Increase the timeout to 60s.
Signed-off-by: Roger Pau Monné
---
ts-debian-di-install
Livepatch payloads containing symbols that belong to init sections can only
lead to page faults later on, as by the time the livepatch is loaded init
sections have already been freed.
Refuse to resolve such symbols and return an error instead.
Note such resolutions are only relevant for symbols
Setting alternative call variables as __init is not safe for use with
livepatch, as livepatches can rightfully introduce new alternative calls to
structures marked as __alt_call_maybe_initdata (possibly just indirectly due to
replacing existing functions that use those). Attempting to resolve
Setting alternative call variables as __init is not safe for use with
livepatch, as livepatches can rightfully introduce new alternative calls to
structures marked as __alt_call_maybe_initdata (possibly just indirectly due to
replacing existing functions that use those). Attempting to resolve
The code in _apply_alternatives() will unconditionally attempt to read
__initdata_cf_clobber_{start,end} when called as part of applying alternatives
to a livepatch payload. That leads to a page-fault as
__initdata_cf_clobber_{start,end} living in .init section will have been
unmapped by the time
Currently the offsets into the boot_video_info struct are manually encoded in
video.S, which is fragile. Generate them in asm-offsets.c and switch the
current code to use those instead.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/boot/video.S | 83
There's no reason to assume VGA text mode 3 to be unconditionally available.
With the addition of booting Xen itself in PVH mode there's a boot path that
explicitly short-circuits all the real-mode logic, including the VGA detection.
Leave the default user selected mode as text mode 3 in
VGA support.
Roger Pau Monne (2):
x86/video: add boot_video_info offset generation to asm-offsets
x86/video: do not assume a video mode to be unconditionally present
xen/arch/x86/boot/video.S | 88 +++
xen/arch/x86/x86_64/asm-offsets.c | 26 +
2
The current console_lock_recursive_irqsave() implementation is not speculation
safe, however it's only used to prevent interleaved output. Note this in the
function declaration in order for callers to be aware of the limitation.
No functional change.
Signed-off-by: Roger Pau Monné
---
There's no reason to force HVM guests to have a valid vcpu_info area when
initializing a vCPU, as the vCPU can also be brought online using the local
APIC, and on that path there's no requirement for vcpu_info to be setup ahead
of the bring up. Note an HVM vCPU can operate normally without making
EFI_GET_TIME doesn't seem to be very reliable:
[ Xen-4.19-unstable x86_64 debug=y Tainted: C]
CPU:0
RIP:e008:[<62ccfa70>] 62ccfa70
[...]
Xen call trace:
[<62ccfa70>] R 62ccfa70
[<732e9a3f>] S 732e9a3f
[] F
The current logic to detect when to switch to the next L1 table is incorrectly
using l2_table_offset() in order to notice when the last entry on the current
L1 table has been reached.
It should instead use l1_table_offset() to check whether the index has wrapped
to point to the first entry, and
The current usage of a cmpxchg loop to increase the value of page count is not
optimal on amd64, as there's already an instruction to do an atomic add to a
64bit integer.
Switch the code in get_page_light() to use an atomic increment, as that avoids
a loop construct. This slightly changes the
Currently vpci_deassign_device() is called without holding the per-domain
pci_lock in pci_remove_device(), which leads to:
Assertion 'rw_is_write_locked(>domain->pci_lock)' failed at
../drivers/vpci/vpci.c:47
[...]
Xen call trace:
[] R vpci_deassign_device+0x10d/0x1b9
[] S
We no longer have a way to build with the minimum required clang/llvm version
stated in the README on the gitlab CI loop, since we dropped the Debian Jessie
container that had Clang 3.5.0.
Bump the minimum required Clang/LLVM to the one used in the oldest production
FreeBSD version (13.2
The generated code between the debug and release builds can be quite
different, as a note 2ce562b2a413 only manifested in non-debug builds due to
the usage of -O2.
Duplicate the clang based test in order to test with both debug and non-debug
Xen builds.
Signed-off-by: Roger Pau Monné
---
Hello,
The following series limits the supported versions of Clang to what I
actually care about, as I seem to be the only one that actively uses
Clang/LLVM builds of Xen.
Patch 2 adds non-debug tests for -clang builds.
Thanks, Roger.
Roger Pau Monne (2):
README: bump minimum required clang
The usage in ALT_CALL_ARG() on clang of:
register union {
typeof(arg) e;
const unsigned long r;
} ...
When `arg` is the first argument to alternative_{,v}call() and
const_vlapic_vcpu() is used results in clang 3.5.0 complaining with:
arch/x86/hvm/vlapic.c:141:47: error: non-const static
It seems the build variables for those tests where copy-pasted from
xen_action_hooks_marker-objs and not adjusted to use the correct source files.
Fixes: 6047104c3ccc ('livepatch: Add per-function applied/reverted state
tracking marker')
Signed-off-by: Roger Pau Monné
Reviewed-by: Ross
When checking if an address belongs to a patch, or when resolving a symbol,
take into account all loaded livepatch payloads, even if not applied.
This is required in order for the pre-apply and post-revert hooks to work
properly, or else Xen won't detect the instruction pointer belonging to those
Group the payload hooks between the pre/post handlers, and the apply/revert
replacements. Also attempt to comment the context in which the hooks are
executed.
No functional change.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
The purpose of the norevert test is to install a dummy handler that replaces
the internal Xen revert code, and then perform the revert in the post-revert
hook. For that purpose the usage of the previous common_livepatch_revert() is
not enough, as that just reverts specific functions, but not the
the build system completely.
I'm unsure how useful the apply and revert hooks really are, as without
calling the internal apply/revert functions the state of the payload
structure is quite likely inconsistent with the code expectations.
Thanks, Roger.
Roger Pau Monne (5):
xen/livepatch: register
Currently livepatch regions are registered as virtual regions only after the
livepatch has been applied.
This can lead to issues when using the pre-apply or post-revert hooks, as at
that point the livepatch is not in the virtual regions list. If a livepatch
pre-apply hook contains a WARN() it
Now that the thunk built-in enable is printed as part of the "Compiled-in
support:" line, avoid printing anything in "Xen settings:" if the thunk is
disabled at build time.
Note the BTI-Thunk option printing is also adjusted to print a colon in the
same way the other options on the line do.
Hello,
A couple of improvements for the spec-ctrl command line parsing.
Thanks, Roger.
Roger Pau Monne (4):
x86/spec: print the built-in SPECULATIVE_HARDEN_* options
x86/spec: fix BRANCH_HARDEN option to only be set when build-enabled
x86/spec: fix INDIRECT_THUNK option to only be set
The current logic to handle the BRANCH_HARDEN option will report it as enabled
even when build-time disabled. Fix this by only allowing the option to be set
when support for it is built into Xen.
Fixes: 2d6f36daa086 ('x86/nospec: Introduce CONFIG_SPECULATIVE_HARDEN_BRANCH')
Signed-off-by: Roger
Attempt to provide a more helpful error message when the user attempts to set
spec-ctrl=bti-thunk option but the support is build-time disabled.
While there also adjust the command line documentation to mention
CONFIG_INDIRECT_THUNK instead of INDIRECT_THUNK.
Reported-by: Andrew Cooper
Just like it's done for INDIRECT_THUNK and SHADOW_PAGING.
Reported-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
Changes since v2:
- New in this version.
---
xen/arch/x86/spec_ctrl.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git
The current code for alternative calls uses the caller parameter types as the
types for the register variables that serve as function parameters:
uint8_t foo;
[...]
alternative_call(myfunc, foo);
Would expand roughly into:
register unint8_t a1_ asm("rdi") = foo;
register unsigned long a2_
Attempt to provide a more helpful error message when the user attempts to set
spec-ctrl=bti-thunk option but the support is build-time disabled.
Reported-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
xen/arch/x86/spec_ctrl.c | 5 +
1
'*' sets the width field, which is the minimum number of characters to output,
but what we want in no_config_param() is the precision instead, which is '.*'
as it imposes a maximum limit on the output.
Fixes: 68d757df8dd2 ('x86/pv: Options to disable and/or compile out 32bit PV
support')
The current logic to handle the BRANCH_HARDEN option will report it as enabled
even when build-time disabled. Fix this by only allowing the option to be set
when support for it is built into Xen.
Fixes: 2d6f36daa086 ('x86/nospec: Introduce CONFIG_SPECULATIVE_HARDEN_BRANCH')
Signed-off-by: Roger
Hello,
A couple of improvements for the spec-ctrl command line parsing, and one
bugfix for no_config_param().
Thanks, Roger.
Roger Pau Monne (3):
xen/cmdline: fix printf format specifier in no_config_param()
x86/spec: fix BRANCH_HARDEN option to only be set when build-enabled
x86/spec
The current logic to handle the BRANCH_HARDEN option will report it as enabled
even when build-time disabled. Fix this by only allowing the option to be set
when support for it is built into Xen.
Fixes: 2d6f36daa086 ('x86/nospec: Introduce CONFIG_SPECULATIVE_HARDEN_BRANCH')
Signed-off-by: Roger
The current code for alternative calls uses the caller parameter types as the
types for the register variables that serve as function parameters:
uint8_t foo;
[...]
alternative_call(myfunc, foo);
Would expand roughly into:
register unint8_t a1_ asm("rdi") = foo;
register unsigned long a2_
Hello,
Following series replace a couple of cmpxchg loops with an atomic inc.
The usage of such loops probably dates back to 32bit support, which
didn't have an instruction to do an atomic 64bit addition.
Thanks, Roger.
Roger Pau Monne (2):
x86/memsharing: use an atomic add instead
The usage of a cmpxchg loop in hpet_get_channel() is unnecessary, as the same
can be achieved with an atomic increment, which is both simpler to read, and
avoid any need for a loop.
Note there can be a small divergence in the channel returned if next_channel
overflows, but returned channel will
The usage of a cmpxchg loop in get_next_handle() is unnecessary, as the same
can be achieved with an atomic increment, which is both simpler to read, and
avoid any need for a loop.
The cmpxchg usage is likely a remnant of 32bit support, which didn't have an
instruction to do an atomic 64bit add,
The current code for alternative calls uses the caller parameter types as the
types for the register variables that serve as function parameters:
uint8_t foo;
[...]
alternative_call(myfunc, foo);
Would expand roughly into:
register unint8_t a1_ asm("rdi") = foo;
register unsigned long a2_
When running as PVH or HVM Linux will use holes in the memory map as scratch
space to map grants, foreign domain pages and possibly miscellaneous other
stuff. However the usage of such memory map holes for Xen purposes can be
problematic. The request of holesby Xen happen quite early in the
The feature is defined in the tertiary exec control, and is available starting
from Sapphire Rapids and Alder Lake CPUs.
When enabled, two extra VMCS fields are used: SPEC_CTRL mask and shadow. Bits
set in mask are not allowed to be toggled by the guest (either set or clear)
and the value in the
When doing a rebuild with an xen/include/config/auto.conf already present in
the tree, failures from Kconfig are ignored since the target is present:
gmake -C xen install
gmake[1]: Entering directory '/root/src/xen/xen'
tools/kconfig/conf --syncconfig Kconfig
common/Kconfig:2: syntax error
It's not obvious from just the function name whether the incremented value will
be stored in the parameter, or returned to the caller. That has leads to bugs
in the past as callers may assume the incremented value is stored in the
parameter.
Add the __must_check attribute to the function to
Provide more information in case the page can't be converted, and print the
original type(s).
Requested-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
xen/drivers/passthrough/x86/iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hello,
First patch is a fix for a silly mistake I introduced in
iommu_unity_region_ok(). The rest are additional chances requested in
that context. Last patch adds __must_check to the gfn/mfn addition
handlers.
Thanks, Roger.
Roger Pau Monne (5):
iommu/x86: fix IVMD/RMRR range checker loop
It's easier to correlate with the physical memory map if the addresses are
fully printed, instead of using frame numbers.
Requested-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
xen/drivers/passthrough/x86/iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
It's not obvious from the function itself whether the incremented value will be
stored in the parameter, or returned to the caller. That has leads to bugs in
the past as callers assume the incremented value is stored in the parameter.
Add the __must_check attribute to the function to easily spot
1 - 100 of 2050 matches
Mail list logo
