Hi Eric,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v5.11]
[also build test ERROR on next-20210223]
[cannot apply to vfio/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--bas
Hi Alex,
On 2021/2/23 23:55, Alexandru Elisei wrote:
Hi Yanan,
I wanted to review the patches, but unfortunately I get an error when trying to
apply the first patch in the series:
Applying: KVM: arm64: Move the clean of dcache to the map handler
error: patch failed: arch/arm64/kvm/hyp/pgtable.
Hi Eric,
I love your patch! Yet something to improve:
[auto build test ERROR on v5.11]
[cannot apply to vfio/next next-20210223]
[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-sc
Hi Eric,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v5.11]
[also build test ERROR on next-20210223]
[cannot apply to vfio/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--bas
Hi Eric,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v5.11]
[also build test ERROR on next-20210223]
[cannot apply to vfio/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--bas
From: Tina Zhang
Caps the number of irqs with fixed indexes and uses capability chains
to chain device specific irqs.
Signed-off-by: Tina Zhang
Signed-off-by: Eric Auger
[Eric: Put cap_offset at the end of the vfio_irq_info struct,
remove GFX IRQ at the moment and remove any reference to this
In preparation for vSVA, let's register a DMA fault response region,
where the userspace will push the page responses and increment the
head of the buffer. The kernel will pop those responses and inject them
on iommu side.
Signed-off-by: Eric Auger
---
v11 -> v12:
- use DMA_FAULT_RESPONSE cap [
When the userspace increments the head of the page response
buffer ring, let's push the response into the iommu layer.
This is done through a workqueue that pops the responses from
the ring buffer and increment the tail.
Signed-off-by: Eric Auger
---
drivers/vfio/pci/vfio_pci.c | 40
Implement IRQ capability chain infrastructure. All interrupt
indexes beyond VFIO_PCI_NUM_IRQS are handled as extended
interrupts. They are registered with a specific type/subtype
and supported flags.
Signed-off-by: Eric Auger
---
v11 -> v12:
- check !vdev->num_ext_irqs in vfio_pci_set_ext_irq_t
Register the VFIO_IRQ_TYPE_NESTED/VFIO_IRQ_SUBTYPE_DMA_FAULT
IRQ that allows to signal a nested mode DMA fault.
Signed-off-by: Eric Auger
---
v10 -> v11:
- the irq now is registered in vfio_pci_dma_fault_init()
in case the domain is nested
---
drivers/vfio/pci/vfio_pci.c | 21 +++
The VFIO API was enhanced to support nested stage control: a bunch of
new iotcls, one DMA FAULT region and an associated specific IRQ.
Let's document the process to follow to set up nested mode.
Signed-off-by: Eric Auger
---
v11 -> v12:
s/VFIO_REGION_INFO_CAP_PRODUCER_FAULT/VFIO_REGION_INFO_CA
The DMA FAULT region contains the fault ring buffer.
There is benefit to let the userspace mmap this area.
Expose this mmappable area through a sparse mmap entry
and implement the mmap operation.
Signed-off-by: Eric Auger
---
v8 -> v9:
- remove unused index local variable in vfio_pci_fault_mmap
This series brings the VFIO part of HW nested paging support
in the SMMUv3.
This is a rebase on top of v5.11
The series depends on:
[PATCH v14 00/13] SMMUv3 Nested Stage Setup (IOMMU part)
3 new IOCTLs are introduced that allow the userspace to
1) pass the guest stage 1 configuration
2) pass sta
Add a new IRQ type/subtype to get notification on nested
stage DMA faults.
Signed-off-by: Eric Auger
---
include/uapi/linux/vfio.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 3688215843fe..f0eea0f9305a 100644
--- a/include/ua
From: "Liu, Yi L"
This patch adds an VFIO_IOMMU_SET_PASID_TABLE ioctl
which aims to pass the virtual iommu guest configuration
to the host. This latter takes the form of the so-called
PASID table.
Signed-off-by: Jacob Pan
Signed-off-by: Liu, Yi L
Signed-off-by: Eric Auger
---
v11 -> v12:
- u
Register an IOMMU fault handler which records faults in
the DMA FAULT region ring buffer. In a subsequent patch, we
will add the signaling of a specific eventfd to allow the
userspace to be notified whenever a new fault has shown up.
Signed-off-by: Eric Auger
---
v11 -> v12:
- take the fault_que
This patch adds the VFIO_IOMMU_SET_MSI_BINDING ioctl which aim
to (un)register the guest MSI binding to the host. This latter
then can use those stage 1 bindings to build a nested stage
binding targeting the physical MSIs.
Signed-off-by: Eric Auger
---
v11 -> v12:
- Share VFIO_BASE + 20 with VF
From: "Liu, Yi L"
When the guest "owns" the stage 1 translation structures, the host
IOMMU driver has no knowledge of caching structure updates unless
the guest invalidation requests are trapped and passed down to the
host.
This patch adds the VFIO_IOMMU_CACHE_INVALIDATE ioctl with aims
at prop
Add a new specific DMA_FAULT region aiming to exposed nested mode
translation faults. This region only is exposed if the device
is attached to a nested domain.
The region has a ring buffer that contains the actual fault
records plus a header allowing to handle it (tail/head indices,
max capacity,
In preparation for vSVA, let's accept userspace provided configs
with more than one CD. We check the max CD against the host iommu
capability and also the format (linear versus 2 level).
Signed-off-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |
Up to now, when the type was UNMANAGED, we used to
allocate IOVA pages within a reserved IOVA MSI range.
If both the host and the guest are exposed with SMMUs, each
would allocate an IOVA. The guest allocates an IOVA (gIOVA)
to map onto the guest MSI doorbell (gDB). The Host allocates
another IOVA
Up to now we have only reported translation faults. Now that
the guest can induce some configuration faults, let's report them
too. Add propagation for BAD_SUBSTREAMID, CD_FETCH, BAD_CD, WALK_EABT.
We also fix the transcoding for some existing translation faults.
Signed-off-by: Eric Auger
---
dr
The bind/unbind_guest_msi() callbacks check the domain
is NESTED and redirect to the dma-iommu implementation.
Signed-off-by: Eric Auger
---
v6 -> v7:
- remove device handle argument
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 43 +
1 file changed, 43 insertions(+)
d
In nested mode we enforce the rule that all devices belonging
to the same iommu_domain share the same msi_domain.
Indeed if there were several physical MSI doorbells being used
within a single iommu_domain, it becomes really difficult to
resolve the nested stage mapping translating into the correc
Nested mode currently is not compatible with HW MSI reserved regions.
Indeed MSI transactions targeting this MSI doorbells bypass the SMMU.
Let's check nested mode is not attempted in such configuration.
Signed-off-by: Eric Auger
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 23
Implement domain-selective, pasid selective and page-selective
IOTLB invalidations.
Signed-off-by: Eric Auger
---
v13 -> v14:
- Add domain invalidation
- do global inval when asid is not provided with addr
granularity
v7 -> v8:
- ASID based invalidation using iommu_inv_pasid_info
- check ARC
With nested stage support, soon we will need to invalidate
S1 contexts and ranges tagged with an unmanaged asid, this
latter being managed by the guest. So let's introduce 2 helpers
that allow to invalidate with externally managed ASIDs
Signed-off-by: Eric Auger
---
v13 -> v14
- Actually send t
On attach_pasid_table() we program STE S1 related info set
by the guest into the actual physical STEs. At minimum
we need to program the context descriptor GPA and compute
whether the stage1 is translated/bypassed or aborted.
On detach, the stage 1 config is unset and the abort flag is
unset.
Sig
This series brings the IOMMU part of HW nested paging support
in the SMMUv3. The VFIO part is submitted separately.
This is based on Jean-Philippe's
[PATCH v12 00/10] iommu: I/O page faults for SMMUv3
https://lore.kernel.org/linux-arm-kernel/YBfij71tyYvh8LhB@myrica/T/
The IOMMU API is extended to
When nested stage translation is setup, both s1_cfg and
s2_cfg are set.
We introduce a new smmu_domain abort field that will be set
upon guest stage1 configuration passing. If no guest stage1
config has been attached, it is ignored when writing the STE.
arm_smmu_write_strtab_ent() is modified to
In true nested mode, both s1_cfg and s2_cfg will coexist.
Let's remove the union and add a "set" field in each
config structure telling whether the config is set and needs
to be applied when writing the STE. In legacy nested mode,
only the second stage is used. In true nested mode, both stages
are
On ARM, MSI are translated by the SMMU. An IOVA is allocated
for each MSI doorbell. If both the host and the guest are exposed
with SMMUs, we end up with 2 different IOVAs allocated by each.
guest allocates an IOVA (gIOVA) to map onto the guest MSI
doorbell (gDB). The Host allocates another IOVA (h
In virtualization use case, when a guest is assigned
a PCI host device, protected by a virtual IOMMU on the guest,
the physical IOMMU must be programmed to be consistent with
the guest mappings. If the physical IOMMU supports two
translation stages it makes sense to program guest mappings
onto the
hyp_panic() reports the address of the panic by using ELR_EL2, but this
isn't a useful address when hyp_panic() is called directly. Replace such
direct calls with BUG() and BUG_ON() which use BRK to trigger and
exception that then goes to hyp_panic() with the correct address. Also
remove the hyp_pa
There is some non-trivial config-based logic to get the file name and
line number associated with a bug. Factor this out to a getter that can
be resused.
Signed-off-by: Andrew Scull
Cc: Peter Zijlstra
Cc: "Steven Rostedt (VMware)"
---
include/linux/bug.h | 3 +++
lib/bug.c | 27
Panics from arm64's nVHE hyp mode are hard to interpret. This series
adds some more debug info to help with diagnosis.
Using BUG() in nVHE hyp gives a meaningful address to locate invariants
that fail to hold. The host can also look up the bug to provide the file
and line, if the debug configs are
report_bug() will return early if it cannot find a bug corresponding to
the provided address. The subsequent test for the bug will always be
true so remove it.
Signed-off-by: Andrew Scull
Cc: Peter Zijlstra
Cc: "Steven Rostedt (VMware)"
---
lib/bug.c | 33 +++--
1 f
To aid with debugging, add details of the source of a panic. This is
done by having nVHE hyp exit to nvhe_hyp_panic_handler() rather than
directly to panic(). The handler will then add the extra details for
debugging before panicking the kernel.
If the panic was due to a BUG(), look up the metadat
On Mon, Feb 22, 2021, David Stevens wrote:
> ---
> v3 -> v4:
> - Skip prefetch while invalidations are in progress
Oof, nice catch.
...
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 9ac0a727015d..f6aaac729667 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mm
On Tue, 23 Feb 2021 15:57:57 +
Andrew Scull wrote:
> There is some non-trivial config-based logic to get the file name and
> line number associated with a bug. Factor this out to a getter that can
> be resused.
>
> Signed-off-by: Andrew Scull
> Cc: Peter Zijlstra
> Cc: "Steven Rostedt (VMw
On Tue, Feb 23, 2021 at 11:29:54AM +, Marc Zyngier wrote:
> Hi Andrew,
>
> On Tue, 23 Feb 2021 09:49:27 +,
> Andrew Scull wrote:
> >
> > To aid with debugging, add details of the source of a panic. This is
> > done by having nVHE hyp exit to nvhe_hyp_panic_handler() rather than
> > direc
On Tue, 23 Feb 2021 15:57:56 +
Andrew Scull wrote:
> report_bug() will return early if it cannot find a bug corresponding to
> the provided address. The subsequent test for the bug will always be
> true so remove it.
Fixes: 1b4cfe3c0a30d ("lib/bug.c: exclude non-BUG/WARN exceptions from
rep
Hi Yanan,
I wanted to review the patches, but unfortunately I get an error when trying to
apply the first patch in the series:
Applying: KVM: arm64: Move the clean of dcache to the map handler
error: patch failed: arch/arm64/kvm/hyp/pgtable.c:464
error: arch/arm64/kvm/hyp/pgtable.c: patch does no
On Tue, 23 Feb 2021 12:34:22 +,
Andrew Scull wrote:
>
> On Tue, Feb 23, 2021 at 11:29:54AM +, Marc Zyngier wrote:
[...]
> > Would it be worth making it a helper that lives there? Something
> > like
> >
> > struct bug_entry *bug_get_entry(unsigned long pc, char **file,
> >
hyp_panic() reports the address of the panic by using ELR_EL2, but this
isn't a useful address when hyp_panic() is called directly. Replace such
direct calls with BUG() and BUG_ON() which use BRK to trigger and
exception that then goes to hyp_panic() with the correct address. Also
remove the hyp_pa
To aid with debugging, add details of the source of a panic. This is
done by having nVHE hyp exit to nvhe_hyp_panic_handler() rather than
directly to panic(). The handler will then add the extra details for
debugging before panicking the kernel.
If the panic was due to a BUG(), look up the metadat
After being on the receiving end of an nVHE hyp panic and trying to
figure out what is was trying to tell me, it seemed like a good excuse
to add some debug info.
nVHE hyp has its own address space. Hyp VAs aren't much use for
debugging but they can be converted into kimg addresses which are
usefu
Hi Shenming,
On 2/23/21 1:45 PM, Shenming Lu wrote:
>> +static int vfio_pci_dma_fault_init(struct vfio_pci_device *vdev)
>> +{
>> +struct vfio_region_dma_fault *header;
>> +struct iommu_domain *domain;
>> +size_t size;
>> +bool nested;
>> +int ret;
>> +
>> +domain = iommu_g
> +static int vfio_pci_dma_fault_init(struct vfio_pci_device *vdev)
> +{
> + struct vfio_region_dma_fault *header;
> + struct iommu_domain *domain;
> + size_t size;
> + bool nested;
> + int ret;
> +
> + domain = iommu_get_domain_for_dev(&vdev->pdev->dev);
> + ret = iommu
Hi Andrew,
On Tue, 23 Feb 2021 09:49:27 +,
Andrew Scull wrote:
>
> To aid with debugging, add details of the source of a panic. This is
> done by having nVHE hyp exit to nvhe_hyp_panic_handler() rather than
> directly to panic(). The handler will then add the extra details for
> debugging be
On Thu, 18 Feb 2021 at 06:10, Marc Zyngier wrote:
>
> On Thu, 04 Feb 2021 07:51:37 +,
> Haibo Xu wrote:
> >
> > Kindly ping!
> >
> > On Thu, 21 Jan 2021 at 11:03, Haibo Xu wrote:
> > >
> > > Re-send in case the previous email was blocked for the inlined hyper-link.
> > >
> > > Hi Marc,
> > >
51 matches
Mail list logo
