On 27/03/2019 08:04, Christoph Hellwig wrote:
arch_dma_prep_coherent can handle physically contiguous ranges larger
than PAGE_SIZE just fine, which means we don't need a page-based
iterator.
Heh, I got several minutes into writing a "but highmem..." reply before
finding csky's
On 05/04/2019 17:39, Will Deacon wrote:
>>> I'm wondering whether we can't take this a bit further and re-organise the
>>> data structures to make this a little simpler overall. Something along the
>>> lines of:
>>>
>>> struct arm_smmu_master_data {
>>> struct list_head
Hey Lu,
My bad, did some debugging on my end. The issue was swapping out
find_domain for iommu_get_domain_for_dev. It seems in some situations the
domain is not attached to the group but the device is expected to have the
domain still stored in its archdata.
I’ve attached the final patch with
On 27/03/2019 08:04, Christoph Hellwig wrote:
We now have a arch_dma_prep_coherent architecture hook that is used
for the generic DMA remap allocator, and we should use the same
interface for the dma-iommu code.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
On 27/03/2019 08:04, Christoph Hellwig wrote:
No need for a __KERNEL__ guard outside uapi and add a missing comment
describing the #else cpp statement. Last but not least include
instead of the asm version, which is frowned upon.
Signed-off-by: Christoph Hellwig
---
On 27/03/2019 08:04, Christoph Hellwig wrote:
Add a Kconfig symbol that indicates an architecture provides a
arch_dma_prep_coherent implementation, and provide a stub otherwise.
This will allow the generic dma-iommu code to it while still allowing
I think you accidentally a word there.
to
On 4/5/19 10:27 AM, Andy Lutomirski wrote:
> At the risk of asking stupid questions: we already have a mechanism for this:
> highmem. Can we enable highmem on x86_64, maybe with some heuristics to make
> it work well?
>
I proposed using highmem infrastructure for xpfo in my cover letter as
On 27/03/2019 08:04, Christoph Hellwig wrote:
The nr_pages checks should be done for all mmap requests, not just those
using remap_pfn_range.
Hmm, the logic in iommu_dma_mmap() inherently returns an error for the
"off >= nr_pages" case already. It's also supposed to be robust against
the
On 27/03/2019 08:04, Christoph Hellwig wrote:
DMA allocations that can't sleep may return non-remapped addresses, but
we do not properly handle them in the mmap and get_sgtable methods.
Resolve non-vmalloc addresses using virt_to_page to handle this corner
case.
Signed-off-by: Christoph Hellwig
> Sorry - "Thread Local Storage" - e.g. registers spilled to memory from a
> shader program.
Gotcha, thank you. Register spilling isn't implemented yet, so I haven't
run into this. (Partially because the blob's RA is very good so it's
somewhat nontrivial to get it to spill... not that I've tried,
On 05/04/2019 17:16, Alyssa Rosenzweig wrote:
>> I'm also somewhat surprised that you don't need loads of other
>> properties from the GPU - in particular knowing the number of shader
>> cores is useful for allocating the right amount of memory for TLS (and
>> can't be obtained purely from the
On Fri, Apr 05, 2019 at 10:27:05AM -0600, Andy Lutomirski wrote:
> At the risk of asking stupid questions: we already have a mechanism
> for this: highmem. Can we enable highmem on x86_64, maybe with some
> heuristics to make it work well?
That's what I said; but note that I'm still not
On Fri, Apr 05, 2019 at 05:35:52PM +0100, Jean-Philippe Brucker wrote:
> On 04/04/2019 15:39, Will Deacon wrote:
> > On Wed, Mar 20, 2019 at 05:36:32PM +, Jean-Philippe Brucker wrote:
> >> When removing a mapping from a domain, we need to send an invalidation to
> >> all devices that might
On 04/04/2019 15:39, Will Deacon wrote:
> Hi Jean-Philippe,
>
> First off, thanks for posting this: it's definitely something that I'm keen
> to support, and getting bits in a piece at a time is probably a good idea.
>
> On Wed, Mar 20, 2019 at 05:36:32PM +, Jean-Philippe Brucker wrote:
>>
> On Apr 5, 2019, at 9:56 AM, Tycho Andersen wrote:
>
>> On Fri, Apr 05, 2019 at 09:24:50AM -0600, Andy Lutomirski wrote:
>>
>>
>>> On Apr 5, 2019, at 8:44 AM, Dave Hansen wrote:
>>>
>>> On 4/5/19 12:17 AM, Thomas Gleixner wrote:
> process. Is that an acceptable trade-off?
You are
> On Apr 5, 2019, at 10:01 AM, Dave Hansen wrote:
>
> On 4/5/19 8:24 AM, Andy Lutomirski wrote:
>>> Sounds like we need a mechanism that will do the deferred XPFO TLB
>>> flushes whenever the kernel is entered, and not _just_ at context
>>> switch time. This permits an app to run in
> I'm also somewhat surprised that you don't need loads of other
> properties from the GPU - in particular knowing the number of shader
> cores is useful for allocating the right amount of memory for TLS (and
> can't be obtained purely from the GPU_ID).
Since I have no idea what TLS is (and in my
On 4/5/19 8:24 AM, Andy Lutomirski wrote:
>> Sounds like we need a mechanism that will do the deferred XPFO TLB
>> flushes whenever the kernel is entered, and not _just_ at context
>> switch time. This permits an app to run in userspace with stale
>> kernel TLB entries as long as it wants...
On 4/5/19 9:24 AM, Andy Lutomirski wrote:
>
>
>> On Apr 5, 2019, at 8:44 AM, Dave Hansen wrote:
>>
>> On 4/5/19 12:17 AM, Thomas Gleixner wrote:
process. Is that an acceptable trade-off?
>>> You are not seriously asking whether creating a user controllable ret2dir
>>> attack window is a
On Fri, Apr 05, 2019 at 09:24:50AM -0600, Andy Lutomirski wrote:
>
>
> > On Apr 5, 2019, at 8:44 AM, Dave Hansen wrote:
> >
> > On 4/5/19 12:17 AM, Thomas Gleixner wrote:
> >>> process. Is that an acceptable trade-off?
> >> You are not seriously asking whether creating a user controllable
On 4/5/19 8:44 AM, Dave Hansen wrote:
> On 4/5/19 12:17 AM, Thomas Gleixner wrote:
>>> process. Is that an acceptable trade-off?
>> You are not seriously asking whether creating a user controllable ret2dir
>> attack window is a acceptable trade-off? April 1st was a few days ago.
>
> Well, let's
> On Apr 5, 2019, at 8:44 AM, Dave Hansen wrote:
>
> On 4/5/19 12:17 AM, Thomas Gleixner wrote:
>>> process. Is that an acceptable trade-off?
>> You are not seriously asking whether creating a user controllable ret2dir
>> attack window is a acceptable trade-off? April 1st was a few days ago.
>
>>> On Apr 4, 2019, at 4:55 PM, Khalid Aziz wrote:
>>>
>>> On 4/3/19 10:10 PM, Andy Lutomirski wrote:
>>> On Wed, Apr 3, 2019 at 10:36 AM Khalid Aziz wrote:
>>>
>>> XPFO flushes kernel space TLB entries for pages that are now mapped
>>> in userspace on not only the current CPU but also all
On 05/04/2019 10:51, Robin Murphy wrote:
> Hi Steve,
>
> On 05/04/2019 10:42, Steven Price wrote:
>> First let me say congratulations to everyone working on Panfrost - it's
>> an impressive achievement!
>>
>> Full disclosure: I used to work on the Mali kbase driver. And have been
>> playing
First let me say congratulations to everyone working on Panfrost - it's
an impressive achievement!
Full disclosure: I used to work on the Mali kbase driver. And have been
playing around with running the Mali user-space blob with the Panfrost
kernel driver.
On 01/04/2019 08:47, Rob Herring wrote:
On 4/5/19 12:17 AM, Thomas Gleixner wrote:
>> process. Is that an acceptable trade-off?
> You are not seriously asking whether creating a user controllable ret2dir
> attack window is a acceptable trade-off? April 1st was a few days ago.
Well, let's not forget that this set at least takes us from
On 03/04/2019 05:57, Rob Herring wrote:
[...]
+static int panfrost_clk_init(struct panfrost_device *pfdev)
+{
+ int err;
+ unsigned long rate;
+
+ pfdev->clock = devm_clk_get(pfdev->dev, NULL);
+ if (IS_ERR(pfdev->clock)) {
The DT binding says clocks are optional, but this
On 01/04/2019 20:11, Robin Murphy wrote:
On 01/04/2019 08:47, Rob Herring wrote:
ARM Mali midgard GPU is similar to standard 64-bit stage 1 page
tables, but
have a few differences. Add a new format type to represent the format.
The
input address size is 48-bits and the output address size is
Hi Steve,
On 05/04/2019 10:42, Steven Price wrote:
First let me say congratulations to everyone working on Panfrost - it's
an impressive achievement!
Full disclosure: I used to work on the Mali kbase driver. And have been
playing around with running the Mali user-space blob with the Panfrost
On Thu, 4 Apr 2019, Khalid Aziz wrote:
> When xpfo unmaps a page from physmap only (after mapping the page in
> userspace in response to an allocation request from userspace) on one
> processor, there is a small window of opportunity for ret2dir attack on
> other cpus until the TLB entry in
30 matches
Mail list logo
