Intel provide CPU sensors through "DTS" MSRs. As these MSR are core-specific
(or package-specific), we can't reliably fetch them from Dom0 directly.
Expose these MSR (if supported) through XENPF_resource_op so that it is
accessible through hypercall.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
There's no need to invoke CPUID yet another time. This way two of the
static booleans can also go away.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
There's no need to invoke CPUID yet another time - we assume symmetry
anyway. With symmetry assumed, logging per-CPU also isn't very useful.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
There's no need to invoke CPUID yet another time. However, as the host CPU
policy is set up only shortly after init_intel() ran on the BSP, defer the
logic to a pre-SMP initcall. This can't be (a new) one in cpu/intel.c
though, as that's linked after acpi/cpu_idle.c (which is where we already
need the feature set). Since opt_arat is local to the cpu/ subtree,
introduce a new Intel-specific helper to hold the code needed.
Further, as we assume symmetry anyway, use setup_force_cpu_cap() and hence
limit the checking to the boot CPU.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Use the respective host CPU policy bit instead. This has the (tolerable,
as we generally assume symmetry anyway) effect of using the BSP's
(unleveled) setting, rather than the result of leveling (as is done by
identify_cpu() on boot_cpu_data, rendering the variable name somewhat
misleading).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Creating a dom0less guest with a high vCPU count (e.g., >32) fails
because the fixed 4KiB device tree buffer (DOMU_DTB_SIZE) overflows
during creation.
The FDT nodes for each vCPU are the primary consumer of space,
and the previous fixed-size buffer was insufficient.
This patch replaces the fixed size with a formula that calculates
the required buffer size based on a fixed baseline plus a scalable
portion for each potential vCPU up to the MAX_VIRT_CPUS limit.
Please note, the change to DOMU_DTB_SIZE formula would result in
a smaller buffer size of 3072 bytes compared to the original 4096 bytes
on Arm32 platforms where MAX_VIRT_CPUS is 8.
***
The following tests were done to confirm that the proposed formula
fits:
1. Arm64 testing with varying vCPU counts (MAX_VIRT_CPUS=128),
final compacted FDT size:
- 1 vCPU: 1586 bytes (with 18432 byte buffer)
- 2 vCPUs: 1698 bytes
- 32 vCPUs: 5058 bytes
- 128 vCPUs: 15810 bytes
2. Arm64 testing with simulated Arm32 conditions (MAX_VIRT_CPUS=8),
final compacted FDT size:
- 1 vCPU: 1586 bytes (with 3072 byte buffer)
- 8 vCPUs: 2370 bytes
3. Arm32 testing (MAX_VIRT_CPUS=8),
final compacted FDT size:
- 8 vCPUs: 1127 bytes (with 3072 byte buffer)
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Grygorii Strashko <grygorii_strashko@epam.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Tested-by: Harry Ramsey <harry.ramsey@arm.com>
Acked-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
File hvm/vm_event.c and x86/vm_event.c are the extend to vm_event handling
routines, and its compilation shall be guarded by CONFIG_VM_EVENT too.
Although CONFIG_VM_EVENT is right now forcibly enabled on x86 via
MEM_ACCESS_ALWAYS_ON, we could disable it through disabling
CONFIG_MGMT_HYPERCALLS later. So we remove MEM_ACCESS_ALWAYS_ON and
make VM_EVENT=y on default only on x86 to retain the same.
The following functions are developed on the basis of vm event framework, or
only invoked by vm_event.c, so they all shall be wrapped with CONFIG_VM_EVENT
(otherwise they will become unreachable and
violate Misra rule 2.1 when VM_EVENT=n):
- hvm_toggle_singlestep
- hvm_fast_singlestep
- hvm_emulate_one_vm_event
- hvmemul_write{,cmpxchg,rep_ins,rep_outs,rep_movs,rep_stos,read_io,write_io}_discard
And Function vm_event_check_ring() needs stub to pass compilation when
VM_EVENT=n.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Feature memory access is based on vm event subsystem, and it could be disabled
in the future. So a few switch-blocks in do_altp2m_op() need
vm_event_is_enabled() condition check to pass compilation when ALTP2M=y and
VM_EVENT=n(, hence MEM_ACCESS=n), like HVMOP_altp2m_set_mem_access, etc.
Function p2m_mem_access_check() still needs stub when VM_EVENT=n to
pass compilation.
Although local variable "req_ptr" still remains NULL throughout its lifetime,
with the change of NULL assignment, we will face runtime undefined error only
when CONFIG_USBAN is on. So we strengthen the condition check via adding
vm_event_is_enabled() for the special case.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Memory access and ALTP2M are two seperate features, while both depending on
helper xenmem_access_to_p2m_access(). So it betters lives in common p2m.c,
other than mem_access.c which will be compiled out when VM_EVENT=n && ALTP2M=y.
Guard xenmem_access_to_p2m_access() with VM_EVENT || ALTP2M, otherwise it
will become unreachable when both VM_EVENT=n and ALTP2M=n, and hence
violating Misra rule 2.1.
Also move declaration from xen/mem_access.h to x86'es one, requiring to also
move the inclusion point and condition of asm/mem_access.h there.
An extra blank line is inserted after each case-block to correct coding
style at the same time.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Feature monitor_op is based on vm event subsystem, so monitor.o shall be
wrapped under CONFIG_VM_EVENT.
The following functions are only invoked by monitor-op, so they all shall be
wrapped with CONFIG_VM_EVENT (otherwise they will become unreachable and
violate Misra rule 2.1 when VM_EVENT=n):
- hvm_enable_msr_interception
- hvm_function_table.enable_msr_interception
- hvm_has_set_descriptor_access_existing
- hvm_function_table.set_descriptor_access_existi
- arch_monitor_get_capabilities
Function monitored_msr() still needs a stub to pass compilation when
VM_EVENT=n.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Function vm_event_is_enabled() is introduced to check if vm event is enabled,
and also make the checking conditional upon CONFIG_VM_EVENT, which could help
DCE a lot unreachable calls/codes, such as hvm_monitor_io(), etc,
when having VM_EVENT=n.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Memory access and ALTP2M are two seperate features, and each could be
controlled via VM_EVENT or ALTP2M. In order to avoid implicit declaration
when ALTP2M=y and VM_EVENT=n on compiling hvm.o/altp2m.o, we move declaration
of the following functions from <asm/mem_access.h> to <asm/altp2m.h>:
- p2m_set_suppress_ve
- p2m_set_suppress_ve_multi
- p2m_get_suppress_ve
Potential error on altp2m.c also breaks Misra Rule 8.4.
Signed-off-by: Penny Zheng <Penny.Zheng@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
allocate_memory_11() can be called for dom0 and direct-mapped hwdom
domU. In the latter scenario, a log message would still mention dom0
instead of the correct domid.
Fixes: 52cb53f181 ("xen/arm: dom0less hwdom construction")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
During `init_done`, Xen sets the permissions of all symbols marked with
__ro_after_init to be read-only. This does not work on MPU systems at
present because part-region modification is not supported.
Therefore introduce the function `modify_after_init_mappings` for MMU
and MPU, to handle the divergent approaches to setting permissions of
__ro_after_init symbols.
For MPU systems `modify_xen_mappings` will shrink the RW mapping on one
side and extend the RO mapping on the other. This approach prevents
wasting an additional region between RW and RO mappings.
As the new function is marked with __init, it needs to be called before
`free_init_memory`.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Signed-off-by: Hari Limaye <hari.limaye@arm.com>
Signed-off-by: Harry Ramsey <harry.ramsey@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Implement the function `free_init_memory` for MPU systems. In order to
support this, the function `modify_xen_mappings` is implemented.
On MPU systems, we map the init text and init data sections using
separate MPU memory regions. Therefore these are removed separately in
`free_init_memory`.
Additionally remove warning messages from `is_mm_attr_match` as some
attributes can now be updated by `xen_mpumap_update_entry`.
Signed-off-by: Penny Zheng <penny.zheng@arm.com>
Signed-off-by: Wei Chen <wei.chen@arm.com>
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Signed-off-by: Hari Limaye <hari.limaye@arm.com>
Signed-off-by: Harry Ramsey <harry.ramsey@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
HAS_VMAP is not enabled on MPU systems, but the vmap functions are used
in places across common code. In order to keep the existing code and
maintain correct functionality, implement the `vmap_contig` and `vunmap`
functions for MPU systems.
Introduce a helper function `destroy_xen_mapping_containing` to aid with
unmapping an entire region when only the start address is known.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Signed-off-by: Harry Ramsey <harry.ramsey@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Implement the function copy_from_paddr variant for MPU systems, using
the map_pages_to_xen/destroy_xen_mappings to temporarily map the memory
range to be copied.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Signed-off-by: Hari Limaye <hari.limaye@arm.com>
Signed-off-by: Harry Ramsey <harry.ramsey@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
There is no reason to use pointer difference.
A violation of MISRA C Rule 18.2 ("Subtraction between pointers
shall only be applied to pointers that address elements of the
same array") is also resolved because the object to the subtraction
is applied is not an array.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Add a XEN infix, to properly distinguish it from the CPUID feature flag
(leaf 6 EAX bit 2).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
The tracking lasted only for about two weeks, but the related comment
parts were never purged.
Amends: 50b74f55e0 ("OOS cleanup: Fixup arrays instead of fixup tables")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
The code has been identified as HVM-only, and its main functions are
pretty well isolated. Move them to their own file. While moving, besides
making two functions non-static, do a few style adjustments, mainly
comment formatting, but leave the code otherwise untouched.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Switch to using IS_ENABLED() in both places, thus in particular making
sure XENPF_get_dom0_console handling doesn't take the "default" path: The
behavior better wouldn't differ between VIDEO=y and there not being VGA vs
VIDEO=n. For this to work, fill_console_start_info() needs to be
unconditionally declared; extend that to vga_console_info as well.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Omit the function when PV=n, by moving it to the sole file using it, thus
allowing it to become static as well.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Omit the function when HVM=n. With that the !HVM logic can also go away;
leave an assertion.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
While the VMX hook never used the parameter, the SVM one lost its sole use
some time ago (while the original use of the parameter had gone away even
earlier).
Again modernize types while there.
Amends: 0cd50753eb ("nestedsvm: Disable TscRateMSR")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
It's used in time.c alone. Modernize types while there.
Amends: 5a82d598d2 ("viridian: unify time sources")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
We'd rather have the full spelling in Kconfig. Adjusts every other
reference to the name too.
Not a functional change.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Debug builds traditionally ship with a 10-bit counter for the TLB
clock. This forces global TLB shootdowns with high frequency, making
debug builds unsuitable for any form of real time testing.
Remove this quirk, unifying release and debug under a wide counter.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
They're dynamic too, and don't have named fields because no (other) logic in
Xen ought to operate on them. In particular, OSPKE being visible depending on
whether we're in HVM or PV vCPU context when scanning.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
This only exists to have it's type taken, despite there being a perfectly good
concrete type to use.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
In addition to GCC not liking x86_emulate(), it turns out that Clang is still
rather more a work in progress than a usable feature, causing failures in the
FreeBSD builds:
https://cirrus-ci.com/task/5934059060199424
Exclude CONFIG_CONDITION_COVERAGE from Ranconfig until it gets a bit more
stable.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Commit 7e5b662 fixed p2m_altp2m_get_or_propagate() to use the altp2m's
default_access when propagating entries from the host p2m. However, the same
fix was not applied to altp2m_get_effective_entry(), which has the same issue.
When altp2m_get_effective_entry() prepopulates a superpage from the host
p2m, it incorrectly uses the host p2m's access permissions instead of
the altp2m's default_access. This causes problems when the superpage is
later split (e.g., when setting mem_access on a specific 4K page): all
512 entries inherit the host p2m's access rights instead of the altp2m's
default_access.
This issue became apparent after commit 50baf2d, which causes the host p2m
to use superpages more frequently. Before that commit, the host p2m
typically had 4K entries after VM restore, so the prepopulate branch was
rarely taken.
Symptoms include memory-access events firing for unexpected pages when
using VMI tools with altp2m, particularly after VM resume.
The issue can be worked around by booting with "hap_1gb=0 hap_2mb=0".
Amends: 7e5b662b28 ("x86/altp2m: p2m_altp2m_get_or_propagate() should honor ap2m->default_access")
Signed-off-by: Petr Beneš <w1benny@gmail.com>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
This is in preparation of using attributes recorded for devices.
Additionally locating (extended) capabilities of non-devices (e.g. phantom
functions) makes no sense.
While there also eliminate open-coding of PCI_CFG_SPACE_SIZE in adjacent
code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
This not only reduces the number of parameters and local variables, but
also prepares for doing the same to pci_find_{,next_}ext_capability().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
This not only brings both in sync with {en,dis}able_ats_device() but also
prepares for doing the same to pci_find_{,next_}ext_capability().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
The Atom block used to fall through into the Phi block to get to it's
return false, and this was accidentally dropped with the Phi removal.
Fixes: 85191cf321 ("x86: drop Xeon Phi support")
Signed-off-by: Kevin Lampis <kevin.lampis@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Introduce tracking of metadata page entries usage and if all of them are
p2m_invalid then free them.
Intermediate P2M page tables are allocated with MEMF_no_owner, so we are free
to repurpose struct page_info fields for them. Since page_info.u.* is not
used for such pages, introduce a used_entries counter in struct page_info
to track how many metadata entries are in use for a given intermediate P2M
page table.
The counter is updated in p2m_set_type() when metadata entries transition
between p2m_invalid and a valid external type. When the last metadata entry
is cleared (used_entries == 0), the associated metadata page is freed and
returned to the P2M pool.
Refactor metadata page freeing into a new helper, p2m_free_metadata_page(),
as the same logic is needed both when tearing down a P2M table and when
all metadata entries become p2m_invalid in p2m_set_type(). As part of this
refactoring, move the declaration of p2m_free_page() earlier to satisfy the
new helper.
Additionally, implement page_set_tlbflush_timestamp() for RISC-V instead of
BUGing, as it is invoked when returning memory to the domheap.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
RISC-V's PTE has only two available bits that can be used to store the P2M
type. This is insufficient to represent all the current RISC-V P2M types.
Therefore, some P2M types must be stored outside the PTE bits.
To address this, a metadata table is introduced to store P2M types that
cannot fit in the PTE itself. Not all P2M types are stored in the
metadata table—only those that require it.
The metadata table is linked to the intermediate page table via the
`struct page_info`'s v.md.metadata field of the corresponding intermediate
page.
Such pages are allocated with MEMF_no_owner, which allows us to use
the v field for the purpose of storing the metadata table.
To simplify the allocation and linking of intermediate and metadata page
tables, `p2m_{alloc,free}_table()` functions are implemented.
These changes impact `p2m_split_superpage()`, since when a superpage is
split, it is necessary to update the metadata table of the new
intermediate page table — if the entry being split has its P2M type set
to `p2m_ext_storage` in its `P2M_TYPES` bits. In addition to updating
the metadata of the new intermediate page table, the corresponding entry
in the metadata for the original superpage is invalidated.
Also, update p2m_{get,set}_type to work with P2M types which don't fit
into PTE bits.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Introduce helper functions for safely querying the P2M (physical-to-machine)
mapping:
- add p2m_read_lock(), p2m_read_unlock(), and p2m_is_locked() for managing
P2M lock state.
- Implement p2m_get_entry() to retrieve mapping details for a given GFN,
including MFN, page order, and validity.
- Introduce p2m_get_page_from_gfn() to convert a GFN into a page_info
pointer, acquiring a reference to the page if valid.
- Introduce get_page().
Implementations are based on Arm's functions with some minor modifications:
- p2m_get_entry():
- Reverse traversal of page tables, as RISC-V uses the opposite level
numbering compared to Arm.
- Removed the return of p2m_access_t from p2m_get_entry() since
mem_access_settings is not introduced for RISC-V.
- Updated BUILD_BUG_ON() to check using the level 0 mask, which corresponds
to Arm's THIRD_MASK.
- Replaced open-coded bit shifts with the BIT() macro.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
xenpm doesn't provide any interesting usable features outside of x86,
skip building it if we are not x86.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
In macros it is common to declare local variables using typeof(param) in order
to ensure that side effects are only evaluated once. A consequence of this is
double textural expansion of the parameter, which can get out of hand very
quickly with nested macros.
In C23, the auto keyword has been repurposed to perform type inference.
A GCC extension, __auto_type, is now available in the new toolchain baseline
and avoids the double textural expansion.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Frediano Ziglio <frediano.ziglio@cloud.com>
The most recent xenoprof change was 300ef0cb4f ("x86: Add Xenoprofile
support for AMD Family16h") in 2013, despite there being 42 changes worth of
other cleanup/rearranging since then.
Oprofile themselves dropped Xen support in commit 0c142c3a096d ("Remove
opcontrol and the GUI and processor models dependent on it") in 2014, as part
of releasing version 1.0 and switching over to using operf based on the Linux
perf_event subsystem. Linux's version of this patch was merged in commit
24880bef417f ("Merge tag 'oprofile-removal-5.12'") in 2021.
Drop xenoprof and all supporting infrastructure, including the hypercall, the
XSM hook and flask vectors which lose their only caller, and even shrinks
struct domain by one pointer which wasn't properly excluded in
!CONFIG_XENOPROF builds.
Retain the public xenoprof.h header as it is ABI, but note that the
functionality is removed.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
xen/drivers/passthrough/arm/ipmmu-vmsa.c contains a git:// URL in a block
comment. This is also not an example of commented out code, so shouldn't be
considered a R3.1 violation.
Extend the regex to include git://, and swap hyperlink for URL in the
associated documentation to be more precise.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
When Cscope-ing through Xen, one occasionally finds themselves in
xen-hypercall-defs.h and needing to find the originating file.
This is substantially magic, and even reading the Makefile that produces
xen-hypercall-defs.h is of little help if you're not aware of of the %.i : %.c
pattern rule, and that the header is generated from a .c file in practice.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
As {alloc,free}_domain_struct() are used only within domain.c,
they can be declared static and their declarations removed
from xen/domain.h.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Teddy Astie