>> Why have these not been changed to set the x86_msi_chip.mask/unmask
> >> fields instead?
> >
> > Hi David, x86_msi_chip here is struct msi_chip data type, used to configure
> > MSI/MSI-X
> > irq. msi_chip above is struct irq_chip data type, represent the MSI i
On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci/msi branch
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi
Is there a git tree for these patches?
>
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Re
si.h to make s390 MSI code compile happy, they wiil be removed
s/wiil/will.
> in the later patch.
>
> Tested-by: Konrad Rzeszutek Wilk
I don't even remember testing it - I guess I did the earlier version.
So a couple of questions since I've totally forgotten about this:
>
pus_atomic() APIs to prevent CPUs from going offline,
> while invoking from atomic context.
>
> Cc: Konrad Rzeszutek Wilk
Weird. I see this in the patch but I don't see it in the header? Did you
explicitly suppress the CC part?
Anyhow, the patch looks sane enough, thought
On Tue, Aug 12, 2014 at 03:26:00PM +0800, Yijing Wang wrote:
> Introduce a new struct msi_chip apic_msi_chip instead of weak arch
> functions to configure MSI/MSI-X in x86.
Why not 'x86_msi_ops' (see arch/x86/kernel/x86_init.c)
>
> Signed-off-by: Yijing Wang
> ---
> arch/x86/include/asm/pci.h
On Fri, Mar 18, 2016 at 11:00 AM, Sinan Kaya wrote:
> On 3/18/2016 8:12 AM, Robin Murphy wrote:
>> Since we know for sure that swiotlb_to_phys is a no-op on arm64, it might be
>> cleaner to simply not reference it at all. I suppose we could have some
>> private local wrappers, e.g.:
>>
>> #defin
f-by: Christoph Hellwig
Reviewed-by: Konrad Rzeszutek Wilk
Thank you!
> ---
> kernel/dma/swiotlb.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 904541055792..1bb420244753 100644
> --- a/kernel/dma/sw
On Fri, Aug 24, 2018 at 01:25:35PM -0300, Thiago Jung Bauermann wrote:
> From: Anshuman Khandual
>
> SWIOTLB buffer default size (64MB) is not enough for large sequential write
> operations which eventually leads to kernel crash like here.
>
> virtio-pci :00:05.0: swiotlb buffer is full (sz:
On Tue, May 15, 2012 at 11:20:23AM +0100, Stefano Stabellini wrote:
> On Tue, 15 May 2012, Dan Carpenter wrote:
> > If kzalloc() returns a NULL here, we pass a NULL to
> > xencons_disconnect_backend() which will cause an Oops.
> >
> > Also I removed the __GFP_ZERO while I was at it since kzalloc()
On Sun, Mar 07, 2010 at 01:11:45PM +0100, Albert Herranz wrote:
> The current SWIOTLB code does not support NOT_COHERENT_CACHE platforms.
> This patch adds support for NOT_COHERENT_CACHE platforms to SWIOTLB by
> adding two platform specific functions swiotlb_dma_sync_page() and
> swiotlb_dma_sync(
On Sun, Mar 07, 2010 at 01:11:46PM +0100, Albert Herranz wrote:
> The current SWIOTLB code uses a default of 64MB for the IO TLB area.
> This size can be influenced using a kernel command line parameter "swiotlb".
> Unfortunately, the parsing of the kernel command line is done _after_ the
> swiotlb
> +int wii_set_mem2_dma_constraints(struct device *dev)
> +{
> + struct dev_archdata *sd;
> +
> + sd = &dev->archdata;
> + sd->max_direct_dma_addr = 0;
> + sd->min_direct_dma_addr = wii_hole_start + wii_hole_size;
> +
> + set_dma_ops(dev, &wii_mem2_dma_ops);
> + return 0;
>
> +/*
> + * The mem2_dma "device".
> + *
> + * This device "owns" a pool of coherent MEM2 memory that can be shared among
> + * several devices requiring MEM2 DMA buffers, instead of dedicating specific
> + * pools for each device.
> + *
> + * A device can use the shared coherent MEM2 memory pool b
On Mon, Jun 06, 2011 at 05:01:36PM -0400, Chris Metcalf wrote:
> On 6/6/2011 12:24 PM, Arnd Bergmann wrote:
> > On Monday 06 June 2011, Timur Tabi wrote:.
> >> And what about my concern that my driver will be the only one in
> >> drivers/virt?
> > I have no doubt that more of these will come. Chri
On Tue, Aug 02, 2011 at 09:34:58AM -0600, Alex Williamson wrote:
> On Tue, 2011-08-02 at 22:58 +1000, Benjamin Herrenschmidt wrote:
> >
> > Don't worry, it took me a while to get my head around the HW :-) SR-IOV
> > VFs will generally not have limitations like that no, but on the other
> > hand, t
On Thu, Feb 04, 2021 at 11:49:23AM +, Robin Murphy wrote:
> On 2021-02-04 07:29, Christoph Hellwig wrote:
> > On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
> > > This patch converts several swiotlb related variables to arrays, in
> > > order to maintain stat/status for different
for it that went through phys_to_virt.
>
Reviewed-by: Konrad Rzeszutek Wilk
> Signed-off-by: Christoph Hellwig
> ---
> drivers/xen/swiotlb-xen.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swi
>
Reviewed-by: Konrad Rzeszutek Wilk
> Signed-off-by: Christoph Hellwig
> ---
> drivers/xen/swiotlb-xen.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index a4026822a889f7..4
On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote:
> On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote:
> > So one thing that has been on my mind for a while: I'd really like
> > to kill the separate dma ops in Xen swiotlb. If we compare xen-swiotlb
> > to swiotlb
On Mon, Mar 01, 2021 at 08:44:24AM +0100, Christoph Hellwig wrote:
> Now that swiotlb remembers the allocation size there is no need to pass
> it back to swiotlb_tbl_unmap_single.
Reviewed-by: Konrad Rzeszutek Wilk
gt; a better code structure.
Reviewed-by: Konrad Rzeszutek Wilk
..snip..
> int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int
> verbose)
> {
..snip..
> /*
>* Allocate and initialize the free list array. This array is used
>* to find contiguous free memory regions of size up to IO_TLB_SEGSIZE
> - * between io_tlb
On Wed, Mar 17, 2021 at 02:53:27PM +0100, Christoph Hellwig wrote:
> On Wed, Mar 17, 2021 at 01:42:07PM +0000, Konrad Rzeszutek Wilk wrote:
> > > - alloc_size = PAGE_ALIGN(io_tlb_nslabs * sizeof(size_t));
> > > - io_tlb_alloc_size = memblock_alloc(alloc_size, P
On Wed, Mar 17, 2021 at 06:57:42PM +0100, Christoph Hellwig wrote:
> On Wed, Mar 17, 2021 at 01:51:56PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Mar 17, 2021 at 02:53:27PM +0100, Christoph Hellwig wrote:
> > > On Wed, Mar 17, 2021 at 01:42:07PM +, Konrad Rz
> -#include
> -
> -/*
> - * History lesson:
> - * The execution chain of IOMMUs in 2.6.36 looks as so:
> - *
> - *[xen-swiotlb]
> - * |
> - * +[swiotlb *]--+
> - */ | \
> - * / | \
> - *[GART] [Calgary]
nder why
the '|=' instead of just '=' ?
Either way:
Reviewed-by: Konrad Rzeszutek Wilk
Thank you!
t; - better document the lower bound swiotlb size for xen-swiotlb
> - improve the nslabs calculation for the retry case in
>swiotlb_init_remap and swiotlb_init_late
Hey Christoph,
Feel free to tack on
Reviewed-by: Konrad Rzeszutek Wilk
on them if you would like.
Thank you for doing the spring cleaning of this codebase!
'structured' way with
dependencies.
Hence this creation... But as Christoph points out - it has gotten out
of hand. So smashing it back to a more simplistic mechanism is good.
Reviewed-by: Konrad Rzeszutek Wilk
Thank you!
> ---
> arch/ia64/include/asm/iommu_table.h| 7 --
On Tue, May 18, 2021 at 02:48:35PM +0800, Claire Chang wrote:
> I didn't move this to a separate file because I feel it might be
> confusing for swiotlb_alloc/free (and need more functions to be
> non-static).
> Maybe instead of moving to a separate file, we can try to come up with
> a better namin
On Tue, May 18, 2021 at 02:51:52PM +0800, Claire Chang wrote:
> Still keep this function because directly using dev->dma_io_tlb_mem
> will cause issues for memory allocation for existing devices. The pool
> can't support atomic coherent allocation so we need to distinguish the
> per device pool and
> > do the set_memory_decrypted()+memset(). Is this okay or should
> > swiotlb_init_io_tlb_mem() add an additional argument to do this
> > conditionally?
>
> I'm actually not sure if this it okay. If not, will add an additional
> argument for it.
Any observations discovered? (Want to make sure my
On Wed, Jun 02, 2021 at 09:53:15AM +0300, Christoph Hellwig wrote:
> Hi all,
Hi!
You wouldn't have a nice git repo to pull so one can test it easily?
Thank you!
Cc-ing Boris/Juergen - pls see below xen.
>
> this series is the scond part of cleaning up lifetimes and allocation of
> the gendisk
>
> To do this, we use mostly the same code as swiotlb_init(), but allocate the
> buffer using memblock_alloc() instead of memblock_alloc_low().
>
> Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> arch/powerpc/include/asm/svm.h
Hello!
In this file:
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index e4368159f88a..7fb2ac087d23 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
..
> +static const struct reserved_mem_ops rmem_swiotlb_ops = {
> + .device_init= rmem_swiotlb_device_init,
On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> Introduce the new compatible string, restricted-dma-pool, for restricted
> DMA. One can specify the address and length of the restricted DMA memory
> region by restricted-dma-pool in the device tree.
>
> Signed-off-by: Claire Chang
>
On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote:
> Hi Greg and Konrad,
>
> This change is intended to be non-arch specific. Any arch that lacks DMA
> access
> control and has devices not behind an IOMMU can make use of it. Could you
> share
> why you think this should be arch specif
On Thu, Jan 07, 2021 at 10:09:14AM -0800, Florian Fainelli wrote:
> On 1/7/21 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote:
> >> Hi Greg and Konrad,
> >>
> >> This change is intended to be non-ar
On Fri, Jan 08, 2021 at 01:39:43AM +0800, Claire Chang wrote:
> On Thu, Jan 7, 2021 at 2:58 AM Konrad Rzeszutek Wilk
> wrote:
> >
> > On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> > > Introduce the new compatible string, restricted-dma-pool, for re
On Fri, Jan 08, 2021 at 09:27:01PM -0300, Thiago Jung Bauermann wrote:
>
> Ram Pai writes:
>
> > On Wed, Dec 23, 2020 at 09:06:01PM -0300, Thiago Jung Bauermann wrote:
> >>
> >> Hi Ram,
> >>
> >> Thanks for reviewing this patch.
> >>
> >> Ram Pai writes:
> >>
> >> > On Fri, Dec 18, 2020 at
On Tue, Jun 15, 2021 at 09:27:02PM +0800, Claire Chang wrote:
> Always have the pointer to the swiotlb pool used in struct device. This
> could help simplify the code for other pools.
Applying: swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
error: patch failed: kernel/dma/swiotlb.c:339
On Sat, Jun 19, 2021 at 11:40:31AM +0800, Claire Chang wrote:
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or unexpected addresses, possibly
> leading to data le
On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
>
>
> On 6/24/2021 7:48 AM, Will Deacon wrote:
> > Ok, diff below which attempts to tackle the offset issue I mentioned as
> > well. Qian Cai -- please can you try with these changes?
>
> This works fine.
Cool. Let me squash this patch i
On Thu, Jun 24, 2021 at 11:55:14PM +0800, Claire Chang wrote:
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or unexpected addresses, possibly
> leading to data le
On Thu, Jun 24, 2021 at 11:58:57PM +0800, Claire Chang wrote:
> On Thu, Jun 24, 2021 at 11:56 PM Konrad Rzeszutek Wilk
> wrote:
> >
> > On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
> > >
> > >
> > > On 6/24/2021 7:48 AM, Will Deacon wr
On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > FWIW I was pondering the question of whether to do something along those
> > lines or just scrap the default assignment entirely, so since I hadn't got
> > round
On Tue, Jul 06, 2021 at 05:57:21PM +0100, Will Deacon wrote:
> On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> > > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
..snip..
> > > I think the main question I have is how would you like to see patches for
> > > 5.15? i.e. as patches on top of devel/for-linus-5.14 or something else?
> >
> > Yes that would be perfect. If there are any dependencies on the rc1, I
> > can rebase it on top of that.
>
> Yes, please,
On Thu, Jul 29, 2021 at 05:13:36PM +0100, Will Deacon wrote:
> On Wed, Jul 28, 2021 at 10:35:34AM -0700, Nathan Chancellor wrote:
> > On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
> > > next-20210723 was good. The boot failure seems to have been introduced
> > > with next-20210726.
---
> drivers/xen/swiotlb-xen.c | 93
> ++
> include/xen/swiotlb-xen.h | 62 +---
> 4 files changed, 49 insertions(+), 137 deletions(-)
Yeeey!
Reviewed-by: Konrad Rzeszutek Wilk
On Thu, Jun 08, 2017 at 03:25:33PM +0200, Christoph Hellwig wrote:
> DMA_ERROR_CODE is going to go away, so don't rely on it.
Reviewed-by: Konrad Rzeszutek Wilk
f-by: Christoph Hellwig
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> include/linux/dma-mapping.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index d84951865be7..9f28b2fa329e 100644
> --- a/include/linux/dma
On Wed, Jan 10, 2018 at 09:00:15AM +0100, Christoph Hellwig wrote:
> To implement the x86 forbid_dac and iommu_sac_force we want an arch hook
> so that it can apply the global options across all dma_map_ops
> implementations.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: K
On Wed, Jan 10, 2018 at 09:09:13AM +0100, Christoph Hellwig wrote:
> We'll need that name for a generic implementation soon.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> arch/ia64/hp/common/hwsw_iommu.c | 4 ++--
> arch/ia64/hp/
On Wed, Jan 10, 2018 at 09:09:14AM +0100, Christoph Hellwig wrote:
> We'll need that name for a generic implementation soon.
>
Reviewed-by: Konrad Rzeszutek Wilk
> Signed-off-by: Christoph Hellwig
> ---
> arch/powerpc/include/asm/swiotlb.h | 2 +-
> arch/powerpc/ke
On Wed, Jan 10, 2018 at 09:09:15AM +0100, Christoph Hellwig wrote:
> We'll need that name for a generic implementation soon.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> arch/x86/kernel/pci-swiotlb.c | 4 ++--
> 1 file changed, 2 ins
On Wed, Jan 10, 2018 at 09:09:16AM +0100, Christoph Hellwig wrote:
OK?
Reviewed-by: Konrad Rzeszutek Wilk
> Signed-off-by: Christoph Hellwig
> ---
> arch/powerpc/kernel/dma-swiotlb.c | 2 +-
> arch/x86/kernel/pci-swiotlb.c | 2 +-
> include/linux/swiotlb.h
On Fri, Oct 28, 2016 at 04:11:16AM -0400, Pan Xinhui wrote:
> change from v5:
> spilt x86/kvm patch into guest/host part.
> introduce kvm_write_guest_offset_cached.
> fix some typos.
> rebase patch onto 4.9.2
> change from v4:
> spilt x86 kvm vcpu preempted check into
On Fri, Oct 28, 2016 at 04:11:26AM -0400, Pan Xinhui wrote:
> From: Juergen Gross
>
> Support the vcpu_is_preempted() functionality under Xen. This will
> enhance lock performance on overcommitted hosts (more runnable vcpus
> than physical cpus in the system) as doing busy waits for preempted
> v
58 matches
Mail list logo
