- 18 Jan, 2021 1 commit
-
-
Manuel Bouyer authored
remove PROCNETDEV_HEADER[] and read_attributes_vbd(), gcc complains that they are unused Signed-off-by:
Manuel Bouyer <bouyer@netbsd.org> Message-Id: <20210112181242.1570-22-bouyer@antioche.eu.org> Reviewed-by:
Roger Pau Monné <roger.pau@citrix.com>
-
- 15 Jan, 2021 14 commits
-
-
Julien Grall authored
Livepatch fails to build on Arm after commit ced9795c "mm: split out mfn_t / gfn_t / pfn_t definitions and helpers": In file included from livepatch.c:13:0: /oss/xen/xen/include/asm/mm.h:32:28: error: field ‘list’ has incomplete type struct page_list_entry list; ^~~~ /oss/xen/xen/include/asm/mm.h:53:43: error: ‘MAX_ORDER’ undeclared here (not in a function); did you mean ‘PFN_ORDER’? unsigned long first_dirty:MAX_ORDER + 1; ^~~~~~~~~ PFN_ORDER /oss/xen/xen/include/asm/mm.h:53:31: error: bit-field ‘first_dirty’ width not an integer constant unsigned long first_dirty:MAX_ORDER + 1; ^~~~~~~~~~~ This is happening because asm/mm.h is included directly by livepatch.c. Yet it depends on xen/mm.h to be included first so MAX_ORDER is defined. Resolve the build failure by including xen/mm.h rather than asm/mm.h. Fixes: ced9795c ("mm: split out mfn_t / gfn_t / pfn_t definitions and helpers") Signed-off-by:
Julien Grall <jgrall@amazon.com> Reviewed-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by:
Stefano Stabellini <sstabellini@kernel.org>
-
Manuel Bouyer authored
On NetBSD the lock directory is in /var/run/ Signed-off-by:
-
Jan Beulich authored
I can only assume that f2ae59bc ("Rationalize max_grant_frames and max_maptrack_frames handling") unintentionally left Arm's create_domUs() set limits to explicit values, as at least some of the same constraints apply here. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Acked-by:
-
Jan Beulich authored
xen/mm.h has heavy dependencies, while in a number of cases only these type definitions are needed. This separation then also allows pulling in these definitions when including xen/mm.h would cause cyclic dependencies. Replace xen/mm.h inclusion where possible in include/xen/. (In xen/iommu.h also take the opportunity and correct the few remaining sorting issues.) While the change could be dropped, remove an unnecessary asm/io.h inclusion from xen/arch/x86/acpi/power.c. This was the initial attempt to address build issues with it, until it became clear that the header itself needs adjustment. Signed-off-by:
-
Jan Beulich authored
Doing so limits what can be done in (in particular included by) this per- arch header. Abstract out page shift/size related #define-s, which is all the respective headers care about. Extend the replacement / removal to some x86 headers as well; some others now need to include page.h (and they really should have before). Arm's VADDR_BITS gets dropped altogether: Its current value is clearly wrong for 64-bit, but the constant also isn't used anywhere right now. While Arm used vaddr_t in PAGE_OFFSET(), this use is compatible with that of unsigned long in the new common implementation. Also drop the dead PAGE_FLAG_MASK at this occasion. Signed-off-by:
-
Juergen Gross authored
For live update of Xenstore some records defined in the migration stream document need to be changed: - Support of the read-only socket has been dropped from all Xenstore implementations, so ro-socket-fd in the global record can be removed. - Some guests require the event channel to Xenstore to remain the same on Xenstore side, so Xenstore has to keep the event channel interface open across a live update. For this purpose an evtchn-fd needs to be added to the global record. - With no read-only support the flags field in the connection record can be dropped. - The evtchn field in the connection record needs to be switched to hold the port of the Xenstore side of the event channel. - A flags field needs to be added to permission specifiers in order to be able to mark a permission as stale (XSA-322). Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
-
Juergen Gross authored
Today the file descriptor for the access of the event channel driver is being closed in case of exec(2). For the support of live update of a daemon using libxenevtchn this can be problematic, so add a way to keep that file descriptor open. Add support of a flag XENEVTCHN_NO_CLOEXEC for xenevtchn_open() which will result in _not_ setting O_CLOEXEC when opening the event channel driver node. The caller can then obtain the file descriptor via xenevtchn_fd(). Add an alternative open function xenevtchn_fdopen() which takes that file descriptor as an additional parameter. This allows to allocate a xenevtchn_handle and to associate it with that file descriptor. Signed-off-by:
Wei Liu <wl@xen.org> Reviewed-by:
-
Juergen Gross authored
Propagate the flags parameter of xenevtchn_open() to the OS-specific handlers in order to enable handling them there. Signed-off-by:
Andrew Cooper <andrew.cooper3@citrix.com>
-
Juergen Gross authored
Refuse a call of xenevtchn_open() with unsupported bits in flags being set. This will change behavior for callers passing junk in flags today, but those would otherwise get probably unwanted side effects when the flags they specify today get any meaning. So checking flags is the right thing to do. Suggested-by:
-
Juergen Gross authored
Rename the xenevtchn_open() parameter open_flags to flags as it might be used for things not passed on to open(). No functional change. No API/ABI changes. Suggested-by:
-
Juergen Gross authored
There is a mixture of different styles in libxenevtchn. Use the standard xen style only. No functional change. Signed-off-by:
-
Stefano Stabellini authored
Instead apt-get'ing Debian's qemu-system-aarch64, simply use the provided QEMU binary under binaries. Signed-off-by:
Stefano Stabellini <stefano.stabellini@xilinx.com> Acked-by:
-
Stefano Stabellini authored
In order to use the pre-built test-artifacts/qemu-system-aarch64 binary for our tests, first we need to import it into the pipeline. Let's do that the same way we did it for the kernel and Alpine Linux filesystem: by creating a special job for it. Signed-off-by:
-
Stefano Stabellini authored
Currently we are using Debian's qemu-system-aarch64 for our tests. However, sometimes it crashes. It is hard to debug and even harder to apply any fixes to it. Instead, build our own QEMU as one of our test-artifacts, which are only built once, then imported into each pipeline via phony jobs. Signed-off-by:
-
- 14 Jan, 2021 6 commits
-
-
Olaf Hering authoredIt is just a declaration, not a variable. ld: /home/abuild/rpmbuild/BUILD/xen-4.14.20200616T103126.3625b049/non-dbg/stubdom/vtpmmgr/vtpmmgr.a(vtpm_cmd_handler.o):(.bss+0x0): multiple definition of `tpm_version'; /home/abuild/rpmbuild/BUILD/xen-4.14.20200616T103126.3625b049/non-dbg/stubdom/vtpmmgr/vtpmmgr.a(vtpmmgr.o):(.bss+0x0): first defined here Signed-off-by:
Olaf Hering <olaf@aepfle.de>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
-
Jan Beulich authored
Its guard was updated such that it is visible by default when POSIX 2008 was adopted by glibc. It's not visible by default on older glibc. Fixes: 40fe714c ("tools/libs/stat: use memcpy instead of strncpy in getBridge") Signed-off-by:
Ian Jackson <ian.jackson@eu.citrix.com>
-
Jan Beulich authored
For short-lived references rcu_lock_domain_by_id() is the better (slightly cheaper) alternative. Signed-off-by:
Christopher Clark <christopher.w.clark@gmail.com> -
Jan Beulich authored
Its expansion shouldn't be tied to NDEBUG - down the road we may want to allow enabling assertions independently of CONFIG_DEBUG. Replace the few uses by a new xen_build_info() helper, subsuming gcov_string at the same time (while replacing the stale CONFIG_GCOV used there) and also adding CONFIG_UBSAN indication. Signed-off-by:
-
Jan Beulich authored
Adjust so we uniformly avoid needlessly arranging for a continuation on the last iteration. Fixes: 5777a374 ("IOMMU: hold page ref until after deferred TLB flush") Signed-off-by:
-
Stefano Stabellini authored
Don't read aarch32 system registers at boot time when the aarch32 state is not available at EL0. They are UNKNOWN, so it is not useful to read them. Moreover, on Cavium ThunderX reading ID_PFR2_EL1 generates an unsupported exception which causes a Xen crash. Instead, only read them when aarch32 is available. Leave the corresponding fields in struct cpuinfo_arm so that they are read-as-zero from a guest. Since we are editing identify_cpu, also fix the indentation: 4 spaces instead of 8. Fixes: 9cfdb489 ("xen/arm: Add ID registers and complete cpuinfo") Link: https://lore.kernel.org/xen-devel/f90e40ee-b042-6cc5-a08d-aef41a279527@suse.com/Suggested-by:
Julien Grall <julien@xen.org> Signed-off-by:
Bertrand Marquis <bertrand.marquis@arm.com> Acked-by:
-
- 13 Jan, 2021 5 commits
-
-
Wei Chen authored
It seems the arm inline function get_cycles has used 8 spaces for line indent since 2012. This patch correct them to 4 spaces and remove extra space between function name and bracket. Signed-off-by:
Wei Chen <wei.chen@arm.com> Acked-by:
-
Tamas K Lengyel authored
The arch_domain struct has "msr", not "msrs". Spotted by a TravisCI Randconfig build. Reported-by:
Tamas K Lengyel <tamas.lengyel@intel.com> Acked-by:
-
Andrew Cooper authored
memshrtool is a tool for a human to use, rather than a test. Move it into misc/ as a more appropriate location to live. Also rename it to xen-memshare Signed-off-by:
-
Andrew Cooper authored
xen-access is a tool for a human to use, rather than a test. Move it into misc/ as a more appropriate location to live. Move the -DXC_WANT_COMPAT_DEVICEMODEL_API from CFLAGS into xen-access.c itself to avoid adding Makefile complexity. Signed-off-by:
Tamas K Lengyel <tamas@tklengyel.com>
-
Andrew Cooper authored
The python unit tests were dropped in Xen 4.12 due to being obsolete, but the scripts to run the tests were missed. Clean up .gitignore as well. Also drop the libxenctrl {C,LD}FLAGS adjustments in the Makefile. This logic isn't used, and isn't appropriate even in principle, as there are tests in here which don't want to use libxenctrl. Signed-off-by:
-
- 12 Jan, 2021 5 commits
-
-
Andrew Cooper authored
Copy the nr_frames from the structure which actually has the correct value, so the caller doesn't unconditionally receive 0. Signed-off-by:
Paul Durrant <paul@xen.org>
-
Andrew Cooper authored
New architectures shouldn't be forced to implement no-op stubs for unused functionality. Introduce CONFIG_ARCH_ACQUIRE_RESOURCE which can be opted in to, and provide compatibility logic in xen/mm.h No functional change. Signed-off-by:
-
Julien Grall authored
clang 11 will throw the following error while build Xen: scif-uart.c:333:33: error: cast to smaller integer type 'enum port_types' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast] uart->params = &port_params[(enum port_types)match->data]; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ The error can be prevented by directly storing a pointer to the port parameters rather than the a cast of the port type. Signed-off-by: -
Oleksandr Tyshchenko authored
Replace all the use of 1 << 31 with 1U << 31 to prevent undefined behavior in the IPMMU-VMSA driver. Signed-off-by:
Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Reviewed-by:
-
Julien Grall authored
Replace all the use of 1 << 31 with 1U << 31 to prevent undefined behavior in the SMMU driver. Signed-off-by:
-
- 11 Jan, 2021 9 commits
-
-
Roger Pau Monné authored
After the recent changes to acpi_fadt_parse_sleep_info the bad label can never be called with facs mapped, and hence the unmap can be removed. Additionally remove the whole label, since it was used by a single caller. Move the relevant code from the label. No functional change intended. CID: 1471722 Fixes: 16ca5b3f ('x86/ACPI: don't invalidate S5 data when S3 wakeup vector cannot be determined') Signed-off-by:
-
Jan Beulich authored
I don't think we mean to ever make them real Kconfig options, so let's just do away with them. Signed-off-by:
-
Jan Beulich authored
The latter is slightly more type-safe. Also add const where possible, including without need to touch further code. Additionally replace an adjacent unnecessary use of u16. Signed-off-by:
-
Jan Beulich authored
When marking fields invalid for our own purposes, we should do so in our local copy (so we will notice later on), not in the firmware provided one (which another entity may want to look at again, e.g. after kexec). Also mark the function parameter const to notice such issues right away. Instead use the pointer at the firmware copy for specifying an adjacent printk()'s arguments. If nothing else this at least reduces the number of relocations the assembler hasto emit and the linker has to process. Fixes: 62d1a69a ("ACPI: support v5 (reduced HW) sleep interface") Signed-off-by:
-
Jan Beulich authored
While they're KERN_INFO messages and hence not visible by default, we still have had reports that the amount of output is too large, not the least because - the command line controlled resizing of the console ring buffer happens only after SRAT parsing (which may alone produce more than 16k of output), - the default resizing of the console ring buffer happens only after ACPI table parsing, since the default size gets calculated depending on the number or processors found. Gate all per-processor logging behind a new "acpi=verbose", making sure we wouldn't unintentionally pass this on to Dom0. Signed-off-by:
-
Jan Beulich authored
Global vIRQ-s have their event channel association tracked on vCPU 0. Per-vCPU vIRQ-s can't have their notify_vcpu_id changed. Hence it is well-known which vCPU's virq_to_evtchn[] needs updating. Signed-off-by:
-
Jan Beulich authored
While there don't look to be any problems with this right now, the lock order implications from holding the lock can be very difficult to follow (and may be easy to violate unknowingly). The present callbacks don't (and no such callback should) have any need for the lock to be held. Signed-off-by:
-
Jan Beulich authored
At least from an abstract perspective it is quite odd for us to compare adjusted old and unadjusted new page table entries when determining whether the fast path can be used. This is largely benign because FASTPATH_FLAG_WHITELIST covers most of the flags which the adjustments may set, and the flags getting set don't affect the outcome of get_page_from_l<N>e(). There's one exception: 32-bit L3 entries get _PAGE_RW set, but get_page_from_l3e() doesn't allow linear page tables to be created at this level for such guests. Apart from this _PAGE_RW is unused by get_page_from_l<N>e() (for N > 1), and hence forcing the bit on early has no functional effect. The main reason for the change, however, is that adjust_guest_l<N>e() aren't exactly cheap - both in terms of pure code size and because each one has at least one evaluate_nospec() by way of containing is_pv_32bit_domain() conditionals. Call the functions once ahead of the fast path checks, instead of twice after. Signed-off-by:
-
Jan Beulich authored
Commit 8a74707a ("x86/nospec: Use always_inline to fix code gen for evaluate_nospec") converted inline to always_inline for adjust_guest_l[134]e(), but left adjust_guest_l2e() and unadjust_guest_l3e() alone without saying why these two would differ in the needed / wanted treatment. Adjust these two as well. Signed-off-by:
-
