So far the kernel only prints the requested size if swiotlb buffer if full.
It is not possible to know whether it is simply an out of buffer, or it is
because swiotlb cannot allocate buffer with the requested size due to
fragmentation.
As 'io_tlb_used' is available since commit 71602fe6d4e9
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 other CPUs
>> synchronously. Processes on each core allocating pages
> On Apr 4, 2019, at 10:28 AM, Thomas Gleixner wrote:
>
>> On Thu, 4 Apr 2019, Tycho Andersen wrote:
>>leaq-PTREGS_SIZE(%rax), %rsp
>>UNWIND_HINT_FUNC sp_offset=PTREGS_SIZE
>>
>> +/*
>> + * If we oopsed in an interrupt handler, interrupts may be off. Let's
>> turn
>> +
On Thu, Apr 04, 2019 at 09:15:46AM -0600, Khalid Aziz wrote:
> Thanks Peter. I really appreciate your review. Your feedback helps make
> this code better and closer to where I can feel comfortable not calling
> it RFC any more.
>
> The more I look at xpfo_kmap()/xpfo_kunmap() code, the more I get
On Thu, 4 Apr 2019, Tycho Andersen wrote:
> leaq-PTREGS_SIZE(%rax), %rsp
> UNWIND_HINT_FUNC sp_offset=PTREGS_SIZE
>
> + /*
> + * If we oopsed in an interrupt handler, interrupts may be off. Let's
> turn
> + * them back on before going back to "normal" code.
> +
Now that we allow drivers to always need to set larger than required
DMA masks we need to be a little more careful in the sun4v PCI iommu
driver to chose when to select the ATU support - a larger DMA mask
can be set even when the platform does not support ATU, so we always
have to check if it is
- stepping on del button while browsing though CCs.
On 2019-04-04 09:47:27 [-0600], Tycho Andersen wrote:
> > Hmm. do_exit() isn't really meant to be "try your best to leave the
> > system somewhat usable without returning" -- it's a function that,
> > other than in OOPSes, is called from a
On 4/4/19 1:56 AM, Peter Zijlstra wrote:
> On Wed, Apr 03, 2019 at 11:34:12AM -0600, Khalid Aziz wrote:
>> From: Julian Stecklina
>>
>> Only the xpfo_kunmap call that needs to actually unmap the page
>> needs to be serialized. We need to be careful to handle the case,
>> where after the atomic
On Wed, Apr 03, 2019 at 09:12:16PM -0700, Andy Lutomirski wrote:
> On Wed, Apr 3, 2019 at 6:42 PM Tycho Andersen wrote:
> >
> > On Wed, Apr 03, 2019 at 05:12:56PM -0700, Andy Lutomirski wrote:
> > > On Wed, Apr 3, 2019 at 10:36 AM Khalid Aziz
> > > wrote:
> > > >
> > > > From: Tycho Andersen
>
On Thu, Apr 04, 2019 at 06:38:53PM +0300, Meelis Roos wrote:
> > > Yes, reverting this commit makes my T1000 boot.
> >
> > Does the patch attached to the last mail work as well?
>
> Sorry for misreading your mail - tested now and yes, it works.
Thanks, I'll submit it with a proper changelog.
[trimmed To: and Cc: It was too large]
On 4/4/19 1:52 AM, Peter Zijlstra wrote:
> On Wed, Apr 03, 2019 at 11:34:05AM -0600, Khalid Aziz wrote:
>> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
>> index 2779ace16d23..5c0e1581fa56 100644
>> ---
Yes, reverting this commit makes my T1000 boot.
Does the patch attached to the last mail work as well?
Sorry for misreading your mail - tested now and yes, it works.
--
Meelis Roos
___
iommu mailing list
iommu@lists.linux-foundation.org
Hi Zhen Lei,
On Mon, Mar 18, 2019 at 09:12:41PM +0800, Zhen Lei wrote:
> v1 --> v2:
> 1. Drop part2. Now, we only use the SMMUv3 hardware feature STE.config=0b000
> (Report abort to device, no event recorded) to suppress the event messages
> caused by the unexpected devices.
> 2. rewrite the
On 4/4/19 1:43 AM, Peter Zijlstra wrote:
>
> You must be so glad I no longer use kmap_atomic from NMI context :-)
>
> On Wed, Apr 03, 2019 at 11:34:04AM -0600, Khalid Aziz wrote:
>> +static inline void xpfo_kmap(void *kaddr, struct page *page)
>> +{
>> +unsigned long flags;
>> +
>> +if
On Fri, Mar 01, 2019 at 11:20:17AM -0800, Douglas Anderson wrote:
> If you're bisecting why your peripherals stopped working, it's
> probably this CL. Specifically if you see this in your dmesg:
> Unexpected global fault, this could be serious
> ...then it's almost certainly this CL.
>
>
On Thu, Apr 04, 2019 at 09:21:52AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 03, 2019 at 11:34:04AM -0600, Khalid Aziz wrote:
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 2c471a2c43fa..d17d33f36a01 100644
> > --- a/include/linux/mm_types.h
> > +++
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:
> When removing a mapping from a domain, we need to send
On Thu, Apr 04, 2019 at 10:11:43AM +0300, Meelis Roos wrote:
> > I think this might have been this commit:
> >
> > commit 24132a419c68f1d69eb8ecc91b3c80d730ecbb59
> > Author: Christoph Hellwig
> > Date: Fri Feb 15 09:30:28 2019 +0100
> >
> > sparc64/pci_sun4v: allow large DMA masks
> >
On 03/04/2019 10:20, John Garry wrote:
On 03/04/2019 09:14, Greg KH wrote:
On Wed, Apr 03, 2019 at 09:02:36AM +0100, John Garry wrote:
On 28/03/2019 10:08, John Garry wrote:
In commit 376991db4b64 ("driver core: Postpone DMA tear-down until
after
devres release"), we changed the ordering of
On 28/03/2019 18:06, Marc Gonzalez wrote:
> Add MSM8998 PCIe QMP PHY and PCIe root complex DT nodes.
I suppose I should add a reference to the downstream DTS:
https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/arch/arm/boot/dts/qcom/msm8998.dtsi?h=LE.UM.1.3.r3.25#n2537
> diff --git
On Thu, Apr 04, 2019 at 09:21:52AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 03, 2019 at 11:34:04AM -0600, Khalid Aziz wrote:
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 2c471a2c43fa..d17d33f36a01 100644
> > --- a/include/linux/mm_types.h
> > +++
On Wed, Apr 03, 2019 at 11:34:13AM -0600, Khalid Aziz wrote:
> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> index 999d6d8f0bef..cc806a01a0eb 100644
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@ -37,6 +37,20 @@
> */
> #define LAST_USER_MM_IBPB0x1UL
>
> +/*
> + * A TLB
On Wed, Apr 03, 2019 at 11:34:12AM -0600, Khalid Aziz wrote:
> From: Julian Stecklina
>
> Only the xpfo_kunmap call that needs to actually unmap the page
> needs to be serialized. We need to be careful to handle the case,
> where after the atomic decrement of the mapcount, a xpfo_kmap
>
On Wed, Apr 03, 2019 at 11:34:05AM -0600, Khalid Aziz wrote:
> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
> index 2779ace16d23..5c0e1581fa56 100644
> --- a/arch/x86/include/asm/pgtable.h
> +++ b/arch/x86/include/asm/pgtable.h
> @@ -1437,6 +1437,32 @@ static inline
You must be so glad I no longer use kmap_atomic from NMI context :-)
On Wed, Apr 03, 2019 at 11:34:04AM -0600, Khalid Aziz wrote:
> +static inline void xpfo_kmap(void *kaddr, struct page *page)
> +{
> + unsigned long flags;
> +
> + if (!static_branch_unlikely(_inited))
> +
On Wed, Apr 03, 2019 at 11:34:04AM -0600, Khalid Aziz wrote:
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 2c471a2c43fa..d17d33f36a01 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -204,6 +204,14 @@ struct page {
> #ifdef
I think this might have been this commit:
commit 24132a419c68f1d69eb8ecc91b3c80d730ecbb59
Author: Christoph Hellwig
Date: Fri Feb 15 09:30:28 2019 +0100
sparc64/pci_sun4v: allow large DMA masks
the patch below adds a few missing checks and hopefully should fix
your problem. If not can
Hi Marc, Robin, Alex,
On 4/3/19 7:38 PM, Alex Williamson wrote:
> On Wed, 3 Apr 2019 16:30:15 +0200
> Auger Eric wrote:
>
>> Hi Alex,
>>
>> On 3/22/19 11:09 PM, Alex Williamson wrote:
>>> On Fri, 22 Mar 2019 10:30:02 +0100
>>> Auger Eric wrote:
>>>
Hi Alex,
On 3/22/19 12:01 AM,
Hi James,
I did a sanity test from my end. The test machine fails to boot. I
haven't seen any valuable kernel log. It results in a purple screen.
Best regards,
Lu Baolu
On 3/29/19 11:26 PM, James Sewart wrote:
Hey Lu,
I’ve attached a preliminary v3, if you could take a look and run some
29 matches
Mail list logo
