On Mon, Jun 15, 2020 at 06:03:57PM +0200, Peter Zijlstra wrote:
>
> I don't get why you need a rdmsr here, or why not having one would
> require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed?
>
> > > > +*/
> > > > + rdmsrl(MSR_IA32_PASID, pasid_msr);
> > > > +
Hi, Peter,
On Mon, Jun 15, 2020 at 08:31:16PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 15, 2020 at 11:12:59AM -0700, Fenghua Yu wrote:
> > > I don't get why you need a rdmsr here, or why not having one would
> > > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed?
> >
> > My
Hi, Peter,
On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
>
> > Or do you suggest to add a random new flag in struct thread_info instead
> > of a TIF flag?
>
> Why thread_info? What's wrong with something simple like
On Mon, Jun 15, 2020 at 08:47:05AM +0200, Mauro Carvalho Chehab wrote:
> As we moved those files to core-api, fix references to point
> to their newer locations.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/PCI/pci.rst | 6 +++---
>
> On Jun 15, 2020, at 1:56 PM, Luck, Tony wrote:
>
>
>>
>> Are we planning to keep PASID live once a task has used it once or are we
>> going to swap it lazily? If the latter, a percpu variable might be better.
>
> Current plan is "touch it once and the task owns it until exit(2)"
>
>
On Mon, Jun 15, 2020 at 06:03:57PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 15, 2020 at 08:48:54AM -0700, Fenghua Yu wrote:
> > Hi, Peter,
> > On Mon, Jun 15, 2020 at 09:56:49AM +0200, Peter Zijlstra wrote:
> > > On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote:
> > > > +/*
> > > > + *
On Mon, Jun 15, 2020 at 11:19:21AM -0700, Raj, Ashok wrote:
> On Mon, Jun 15, 2020 at 06:03:57PM +0200, Peter Zijlstra wrote:
> >
> > I don't get why you need a rdmsr here, or why not having one would
> > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed?
> >
> > > > > +
On Mon, Jun 15, 2020 at 11:12:59AM -0700, Fenghua Yu wrote:
> > I don't get why you need a rdmsr here, or why not having one would
> > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed?
>
> My concern is TIF flags are precious (only 3 slots available). Defining
> a new TIF flag
On Mon, 1 Jun 2020, Suravee Suthikulpanit wrote:
> Alexander
>
> On 6/1/20 4:01 PM, Alexander Monakov wrote:
> > On Mon, 1 Jun 2020, Suravee Suthikulpanit wrote:
> >
> > > > Moving init_iommu_perf_ctr just after iommu_flush_all_caches resolves
> > > > the issue. This is the earliest point in
On Mon, Jun 15, 2020 at 01:17:35PM -0700, Fenghua Yu wrote:
> Hi, Peter,
>
> On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
> > On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
> >
> > > Or do you suggest to add a random new flag in struct thread_info instead
> > > of
> On Jun 15, 2020, at 1:17 PM, Fenghua Yu wrote:
>
> Hi, Peter,
>
>> On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
>>> On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
>>>
>>> Or do you suggest to add a random new flag in struct thread_info instead
>>> of a TIF
On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
> Or do you suggest to add a random new flag in struct thread_info instead
> of a TIF flag?
Why thread_info? What's wrong with something simple like the below. It
takes a bit from the 'strictly current' flags word.
diff --git
> Are we planning to keep PASID live once a task has used it once or are we
> going to swap it lazily? If the latter, a percpu variable might be better.
Current plan is "touch it once and the task owns it until exit(2)"
Maybe someday in the future when we have data on how applications
actually
> So what’s the RDMSR for? Surely you
> have some state somewhere that says “this task has a PASID.”
> Can’t you just make sure that stays in sync with the MSR? Then, on #GP, if
> the task already has a PASID, you know the MSR is set.
We have state that says the process ("mm") has been
When enabling ACS, currently the bit "translation blocking" was
not getting changed at all. Set it to disable translation blocking
too for all external facing or untrusted devices. This is OK
because ATS is only allowed on internal devces.
Signed-off-by: Rajat Jain
---
drivers/pci/pci.c| 4
Currently this is being looked up at a number of places. Read
and store it once at bootup so that it can be used by all later.
Signed-off-by: Rajat Jain
---
drivers/pci/p2pdma.c | 2 +-
drivers/pci/pci.c| 21 +
drivers/pci/pci.h| 2 +-
drivers/pci/probe.c | 2 +-
On Mon, Jun 15, 2020 at 06:17:42PM -0700, Rajat Jain wrote:
> This is needed to allow the userspace to determine when an untrusted
> device has been added, and thus allowing it to bind the driver manually
> to it, if it so wishes. This is being done as part of the approach
> discussed at
On Thu, Jun 11, 2020 at 12:20:29PM -0700, David Rientjes wrote:
> If arch_dma_set_uncached() fails after memory has been decrypted, it needs
> to be re-encrypted before freeing.
>
> Fixes: fa7e2247c572 ("dma-direct: make uncached_kernel_address more
> general")
> Cc: sta...@vger.kernel.org # 5.7
Hi Jon,
That's a bunch of files I have to be applied on the top of v5.8-rc1 fixing
documentation warnings. I already removed some duplicated stuff.
Regards,
Mauro
Mauro Carvalho Chehab (29):
mm: vmalloc.c: remove a kernel-doc annotation from a removed parameter
net: dev: add a missing
nommu configfs can trivially map the coherent allocations to user space,
as no actual page table setup is required and the kernel and the user
space programs share the same address space.
Fixes: 62fcee9a3bd7 ("dma-mapping: remove CONFIG_ARCH_NO_COHERENT_DMA_MMAP")
Signed-off-by: Christoph Hellwig
Hi Koba Ko,
On 2020/6/15 11:19, Koba Ko wrote:
hi All,
I have a machine and there's only intel gpu.
the secureboot and vt-d is enabled in BIOS.
On the Ubuntu desktop, I do s2idle first and restart the machine.
The machine can't restart successfully, so I need to press the
power button to
On 12/06/2020 15:30, Lorenzo Pieralisi wrote:
On Mon, Feb 17, 2020 at 12:08:48PM +, John Garry wrote:
Right, and even worse is that it relies on the port driver even
existing at all.
All this iommu group assignment should be taken outside device
driver probe paths.
However we could still
On Thu, Jun 11, 2020 at 12:20:32PM -0700, David Rientjes wrote:
> When a coherent mapping is created in dma_direct_alloc_pages(), it needs
> to be decrypted if the device requires unencrypted DMA before returning.
>
> Fixes: 3acac065508f ("dma-mapping: merge the generic remapping helpers
> into
As we moved those files to core-api, fix references to point
to their newer locations.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/PCI/pci.rst | 6 +++---
Documentation/block/biodoc.rst | 2 +-
On Thu, Jun 11, 2020 at 12:20:28PM -0700, David Rientjes wrote:
> dma_alloc_contiguous() does size >> PAGE_SHIFT and set_memory_decrypted()
> works at page granularity. It's necessary to page align the allocation
> size in dma_direct_alloc_pages() for consistent behavior.
>
> This also fixes an
Hi Kevin,
> From: Tian, Kevin
> Sent: Monday, June 15, 2020 9:23 AM
>
> > From: Liu, Yi L
> > Sent: Friday, June 12, 2020 5:05 PM
> >
> > Hi Alex,
> >
> > > From: Alex Williamson
> > > Sent: Friday, June 12, 2020 3:30 AM
> > >
> > > On Thu, 11 Jun 2020 05:15:21 -0700
> > > Liu Yi L wrote:
>
The "ExternalFacing" devices (root ports) are still internal devices
that sit on the internal system fabric and thus trusted. Currently they
were being marked untrusted - likely as an unintended border case.
This patch uses the platform flag to identify the external facing devices
and then use it
This is needed to allow the userspace to determine when an untrusted
device has been added, and thus allowing it to bind the driver manually
to it, if it so wishes. This is being done as part of the approach
discussed at https://lkml.org/lkml/2020/6/9/1331
Signed-off-by: Rajat Jain
---
> From: Liu, Yi L
> Sent: Monday, June 15, 2020 2:05 PM
>
> Hi Kevin,
>
> > From: Tian, Kevin
> > Sent: Monday, June 15, 2020 9:23 AM
> >
> > > From: Liu, Yi L
> > > Sent: Friday, June 12, 2020 5:05 PM
> > >
> > > Hi Alex,
> > >
> > > > From: Alex Williamson
> > > > Sent: Friday, June 12,
On Sat, Jun 13, 2020 at 10:30:56PM +0800, Zhangfei Gao wrote:
> On 2020/6/11 下午9:44, Bjorn Helgaas wrote:
> > +++ b/drivers/iommu/iommu.c
> > > > > > > > > > @@ -2418,6 +2418,10 @@ int iommu_fwspec_init(struct device
> > > > > > > > > > *dev, struct
> > > > > > > > > > fwnode_handle
> From: Stefan Hajnoczi
> Sent: Monday, June 15, 2020 6:02 PM
>
> On Thu, Jun 11, 2020 at 05:15:19AM -0700, Liu Yi L wrote:
> > Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
> > Intel platforms allows address space sharing between device DMA and
> > applications. SVA can
Hi, Baolu,
On Sat, Jun 13, 2020 at 08:17:40PM +0800, Lu Baolu wrote:
> Hi Fenghua,
>
> On 2020/6/13 8:41, Fenghua Yu wrote:
> >+implement implement fairness or ensure forward progress can be made.
>
> Repeated "implement".
Will fix this.
> >+For example, the Intel Data Streaming Accelerator
On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote:
> @@ -447,6 +458,18 @@ dotraplinkage void do_general_protection(struct pt_regs
> *regs, long error_code)
> int ret;
>
> RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
> +
> + /*
> + * Perform
On Fri, Jun 12, 2020 at 05:41:21PM -0700, Fenghua Yu wrote:
> This series only provides simple and basic support for ENQCMD and the MSR:
> 1. Clean up type definitions (patch 1-3). These patches can be in a
>separate series.
>- Define "pasid" as "unsigned int" consistently (patch 1 and
On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote:
> +/*
> + * Apply some heuristics to see if the #GP fault was caused by a thread
> + * that hasn't had the IA32_PASID MSR initialized. If it looks like that
> + * is the problem, try initializing the IA32_PASID MSR. If the heuristic
> +
> From: Stefan Hajnoczi
> Sent: Monday, June 15, 2020 6:02 PM
>
> On Thu, Jun 11, 2020 at 05:15:19AM -0700, Liu Yi L wrote:
> > Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
> > Intel platforms allows address space sharing between device DMA and
> > applications. SVA can
hi All,
I have a machine and there's only intel gpu.
the secureboot and vt-d is enabled in BIOS.
On the Ubuntu desktop, I do s2idle first and restart the machine.
The machine can't restart successfully, so I need to press the power button
to shutdown.
I tried each of the following and the issue
On Thu, Jun 11, 2020 at 05:15:33AM -0700, Liu Yi L wrote:
> From: Eric Auger
>
> The VFIO API was enhanced to support nested stage control: a bunch of
> new iotcls and usage guideline.
>
> Let's document the process to follow to set up nested mode.
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc:
hi All,
I have a machine and there's only intel gpu.
the secureboot and vt-d is enabled in BIOS.
On the Ubuntu desktop, I do s2idle first and restart the machine.
The machine can't restart successfully, so I need to press the power
button to shutdown.
I tried each of the following and the issue
On Thu, Jun 11, 2020 at 05:15:19AM -0700, Liu Yi L wrote:
> Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
> Intel platforms allows address space sharing between device DMA and
> applications. SVA can reduce programming complexity and enhance security.
>
> This VFIO series
Fix NULL pointer error if removing uacce's parent module during app's
running. SIGBUS is already reported by do_page_fault, so uacce_vma_fault
is not needed. If providing vma_fault, vmf->page has to be filled as well,
required by __do_fault.
Reported-by: Jean-Philippe Brucker
Signed-off-by:
On Mon, Jun 15, 2020 at 08:48:54AM -0700, Fenghua Yu wrote:
> Hi, Peter,
> On Mon, Jun 15, 2020 at 09:56:49AM +0200, Peter Zijlstra wrote:
> > On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote:
> > > +/*
> > > + * Apply some heuristics to see if the #GP fault was caused by a thread
> > >
25.05.2020 22:54, Dmitry Osipenko пишет:
> The mapping operations of the Tegra SMMU driver are subjected to a race
> condition issues because SMMU Address Space isn't allocated and freed
> atomically, while it should be. This patch makes the mapping operations
> atomic, it fixes an accidentally
Reviewed-by: Suravee Suthikulpanit
Thanks,
Suravee
On 6/13/20 6:11 AM, Jerry Snitselaar wrote:
Move AMD Kconfig and Makefile bits down into the amd directory
with the rest of the AMD specific files.
Cc: Joerg Roedel
Cc: Suravee Suthikulpanit
Signed-off-by: Jerry Snitselaar
---
Hi, Peter,
On Mon, Jun 15, 2020 at 09:52:02AM +0200, Peter Zijlstra wrote:
> On Fri, Jun 12, 2020 at 05:41:21PM -0700, Fenghua Yu wrote:
>
> > This series only provides simple and basic support for ENQCMD and the MSR:
> > 1. Clean up type definitions (patch 1-3). These patches can be in a
> >
Hi, Peter,
On Mon, Jun 15, 2020 at 09:56:49AM +0200, Peter Zijlstra wrote:
> On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote:
> > +/*
> > + * Apply some heuristics to see if the #GP fault was caused by a thread
> > + * that hasn't had the IA32_PASID MSR initialized. If it looks like
>> The heuristic always initializes the MSR with the per mm PASID IIF the
>> mm has a valid PASID but the MSR doesn't have one. This heuristic usually
>> happens only once on the first #GP in a thread.
>
> But it doesn't guarantee the PASID is the right one. Suppose both the mm
> has a PASID and
47 matches
Mail list logo
