On 2024/9/4 9:44 AM, Joseph Jang wrote:
Validate there are no duplicate hwirq from the irq debug
file system /sys/kernel/debug/irq/irqs/* per chip name.
One example log show 2 duplicated hwirq in the irq debug
file system.
$ sudo cat /sys/kernel/debug/irq/irqs/163
handler: handle_fasteoi_ir
On 2024/6/24 9:43 AM, Joseph Jang wrote:
On 2024/6/21 3:36 AM, Alexandre Belloni wrote:
On 23/05/2024 18:38:06-0700, Joseph Jang wrote:
In alarm_wkalm_set and alarm_wkalm_set_minute test, they use different
ioctl (RTC_ALM_SET/RTC_WKALM_SET) for alarm feature detection. They will
skip testi
On 2024/9/25 3:57 AM, Shuah Khan wrote:
On 9/24/24 13:31, Alexandre Belloni wrote:
Hello,
On 24/09/2024 10:05:43-0600, Shuah Khan wrote:
On 9/23/24 23:37, Joseph Jang wrote:
Hi Alexandre,
Thank you for looking at the rtc patch.
I saw you Acked the [PATCH 2/2], not sure when could we see t
The resctrl selftests drop the results from every first test run
to avoid (per comment) "inaccurate due to monitoring setup transition
phase" data. Previously inaccurate data resulted from workloads needing
some time to "settle" and also the measurements themselves to
account for earlier measuremen
The Memory Bandwidth Allocation (MBA) test iterates through all possible
MBA allocations, from 10% (ALLOCATION_MIN) to 100% (ALLOCATION_MAX) with
increments of 10% (ALLOCATION_STEP) at each iteration. During each
iteration the test measures the actual memory bandwidth NUM_OF_RUNS times
to determine
The MBA test incrementally throttles memory bandwidth, each time
followed by a comparison between the memory bandwidth observed
by the performance counters and resctrl respectively.
While a comparison between performance counters and resctrl is
generally appropriate, they do not have an identical
The CMT, MBA, and MBM tests rely on the resctrl_val() wrapper to
start and run a benchmark while providing test specific flows
via callbacks to do test specific configuration and measurements.
At a high level, the resctrl_val() flow is:
a) Start by fork()ing a child process that installs a
By default the MBM and MBA tests use the "fill_buf" benchmark to
read from a buffer with the goal to measure the memory bandwidth
generated by this buffer access.
Care should be taken when sizing the buffer used by the "fill_buf"
benchmark. If the buffer is small enough to fit in the cache then
it
The benchmark used during the CMT, MBM, and MBA tests can be provided by
the user via (-b) parameter, if not provided the default "fill_buf"
benchmark is used. The user is additionally able to override
any of the "fill_buf" default parameters when running the tests with
"-b fill_buf ".
The "fill_b
The CMT, MBM, and MBA tests rely on a benchmark to generate
memory traffic. By default this is the "fill_buf" benchmark that
can be replaced via the "-b" command line argument.
The original intent of the "-b" command line parameter was
to replace the default "fill_buf" benchmark, but the implement
The MBM and MBA resctrl selftests run a benchmark during which
it takes measurements of read memory bandwidth via perf.
Code exists to support measurements of write memory bandwidth
but there exists no path with which this code can execute.
While code exists for write memory bandwidth measurement
The CMT, MBM, and MBA tests rely on a benchmark that runs while
the test makes changes to needed configuration (for example memory
bandwidth allocation) and takes needed measurements. By default
the "fill_buf" benchmark is used and by default (via its
"once = false" setting) "fill_buf" is configure
Within mba_setup() the programmed bandwidth delay value starts
at the maximum (100, or rather ALLOCATION_MAX) and progresses
towards ALLOCATION_MIN by decrementing with ALLOCATION_STEP.
The programmed bandwidth delay should never be negative, so
representing it with an unsigned int is most appropr
resctrl selftests discover system properties via a variety of sysfs files.
The MBM and MBA tests need to discover the event and umask with which to
configure the performance event used to measure read memory bandwidth.
This is done by parsing the contents of
/sys/bus/event_source/devices/uncore_imc
alloc_buffer() allocates and initializes (with random data) a
buffer of requested size. The initialization starts from the beginning
of the allocated buffer and incrementally assigns sizeof(uint64_t) random
data to each cache line. The initialization uses the size of the
buffer to control the initi
The MBM and MBA tests need to discover the event and umask with which to
configure the performance event used to measure read memory bandwidth.
This is done by parsing the
/sys/bus/event_source/devices/uncore_imc_/events/cas_count_read
file for each iMC instance that contains the formatted
output:
By default the MBM test uses the "fill_buf" benchmark to keep reading
from a buffer with size DEFAULT_SPAN while measuring memory bandwidth.
User space can provide an alternate benchmark or amend the size of
the buffer "fill_buf" should use.
Analysis of the MBM measurements do not require that a b
Fix following sparse warnings:
tools/testing/selftests/resctrl/resctrl_val.c:47:6: warning: symbol
'membw_initialize_perf_event_attr' was not declared. Should it be static?
tools/testing/selftests/resctrl/resctrl_val.c:64:6: warning: symbol
'membw_ioctl_perf_event_ioc_reset_enable' was not decl
Changes since V2:
- V2:
https://lore.kernel.org/all/cover.1726164080.git.reinette.cha...@intel.com/
- Add fix to protect against buffer overflow when parsing text from sysfs files.
- Add cleanup patch to address use of magic constants as pointed out by
Ilpo.
- Add Reviewed-by tags where received
> On Oct 17, 2024, at 5:55 PM, Stanislav Fomichev wrote:
>
> On 10/18, Anjali Kulkarni wrote:
>>
>>
>>> On Oct 17, 2024, at 5:13 PM, Stanislav Fomichev
>>> wrote:
>>>
>>> On 10/17, Anjali Kulkarni wrote:
Kunit tests to test hash table add, delete, duplicate add and delete.
Add fo
On 10/18, Anjali Kulkarni wrote:
>
>
> > On Oct 17, 2024, at 5:13 PM, Stanislav Fomichev
> > wrote:
> >
> > On 10/17, Anjali Kulkarni wrote:
> >> Kunit tests to test hash table add, delete, duplicate add and delete.
> >> Add following configs and compile kernel code:
> >>
> >> CONFIG_CONNECTO
> On Oct 17, 2024, at 5:13 PM, Stanislav Fomichev wrote:
>
> On 10/17, Anjali Kulkarni wrote:
>> Kunit tests to test hash table add, delete, duplicate add and delete.
>> Add following configs and compile kernel code:
>>
>> CONFIG_CONNECTOR=y
>> CONFIG_PROC_EVENTS=y
>> CONFIG_NET=y
>> CONFIG_KU
On 10/17, Anjali Kulkarni wrote:
> Kunit tests to test hash table add, delete, duplicate add and delete.
> Add following configs and compile kernel code:
>
> CONFIG_CONNECTOR=y
> CONFIG_PROC_EVENTS=y
> CONFIG_NET=y
> CONFIG_KUNIT=m
> CONFIG_CN_HASH_KUNIT_TEST=m
>
> To run kunit tests:
> sudo modp
Patrick Roy writes:
> On Tue, 2024-10-08 at 20:56 +0100, Sean Christopherson wrote:
>> On Tue, Oct 08, 2024, Ackerley Tng wrote:
>>> Patrick Roy writes:
For the "non-CoCo with direct map entries removed" VMs that we at AWS
are going for, we'd like a VM type with host-controlled in-plac
On Wed, Oct 16, 2024 at 07:24:09PM +0530, Balaji Pothunoori wrote:
> auto_boot flag ensures to take the firmware and boots it
> up during the wpss remoteproc start.
> wpss host driver would like to control the load and unload
> of the firmware during the load and unload of the driver.
> Hence, disa
On 10/17/24 3:11 PM, Shuah Khan wrote:
On 10/17/24 15:45, John Hubbard wrote:
On 10/17/24 2:05 PM, Lorenzo Stoakes wrote:
Conflicts can arise between system fcntl.h and linux/fcntl.h, imported by
the linux/pidfd.h UAPI header.
Work around this by adding a wrapper for linux/pidfd.h to
tools/inc
On 10/17/24 15:45, John Hubbard wrote:
On 10/17/24 2:05 PM, Lorenzo Stoakes wrote:
Conflicts can arise between system fcntl.h and linux/fcntl.h, imported by
the linux/pidfd.h UAPI header.
Work around this by adding a wrapper for linux/pidfd.h to
tools/include/ which sets the linux/fcntl.h heade
On 10/17/24 2:05 PM, Lorenzo Stoakes wrote:
Conflicts can arise between system fcntl.h and linux/fcntl.h, imported by
the linux/pidfd.h UAPI header.
Work around this by adding a wrapper for linux/pidfd.h to
tools/include/ which sets the linux/fcntl.h header guard ahead of
importing the pidfd.h h
On 10/17/24 05:27, Antonio Quartulli wrote:
On 16/10/2024 23:14, Shuah Khan wrote:
On 10/15/24 19:03, Antonio Quartulli wrote:
The ovpn-cli tool can be compiled and used as selftest for the ovpn
kernel module.
It implements the netlink API and can thus be integrated in any
script for more auto
The new option controls tests run on boot or module load. With the new
debugfs "run" dentry allowing to run tests on demand, an ability to disable
automatic tests run becomes a useful option in case of intrusive tests.
The option is set to true by default to preserve the existent behavior. It
can
On 10.10.2024 8:59 AM, neil.armstr...@linaro.org wrote:
> Hi,
>
> On 07/10/2024 16:37, Mukesh Ojha wrote:
>> On Mon, Oct 07, 2024 at 10:08:16AM +0200, neil.armstr...@linaro.org wrote:
>>> On 04/10/2024 23:23, Mukesh Ojha wrote:
From: Shiraz Hashim
Qualcomm SoCs runnning with Qualco
Add tests to assert that PIDFD_SELF_* correctly refers to the current
thread and process.
This is only practically meaningful to pidfd_send_signal() and
pidfd_getfd(), but also explicitly test that we disallow this feature for
setns() where it would make no sense.
We cannot reasonably wait on our
Conflicts can arise between system fcntl.h and linux/fcntl.h, imported by
the linux/pidfd.h UAPI header.
Work around this by adding a wrapper for linux/pidfd.h to
tools/include/ which sets the linux/fcntl.h header guard ahead of
importing the pidfd.h header file.
Adjust the pidfd selftests Makefi
The means by which a pid is determined from a pidfd is duplicated, with
some callers holding a reference to the (pid)fd, and others explicitly
pinning the pid.
Introduce __pidfd_get_pid() which narrows this to one approach of pinning
the pid, with an optional output parameters for file->f_flags to
It is useful to be able to utilise the pidfd mechanism to reference the
current thread or process (from a userland point of view - thread group
leader from the kernel's point of view).
Therefore introduce PIDFD_SELF_THREAD to refer to the current thread, and
PIDFD_SELF_THREAD_GROUP to refer to the
If you wish to utilise a pidfd interface to refer to the current process or
thread it is rather cumbersome, requiring something like:
int pidfd = pidfd_open(getpid(), 0 or PIDFD_THREAD);
...
close(pidfd);
Or the equivalent call opening /proc/self. It is more convenient t
On 10/17/24 14:31, Thomas Weißschuh wrote:
Hi Shuah,
Oct 17, 2024 22:27:29 Shuah Khan :
On 10/14/24 05:36, Thomas Weißschuh wrote:
Add a basic config to run kunit tests on LoongArch.
This requires QEMU 9.1.0 or later for the necessary direct kernel boot
support.
Signed-off-by: Thomas Weißschu
Hi Shuah,
Oct 17, 2024 22:27:29 Shuah Khan :
> On 10/14/24 05:36, Thomas Weißschuh wrote:
>> Add a basic config to run kunit tests on LoongArch.
>> This requires QEMU 9.1.0 or later for the necessary direct kernel boot
>> support.
>> Signed-off-by: Thomas Weißschuh
>> ---
>> tools/testing/kuni
Hi Thomas,
On 10/14/24 05:36, Thomas Weißschuh wrote:
Add a basic config to run kunit tests on LoongArch.
This requires QEMU 9.1.0 or later for the necessary direct kernel boot
support.
Signed-off-by: Thomas Weißschuh
---
tools/testing/kunit/qemu_configs/loongarch.py | 16
]
[cannot apply to akpm-mm/mm-everything nf-next/master next-20241017]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
The test proves that a function that is being kprobed and uses a
post_handler cannot be livepatched.
Only one ftrace_ops with FTRACE_OPS_FL_IPMODIFY set may be registered
to any given function at a time.
Note that the conflicting kprobe could not be created using the
tracefs interface, see Docume
This naming makes more sense according to the directory structure.
Especially when we later add more paths.
Addtionally replace `/sys/kernel/livepatch` with `$SYSFS_KLP_DIR` in
the livepatch test files.
Signed-off-by: Michael Vetter
---
.../testing/selftests/livepatch/functions.sh | 16 ++-
Save the state of /sys/kernel/debug/kprobes/enabled
during setup_config() and restore it during cleanup().
This is in preparation for a future commit that will add a test
that should confirm that we cannot livepatch a kprobed function
if that kprobe has a post handler.
Signed-off-by: Michael Vett
Thanks for all the reviews.
V5:
Replace /sys/kernel/livepatch also in other/already existing tests.
Improve commit message of 3rd patch.
V4:
Use variable for /sys/kernel/debug.
Be consistent with "" around variables.
Fix path in commit message to /sys/kernel/debug/kprobes/enabled.
V3:
Save and r
On Thu, Oct 17, 2024 at 01:37:06PM -0600, Shuah Khan wrote:
> On 10/17/24 11:38, Lorenzo Stoakes wrote:
> > On Thu, Oct 17, 2024 at 10:37:00AM -0700, John Hubbard wrote:
> > > On 10/17/24 10:28 AM, Lorenzo Stoakes wrote:
> > > > On Thu, Oct 17, 2024 at 10:17:54AM -0700, John Hubbard wrote:
> > > >
On 10/17/24 11:38, Lorenzo Stoakes wrote:
On Thu, Oct 17, 2024 at 10:37:00AM -0700, John Hubbard wrote:
On 10/17/24 10:28 AM, Lorenzo Stoakes wrote:
On Thu, Oct 17, 2024 at 10:17:54AM -0700, John Hubbard wrote:
On 10/17/24 5:06 AM, Lorenzo Stoakes wrote:
...
#ifndef __TOOLS_LINUX_PID
On 17.10.24 21:18, Jason Gunthorpe wrote:
On Thu, Oct 17, 2024 at 03:11:10PM -0400, Peter Xu wrote:
On Thu, Oct 17, 2024 at 02:10:10PM -0300, Jason Gunthorpe wrote:
If so, maybe that's a non-issue for non-CoCo, where the VM object /
gmemfd object (when created) can have a flag marking that it's
On Thu, Oct 17, 2024 at 04:14:16PM -0300, Jason Gunthorpe wrote:
> On Wed, Oct 09, 2024 at 09:38:12AM -0700, Nicolin Chen wrote:
> > Following the previous vIOMMU series, this adds another vDEVICE structure,
> > representing the association from an iommufd_device to an iommufd_viommu.
> > This give
On Thu, Oct 17, 2024 at 03:11:10PM -0400, Peter Xu wrote:
> On Thu, Oct 17, 2024 at 02:10:10PM -0300, Jason Gunthorpe wrote:
> > > If so, maybe that's a non-issue for non-CoCo, where the VM object /
> > > gmemfd object (when created) can have a flag marking that it's
> > > always shared and can nev
On Wed, Oct 09, 2024 at 09:38:12AM -0700, Nicolin Chen wrote:
> Following the previous vIOMMU series, this adds another vDEVICE structure,
> representing the association from an iommufd_device to an iommufd_viommu.
> This gives the whole architecture a new "v" layer:
Don't thread series together l
On Wed, Oct 09, 2024 at 09:38:10AM -0700, Nicolin Chen wrote:
> With the introduction of the new object and its infrastructure, update the
> doc to reflect that and add a new graph.
>
> Signed-off-by: Nicolin Chen
> ---
> Documentation/userspace-api/iommufd.rst | 66 -
>
On Wed, Oct 09, 2024 at 09:38:25AM -0700, Nicolin Chen wrote:
> With the introduction of the new object and its infrastructure, update the
> doc and the vIOMMU graph to reflect that.
>
> Signed-off-by: Nicolin Chen
> ---
> Documentation/userspace-api/iommufd.rst | 58 ++---
>
On Thu, Oct 17, 2024 at 02:10:10PM -0300, Jason Gunthorpe wrote:
> > If so, maybe that's a non-issue for non-CoCo, where the VM object /
> > gmemfd object (when created) can have a flag marking that it's
> > always shared and can never be converted to private for any page
> > within.
>
> What is n
On Wed, Oct 09, 2024 at 09:38:21AM -0700, Nicolin Chen wrote:
> This avoids a bigger trouble of moving the struct iommufd_device to the
> public header.
>
> Signed-off-by: Nicolin Chen
> ---
> include/linux/iommufd.h| 7 +++
> drivers/iommu/iommufd/viommu_api.c | 7 +++
> 2 f
On Wed, Oct 09, 2024 at 09:38:19AM -0700, Nicolin Chen wrote:
> With a vIOMMU object, use space can flush any IOMMU related cache that can
> be directed using the vIOMMU object. It is similar to IOMMU_HWPT_INVALIDATE
> uAPI, but can cover a wider range than IOTLB, e.g. device/desciprtor cache.
>
>
On Wed, Oct 09, 2024 at 09:38:18AM -0700, Nicolin Chen wrote:
> Now cache entries for hwpt_nested can be invalidated via the vIOMMU's
> cache_invalidate op alternatively. Allow iommufd_hwpt_nested_alloc to
> support such a case.
>
> Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/iommufd/hw_pa
On Thu, Oct 17, 2024 at 11:50:44AM -0700, Nicolin Chen wrote:
> On Thu, Oct 17, 2024 at 03:47:29PM -0300, Jason Gunthorpe wrote:
> > On Wed, Oct 09, 2024 at 09:38:14AM -0700, Nicolin Chen wrote:
> > > An IOMMU_VIOMMU_TYPE_DEFAULT doesn't need a free() op since the core can
> > > free everything in
On Wed, Oct 09, 2024 at 09:38:15AM -0700, Nicolin Chen wrote:
> +void iommufd_vdevice_destroy(struct iommufd_object *obj)
> +{
> + struct iommufd_vdevice *old, *vdev =
> + container_of(obj, struct iommufd_vdevice, obj);
> + struct iommufd_viommu *viommu = vdev->viommu;
> + s
On Thu, Oct 17, 2024 at 03:47:29PM -0300, Jason Gunthorpe wrote:
> On Wed, Oct 09, 2024 at 09:38:14AM -0700, Nicolin Chen wrote:
> > An IOMMU_VIOMMU_TYPE_DEFAULT doesn't need a free() op since the core can
> > free everything in the destroy(). Now with the new vDEVICE structure, it
> > might want t
On Thu, Oct 17, 2024 at 03:40:15PM -0300, Jason Gunthorpe wrote:
> On Wed, Oct 09, 2024 at 09:38:11AM -0700, Nicolin Chen wrote:
> > Add a new driver-type for ARM SMMUv3 to enum iommu_viommu_type. Implement
> > +static inline struct iommufd_viommu *
> > +arm_vsmmu_alloc(struct iommu_device *iommu_d
On Wed, Oct 09, 2024 at 09:38:14AM -0700, Nicolin Chen wrote:
> An IOMMU_VIOMMU_TYPE_DEFAULT doesn't need a free() op since the core can
> free everything in the destroy(). Now with the new vDEVICE structure, it
> might want to allocate its own vDEVICEs.
>
> Add a default_viommu_ops for driver to
> +struct iommufd_vdevice *
> +__iommufd_vdevice_alloc(struct iommufd_ctx *ictx, size_t size)
> +{
> + struct iommufd_object *obj;
> +
> + if (WARN_ON(size < sizeof(struct iommufd_vdevice)))
> + return ERR_PTR(-EINVAL);
> + obj = iommufd_object_alloc_elm(ictx, size, IOMMUFD_
On Wed, Oct 09, 2024 at 09:38:11AM -0700, Nicolin Chen wrote:
> Add a new driver-type for ARM SMMUv3 to enum iommu_viommu_type. Implement
> +static inline struct iommufd_viommu *
> +arm_vsmmu_alloc(struct iommu_device *iommu_dev, struct iommu_domain *parent,
> + struct iommufd_ctx *ictx
On Thu, Oct 17, 2024 at 10:46 PM Jason Gunthorpe wrote:
>
> On Thu, Oct 17, 2024 at 07:11:46PM +0200, David Hildenbrand wrote:
> > On 17.10.24 18:47, Jason Gunthorpe wrote:
> > > On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
> > >
> > > > My question was more torwards whether gmemfd co
Kunit tests to test hash table add, delete, duplicate add and delete.
Add following configs and compile kernel code:
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_NET=y
CONFIG_KUNIT=m
CONFIG_CN_HASH_KUNIT_TEST=m
To run kunit tests:
sudo modprobe cn_hash_test
Output of kunit tests and hash table
Add a new type PROC_CN_MCAST_NOTIFY to proc connector API, which allows a
thread to notify the kernel that is going to exit with a non-zero exit
code and specify the exit code in it. When thread exits in the kernel,
it will send this exit code as a proc filter notification to any
listening process.
Test to check if setting PROC_CN_MCAST_NOTIFY in proc connector API, allows
a thread's non-zero exit status to be returned to proc_filter.
The threads.c program creates 2 child threads. 1st thread handles signal
SIGSEGV, and 2nd thread needs to indicate some error condition (value 1)
to the kernel
Recently we committed a fix to allow processes to receive notifications for
non-zero exits via the process connector module. Commit is a4c9a56e6a2c.
However, for threads, when it does a pthread_exit(&exit_status) call, the
kernel is not aware of the exit status with which pthread_exit is called.
I
On 17.10.24 19:16, Jason Gunthorpe wrote:
On Thu, Oct 17, 2024 at 07:11:46PM +0200, David Hildenbrand wrote:
On 17.10.24 18:47, Jason Gunthorpe wrote:
On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
My question was more torwards whether gmemfd could still expose the
possibility to b
: 8e929cb546ee42c9a61d24fae60605e9e3192354
change-id: 20241017-arm64-fp-stress-exit-code-90fe21dc4bc3
Best regards,
--
Mark Brown
On Thu, Oct 17, 2024 at 02:38:55PM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 17, 2024 at 10:21:31AM -0700, Nicolin Chen wrote:
> > On Thu, Oct 17, 2024 at 01:51:51PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Oct 09, 2024 at 09:38:05AM -0700, Nicolin Chen wrote:
> > > > With a viommu object wrap
On Thu, Oct 17, 2024 at 10:37:00AM -0700, John Hubbard wrote:
> On 10/17/24 10:28 AM, Lorenzo Stoakes wrote:
> > On Thu, Oct 17, 2024 at 10:17:54AM -0700, John Hubbard wrote:
> > > On 10/17/24 5:06 AM, Lorenzo Stoakes wrote:
> ...
> > > > #ifndef __TOOLS_LINUX_PIDFD_H
> > > > #defin
On Thu, Oct 17, 2024 at 10:21:31AM -0700, Nicolin Chen wrote:
> On Thu, Oct 17, 2024 at 01:51:51PM -0300, Jason Gunthorpe wrote:
> > On Wed, Oct 09, 2024 at 09:38:05AM -0700, Nicolin Chen wrote:
> > > With a viommu object wrapping a potentially shareable S2 domain, a nested
> > > domain should be a
On 10/17/24 10:28 AM, Lorenzo Stoakes wrote:
On Thu, Oct 17, 2024 at 10:17:54AM -0700, John Hubbard wrote:
On 10/17/24 5:06 AM, Lorenzo Stoakes wrote:
...
#ifndef __TOOLS_LINUX_PIDFD_H
#define __TOOLS_LINUX_PIDFD_H
/*
* Some systems have issues with the linux/
Hi Petr,
On Thu, Oct 17, 2024 at 7:13 AM Petr Pavlu wrote:
>
> On 10/8/24 20:38, Sami Tolvanen wrote:
> > + if (symtypes_file) {
> > + symfile = fopen(symtypes_file, "w");
> > +
> > + if (!symfile) {
> > + error("fopen failed for '%s': %s", symtypes
On Thu, Oct 17, 2024 at 10:17:54AM -0700, John Hubbard wrote:
> On 10/17/24 5:06 AM, Lorenzo Stoakes wrote:
> > +cc John, sorry I forgot to cc you on other replies!!
> >
> > On Thu, Oct 17, 2024 at 09:08:19AM +0100, Lorenzo Stoakes wrote:
> > [snip]
> > >
> > > In any case I think copying the heade
On Wed, Oct 09, 2024 at 09:38:06AM -0700, Nicolin Chen wrote:
> @@ -317,6 +324,19 @@ int iommufd_hwpt_alloc(struct iommufd_ucmd *ucmd)
> goto out_unlock;
> }
> hwpt = &hwpt_nested->common;
> + } else if (pt_obj->type == IOMMUFD_OBJ_VIOMMU) {
> +
On Thu, Oct 17, 2024 at 02:15:00PM -0300, Jason Gunthorpe wrote:
> On Wed, Oct 09, 2024 at 09:38:08AM -0700, Nicolin Chen wrote:
>
> > +static struct iommufd_viommu *
> > +mock_viommu_alloc(struct iommu_device *iommu_dev, struct iommu_domain
> > *domain,
> > + struct iommufd_ctx *ictx
On 17.10.24 18:47, Jason Gunthorpe wrote:
On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
My question was more torwards whether gmemfd could still expose the
possibility to be used in VA forms to other modules that may not support
fd+offsets yet.
I keep hearing they don't want to su
On Thu, Oct 17, 2024 at 01:51:51PM -0300, Jason Gunthorpe wrote:
> On Wed, Oct 09, 2024 at 09:38:05AM -0700, Nicolin Chen wrote:
> > With a viommu object wrapping a potentially shareable S2 domain, a nested
> > domain should be allocated by associating to a viommu instead.
> >
> > For drivers with
Harshit Mogalapalli wrote:
> After commit: 83762cb5c7c4 ("dax: Kill DEV_DAX_PMEM_COMPAT") the pmem/
> directory is not needed anymore and Makefile changes were made
> accordingly in this commit, but there is a Makefile and pmem.c in pmem/
> which are now stale and pmem.c is empty, remove them.
>
>
On 10/17/24 5:06 AM, Lorenzo Stoakes wrote:
+cc John, sorry I forgot to cc you on other replies!!
On Thu, Oct 17, 2024 at 09:08:19AM +0100, Lorenzo Stoakes wrote:
[snip]
In any case I think copying the header to the tools/ directory with this
linux/fcntl.h in some way stubbed out (we could eve
Hi,
On Thu, Oct 17, 2024 at 7:08 AM Petr Pavlu wrote:
>
> > @@ -22,9 +53,13 @@ static unsigned int for_each(const char *name,
> > symbol_callback_t func,
> > if (strcmp(match->name, name))
> > continue;
> >
> > + /* Call func for the match, and all
On Thu, Oct 17, 2024 at 07:11:46PM +0200, David Hildenbrand wrote:
> On 17.10.24 18:47, Jason Gunthorpe wrote:
> > On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
> >
> > > My question was more torwards whether gmemfd could still expose the
> > > possibility to be used in VA forms to oth
On Wed, Oct 09, 2024 at 09:38:08AM -0700, Nicolin Chen wrote:
> +static struct iommufd_viommu *
> +mock_viommu_alloc(struct iommu_device *iommu_dev, struct iommu_domain
> *domain,
> + struct iommufd_ctx *ictx, unsigned int viommu_type)
> +{
> + struct mock_iommu_device *mock_iom
On Thu, Oct 17, 2024 at 01:47:13PM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
>
> > My question was more torwards whether gmemfd could still expose the
> > possibility to be used in VA forms to other modules that may not support
> > fd+offsets yet.
>
On Wed, Oct 09, 2024 at 09:38:07AM -0700, Nicolin Chen wrote:
> For an iommu_dev that can unplug (so far only this selftest does so), the
> viommu->iommu_dev pointer has no guarantee of its life cycle after it is
> copied from the idev->dev->iommu->iommu_dev.
>
> Track the user count of the iommu_
On Wed, Oct 09, 2024 at 09:38:05AM -0700, Nicolin Chen wrote:
> With a viommu object wrapping a potentially shareable S2 domain, a nested
> domain should be allocated by associating to a viommu instead.
>
> For drivers without a viommu support, keep the parent domain input, which
> should be just
On Thu, Oct 17, 2024 at 01:05:34PM -0400, Peter Xu wrote:
> On Thu, Oct 17, 2024 at 01:47:13PM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
> >
> > > My question was more torwards whether gmemfd could still expose the
> > > possibility to be used in V
On Thu, Oct 17, 2024 at 10:01:28AM -0700, Nicolin Chen wrote:
> On Thu, Oct 17, 2024 at 01:33:59PM -0300, Jason Gunthorpe wrote:
>
> > > diff --git a/drivers/iommu/iommufd/viommu_api.c
> > > b/drivers/iommu/iommufd/viommu_api.c
> > > new file mode 100644
> > > index ..c1731f080d6b
> >
On Thu, Oct 17, 2024 at 01:33:59PM -0300, Jason Gunthorpe wrote:
> > diff --git a/drivers/iommu/iommufd/viommu_api.c
> > b/drivers/iommu/iommufd/viommu_api.c
> > new file mode 100644
> > index ..c1731f080d6b
> > --- /dev/null
> > +++ b/drivers/iommu/iommufd/viommu_api.c
>
> Let's cal
On Thu, Oct 17, 2024, David Woodhouse wrote:
> On Fri, 2024-10-11 at 17:21 -0700, Sean Christopherson wrote:
> >
> > > +
> > > + /* We should never reach this point */
> >
> > No pronouns. Yes, it's nitpicky, but "we" gets _very_ ambiguous when "we"
> > could
> > mean the admin, the user,
On Thu, Oct 17, 2024 at 09:48:23AM -0700, Nicolin Chen wrote:
> On Thu, Oct 17, 2024 at 01:35:07PM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 17, 2024 at 09:12:03AM -0700, Nicolin Chen wrote:
> >
> > > > Then you can keep the pattern of _ being the allocation function of
> > > > the macro
> > >
On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote:
> My question was more torwards whether gmemfd could still expose the
> possibility to be used in VA forms to other modules that may not support
> fd+offsets yet.
I keep hearing they don't want to support page pinning on a guestmemfd
mappi
On Thu, Oct 17, 2024 at 01:41:23PM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 17, 2024 at 09:28:16AM -0700, Nicolin Chen wrote:
> > On Wed, Oct 09, 2024 at 09:38:11AM -0700, Nicolin Chen wrote:
> > > Add a new driver-type for ARM SMMUv3 to enum iommu_viommu_type. Implement
> > > the viommu_alloc o
On Thu, Oct 17, 2024 at 01:35:07PM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 17, 2024 at 09:12:03AM -0700, Nicolin Chen wrote:
>
> > > Then you can keep the pattern of _ being the allocation function of
> > > the macro
> >
> > If I get it correctly, the change would be
> > [From]
> > level-0: i
On Thu, Oct 17, 2024 at 09:43:22AM -0700, Nicolin Chen wrote:
> On Thu, Oct 17, 2024 at 01:41:23PM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 17, 2024 at 09:28:16AM -0700, Nicolin Chen wrote:
> > > On Wed, Oct 09, 2024 at 09:38:11AM -0700, Nicolin Chen wrote:
> > > > Add a new driver-type for AR
On 10/17/24 9:33 AM, Shuah Khan wrote:
On 10/16/24 20:01, John Hubbard wrote:
On 10/16/24 1:00 PM, Shuah Khan wrote:
On 10/16/24 04:20, Lorenzo Stoakes wrote:
...
The requirement to do "make headers" is not a keeper. Really.
The reason we added the requirement to avoid duplicate defines
suc
On Thu, Oct 17, 2024 at 09:28:16AM -0700, Nicolin Chen wrote:
> On Wed, Oct 09, 2024 at 09:38:11AM -0700, Nicolin Chen wrote:
> > Add a new driver-type for ARM SMMUv3 to enum iommu_viommu_type. Implement
> > the viommu_alloc op with an arm_vsmmu_alloc function. As an initial step,
> > copy the VMID
On Wed, Oct 09, 2024 at 09:38:04AM -0700, Nicolin Chen wrote:
> Add a new ioctl for user space to do a vIOMMU allocation. It must be based
> on a nesting parent HWPT, so take its refcount.
>
> As an initial version, define an IOMMU_VIOMMU_TYPE_DEFAULT type. Using it,
> the object will be allocated
1 - 100 of 137 matches
Mail list logo
