On Fri, Oct 25, 2024 at 04:14:49PM +0200, David Hildenbrand wrote:
> Now that s390 code is prepared for memory devices that reside above the
> maximum storage increment exposed through SCLP, everything is in place
> to unlock virtio-mem support.
...
> Acked-by: Michael S. Tsirkin
> Tested-by: Mari
On Fri, Oct 25, 2024 at 04:14:45PM +0200, David Hildenbrand wrote:
> Let's finally add s390 support for virtio-mem; my last RFC was sent
> 4 years ago, and a lot changed in the meantime.
>
> The latest QEMU series is available at [1], which contains some more
> details and a usage example on s390
On Fri, Oct 25, 2024 at 04:14:46PM +0200, David Hildenbrand wrote:
> Let's make it a generic KVM hypercall, allowing other subfunctions to
> be more independent of virtio.
>
> While at it, document that unsupported/unimplemented subfunctions result
> in a SPECIFICATION exception.
>
> This is a pr
On Fri, Oct 25, 2024 at 04:14:47PM +0200, David Hildenbrand wrote:
> Let's document our new diag500 subfunction that can be implemented by
> userspace.
>
> Signed-off-by: David Hildenbrand
> ---
> Documentation/virt/kvm/s390/s390-diag.rst | 17 +
> 1 file changed, 17 insertions(+
On Fri, Oct 25, 2024 at 04:14:48PM +0200, David Hildenbrand wrote:
> To support memory devices under QEMU/KVM, such as virtio-mem,
> we have to prepare our kernel virtual address space accordingly and
> have to know the highest possible physical memory address we might see
> later: the storage limi
On 30.10.24 10:23, Heiko Carstens wrote:
On Fri, Oct 25, 2024 at 04:14:48PM +0200, David Hildenbrand wrote:
To support memory devices under QEMU/KVM, such as virtio-mem,
we have to prepare our kernel virtual address space accordingly and
have to know the highest possible physical memory address
On Wed, Oct 30, 2024 at 10:42:05AM +0100, David Hildenbrand wrote:
> On 30.10.24 10:23, Heiko Carstens wrote:
> > Looks like I couldn't convince you to implement a query subcode.
>
> Well, you convinced me that it might be useful, but after waiting on
> feedback from the KVM folks ... which didn't
On Tue, 29 Oct 2024 15:34:40 -0500
Ira Weiny wrote:
> Additional DCD functionality is being added to this call which will be
> simplified by the use of guard() with the cxl_dpa_rwsem.
>
> Convert the function to use guard() prior to adding DCD functionality.
>
> Suggested-by: Jonathan Cameron
Jonathan Cameron wrote:
> A few minor things inline from a fresh read.
>
> Other than maybe a missing header, the others are all trivial
> and you can make your own minds up.
>
> Reviewed-by: Jonathan Cameron
>
[snip]
>
> > +static bool extents_contain(struct cxl_dax_region *cxlr_dax,
> > +
On 10/29/24 1:34 PM, Ira Weiny wrote:
> Additional DCD region (partition) information is contained in the DSMAS
> CDAT tables, including performance, read only, and shareable attributes.
>
> Match DCD partitions with DSMAS tables and store the meta data.
>
> Reviewed-by: Jonathan Cameron
> Si
On Tue, Oct 29, 2024 at 03:34:48PM -0500, ira.we...@intel.com wrote:
> From: Navneet Singh
>
> To properly configure CXL regions on Dynamic Capacity Devices (DCD),
> user space will need to know the details of the DC partitions available.
>
> Expose dynamic capacity capabilities through sysfs.
>
DDI0601 2024-09 introduces SVE 2.2 as well as a few new optional features,
update sysreg to reflect the changes in ID_AA64ZFR0_EL1 enumerating them.
Signed-off-by: Mark Brown
---
arch/arm64/tools/sysreg | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm6
The 2024 architecture release includes a number of data processing
extensions, mostly SVE and SME additions with a few others. These are
all very straightforward extensions which add instructions but no
architectural state so only need hwcaps and exposing of the ID registers
to KVM guests and user
DDI0601 2024-09 defines two new feature flags in ID_AA64FPFR0_EL1
describing new FP8 operations, describe them in sysreg.
Signed-off-by: Mark Brown
---
arch/arm64/tools/sysreg | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools
DDI0601 2024-09 introduces SME 2.2 as well as a few new optional features,
update sysreg to reflect the changes in ID_AA64SMFR0_EL1 enumerating them.
Signed-off-by: Mark Brown
---
arch/arm64/tools/sysreg | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff
DDI0601 2024-09 defines several new feature flags in ID_AA64ISAR3_EL1,
update our description in sysreg to reflect these.
Signed-off-by: Mark Brown
---
arch/arm64/tools/sysreg | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/tools/sysreg b/arch/ar
DDI0601 2024-09 defines a new feature flags in ID_AA64PFR2_EL1
describing support for injecting UNDEF exceptions, update sysreg to
include this.
Signed-off-by: Mark Brown
---
arch/arm64/tools/sysreg | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/tools/sysreg
Jonathan Cameron wrote:
> On Tue, 29 Oct 2024 15:34:43 -0500
> ira.we...@intel.com wrote:
>
> > From: Navneet Singh
> >
> > Devices which optionally support Dynamic Capacity (DC) are configured
> > via mailbox commands. CXL 3.1 requires the host to issue the Get DC
> > Configuration command in
We don't actually test SIGILL generation for CMPBR since the need to
branch makes it a pain to generate and the SIGILL detection would be
unreliable anyway. Since this should be very unusual we provide a stub
function rather than supporting a missing function.
The sigill functions aren't well sort
On Tue, 29 Oct 2024 15:34:38 -0500
Ira Weiny wrote:
> The device DAX structure is being enhanced to track additional DCD
> information. Specifically the range tuple needs additional parameters.
> The current range tuple is not fully documented and is large enough to
> warrant its own definition.
The 2024 dpISA introduces a number of architecture features all of which
only add new instructions so only require the addition of hwcaps and ID
register visibility.
Signed-off-by: Mark Brown
---
Documentation/arch/arm64/elf_hwcaps.rst | 51 +
arch/arm64/include/a
ID_AA64ISAR3_EL1 is currently marked as unallocated in KVM but does have a
number of bitfields defined in it. Expose FPRCVT and FAMINMAX, two simple
instruction only extensions to guests.
Signed-off-by: Mark Brown
---
arch/arm64/kvm/sys_regs.c | 6 +-
1 file changed, 5 insertions(+), 1 delet
DDI0601 2024-09 introduces new features which are enumerated via
ID_AA64ISAR2_EL1, update the sysreg file to reflect these updates.
Signed-off-by: Mark Brown
---
arch/arm64/tools/sysreg | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/
Am 30.10.24 um 10:34 schrieb Heiko Carstens:
On Fri, Oct 25, 2024 at 04:14:45PM +0200, David Hildenbrand wrote:
Let's finally add s390 support for virtio-mem; my last RFC was sent
4 years ago, and a lot changed in the meantime.
The latest QEMU series is available at [1], which contains some
On Tue, Oct 29, 2024 at 03:34:53PM -0500, ira.we...@intel.com wrote:
> From: Navneet Singh
>
> Dynamic Capacity Devices (DCD) support extent change notifications
> through the event log mechanism. The interrupt mailbox commands were
> extended in CXL 3.1 to support these notifications. Firmware
On 2024/10/28 04:54, li...@treblig.org wrote:
From: "Dr. David Alan Gilbert"
devm_hwspin_lock_request() was added by 2018's
commit 4f1acd758b08 ("hwspinlock: Add devm_xxx() APIs to request/free
hwlock") however, it's never been used, everyone uses the
devm_hwspin_lock_request_specific() call
On Fri, Oct 25, 2024 at 04:14:52PM +0200, David Hildenbrand wrote:
> virtio-mem uses memory_add_physaddr_to_nid() to determine the NID to use
> for memory it adds.
>
> We currently fallback to the dummy implementation in mm/numa.c with
> CONFIG_NUMA, which will end up triggering an undesired pr_in
On Tue, 29 Oct 2024 15:34:43 -0500
ira.we...@intel.com wrote:
> From: Navneet Singh
>
> Devices which optionally support Dynamic Capacity (DC) are configured
> via mailbox commands. CXL 3.1 requires the host to issue the Get DC
> Configuration command in order to properly configure DCDs. Witho
On Fri, Oct 25, 2024 at 04:14:48PM +0200, David Hildenbrand wrote:
> To support memory devices under QEMU/KVM, such as virtio-mem,
> we have to prepare our kernel virtual address space accordingly and
> have to know the highest possible physical memory address we might see
> later: the storage limi
A few minor things inline from a fresh read.
Other than maybe a missing header, the others are all trivial
and you can make your own minds up.
Reviewed-by: Jonathan Cameron
> #endif /* __CXL_CORE_H__ */
> diff --git a/drivers/cxl/core/extent.c b/drivers/cxl/core/extent.c
> new file mode 100644
> > arch/s390/boot/physmem_info.c| 46 ++--
> > arch/s390/include/asm/physmem_info.h | 3 ++
> > 2 files changed, 46 insertions(+), 3 deletions(-)
>
> Reviewed-by: Alexander Gordeev
Sorry, it supposed to be for v3, so please dismiss this one.
> Thanks!
On Mon, Oct 14, 2024 at 04:46:16PM +0200, David Hildenbrand wrote:
Hi David,
> To support memory devices under QEMU/KVM, such as virtio-mem,
> we have to prepare our kernel virtual address space accordingly and
> have to know the highest possible physical memory address we might see
> later: the
On Tue, 29 Oct 2024 15:34:58 -0500
ira.we...@intel.com wrote:
> From: Navneet Singh
>
> DAX regions which map dynamic capacity partitions require that memory be
> allowed to come and go. Recall sparse regions were created for this
> purpose. Now that extents can be realized within DAX regions
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.
IOMMU driver wanting to support vIOMMUs must define its IOMMU_VIOMMU_TYPE_
in the uAPI header and implement a viommu_alloc op in its iommu_ops.
Reviewed-by: Jason Gunthorpe
Now a vIOMMU holds a shareable nesting parent HWPT. So, it can act like
that nesting parent HWPT to allocate a nested HWPT.
Support that in the IOMMU_HWPT_ALLOC ioctl handler, and update its kdoc.
Also, add an iommufd_viommu_alloc_hwpt_nested helper to allocate a nested
HWPT for a vIOMMU object.
With the introduction of the new object and its infrastructure, update the
doc to reflect that and add a new graph.
Reviewed-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
Signed-off-by: Nicolin Chen
---
Documentation/userspace-api/iommufd.rst | 69 -
1 file changed, 68 in
Implement the viommu alloc/free functions to increase/reduce refcount of
its dependent mock iommu device. User space can verify this loop via the
IOMMU_VIOMMU_TYPE_SELFTEST.
Reviewed-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Signed-off-by: Nicolin Chen
---
drivers/iommu/iommufd/iommufd_test.
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_dev. Postpone the exit routine using a
completion, if refcount is unbala
Similar to IOMMU_TEST_OP_MD_CHECK_IOTLB verifying a mock_domain's iotlb,
IOMMU_TEST_OP_DEV_CHECK_CACHE will be used to verify a mock_dev's cache.
Reviewed-by: Kevin Tian
Signed-off-by: Nicolin Chen
---
drivers/iommu/iommufd/iommufd_test.h | 5
tools/testing/selftests/iommu/iommuf
This avoids a bigger trouble of exposing struct iommufd_device and struct
iommufd_vdevice in the public header.
Reviewed-by: Kevin Tian
Signed-off-by: Nicolin Chen
---
include/linux/iommufd.h| 8
drivers/iommu/iommufd/driver.c | 13 +
2 files changed, 21 insertions
Add a viommu_cache test function to cover vIOMMU invalidations using the
updated IOMMU_HWPT_INVALIDATE ioctl, which now allows passing in a vIOMMU
via its hwpt_id field.
Reviewed-by: Kevin Tian
Signed-off-by: Nicolin Chen
---
tools/testing/selftests/iommu/iommufd_utils.h | 32
tools/testi
net_dim() is currently passed a struct dim_sample argument by value.
struct dim_sample is 24 bytes. Since this is greater 16 bytes, x86-64
passes it on the stack. All callers have already initialized dim_sample
on the stack, so passing it by value requires pushing a duplicated copy
to the stack. Ei
Make the start and end arguments to dim_calc_stats() const pointers
to clarify that the function does not modify their values.
Signed-off-by: Caleb Sander Mateos
---
include/linux/dim.h | 3 ++-
lib/dim/dim.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/l
Allow IOMMU driver to use a vIOMMU object that holds a nesting parent
hwpt/domain to allocate a nested domain.
Suggested-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Signed-off-by: Nicolin Chen
---
include/linux/iommufd.h | 9 +
1 file changed, 9 insertions
Introduce a new IOMMUFD_OBJ_VDEVICE to represent a physical device (struct
device) against a vIOMMU (struct iommufd_viommu) object in a VM.
This vDEVICE object (and its structure) holds all the infos and attributes
in the VM, regarding the device related to the vIOMMU.
As an initial patch, add a
Add a new iommufd_viommu FIXTURE and setup it up with a vIOMMU object.
Any new vIOMMU feature will be added as a TEST_F under that.
Reviewed-by: Kevin Tian
Signed-off-by: Nicolin Chen
---
tools/testing/selftests/iommu/iommufd_utils.h | 28
tools/testing/selftests/iommu/iommufd.c |
Use these inline helpers to shorten those container_of lines.
Note that one of them goes back and forth between iommu_domain and
mock_iommu_domain, which isn't necessary. So drop its container_of.
Reviewed-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Signed-off-by: Nicolin Chen
---
drivers/iom
A nested domain now can be allocated for a parent domain or for a vIOMMU
object. Rework the existing allocators to prepare for the latter case.
Reviewed-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Signed-off-by: Nicolin Chen
---
drivers/iommu/iommufd/selftest.c | 89 ++-
From: Jason Gunthorpe
The iommu_copy_struct_from_user_array helper can be used to copy a single
entry from a user array which might not be efficient if the array is big.
Add a new iommu_copy_struct_from_full_user_array to copy the entire user
array at once. Update the existing iommu_copy_struct_
With the introduction of the new object and its infrastructure, update the
doc and the vIOMMU graph to reflect that.
Reviewed-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
Signed-off-by: Nicolin Chen
---
Documentation/userspace-api/iommufd.rst | 41 +++--
1 file changed, 32 i
This series introduces a new vIOMMU infrastructure and related ioctls.
IOMMUFD has been using the HWPT infrastructure for all cases, including a
nested IO page table support. Yet, there're limitations for an HWPT-based
structure to support some advanced HW-accelerated features, such as CMDQV
on NV
To support driver-allocated vIOMMU objects, it's required for IOMMU driver
to call the provided iommufd_viommu_alloc helper to embed the core struct.
However, there is no guarantee that every driver will call it and allocate
objects properly.
Make the iommufd_object_finalize/abort functions more r
The following patch will add a new vIOMMU allocator that will require this
_iommufd_object_alloc to be sharable with IOMMU drivers (and iommufd too).
Add a new driver.c file that will be built with CONFIG_IOMMUFD_DRIVER_CORE
selected by CONFIG_IOMMUFD, and put the CONFIG_DRIVER under that remainin
Prepare for an embedded structure design for driver-level iommufd_viommu
objects:
// include/linux/iommufd.h
struct iommufd_viommu {
struct iommufd_object obj;
};
// Some IOMMU driver
struct iommu_driver_viommu {
struct iommufd_viommu core;
On 30.10.24 15:32, Alexander Gordeev wrote:
On Fri, Oct 25, 2024 at 04:14:48PM +0200, David Hildenbrand wrote:
To support memory devices under QEMU/KVM, such as virtio-mem,
we have to prepare our kernel virtual address space accordingly and
have to know the highest possible physical memory addre
This per-vIOMMU cache_invalidate op is like the cache_invalidate_user op
in struct iommu_domain_ops, but wider, supporting device cache (e.g. PCI
ATC invaldiations).
Reviewed-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
Signed-off-by: Nicolin Chen
---
include/linux/iommufd.h | 10 ++
1
With a vIOMMU object, use space can flush any IOMMU related cache that can
be directed via a vIOMMU object. It is similar to the IOMMU_HWPT_INVALIDATE
uAPI, but can cover a wider range than IOTLB, e.g. device/desciprtor cache.
Allow hwpt_id of the iommu_hwpt_invalidate structure to carry a viommu_
Similar to the coverage of cache_invalidate_user for iotlb invalidation,
add a device cache and a viommu_cache_invalidate function to test it out.
Reviewed-by: Kevin Tian
Signed-off-by: Nicolin Chen
---
drivers/iommu/iommufd/iommufd_test.h | 25 +
drivers/iommu/iommufd/selftest.c |
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:
___
| i
Add a vdevice_alloc op to the viommu mock_viommu_ops for the coverage of
IOMMU_VIOMMU_TYPE_SELFTEST allocations. Then, add a vdevice_alloc TEST_F
to cover the IOMMU_VDEVICE_ALLOC ioctl.
Reviewed-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Signed-off-by: Nicolin Chen
---
tools/testing/selftests
On Wed, 30 Oct 2024 13:49:08 -0600 Caleb Sander Mateos wrote:
> net_dim() is currently passed a struct dim_sample argument by value.
> struct dim_sample is 24 bytes. Since this is greater 16 bytes, x86-64
> passes it on the stack. All callers have already initialized dim_sample
> on the stack, so p
On Tue, 29 Oct 2024, ira.we...@intel.com wrote:
Linux has no use for the trailing fields of the Get Dynamic Capacity
Configuration Output Payload (Total number of supported extents, number
of available extents, total number of supported tags, and number of
available tags). Avoid defining those
On Tue, 29 Oct 2024, Ira Weiny wrote:
Additional DCD functionality is being added to this call which will be
simplified by the use of guard() with the cxl_dpa_rwsem.
Convert the function to use guard() prior to adding DCD functionality.
Suggested-by: Jonathan Cameron
Signed-off-by: Ira Weiny
Add a new IOMMUFD_OBJ_VIOMMU with an iommufd_viommu structure to represent
a slice of physical IOMMU device passed to or shared with a user space VM.
This slice, now a vIOMMU object, is a group of virtualization resources of
a physical IOMMU's, such as:
- Security namespace for guest owned ID, e.g
On Tue, 29 Oct 2024, ira.we...@intel.com wrote:
+/* See CXL 3.1 Table 8-164 get dynamic capacity config Output Payload */
+struct cxl_mbox_get_dc_config_out {
+ u8 avail_region_count;
+ u8 regions_returned;
+ u8 rsvd[6];
+ /* See CXL 3.1 Table 8-165 */
+ struct cxl_
On Thu, 31 Oct 2024 at 05:36, 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:
>
66 matches
Mail list logo
