On Tue, Jan 07, 2025 at 03:13:24PM +, Will Deacon wrote:
> On Wed, Dec 11, 2024 at 01:02:50AM +, Mark Brown wrote:
> > -Res0 27:0
> > +UnsignedEnum 27 SF8MM8
> > + 0b0 NI
> > + 0b1 IMP
> > +EndEnum
> > +UnsignedEnum 26 SF8MM4
> > + 0b0 NI
> > +
As the vIOMMU infrastructure series part-3, this introduces a new vEVENTQ
object. The existing FAULT object provides a nice notification pathway to
the user space with a queue already, so let vEVENTQ reuse that.
Mimicing the HWPT structure, add a common EVENTQ structure to support its
derivatives:
Introduce a new IOMMUFD_OBJ_VEVENTQ object for vIOMMU Event Queue that
provides user space (VMM) another FD to read the vIOMMU Events.
Allow a vIOMMU object to allocate vEVENTQs, with a condition that each
vIOMMU can only have one single vEVENTQ per type.
Add iommufd_veventq_alloc() with iommufd_
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.
Reviewed-b
Rename the file, aligning with the new eventq object.
Reviewed-by: Kevin Tian
Reviewed-by: Lu Baolu
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 driver
Similar to iommu_report_device_fault, this allows IOMMU drivers to report
vIOMMU events from threaded IRQ handlers to user space hypervisors.
Reviewed-by: Lu Baolu
Signed-off-by: Nicolin Chen
---
include/linux/iommufd.h| 11 +
drivers/iommu/iommufd/driver.c | 43
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 to set
or unset the master->vmaster point. Put these helpers inside the existing
arm_smmu_attac
On Wed, 11 Dec 2024 01:02:53 +,
Mark Brown wrote:
>
> 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
Reviewed-by: M
The fault object was designed exclusively for hwpt's IO page faults (PRI).
But its queue implementation can 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 queue".
The infrastructure of a fault object will be shared with a new vEVENTQ
object in a following change. Add a helper for a vEVENTQ 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 vEVENTQ doesn't nee
The new vEVENTQ object will need a similar function for drivers to report
the vIOMMU related events. 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_h
Reorder the existing OBJ/IOCTL lists.
Also run clang-format for the same coding style at line wrappings.
No functional change.
Reviewed-by: Lu Baolu
Signed-off-by: Nicolin Chen
---
drivers/iommu/iommufd/main.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions
When attaching a device to a vIOMMU-based nested domain, vdev_id must be
present. Add a piece of code hard-requesting it, preparing for a vEVENTQ
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.
Trigger a vEVENT by feeding an idev ID and validating the returned output
virt_id whether it equals to the value that was set to the vDEVICE.
Signed-off-by: Nicolin Chen
---
tools/testing/selftests/iommu/iommufd_utils.h | 65 +++
tools/testing/selftests/iommu/iommufd.c | 22
With the introduction of the new objects, update the doc to reflect that.
Reviewed-by: Lu Baolu
Signed-off-by: Nicolin Chen
---
Documentation/userspace-api/iommufd.rst | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/userspace-api/iommufd.rst
b/Documentation/
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
Aside from the IOPF framework, iommufd provides an additional pathway to
report hardware events, via the vEVENTQ of vIOMMU infrastructure.
Define an iommu_vevent_arm_smmuv3 uAPI structure, and report stage-1 events
in the threaded IRQ handler.
Signed-off-by: Nicolin Chen
---
drivers/iommu/arm/a
On Tue, 07 Jan 2025 16:42:38 +,
Will Deacon wrote:
>
> On Wed, 11 Dec 2024 01:02:45 +, Mark Brown wrote:
> > 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 extension
On Tue, Jan 07, 2025 at 03:26:34PM +, Mark Brown wrote:
> On Tue, Jan 07, 2025 at 03:13:24PM +, Will Deacon wrote:
> > On Wed, Dec 11, 2024 at 01:02:50AM +, Mark Brown wrote:
>
> > > -Res0 27:0
> > > +UnsignedEnum 27 SF8MM8
> > > + 0b0 NI
> > > + 0b1 IMP
> > > +End
On Wed, Dec 11, 2024 at 01:02:50AM +, Mark Brown wrote:
> 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 +++
On Wed, 11 Dec 2024 01:02:45 +, Mark Brown wrote:
> 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
On 01/06, Song Yoong Siang wrote:
> Extend the XDP Tx metadata framework so that user can requests launch time
> hardware offload, where the Ethernet device will schedule the packet for
> transmission at a pre-determined time called launch time. The value of
> launch time is communicated from user
On 01/06, Song Yoong Siang wrote:
> Add Launch Time hw offload request to xdp_hw_metadata. User can configure
> the delta of launch time to HW RX-time by using "-l" argument. The default
> delta is 100,000,000 nanosecond.
>
> Signed-off-by: Song Yoong Siang
> ---
> tools/testing/selftests/bpf/xd
On Fri, Dec 13, 2024 at 01:34:41PM -0600, Elizabeth Figura wrote:
> This patch series implements a new char misc driver, /dev/ntsync, which is
> used
> to implement Windows NT synchronization primitives.
>
> NT synchronization primitives are unique in that the wait functions both are
> vectored,
On 01/06, Song Yoong Siang wrote:
> Enable launch time (Time-Based Scheduling) support to XDP zero copy via XDP
> Tx metadata framework.
>
> This patch is tested with tools/testing/selftests/bpf/xdp_hw_metadata on
> Intel Tiger Lake platform. Below are the test steps and result.
>
> Test Steps:
>
On Wed, Dec 18, 2024 at 4:44 AM Sean Christopherson wrote:
> > Changing our legacy BIOS is not an option so in order to support Windows VMs
> > with the legacy BIOS with decent performance we would either need to add
> > support
> > for remote reads of the APIC ID register to KVM or support CR8 a
On Tue, Jan 07, 2025 at 06:06:03PM +0100, Greg Kroah-Hartman wrote:
> Given a lack of complaints, I've now applied this to my testing tree.
> Thanks for sticking with it!
Right, so I acked v6, which wasn't preserved. The v7 changes are minor
and seem fine (IIRc I even suggested them some very very
From: Michael Kelley
Add documentation on how hibernation works in a guest VM on Hyper-V.
Describe how VMBus devices and the VMBus itself are hibernated and
resumed, along with various limitations.
Signed-off-by: Michael Kelley
---
Changes in v2:
* Added discussion of implications of moving a h
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
From: Marc Zyngier
The hwcaps code that exposes SVE features to userspace only
considers ID_AA64ZFR0_EL1, while this is only valid when
ID_AA64PFR0_EL1.SVE advertises that SVE is actually supported.
The expectations are that when ID_AA64PFR0_EL1.SVE is 0, the
ID_AA64ZFR0_EL1 register is also 0.
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
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 | 50 +
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.
Reviewed-by: Marc Zyngier
Signed-off-by: Mark Brown
---
arch/arm64/kvm/sys_regs.c | 6 +-
1 file change
DDI0601 2024-12 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 | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --gi
On Tuesday, 7 January 2025 13:42:41 CST Peter Zijlstra wrote:
> On Tue, Jan 07, 2025 at 06:06:03PM +0100, Greg Kroah-Hartman wrote:
> > Given a lack of complaints, I've now applied this to my testing tree.
> > Thanks for sticking with it!
>
> Right, so I acked v6, which wasn't preserved. The v7 ch
On 06.01.25 03:07, Alistair Popple wrote:
On Fri, Dec 20, 2024 at 08:06:48PM +0100, David Hildenbrand wrote:
On 20.12.24 20:01, David Hildenbrand wrote:
On 17.12.24 06:12, Alistair Popple wrote:
In preparation for using insert_page() for DAX, enhance
insert_page_into_pte_locked() to handle est
On 07.01.25 04:42, Alistair Popple wrote:
The rmap doesn't currently support adding a PUD mapping of a
folio. This patch adds support for entire PUD mappings of folios,
primarily to allow for more standard refcounting of device DAX
folios. Currently DAX is the only user of this and it doesn't req
On Tue, 7 Jan 2025 14:42:16 +1100 Alistair Popple wrote:
> Device and FS DAX pages have always maintained their own page
> reference counts without following the normal rules for page reference
> counting. In particular pages are considered free when the refcount
> hits one rather than zero and
Hi Alistair,
kernel test robot noticed the following build warnings:
[auto build test WARNING on e25c8d66f6786300b680866c0e0139981273feba]
url:
https://github.com/intel-lab-lkp/linux/commits/Alistair-Popple/fuse-Fix-dax-truncate-punch_hole-fault-path/20250107-114726
base
On Tue, Jan 07, 2025 at 12:20:47PM -0800, mhkelle...@gmail.com wrote:
> +VMBus devices are identified by class and instance GUID. (See section
> +"VMBus device creation/deletion" in
> +Documentation/virt/hyperv/vmbus.rst.) Upon resume from hibernation,
> +the resume functions expect that the device
From: Bagas Sanjaya Sent: Tuesday, January 7, 2025 8:07
PM
>
> On Tue, Jan 07, 2025 at 12:20:47PM -0800, mhkelle...@gmail.com wrote:
> > +VMBus devices are identified by class and instance GUID. (See section
> > +"VMBus device creation/deletion" in
> > +Documentation/virt/hyperv/vmbus.rst.) Upon
41 matches
Mail list logo
