Hi Fenghua,
On 9/21/21 3:23 AM, Fenghua Yu wrote:
PASIDs are fundamentally hardware resources in a shared address space.
There is a limited number of them to use ENQCMD on shared workqueue.
They must be shared and managed. They can not, for instance, be
statically allocated to processes.
Free
From: Hamza Mahfooz
[ Upstream commit 510e1a724ab1bf38150be2c1acabb303f98d0047 ]
For some drivers, that use the DMA API. This error message can be reached
several millions of times per second, causing spam to the kernel's printk
buffer and bringing the CPU usage up to 100% (so, it should be
> From: Tian, Kevin
> Sent: Thursday, September 23, 2021 11:11 AM
>
> >
> > The required behavior for iommufd is to have the IOMMU ignore the
> > no-snoop bit so that Intel HW can disable wbinvd. This bit should be
> > clearly documented for its exact purpose and if other arches also have
> >
> From: Jason Gunthorpe
> Sent: Thursday, September 23, 2021 7:50 AM
>
> On Wed, Sep 22, 2021 at 03:24:07PM -0600, Alex Williamson wrote:
> > On Sun, 19 Sep 2021 14:38:38 +0800
> > Liu Yi L wrote:
> >
> > > +struct iommu_device_info {
> > > + __u32 argsz;
> > > + __u32 flags;
> > > +#define
> From: Jason Gunthorpe
> Sent: Thursday, September 23, 2021 7:52 AM
>
> On Wed, Sep 22, 2021 at 11:45:33PM +, Tian, Kevin wrote:
> > > From: Alex Williamson
>
> > btw I realized another related piece regarding to the new layout that
> > Jason suggested, which have sys device node include
On Wed, Sep 22, 2021 at 02:10:36PM -0600, Alex Williamson wrote:
> But why would we create vfio device interface files at all if they
> can't work? I'm not really on board with creating a try-and-fail
> interface for a mechanism that cannot work for a given device. The
> existence of the device
On Wed, Sep 22, 2021 at 11:45:33PM +, Tian, Kevin wrote:
> > From: Alex Williamson
> btw I realized another related piece regarding to the new layout that
> Jason suggested, which have sys device node include a link to the vfio
> devnode:
>
>
On Wed, Sep 22, 2021 at 03:24:07PM -0600, Alex Williamson wrote:
> On Sun, 19 Sep 2021 14:38:38 +0800
> Liu Yi L wrote:
>
> > +struct iommu_device_info {
> > + __u32 argsz;
> > + __u32 flags;
> > +#define IOMMU_DEVICE_INFO_ENFORCE_SNOOP(1 << 0) /* IOMMU enforced
> > snoop */
>
> Is
> From: Alex Williamson
> Sent: Thursday, September 23, 2021 5:17 AM
>
> On Wed, 22 Sep 2021 01:19:08 +
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Wednesday, September 22, 2021 5:09 AM
> > >
> > > On Tue, 21 Sep 2021 13:40:01 -0300
> > > Jason Gunthorpe wrote:
> > >
> From: Alex Williamson
> Sent: Thursday, September 23, 2021 6:45 AM
>
> On Wed, 22 Sep 2021 22:34:42 +
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Thursday, September 23, 2021 4:11 AM
> > >
> > > On Wed, 22 Sep 2021 09:22:52 -0300
> > > Jason Gunthorpe wrote:
> > >
Hi, Peter,
On Wed, Sep 22, 2021 at 11:03:43PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 20, 2021 at 07:23:48PM +, Fenghua Yu wrote:
> > + ret = validate_enqcmd(file);
> > + if (ret < 0)
> > + goto out;
> > + warnings += ret;
> > +
> > if (vmlinux && !validate_dup) {
> >
Hi, Peter,
On Wed, Sep 22, 2021 at 11:07:22PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 20, 2021 at 07:23:45PM +, Fenghua Yu wrote:
> >
> > + if (user_mode(regs) && fixup_pasid_exception())
> > + goto exit;
> > +
> > if (static_cpu_has(X86_FEATURE_UMIP)) {
> >
On Wed, Sep 22, 2021 at 03:01:01PM -0600, Alex Williamson wrote:
> On Tue, 21 Sep 2021 14:29:39 -0300
> Jason Gunthorpe wrote:
>
> > On Sun, Sep 19, 2021 at 02:38:36PM +0800, Liu Yi L wrote:
> > > +struct vfio_device_iommu_bind_data {
> > > + __u32 argsz;
> > > + __u32 flags;
> > > + __s32
On Wed, 22 Sep 2021 22:34:42 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Thursday, September 23, 2021 4:11 AM
> >
> > On Wed, 22 Sep 2021 09:22:52 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Wed, Sep 22, 2021 at 09:23:34AM +, Tian, Kevin wrote:
> > >
> > > > >
> From: Alex Williamson
> Sent: Thursday, September 23, 2021 4:11 AM
>
> On Wed, 22 Sep 2021 09:22:52 -0300
> Jason Gunthorpe wrote:
>
> > On Wed, Sep 22, 2021 at 09:23:34AM +, Tian, Kevin wrote:
> >
> > > > Providing an ioctl to bind to a normal VFIO container or group might
> > > > allow
From: Rob Clark
Add an io-pgtable method to retrieve the raw PTEs that would be
traversed for a given iova access.
Signed-off-by: Rob Clark
---
drivers/iommu/io-pgtable-arm.c | 40 +++---
include/linux/io-pgtable.h | 9
2 files changed, 41
From: Rob Clark
This series extends io-pgtable-arm with a method to retrieve the page
table entries traversed in the process of address translation, and then
beefs up drm/msm gpu devcore dump to include this (and additional info)
in the devcore dump.
The motivation is tracking down an obscure
Hi, Peter,
On Wed, Sep 22, 2021 at 11:11:45PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 22, 2021 at 11:07:22PM +0200, Peter Zijlstra wrote:
> > On Mon, Sep 20, 2021 at 07:23:45PM +, Fenghua Yu wrote:
> > > +static bool fixup_pasid_exception(void)
> > > +{
> > > + if
On 9/22/21 2:11 PM, Peter Zijlstra wrote:
>>> +static bool fixup_pasid_exception(void)
>>> +{
>>> + if (!cpu_feature_enabled(X86_FEATURE_ENQCMD))
>>> + return false;
>>> +
>>> + return __fixup_pasid_exception();
>>> +}
> That is, shouldn't the above at the very least decode the
>> > +static bool fixup_pasid_exception(void)
>> > +{
>> > + if (!cpu_feature_enabled(X86_FEATURE_ENQCMD))
>> > + return false;
>> > +
>> > + return __fixup_pasid_exception();
>> > +}
>
> That is, shouldn't the above at the very least decode the instruction
> causing the #GP and check
On Sun, 19 Sep 2021 14:38:38 +0800
Liu Yi L wrote:
> +struct iommu_device_info {
> + __u32 argsz;
> + __u32 flags;
> +#define IOMMU_DEVICE_INFO_ENFORCE_SNOOP (1 << 0) /* IOMMU enforced
> snoop */
Is this too PCI specific, or perhaps too much of the mechanism rather
than the
On Wed, 22 Sep 2021 01:19:08 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Wednesday, September 22, 2021 5:09 AM
> >
> > On Tue, 21 Sep 2021 13:40:01 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Sun, Sep 19, 2021 at 02:38:33PM +0800, Liu Yi L wrote:
> > > > This patch
On Wed, Sep 22, 2021 at 11:07:22PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 20, 2021 at 07:23:45PM +, Fenghua Yu wrote:
> > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> > index a58800973aed..a25d738ae839 100644
> > --- a/arch/x86/kernel/traps.c
> > +++
On Mon, Sep 20, 2021 at 07:23:45PM +, Fenghua Yu wrote:
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index a58800973aed..a25d738ae839 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -61,6 +61,7 @@
> #include
> #include
> #include
>
On Wed, Sep 22, 2021 at 09:52:07PM +0200, Borislav Petkov wrote:
> On Wed, Sep 22, 2021 at 05:30:15PM +0300, Kirill A. Shutemov wrote:
> > Not fine, but waiting to blowup with random build environment change.
>
> Why is it not fine?
>
> Are you suspecting that the compiler might generate
On Mon, Sep 20, 2021 at 07:23:48PM +, Fenghua Yu wrote:
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index e5947fbb9e7a..91d13521d9d6 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -3133,6 +3133,21 @@ static int
On Tue, 21 Sep 2021 14:29:39 -0300
Jason Gunthorpe wrote:
> On Sun, Sep 19, 2021 at 02:38:36PM +0800, Liu Yi L wrote:
> > +struct vfio_device_iommu_bind_data {
> > + __u32 argsz;
> > + __u32 flags;
> > + __s32 iommu_fd;
> > + __u64 dev_cookie;
>
> Missing explicit padding
>
>
On Wed, 22 Sep 2021 09:22:52 -0300
Jason Gunthorpe wrote:
> On Wed, Sep 22, 2021 at 09:23:34AM +, Tian, Kevin wrote:
>
> > > Providing an ioctl to bind to a normal VFIO container or group might
> > > allow a reasonable fallback in userspace..
> >
> > I didn't get this point though. An
On Wed, Sep 22, 2021 at 05:30:15PM +0300, Kirill A. Shutemov wrote:
> Not fine, but waiting to blowup with random build environment change.
Why is it not fine?
Are you suspecting that the compiler might generate something else and
not a rip-relative access?
--
Regards/Gruss,
Boris.
On Tue, Sep 21, 2021 at 01:29:34PM -0700, Jacob Pan wrote:
> Hi Joerg/Jason/Christoph et all,
>
> The current in-kernel supervisor PASID support is based on the SVM/SVA
> machinery in sva-lib. Kernel SVA is achieved by extending a special flag
> to indicate the binding of the device and a page
On Sun, Sep 19, 2021 at 02:38:45PM +0800, Liu Yi L wrote:
> [HACK. will fix in v2]
>
> IOVA range is critical info for userspace to manage DMA for an I/O address
> space. This patch reports the valid iova range info of a given device.
>
> Due to aforementioned hack, this info comes from the
On Wed, Sep 22, 2021 at 08:40:43AM -0500, Tom Lendacky wrote:
> On 9/21/21 4:58 PM, Kirill A. Shutemov wrote:
> > On Tue, Sep 21, 2021 at 04:43:59PM -0500, Tom Lendacky wrote:
> > > On 9/21/21 4:34 PM, Kirill A. Shutemov wrote:
> > > > On Tue, Sep 21, 2021 at 11:27:17PM +0200, Borislav Petkov
> From: Eric Auger
> Sent: Wednesday, September 22, 2021 9:43 PM
>
> Hi,
>
> On 9/19/21 8:38 AM, Liu Yi L wrote:
> > From: Lu Baolu
> >
> > This exposes PAGE_SIZE and ADDR_WIDTH attributes. The iommufd could
> use
> > them to define the IOAS.
> >
> > Signed-off-by: Lu Baolu
> > ---
> >
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 8:59 PM
>
> On Wed, Sep 22, 2021 at 03:56:18AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, September 22, 2021 2:04 AM
> > >
> > > On Sun, Sep 19, 2021 at 02:38:43PM +0800, Liu Yi L wrote:
> > > > This
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 8:57 PM
>
> On Wed, Sep 22, 2021 at 03:53:52AM +, Tian, Kevin wrote:
>
> > Actually this was one open we closed in previous design proposal, but
> > looks you have a different thought now.
> >
> > vfio maintains one ioas per
On Wed, Sep 22, 2021 at 01:59:39PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, September 22, 2021 8:41 PM
> >
> > On Wed, Sep 22, 2021 at 01:51:03AM +, Tian, Kevin wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Tuesday, September 21, 2021 11:42 PM
> > > >
>
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 8:51 PM
>
> On Wed, Sep 22, 2021 at 03:22:42AM +, Tian, Kevin wrote:
> > > From: Tian, Kevin
> > > Sent: Wednesday, September 22, 2021 9:07 AM
> > >
> > > > From: Jason Gunthorpe
> > > > Sent: Wednesday, September 22, 2021 8:55
On Wed, Sep 22, 2021 at 03:40:25AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, September 22, 2021 1:45 AM
> >
> > On Sun, Sep 19, 2021 at 02:38:39PM +0800, Liu Yi L wrote:
> > > This patch adds IOASID allocation/free interface per iommufd. When
> > > allocating an
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 8:41 PM
>
> On Wed, Sep 22, 2021 at 01:51:03AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, September 21, 2021 11:42 PM
> > >
> > > - Delete the iommufd_ctx->lock. Use RCU to protect load, erase/alloc
>
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 8:40 PM
>
> On Wed, Sep 22, 2021 at 01:47:05AM +, Tian, Kevin wrote:
>
> > > IIRC in VFIO the container is the IOAS and when the group goes to
> > > create the device fd it should simply do the
> > > iommu_device_init_user_dma()
On Sun, Sep 19, 2021 at 02:38:39PM +0800, Liu Yi L wrote:
> This patch adds IOASID allocation/free interface per iommufd. When
> allocating an IOASID, userspace is expected to specify the type and
> format information for the target I/O page table.
>
> This RFC supports only one type
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 8:23 PM
>
> On Wed, Sep 22, 2021 at 09:23:34AM +, Tian, Kevin wrote:
>
> > > Providing an ioctl to bind to a normal VFIO container or group might
> > > allow a reasonable fallback in userspace..
> >
> > I didn't get this point
Hi,
On 9/19/21 8:38 AM, Liu Yi L wrote:
> From: Lu Baolu
>
> This exposes PAGE_SIZE and ADDR_WIDTH attributes. The iommufd could use
> them to define the IOAS.
>
> Signed-off-by: Lu Baolu
> ---
> include/linux/iommu.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git
On 9/21/21 4:58 PM, Kirill A. Shutemov wrote:
On Tue, Sep 21, 2021 at 04:43:59PM -0500, Tom Lendacky wrote:
On 9/21/21 4:34 PM, Kirill A. Shutemov wrote:
On Tue, Sep 21, 2021 at 11:27:17PM +0200, Borislav Petkov wrote:
On Wed, Sep 22, 2021 at 12:20:59AM +0300, Kirill A. Shutemov wrote:
I
On Wed, Sep 22, 2021 at 12:51:38PM +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, September 22, 2021 1:45 AM
> >
> [...]
> > > diff --git a/drivers/iommu/iommufd/iommufd.c
> > b/drivers/iommu/iommufd/iommufd.c
> > > index 641f199f2d41..4839f128b24a 100644
> > > +++
On Wed, Sep 22, 2021 at 03:56:18AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, September 22, 2021 2:04 AM
> >
> > On Sun, Sep 19, 2021 at 02:38:43PM +0800, Liu Yi L wrote:
> > > This patch adds interface for userspace to attach device to specified
> > > IOASID.
> > >
On Wed, Sep 22, 2021 at 03:53:52AM +, Tian, Kevin wrote:
> Actually this was one open we closed in previous design proposal, but
> looks you have a different thought now.
>
> vfio maintains one ioas per container. Devices in the container
> can be attached to different domains (e.g. due to
On Wed, Sep 22, 2021 at 03:41:50AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, September 22, 2021 1:47 AM
> >
> > On Sun, Sep 19, 2021 at 02:38:40PM +0800, Liu Yi L wrote:
> > > As aforementioned, userspace should check extension for what formats
> > > can be
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 1:45 AM
>
[...]
> > diff --git a/drivers/iommu/iommufd/iommufd.c
> b/drivers/iommu/iommufd/iommufd.c
> > index 641f199f2d41..4839f128b24a 100644
> > +++ b/drivers/iommu/iommufd/iommufd.c
> > @@ -24,6 +24,7 @@
> > struct iommufd_ctx {
On Wed, Sep 22, 2021 at 03:22:42AM +, Tian, Kevin wrote:
> > From: Tian, Kevin
> > Sent: Wednesday, September 22, 2021 9:07 AM
> >
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, September 22, 2021 8:55 AM
> > >
> > > On Tue, Sep 21, 2021 at 11:56:06PM +, Tian, Kevin wrote:
> > > > >
On Wed, Sep 22, 2021 at 03:30:09AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, September 22, 2021 1:41 AM
> >
> > On Sun, Sep 19, 2021 at 02:38:38PM +0800, Liu Yi L wrote:
> > > After a device is bound to the iommufd, userspace can use this interface
> > > to query
On Wed, Sep 22, 2021 at 01:51:03AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, September 21, 2021 11:42 PM
> >
> > - Delete the iommufd_ctx->lock. Use RCU to protect load, erase/alloc does
> >not need locking (order it properly too, it is in the wrong order), and
On Wed, Sep 22, 2021 at 01:47:05AM +, Tian, Kevin wrote:
> > IIRC in VFIO the container is the IOAS and when the group goes to
> > create the device fd it should simply do the
> > iommu_device_init_user_dma() followed immediately by a call to bind
> > the container IOAS as your #3.
>
> a
On Wed, Sep 22, 2021 at 01:07:11AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, September 22, 2021 8:55 AM
> >
> > On Tue, Sep 21, 2021 at 11:56:06PM +, Tian, Kevin wrote:
> > > > The opened atomic is aweful. A newly created fd should start in a
> > > > state
On Wed, Sep 22, 2021 at 09:23:34AM +, Tian, Kevin wrote:
> > Providing an ioctl to bind to a normal VFIO container or group might
> > allow a reasonable fallback in userspace..
>
> I didn't get this point though. An error in binding already allows the
> user to fall back to the group path.
On Fri, Aug 27, 2021 at 09:28:25AM -0400, Ross Philipson wrote:
> The x86 boot documentation describes the setup_indirect structures and
> how they are used. Only one of the two functions in ioremap.c that needed
> to be modified to be aware of the introduction of setup_indirect
> functionality
On Fri, Aug 27, 2021 at 09:28:24AM -0400, Ross Philipson wrote:
> As documented, the setup_indirect structure is nested inside
> the setup_data structures in the setup_data list. The code currently
> accesses the fields inside the setup_indirect structure but only
> the sizeof(struct setup_data)
Hi Christoph:
This patch follows your purposal in the previous discussion.
Could you have a look?
"use vmap_pfn as in the current series. But in that case I think
we should get rid of the other mapping created by vmalloc. I
though a bit about finding a way to apply the offset in
> From: Jason Gunthorpe
> Sent: Wednesday, September 22, 2021 8:54 AM
>
> On Tue, Sep 21, 2021 at 11:10:15PM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, September 22, 2021 12:01 AM
> > >
> > > On Sun, Sep 19, 2021 at 02:38:31PM +0800, Liu Yi L wrote:
> > > >
On Tue, 14 Sep 2021 19:36:50 +0800, Yong Wu wrote:
> This patchset mainly adds SMI support for mt8195.
>
> Comparing with the previous version, add two new functions:
> a) add smi sub common
> b) add initial setting for smi-common and smi-larb.
>
> Change note:
> v4:1) base on v5.15-rc1
>2)
60 matches
Mail list logo
