As documented in issue C215 in the known issues list for DDI0487I.a [1] Arm
will be making a retroactive change to SVE to remove the possibility of
selecting non power of two vector lengths. This has no impact on existing
physical implementations but most virtual implementations have implemented
the full range of permissible vector lengths. Given how demanding fp-stress
is for these implementations update to only attempt to enumerate the power
of two vector lengths, reducing the load created on existing virtual
implementations and only exercising the functionality that will be seen in
physical implementations.
[1] https://developer.arm.com/documentation/102105/ia-00/
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
tools/testing/selftests/arm64/fp/fp-stress.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/arm64/fp/fp-stress.c b/tools/testing/selftests/arm64/fp/fp-stress.c
index f8b2f41aac36..2b95f9451b1b 100644
--- a/tools/testing/selftests/arm64/fp/fp-stress.c
+++ b/tools/testing/selftests/arm64/fp/fp-stress.c
@@ -377,7 +377,7 @@ static void probe_vls(int vls[], int *vl_count, int set_vl)
*vl_count = 0;
- for (vq = SVE_VQ_MAX; vq > 0; --vq) {
+ for (vq = SVE_VQ_MAX; vq > 0; vq /= 2) {
vl = prctl(set_vl, vq * 16);
if (vl == -1)
ksft_exit_fail_msg("SET_VL failed: %s (%d)\n",
@@ -385,6 +385,9 @@ static void probe_vls(int vls[], int *vl_count, int set_vl)
vl &= PR_SVE_VL_LEN_MASK;
+ if (*vl_count && (vl == vls[*vl_count - 1]))
+ break;
+
vq = sve_vq_from_vl(vl);
vls[*vl_count] = vl;
---
base-commit: 1b929c02afd37871d5afb9d498426f83432e71c2
change-id: 20221220-arm64-fp-stress-pow2-b81ee6471492
Best regards,
--
Mark Brown <broonie(a)kernel.org>
The first patch here is a fix which should ideally be sent as such,
currently the program will hang on architecturally valid systems which
implement SME but not 128 bit vector lengths. The remaining patches
are general enhancements, including coverage for the SME ABI on SME only
systems.
To: Catalin Marinas <catalin.marinas(a)arm.com>
To: Will Deacon <will(a)kernel.org>
To: Shuah Khan <shuah(a)kernel.org>
Cc: Shuah Khan <skhan(a)linuxfoundation.org>
Cc: linux-arm-kernel(a)lists.infradead.org
Cc: linux-kselftest(a)vger.kernel.org
Cc: linux-kernel(a)vger.kernel.org
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
Mark Brown (4):
kselftest/arm64: Fix syscall-abi for systems without 128 bit SME
kselftest/arm64: Only enumerate VLs once in syscall-abi
kselftest/arm64: Verify SME only ABI in syscall-abi
kselftest/arm64: Only enumerate power of two VLs in syscall-abi
.../testing/selftests/arm64/abi/syscall-abi-asm.S | 14 ++-
tools/testing/selftests/arm64/abi/syscall-abi.c | 133 +++++++++++++--------
2 files changed, 89 insertions(+), 58 deletions(-)
---
base-commit: 1b929c02afd37871d5afb9d498426f83432e71c2
change-id: 20221223-arm64-syscall-abi-sme-only-c3bb2c0f81e5
Best regards,
--
Mark Brown <broonie(a)kernel.org>
Confidential VMs(CVMs) need to execute hypercall instruction as per the CPU
type. Normally KVM emulates the vmcall/vmmcall instruction by patching
the guest code at runtime. Such a guest memory manipulation by KVM is
not allowed with CVMs and is also undesirable in general.
This series adds support of executing hypercall as per the host cpu
type queried using cpuid instruction. CPU vendor type is stored early
during selftest setup and guest setup to be reused later.
Changes in v4:
1) Incoporated suggestions from Sean -
* Added APIs to query host cpu type
* Shared the host cpu type with guests to avoid querying the cpu type
again
* Modified kvm_hypercall to execute vmcall/vmmcall according to host
cpu type.
2) Dropped the separate API for kvm_hypercall.
v3:
https://lore.kernel.org/lkml/20221222230458.3828342-1-vannapurve@google.com/
Vishal Annapurve (4):
KVM: selftests: x86: use this_cpu_* helpers
KVM: selftests: x86: Add variables to store cpu type
KVM: sefltests: x86: Replace is_*cpu with is_host_*cpu
KVM: selftests: x86: Invoke kvm hypercall as per host cpu
.../selftests/kvm/include/x86_64/processor.h | 26 ++++++++++-
.../selftests/kvm/lib/x86_64/processor.c | 44 ++++++++++---------
.../selftests/kvm/x86_64/fix_hypercall_test.c | 4 +-
.../selftests/kvm/x86_64/mmio_warning_test.c | 2 +-
.../kvm/x86_64/pmu_event_filter_test.c | 4 +-
.../vmx_exception_with_invalid_guest_state.c | 2 +-
6 files changed, 54 insertions(+), 28 deletions(-)
--
2.39.0.314.g84b9a713c41-goog
[
This has been in linux-next for a little while now, and we've completed
the syzkaller run. 1300 hours of CPU time have been invested since the
last report with no improvement in coverage or new detections. syzkaller
coverage reached 69%(75%), and review of the misses show substantial
amounts are WARN_ON's and other debugging which are not expected to be
covered.
]
iommufd is the user API to control the IOMMU subsystem as it relates to
managing IO page tables that point at user space memory.
It takes over from drivers/vfio/vfio_iommu_type1.c (aka the VFIO
container) which is the VFIO specific interface for a similar idea.
We see a broad need for extended features, some being highly IOMMU device
specific:
- Binding iommu_domain's to PASID/SSID
- Userspace IO page tables, for ARM, x86 and S390
- Kernel bypassed invalidation of user page tables
- Re-use of the KVM page table in the IOMMU
- Dirty page tracking in the IOMMU
- Runtime Increase/Decrease of IOPTE size
- PRI support with faults resolved in userspace
Many of these HW features exist to support VM use cases - for instance the
combination of PASID, PRI and Userspace IO Page Tables allows an
implementation of DMA Shared Virtual Addressing (vSVA) within a
guest. Dirty tracking enables VM live migration with SRIOV devices and
PASID support allow creating "scalable IOV" devices, among other things.
As these features are fundamental to a VM platform they need to be
uniformly exposed to all the driver families that do DMA into VMs, which
is currently VFIO and VDPA.
The pre-v1 series proposed re-using the VFIO type 1 data structure,
however it was suggested that if we are doing this big update then we
should also come with an improved data structure that solves the
limitations that VFIO type1 has. Notably this addresses:
- Multiple IOAS/'containers' and multiple domains inside a single FD
- Single-pin operation no matter how many domains and containers use
a page
- A fine grained locking scheme supporting user managed concurrency for
multi-threaded map/unmap
- A pre-registration mechanism to optimize vIOMMU use cases by
pre-pinning pages
- Extended ioctl API that can manage these new objects and exposes
domains directly to user space
- domains are sharable between subsystems, eg VFIO and VDPA
The bulk of this code is a new data structure design to track how the
IOVAs are mapped to PFNs.
iommufd intends to be general and consumable by any driver that wants to
DMA to userspace. From a driver perspective it can largely be dropped in
in-place of iommu_attach_device() and provides a uniform full feature set
to all consumers.
As this is a larger project this series is the first step. This series
provides the iommfd "generic interface" which is designed to be suitable
for applications like DPDK and VMM flows that are not optimized to
specific HW scenarios. It is close to being a drop in replacement for the
existing VFIO type 1 and supports existing qemu based VM flows.
Several follow-on series are being prepared:
- Patches integrating with qemu in native mode:
https://github.com/yiliu1765/qemu/commits/qemu-iommufd-6.0-rc2
- A completed integration with VFIO now exists that covers "emulated" mdev
use cases now, and can pass testing with qemu/etc in compatability mode:
https://github.com/jgunthorpe/linux/commits/vfio_iommufd
- A draft providing system iommu dirty tracking on top of iommufd,
including iommu driver implementations:
https://github.com/jpemartins/linux/commits/x86-iommufd
This pairs with patches for providing a similar API to support VFIO-device
tracking to give a complete vfio solution:
https://lore.kernel.org/kvm/20220901093853.60194-1-yishaih@nvidia.com/
- Userspace page tables aka 'nested translation' for ARM and Intel iommu
drivers:
https://github.com/nicolinc/iommufd/commits/iommufd_nesting
- "device centric" vfio series to expose the vfio_device FD directly as a
normal cdev, and provide an extended API allowing dynamically changing
the IOAS binding:
https://github.com/yiliu1765/iommufd/commits/iommufd-v6.0-rc2-nesting-0901
- Drafts for PASID and PRI interfaces are included above as well
Overall enough work is done now to show the merit of the new API design
and at least draft solutions to many of the main problems.
Several people have contributed directly to this work: Eric Auger, Joao
Martins, Kevin Tian, Lu Baolu, Nicolin Chen, Yi L Liu. Many more have
participated in the discussions that lead here, and provided ideas. Thanks
to all!
The v1/v2 iommufd series has been used to guide a large amount of preparatory
work that has now been merged. The general theme is to organize things in
a way that makes injecting iommufd natural:
- VFIO live migration support with mlx5 and hisi_acc drivers.
These series need a dirty tracking solution to be really usable.
https://lore.kernel.org/kvm/20220224142024.147653-1-yishaih@nvidia.com/https://lore.kernel.org/kvm/20220308184902.2242-1-shameerali.kolothum.thodi…
- Significantly rework the VFIO gvt mdev and remove struct
mdev_parent_ops
https://lore.kernel.org/lkml/20220411141403.86980-1-hch@lst.de/
- Rework how PCIe no-snoop blocking works
https://lore.kernel.org/kvm/0-v3-2cf356649677+a32-intel_no_snoop_jgg@nvidia…
- Consolidate dma ownership into the iommu core code
https://lore.kernel.org/linux-iommu/20220418005000.897664-1-baolu.lu@linux.…
- Make all vfio driver interfaces use struct vfio_device consistently
https://lore.kernel.org/kvm/0-v4-8045e76bf00b+13d-vfio_mdev_no_group_jgg@nv…
- Remove the vfio_group from the kvm/vfio interface
https://lore.kernel.org/kvm/0-v3-f7729924a7ea+25e33-vfio_kvm_no_group_jgg@n…
- Simplify locking in vfio
https://lore.kernel.org/kvm/0-v2-d035a1842d81+1bf-vfio_group_locking_jgg@nv…
- Remove the vfio notifiter scheme that faces drivers
https://lore.kernel.org/kvm/0-v4-681e038e30fd+78-vfio_unmap_notif_jgg@nvidi…
- Improve the driver facing API for vfio pin/unpin pages to make the
presence of struct page clear
https://lore.kernel.org/kvm/20220723020256.30081-1-nicolinc@nvidia.com/
- Clean up in the Intel IOMMU driver
https://lore.kernel.org/linux-iommu/20220301020159.633356-1-baolu.lu@linux.…https://lore.kernel.org/linux-iommu/20220510023407.2759143-1-baolu.lu@linux…https://lore.kernel.org/linux-iommu/20220514014322.2927339-1-baolu.lu@linux…https://lore.kernel.org/linux-iommu/20220706025524.2904370-1-baolu.lu@linux…https://lore.kernel.org/linux-iommu/20220702015610.2849494-1-baolu.lu@linux…
- Rework s390 vfio drivers
https://lore.kernel.org/kvm/20220707135737.720765-1-farman@linux.ibm.com/
- Normalize vfio ioctl handling
https://lore.kernel.org/kvm/0-v2-0f9e632d54fb+d6-vfio_ioctl_split_jgg@nvidi…
- VFIO API for dirty tracking (aka dma logging) managed inside a PCI
device, with mlx5 implementation
https://lore.kernel.org/kvm/20220901093853.60194-1-yishaih@nvidia.com
- Introduce a struct device sysfs presence for struct vfio_device
https://lore.kernel.org/kvm/20220901143747.32858-1-kevin.tian@intel.com/
- Complete restructuring the vfio mdev model
https://lore.kernel.org/kvm/20220822062208.152745-1-hch@lst.de/
- Isolate VFIO container code in preperation for iommufd to provide an
alternative implementation of it all
https://lore.kernel.org/kvm/0-v1-a805b607f1fb+17b-vfio_container_split_jgg@…
- Simplify and consolidate iommu_domain/device compatability checking
https://lore.kernel.org/linux-iommu/cover.1666042872.git.nicolinc@nvidia.co…
- Align iommu SVA support with the domain-centric model
https://lore.kernel.org/all/20221031005917.45690-1-baolu.lu@linux.intel.com/
This is about 233 patches applied since March, thank you to everyone
involved in all this work!
Currently there are a number of supporting series still in progress:
- DMABUF exporter support for VFIO to allow PCI P2P with VFIO
https://lore.kernel.org/r/0-v2-472615b3877e+28f7-vfio_dma_buf_jgg@nvidia.com
- Start to provide iommu_domain ops for POWER
https://lore.kernel.org/all/20220714081822.3717693-1-aik@ozlabs.ru/
However, these are not necessary for this series to advance.
This is on github: https://github.com/jgunthorpe/linux/commits/iommufd
v4:
- Rebase to v6.1-rc3, include the iommu branch with the needed EINVAL
patch series and also the SVA rework
- All bug fixes and comments with no API or behavioral changes
- gvt tests are passing again
- Syzkaller is no longer finding issues and achieved high coverage of
69%(75%)
- Coverity has been run by two people
- new "nth failure" test that systematically sweeps all error unwind paths
looking for splats
- All fixes noted in the mailing list
If you sent an email and I didn't reply please ping it, I have lost it.
- The selftest patch has been broken into three to make the additional
modification to the main code clearer
- The interdiff is 1.8k lines for the main code, with another 3k of
test suite changes
v3: https://lore.kernel.org/r/0-v3-402a7d6459de+24b-iommufd_jgg@nvidia.com
- Rebase to v6.1-rc1
- Improve documentation
- Use EXPORT_SYMBOL_NS
- Fix W1, checkpatch stuff
- Revise pages.c to resolve the FIXMEs. Create a
interval_tree_double_span_iter which allows a simple expression of the
previously problematic algorithms
- Consistently use the word 'access' instead of user to refer to an
access from an in-kernel user (eg vfio mdev)
- Support two forms of rlimit accounting and make the vfio compatible one
the default in compatability mode (following series)
- Support old VFIO type1 by disabling huge pages and implementing a
simple algorithm to split a struct iopt_area
- Full implementation of access support, test coverage and optimizations
- Complete COPY to be able to copy across contiguous areas. Improve
all the algorithms around contiguous areas with a dedicated iterator
- Functional ENFORCED_COHERENT support
- Support multi-device groups
- Lots of smaller changes (the interdiff is 5k lines)
v2: https://lore.kernel.org/r/0-v2-f9436d0bde78+4bb-iommufd_jgg@nvidia.com
- Rebase to v6.0-rc3
- Improve comments
- Change to an iterative destruction approach to avoid cycles
- Near rewrite of the vfio facing implementation, supported by a complete
implementation on the vfio side
- New IOMMU_IOAS_ALLOW_IOVAS API as discussed. Allows userspace to
assert that ranges of IOVA must always be mappable. To be used by a VMM
that has promised a guest a certain availability of IOVA. May help
guide PPC's multi-window implementation.
- Rework how unmap_iova works, user can unmap the whole ioas now
- The no-snoop / wbinvd support is implemented
- Bug fixes
- Test suite improvements
- Lots of smaller changes (the interdiff is 3k lines)
v1: https://lore.kernel.org/r/0-v1-e79cd8d168e8+6-iommufd_jgg@nvidia.com
Jason Gunthorpe (15):
iommu: Add IOMMU_CAP_ENFORCE_CACHE_COHERENCY
interval-tree: Add a utility to iterate over spans in an interval tree
iommufd: File descriptor, context, kconfig and makefiles
kernel/user: Allow user::locked_vm to be usable for iommufd
iommufd: PFN handling for iopt_pages
iommufd: Algorithms for PFN storage
iommufd: Data structure to provide IOVA to PFN mapping
iommufd: IOCTLs for the io_pagetable
iommufd: Add a HW pagetable object
iommufd: Add kAPI toward external drivers for physical devices
iommufd: Add kAPI toward external drivers for kernel access
iommufd: vfio container FD ioctl compatibility
iommufd: Add a selftest
iommufd: Add some fault injection points
iommufd: Add additional invariant assertions
Kevin Tian (1):
iommufd: Document overview of iommufd
Lu Baolu (1):
iommu: Add device-centric DMA ownership interfaces
.clang-format | 3 +
Documentation/userspace-api/index.rst | 1 +
.../userspace-api/ioctl/ioctl-number.rst | 1 +
Documentation/userspace-api/iommufd.rst | 222 ++
MAINTAINERS | 12 +
drivers/iommu/Kconfig | 1 +
drivers/iommu/Makefile | 2 +-
drivers/iommu/amd/iommu.c | 2 +
drivers/iommu/intel/iommu.c | 16 +-
drivers/iommu/iommu.c | 124 +-
drivers/iommu/iommufd/Kconfig | 23 +
drivers/iommu/iommufd/Makefile | 13 +
drivers/iommu/iommufd/device.c | 748 +++++++
drivers/iommu/iommufd/double_span.h | 98 +
drivers/iommu/iommufd/hw_pagetable.c | 57 +
drivers/iommu/iommufd/io_pagetable.c | 1214 +++++++++++
drivers/iommu/iommufd/io_pagetable.h | 241 +++
drivers/iommu/iommufd/ioas.c | 390 ++++
drivers/iommu/iommufd/iommufd_private.h | 307 +++
drivers/iommu/iommufd/iommufd_test.h | 93 +
drivers/iommu/iommufd/main.c | 419 ++++
drivers/iommu/iommufd/pages.c | 1884 +++++++++++++++++
drivers/iommu/iommufd/selftest.c | 853 ++++++++
drivers/iommu/iommufd/vfio_compat.c | 452 ++++
include/linux/interval_tree.h | 58 +
include/linux/iommu.h | 17 +
include/linux/iommufd.h | 102 +
include/linux/sched/user.h | 2 +-
include/uapi/linux/iommufd.h | 332 +++
kernel/user.c | 1 +
lib/Kconfig | 4 +
lib/interval_tree.c | 132 ++
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/iommu/.gitignore | 3 +
tools/testing/selftests/iommu/Makefile | 12 +
tools/testing/selftests/iommu/config | 2 +
tools/testing/selftests/iommu/iommufd.c | 1627 ++++++++++++++
.../selftests/iommu/iommufd_fail_nth.c | 580 +++++
tools/testing/selftests/iommu/iommufd_utils.h | 278 +++
39 files changed, 10294 insertions(+), 33 deletions(-)
create mode 100644 Documentation/userspace-api/iommufd.rst
create mode 100644 drivers/iommu/iommufd/Kconfig
create mode 100644 drivers/iommu/iommufd/Makefile
create mode 100644 drivers/iommu/iommufd/device.c
create mode 100644 drivers/iommu/iommufd/double_span.h
create mode 100644 drivers/iommu/iommufd/hw_pagetable.c
create mode 100644 drivers/iommu/iommufd/io_pagetable.c
create mode 100644 drivers/iommu/iommufd/io_pagetable.h
create mode 100644 drivers/iommu/iommufd/ioas.c
create mode 100644 drivers/iommu/iommufd/iommufd_private.h
create mode 100644 drivers/iommu/iommufd/iommufd_test.h
create mode 100644 drivers/iommu/iommufd/main.c
create mode 100644 drivers/iommu/iommufd/pages.c
create mode 100644 drivers/iommu/iommufd/selftest.c
create mode 100644 drivers/iommu/iommufd/vfio_compat.c
create mode 100644 include/linux/iommufd.h
create mode 100644 include/uapi/linux/iommufd.h
create mode 100644 tools/testing/selftests/iommu/.gitignore
create mode 100644 tools/testing/selftests/iommu/Makefile
create mode 100644 tools/testing/selftests/iommu/config
create mode 100644 tools/testing/selftests/iommu/iommufd.c
create mode 100644 tools/testing/selftests/iommu/iommufd_fail_nth.c
create mode 100644 tools/testing/selftests/iommu/iommufd_utils.h
base-commit: 69e61edebea030f177de7a23b8d5d9b8c4a90bda
--
2.38.1
Since [1] the user-space program dma_map_benchmark shares the header file
linux/map_benchmark.h with the kernel driver in kernel/dma/map_benchmark.c.
With latest kernel version this does not compile any more.
While https://kernelnewbies.org/KernelHeaders suggests otherwise, allow it
to use of kernel headers through the uapi/ include direcotry. I assume we can
do so safely, since the controlling user-space program is distributed with
the kernel.
With this change dma_map_benchmark compiles with just the obvious warning
about uapi usage on ARCH=x86 and s390 and runs on ARCH=s390.
[1] commit 8ddde07a3d28 ("dma-mapping: benchmark: extract a common header file for map_benchmark definition")
Signed-off-by: Gerd Bayer <gbayer(a)linux.ibm.com>
---
tools/testing/selftests/dma/dma_map_benchmark.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/dma/dma_map_benchmark.c b/tools/testing/selftests/dma/dma_map_benchmark.c
index 5c997f17fcbd..d49d7ea6a63e 100644
--- a/tools/testing/selftests/dma/dma_map_benchmark.c
+++ b/tools/testing/selftests/dma/dma_map_benchmark.c
@@ -10,7 +10,7 @@
#include <unistd.h>
#include <sys/ioctl.h>
#include <sys/mman.h>
-#include <linux/types.h>
+#include <uapi/linux/types.h>
#include <linux/map_benchmark.h>
#define NSEC_PER_MSEC 1000000L
base-commit: 8abacb3356e68261ccd3a2ad74ed6042363e5d0f
--
2.38.1
From: Ammar Faizi <ammarfaizi2(a)gnuweeb.org>
Hi,
This series adds signal handling support to the nolibc subsystem.
1) Initial implementation of nolibc sigaction(2) function.
Currently, this implementation is only available on the x86-64 arch.
sigaction() needs an architecture-dependent "signal trampoline"
function that invokes the __rt_sigreturn syscall to resume the process
after a signal gets handled.
On Linux x86-64, the "signal trampoline" function has to be written in
inline Assembly to prevent the compiler from controlling the %rsp
(e.g., with -fno-omit-frame-pointer, every function has a pushq
%rbp that makes the %rsp no longer point to struct rt_sigframe).
The "signal trampoline" function is called __arch_restore_rt in this
implementation.
2) signal(2) function.
signal() function is the simpler version of sigaction(). Unlike
sigaction(), which fully controls the struct sigaction, the caller
only cares about the sa_handler when calling the signal() function.
signal() internally calls sigaction(). This implementation is
currently only available on the x86-64 arch. When the sigaction()
function support is expanded to other architectures, this function
will automatically support those architectures. It's basically just
a sigaction() wrapper.
3) Extra nolibc updates.
Apart from the signal handling support. This series also contains
nolibc updates, they are:
- getpagesize() support.
- CFLAGS update.
- fork(2) selftest.
- sigaction(2) selftest.
- signal(2) selftest.
- getpagesize(2) selftest.
There 8 patches in this series. It has been tested on Linux x86-64 arch
and all tests OK.
$ sudo ./nolibc-test
Running test 'syscall'
...
...
66 wait_child = -1 ECHILD [OK]
67 waitpid_min = -1 ESRCH [OK]
68 waitpid_child = -1 ECHILD [OK]
69 write_badf = -1 EBADF [OK]
70 write_zero = 0 [OK]
Errors during this test: 0
Running test 'stdlib'
...
...
14 memcmp_60_20 = 64 [OK]
15 memcmp_20_e0 = -192 [OK]
16 memcmp_e0_20 = 192 [OK]
17 memcmp_80_e0 = -96 [OK]
18 memcmp_e0_80 = 96 [OK]
Errors during this test: 0
Total number of errors: 0
Exiting with status 0
$ make run -j8
Kernel: arch/x86/boot/bzImage is ready (#3)
...
82 test(s) passed.
Signed-off-by: Ammar Faizi <ammarfaizi2(a)gnuweeb.org>
---
It's also available in the Git repository.
The following changes since commit caf5c36025ec9395c8d7c78957b016a284812d23:
srcu: Update comment after the index flip (2022-12-21 09:01:53 -0800)
are available in the Git repository at:
https://github.com/ammarfaizi2/linux-block testing/rfc.v1.2022-12-22.nolibc
for you to fetch changes up to ac79aca684125907bfbefadfd6c6be0ccdfe8b33:
selftests/nolibc: Add `getpagesize(2)` selftest (2022-12-22 09:57:31 +0700)
----------------------------------------------------------------
Ammar Faizi (8):
nolibc/sys: Implement `sigaction(2)` function
nolibc/sys: Implement `signal(2)` function
nolibc/sys: Implement `getpagesize(2)` function
selftests/nolibc: Add `-Wall` and `-Wno-unsed-function` to the CFLAGS
selftests/nolibc: Add `fork(2)` selftest
selftests/nolibc: Add `sigaction(2)` selftest
selftests/nolibc: Add `signal(2)` selftest
selftests/nolibc: Add `getpagesize(2)` selftest
tools/include/nolibc/arch-x86_64.h | 12 +
tools/include/nolibc/sys.h | 224 +++++++++++++++++++
tools/testing/selftests/nolibc/Makefile | 2 +-
tools/testing/selftests/nolibc/nolibc-test.c | 219 +++++++++++++++++-
4 files changed, 454 insertions(+), 3 deletions(-)
base-commit: caf5c36025ec9395c8d7c78957b016a284812d23
--
Ammar Faizi