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
Hi Mauro,
On Tue, Dec 03, 2024 at 09:26:13AM +0100, Mauro Carvalho Chehab wrote:
> > > +is also based on a trust relationship between the rest of the
> > > committers,
> >
> > s/also//
> > s/between the rest of/among/
> >
> > I wonder if we should add here some expectation on being reachable
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 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
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
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
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/
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 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
Add coverage of the hwcaps for the 2024 dpISA extensions to the hwcap
test.
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 rath
Em Mon, 2 Dec 2024 14:13:42 +
Sakari Ailus escreveu:
> Hi Mauro,
>
> On Mon, Dec 02, 2024 at 10:26:20AM +0100, Mauro Carvalho Chehab wrote:
> > As the media subsystem will experiment with a multi-committers model,
> > update the Maintainer's entry profile to the new rules, and add a file
> >
On Tue, Dec 03, 2024 at 08:19:58AM +0100, Mauro Carvalho Chehab wrote:
> Em Mon, 2 Dec 2024 16:03:45 +0100 Hans Verkuil escreveu:
> > On 02/12/2024 10:26, Mauro Carvalho Chehab wrote:
> > > The media subsystem used to have a multi-commiter's model in the
> > > past, but things didn't go well on tha
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
Em Tue, 3 Dec 2024 13:22:09 +0200
Laurent Pinchart escreveu:
> On Tue, Dec 03, 2024 at 08:19:58AM +0100, Mauro Carvalho Chehab wrote:
> > Em Mon, 2 Dec 2024 16:03:45 +0100 Hans Verkuil escreveu:
> > > On 02/12/2024 10:26, Mauro Carvalho Chehab wrote:
> > > > The media subsystem used to have a
The media subsystem used to have a multi-commiter's model in the
past, but things didn't go well on that time, and we had to move to
a centralized model.
As the community has evolved, and as there are now new policies in
place like CoC, let's experiment with a multi-committers again.
The model we
The media profile documentation will point to kernel.org sign.
Add a link to it.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/process/maintainer-pgp-guide.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/process/maintainer-pgp-guide.rst
b/Documentation/process/m
On Mon, 02 Dec 2024 13:55:04 +,
Yicong Yang wrote:
>
> From: Yicong Yang
>
> FEAT_LS64* instructions only support to access Device/Uncacheable
> memory, otherwise a data abort for unsupported Exclusive or atomic
Not quite. FEAT_LS64WB explicitly supports Write-Back mappings.
> access (0x3
On Mon, 02 Dec 2024 13:55:01 +,
Yicong Yang wrote:
>
> From: Yicong Yang
>
> Armv8.7 introduces single-copy atomic 64-byte loads and stores
> instructions and its variants named under FEAT_{LS64, LS64_V,
> LS64_ACCDATA}. These features are identified by ID_AA64ISAR1_EL1.LS64
> and the use o
Similar to iommu_report_device_fault, this allows IOMMU drivers to report,
from threaded IRQ handlers to user space hypervisors, IRQs or events that
belong to a vIOMMU.
Signed-off-by: Nicolin Chen
---
include/linux/iommufd.h| 9
drivers/iommu/iommufd/driver.c | 41 +
The handler will get vDEVICE object from the given mdev and convert it to
its per-vIOMMU virtual ID to mimic a real IOMMU driver.
Signed-off-by: Nicolin Chen
---
drivers/iommu/iommufd/iommufd_test.h | 10 ++
drivers/iommu/iommufd/selftest.c | 30
2 files
Use it to store all vSMMU-related data. The vsid (Virtual Stream ID) will
be the first use case. Then, add a rw_semaphore to protect it.
Also add a pair of arm_smmu_attach_prepare/commit_vmaster helpers and put
them in the existing arm_smmu_attach_prepare/commit(). Note that identity
and blocked o
The new vIRQ object will need a similar function for drivers to report the
vIOMMU related interrupts. Split the common part out to a smaller helper,
and place it in the header so that CONFIG_IOMMUFD_DRIVER_CORE can include
that in the driver.c file for drivers to use.
Then keep iommufd_fault_iopf_
Rename the file, aligning with the new eventq object.
Signed-off-by: Nicolin Chen
---
drivers/iommu/iommufd/Makefile | 2 +-
drivers/iommu/iommufd/{fault.c => eventq.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename drivers/iommu/iommufd/{fault.c => eventq.c} (100%)
di
The fault object was designed exclusively for hwpt's IO page faults (PRI).
But its implementation can actually be reused for other purposes too, such
as hardware IRQ and event injections to user space.
Meanwhile, a fault object holds a list of faults. So it's more accurate to
call it a "fault queu
Aside from the IOPF framework, iommufd provides an additional pathway to
report a hardware event or IRQ, via the vIRQ of vIOMMU infrastructure.
Define an iommu_virq_arm_smmuv3 uAPI structure, and report stage-1 faults
in the threaded IRQ handler.
Signed-off-by: Nicolin Chen
---
drivers/iommu/ar
Allow a vIOMMU object to allocate vIRQ Event Queues, with a condition that
each vIOMMU can only have one single vIRQ event queue per type.
Add iommufd_eventq_virq_alloc with an iommufd_eventq_virq_ops for this new
ioctl.
Signed-off-by: Nicolin Chen
---
drivers/iommu/iommufd/iommufd_private.h |
This is a reverse search v.s. iommufd_viommu_find_dev, as drivers may want
to convert a struct device pointer (physical) to its virtual device ID for
an event injection to the user space VM.
Again, this avoids exposing more core structures to the drivers, than the
iommufd_viommu alone.
Signed-off
When attaching a device to a vIOMMU-based nested domain, vdev_id must be
present. Add a piece of code hard-requesting it, for vIRQ support in the
following patch. Then, update the TEST_F.
A HWPT-based nested domain will return a NULL new_viommu, thus no such a
vDEVICE requirement.
Signed-off-by:
Trigger an IRQ giving an idev ID, to test the loopback whether receiving
or not the vdev_id that was set to the idev by the line above.
Signed-off-by: Nicolin Chen
---
tools/testing/selftests/iommu/iommufd_utils.h | 63 +++
tools/testing/selftests/iommu/iommufd.c | 22 +
With the introduction of the new objects, update the doc to reflect that.
Signed-off-by: Nicolin Chen
---
Documentation/userspace-api/iommufd.rst | 19 +++
1 file changed, 19 insertions(+)
diff --git a/Documentation/userspace-api/iommufd.rst
b/Documentation/userspace-api/iommuf
> On Nov 26, 2024, at 3:41 AM, Roberto Sassu
> wrote:
>
> On Tue, 2024-11-26 at 00:13 +, Eric Snowberg wrote:
>>
>>> On Nov 19, 2024, at 3:49 AM, Roberto Sassu
>>> wrote:
>>>
>>> From: Roberto Sassu
>>>
>>> The Integrity Digest Cache can also help IMA for appraisal. IMA can simply
>>
On 12/2/24 10:11, Matthew Wilcox wrote:
On Mon, Dec 02, 2024 at 04:00:47PM +0100, Dragan Simic wrote:
On 2024-11-09 04:10, Dragan Simic wrote:
On 2024-11-08 20:12, Dan Williams wrote:
Dragan Simic wrote:
I'm fully aware that we may be reluctant to supporting
additional tags,
because we may th
On 12/2/24 01:14, Thorsten Leemhuis wrote:
Point out that explicit permission is usually needed to tag other people
in changes, but mention that implicit permission can be sufficient in
certain cases. This fixes slight inconsistencies between Reported-by:
and Suggested-by: and makes the usage mor
As the part-3 of the vIOMMU infrastructure, this series introduces a vIRQ
object. The existing FAULT object provides a nice notification pathway to
the user space already, so let vIRQ reuse the infrastructure.
Mimicing the HWPT structure, add a common EVENTQ structure to support its
derivatives: E
A fault object will be renamed and shared with a new vIRQ object in one of
the following changes. Add a helper for the new allocator to call it too.
Reorder the iommufd_ctx_get and refcount_inc to keep them symmetrical with
the iommufd_fault_fops_release().
Since the new vIRQ object doesn't need
35 matches
Mail list logo
