[PATCH v1] xen: remove a confusing comment on auto-translated guest I/O

From: Petr Tesarik After removing the conditional return from xen_create_contiguous_region(), the accompanying comment was left in place, but it now precedes an unrelated conditional and confuses readers. Fixes: 989513a735f5 ("xen: cleanup pvh leftovers from pv-only sources")

Re: [PATCH v7 0/9] Allow dynamic allocation of software IO TLB bounce buffers

On 8/1/2023 6:03 PM, Christoph Hellwig wrote: > Thanks, > > I've applied this to a new swiotlb-dynamic branch that I'll pull into > the dma-mapping for-next tree. Thank you. I guess I can prepare some follow-up series now. ;-) Petr T

[PATCH v7 7/9] swiotlb: determine potential physical address limit

From: Petr Tesarik The value returned by default_swiotlb_limit() should be constant, because it is used to decide whether DMA can be used. To allow allocating memory pools on the fly, use the maximum possible physical address rather than the highest address used by the default pool

[PATCH v7 8/9] swiotlb: allocate a new memory pool when existing pools are full

From: Petr Tesarik When swiotlb_find_slots() cannot find suitable slots, schedule the allocation of a new memory pool. It is not possible to allocate the pool immediately, because this code may run in interrupt context, which is not suitable for large memory allocations. This means

Re: [PATCH v6 0/9] Allow dynamic allocation of software IO TLB bounce buffers

On 7/31/2023 9:46 PM, Petr Tesařík wrote: > V Mon, 31 Jul 2023 18:04:09 +0200 > Christoph Hellwig napsáno: > >> I was just going to apply this, but patch 1 seems to have a non-trivial >> conflict with the is_swiotlb_active removal in pci-dma.c. Can you resend >> against the current dma-mapping

[PATCH v7 9/9] swiotlb: search the software IO TLB only if the device makes use of it

From: Petr Tesarik Skip searching the software IO TLB if a device has never used it, making sure these devices are not affected by the introduction of multiple IO TLB memory pools. Additional memory barrier is required to ensure that the new value of the flag is visible to other CPUs after

[PATCH v7 6/9] swiotlb: if swiotlb is full, fall back to a transient memory pool

From: Petr Tesarik Try to allocate a transient memory pool if no suitable slots can be found and the respective SWIOTLB is allowed to grow. The transient pool is just enough big for this one bounce buffer. It is inserted into a per-device list of transient memory pools, and it is freed again

[PATCH v7 5/9] swiotlb: add a flag whether SWIOTLB is allowed to grow

From: Petr Tesarik Add a config option (CONFIG_SWIOTLB_DYNAMIC) to enable or disable dynamic allocation of additional bounce buffers. If this option is set, mark the default SWIOTLB as able to grow and restricted DMA pools as unable. However, if the address of the default memory pool

[PATCH v7 4/9] swiotlb: separate memory pool data from other allocator data

From: Petr Tesarik Carve out memory pool specific fields from struct io_tlb_mem. The original struct now contains shared data for the whole allocator, while the new struct io_tlb_pool contains data that is specific to one memory pool of (potentially) many. Signed-off-by: Petr Tesarik

[PATCH v7 3/9] swiotlb: add documentation and rename swiotlb_do_find_slots()

From: Petr Tesarik Add some kernel-doc comments and move the existing documentation of struct io_tlb_slot to its correct location. The latter was forgotten in commit 942a8186eb445 ("swiotlb: move struct io_tlb_slot to swiotlb.c"). Use the opportunity to give swiotlb_do_find_slot

[PATCH v7 2/9] swiotlb: make io_tlb_default_mem local to swiotlb.c

From: Petr Tesarik SWIOTLB implementation details should not be exposed to the rest of the kernel. This will allow to make changes to the implementation without modifying non-swiotlb code. To avoid breaking existing users, provide helper functions for the few required fields. As a bonus, using

[PATCH v7 1/9] swiotlb: bail out of swiotlb_init_late() if swiotlb is already allocated

From: Petr Tesarik If swiotlb is allocated, immediately return 0, so callers do not have to check io_tlb_default_mem.nslabs explicitly. Signed-off-by: Petr Tesarik --- arch/arm/xen/mm.c| 10 -- kernel/dma/swiotlb.c | 3 +++ 2 files changed, 7 insertions(+), 6 deletions(-) diff

[PATCH v7 0/9] Allow dynamic allocation of software IO TLB bounce buffers

From: Petr Tesarik Motivation == The software IO TLB was designed with these assumptions: 1) It would not be used much. Small systems (little RAM) don't need it, and big systems (lots of RAM) would have modern DMA controllers and an IOMMU chip to handle legacy devices. 2) A small

[PATCH v6 7/9] swiotlb: determine potential physical address limit

From: Petr Tesarik The value returned by default_swiotlb_limit() should be constant, because it is used to decide whether DMA can be used. To allow allocating memory pools on the fly, use the maximum possible physical address rather than the highest address used by the default pool

[PATCH v6 6/9] swiotlb: if swiotlb is full, fall back to a transient memory pool

From: Petr Tesarik Try to allocate a transient memory pool if no suitable slots can be found and the respective SWIOTLB is allowed to grow. The transient pool is just enough big for this one bounce buffer. It is inserted into a per-device list of transient memory pools, and it is freed again

[PATCH v6 9/9] swiotlb: search the software IO TLB only if the device makes use of it

From: Petr Tesarik Skip searching the software IO TLB if a device has never used it, making sure these devices are not affected by the introduction of multiple IO TLB memory pools. Additional memory barrier is required to ensure that the new value of the flag is visible to other CPUs after

[PATCH v6 8/9] swiotlb: allocate a new memory pool when existing pools are full

From: Petr Tesarik When swiotlb_find_slots() cannot find suitable slots, schedule the allocation of a new memory pool. It is not possible to allocate the pool immediately, because this code may run in interrupt context, which is not suitable for large memory allocations. This means

[PATCH v6 5/9] swiotlb: add a flag whether SWIOTLB is allowed to grow

From: Petr Tesarik Add a config option (CONFIG_SWIOTLB_DYNAMIC) to enable or disable dynamic allocation of additional bounce buffers. If this option is set, mark the default SWIOTLB as able to grow and restricted DMA pools as unable. However, if the address of the default memory pool

[PATCH v6 4/9] swiotlb: separate memory pool data from other allocator data

From: Petr Tesarik Carve out memory pool specific fields from struct io_tlb_mem. The original struct now contains shared data for the whole allocator, while the new struct io_tlb_pool contains data that is specific to one memory pool of (potentially) many. Signed-off-by: Petr Tesarik

[PATCH v6 3/9] swiotlb: add documentation and rename swiotlb_do_find_slots()

From: Petr Tesarik Add some kernel-doc comments and move the existing documentation of struct io_tlb_slot to its correct location. The latter was forgotten in commit 942a8186eb445 ("swiotlb: move struct io_tlb_slot to swiotlb.c"). Use the opportunity to give swiotlb_do_find_slot

[PATCH v6 2/9] swiotlb: make io_tlb_default_mem local to swiotlb.c

From: Petr Tesarik SWIOTLB implementation details should not be exposed to the rest of the kernel. This will allow to make changes to the implementation without modifying non-swiotlb code. To avoid breaking existing users, provide helper functions for the few required fields. As a bonus, using

[PATCH v6 1/9] swiotlb: bail out of swiotlb_init_late() if swiotlb is already allocated

From: Petr Tesarik If swiotlb is allocated, immediately return 0, so callers do not have to check io_tlb_default_mem.nslabs explicitly. Signed-off-by: Petr Tesarik --- arch/arm/xen/mm.c | 10 -- arch/x86/kernel/pci-dma.c | 12 ++-- kernel/dma/swiotlb.c | 3 +++ 3

[PATCH v6 0/9] Allow dynamic allocation of software IO TLB bounce buffers

From: Petr Tesarik Motivation == The software IO TLB was designed with these assumptions: 1) It would not be used much. Small systems (little RAM) don't need it, and big systems (lots of RAM) would have modern DMA controllers and an IOMMU chip to handle legacy devices. 2) A small

[PATCH v5 3/9] swiotlb: add documentation and rename swiotlb_do_find_slots()

From: Petr Tesarik Add some kernel-doc comments and move the existing documentation of struct io_tlb_slot to its correct location. The latter was forgotten in commit 942a8186eb445 ("swiotlb: move struct io_tlb_slot to swiotlb.c"). Use the opportunity to give swiotlb_do_find_slot

[PATCH v5 4/9] swiotlb: separate memory pool data from other allocator data

From: Petr Tesarik Carve out memory pool specific fields from struct io_tlb_mem. The original struct now contains shared data for the whole allocator, while the new struct io_tlb_pool contains data that is specific to one memory pool of (potentially) many. Signed-off-by: Petr Tesarik

[PATCH v5 5/9] swiotlb: add a flag whether SWIOTLB is allowed to grow

From: Petr Tesarik Add a config option (CONFIG_SWIOTLB_DYNAMIC) to enable or disable dynamic allocation of additional bounce buffers. If this option is set, mark the default SWIOTLB as able to grow and restricted DMA pools as unable. However, if the address of the default memory pool

[PATCH v5 9/9] swiotlb: search the software IO TLB only if the device makes use of it

From: Petr Tesarik Skip searching the software IO TLB if a device has never used it, making sure these devices are not affected by the introduction of multiple IO TLB memory pools. Additional memory barrier is required to ensure that the new value of the flag is visible to other CPUs after

[PATCH v5 8/9] swiotlb: allocate a new memory pool when existing pools are full

From: Petr Tesarik When swiotlb_find_slots() cannot find suitable slots, schedule the allocation of a new memory pool. It is not possible to allocate the pool immediately, because this code may run in interrupt context, which is not suitable for large memory allocations. This means

[PATCH v5 7/9] swiotlb: determine potential physical address limit

From: Petr Tesarik The value returned by default_swiotlb_limit() should be constant, because it is used to decide whether DMA can be used. To allow allocating memory pools on the fly, use the maximum possible physical address rather than the highest address used by the default pool

[PATCH v5 6/9] swiotlb: if swiotlb is full, fall back to a transient memory pool

From: Petr Tesarik Try to allocate a transient memory pool if no suitable slots can be found and the respective SWIOTLB is allowed to grow. The transient pool is just enough big for this one bounce buffer. It is inserted into a per-device list of transient memory pools, and it is freed again

[PATCH v5 2/9] swiotlb: make io_tlb_default_mem local to swiotlb.c

From: Petr Tesarik SWIOTLB implementation details should not be exposed to the rest of the kernel. This will allow to make changes to the implementation without modifying non-swiotlb code. To avoid breaking existing users, provide helper functions for the few required fields. As a bonus, using

[PATCH v5 1/9] swiotlb: bail out of swiotlb_init_late() if swiotlb is already allocated

From: Petr Tesarik If swiotlb is allocated, immediately return 0, so callers do not have to check io_tlb_default_mem.nslabs explicitly. Signed-off-by: Petr Tesarik --- arch/arm/xen/mm.c | 10 -- arch/x86/kernel/pci-dma.c | 12 ++-- kernel/dma/swiotlb.c | 3 +++ 3

[PATCH v5 0/9] Allow dynamic allocation of software IO TLB bounce buffers

From: Petr Tesarik Motivation == The software IO TLB was designed with these assumptions: 1) It would not be used much. Small systems (little RAM) don't need it, and big systems (lots of RAM) would have modern DMA controllers and an IOMMU chip to handle legacy devices. 2) A small

[PATCH v4 8/8] swiotlb: search the software IO TLB only if a device makes use of it

From: Petr Tesarik Skip searching the software IO TLB if a device has never used it, making sure these devices are not affected by the introduction of multiple IO TLB memory pools. Additional memory barrier is required to ensure that the new value of the flag is visible to other CPUs after

[PATCH v4 7/8] swiotlb: allocate a new memory pool when existing pools are full

From: Petr Tesarik When swiotlb_find_slots() cannot find suitable slots, schedule the allocation of a new memory pool. It is not possible to allocate the pool immediately, because this code may run in interrupt context, which is not suitable for large memory allocations. This means

[PATCH v4 6/8] swiotlb: determine potential physical address limit

From: Petr Tesarik The value returned by default_swiotlb_limit() should be constant, because it is used to decide whether DMA can be used. To allow allocating memory pools on the fly, use the maximum possible physical address rather than the highest address used by the default pool

[PATCH v4 5/8] swiotlb: if swiotlb is full, fall back to a transient memory pool

From: Petr Tesarik Try to allocate a transient memory pool if no suitable slots can be found and the respective SWIOTLB is allowed to grow. The transient pool is just enough big for this one bounce buffer. It is inserted into a per-device list of transient memory pools, and it is freed again

[PATCH v4 4/8] swiotlb: add a flag whether a SWIOTLB is allowed to grow

From: Petr Tesarik Mark the default SWIOTLB as able to grow and restricted DMA pools as unable. However, if the address of the default memory pool is explicitly queried, make the default SWIOTLB also unable to grow. This is currently used to set up PCI BAR movable regions on some Octeon MIPS

[PATCH v4 3/8] swiotlb: separate memory pool data from other allocator data

From: Petr Tesarik Carve out memory pool specific fields from struct io_tlb_mem. The original struct now contains shared data for the whole allocator, while the new struct io_tlb_pool contains data that is specific to one memory pool of (potentially) many. Allocate both structures together

[PATCH v4 2/8] swiotlb: add documentation and rename swiotlb_do_find_slots()

From: Petr Tesarik Add some kernel-doc comments and move the existing documentation of struct io_tlb_slot to its correct location. The latter was forgotten in commit 942a8186eb445 ("swiotlb: move struct io_tlb_slot to swiotlb.c"). Use the opportunity to give swiotlb_do_find_slot

[PATCH v4 1/8] swiotlb: make io_tlb_default_mem local to swiotlb.c

From: Petr Tesarik SWIOTLB implementation details should not be exposed to the rest of the kernel. This will allow to make changes to the implementation without modifying non-swiotlb code. To avoid breaking existing users, provide helper functions for the few required fields. As a bonus, using

[PATCH v4 0/8] Allow dynamic allocation of software IO TLB bounce buffers

From: Petr Tesarik Motivation == The software IO TLB was designed with these assumptions: 1) It would not be used much. Small systems (little RAM) don't need it, and big systems (lots of RAM) would have modern DMA controllers and an IOMMU chip to handle legacy devices. 2) A small

[PATCH v3 0/7] Allow dynamic allocation of software IO TLB bounce buffers

From: Petr Tesarik Note: This patch series depends on fixes from this thread: https://lore.kernel.org/linux-iommu/cover.1687784289.git.petr.tesarik@huawei.com/T/ Motivation == The software IO TLB was designed with these assumptions: 1) It would not be used much. Small systems

[PATCH v3 6/7] swiotlb: allocate a new memory pool when existing pools are full

From: Petr Tesarik When swiotlb_find_slots() cannot find suitable slots, schedule the allocation of a new memory pool. It is not possible to allocate the pool immediately, because this code may run in interrupt context, which is not suitable for large memory allocations. This means

[PATCH v3 7/7] swiotlb: search the software IO TLB only if a device makes use of it

From: Petr Tesarik Skip searching the software IO TLB if a device has never used it, making sure these devices are not affected by the introduction of multiple IO TLB memory pools. Additional memory barrier is required to ensure that the new value of the flag is visible to other CPUs after

[PATCH v3 3/7] swiotlb: separate memory pool data from other allocator data

From: Petr Tesarik Carve out memory pool specific fields from struct io_tlb_mem. The original struct now contains shared data for the whole allocator, while the new struct io_tlb_pool contains data that is specific to one memory pool of (potentially) many. Allocate both structures together

[PATCH v3 1/7] swiotlb: make io_tlb_default_mem local to swiotlb.c

From: Petr Tesarik SWIOTLB implementation details should not be exposed to the rest of the kernel. This will allow to make changes to the implementation without modifying non-swiotlb code. To avoid breaking existing users, provide helper functions for the few required fields. Enhance

[PATCH v3 5/7] swiotlb: determine potential physical address limit

From: Petr Tesarik The value returned by default_swiotlb_limit() should not change, because it is used to decide whether DMA can be used. To allow allocating memory pools on the fly, use the maximum possible physical address rather than the highest address used by the default pool

[PATCH v3 2/7] swiotlb: add documentation and rename swiotlb_do_find_slots()

From: Petr Tesarik Add some kernel-doc comments and move the existing documentation of struct io_tlb_slot to its correct location. The latter was forgotten in commit 942a8186eb445 ("swiotlb: move struct io_tlb_slot to swiotlb.c"). Use the opportunity to give swiotlb_do_find_slot

[PATCH v3 4/7] swiotlb: if swiotlb is full, fall back to a transient memory pool

From: Petr Tesarik Try to allocate a transient memory pool if no suitable slots can be found, except when allocating from a restricted pool. The transient pool is just enough big for this one bounce buffer. It is inserted into a per-device list of transient memory pools, and it is freed again

Re: [Xen-devel] where can I find the 'address translation' code in Xen?

Hi Minjun, On Mon, 30 Apr 2018 17:17:36 +0900 Minjun Hong <nickey...@gmail.com> wrote: > On Mon, Apr 30, 2018 at 3:44 PM, Petr Tesarik <ptesa...@suse.cz> wrote: > > > Hi Minjun, > > > > On Sun, 29 Apr 2018 19:11:30 +0900 > > Minjun Hong <nickey..

Re: [Xen-devel] where can I find the 'address translation' code in Xen?

Hi Minjun, On Sun, 29 Apr 2018 19:11:30 +0900 Minjun Hong wrote: >[...] > My question is, > > 1. Is it sure that the function will be called even though the HW already > translates the address and populates the TLB entry? I think you miss the point. The hardware page

Re: [Xen-devel] Should PV frontend drivers trust the backends?

On Wed, 25 Apr 2018 13:47:09 + Paul Durrant wrote: > > -Original Message- > > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On > > Behalf Of Juergen Gross > > Sent: 25 April 2018 13:43 > > To: xen-devel > >

[Xen-devel] [PATCH] x86: Do not reserve a crash kernel region if booted on Xen PV

. It may also confuse users of kexec_load(2) and/or kexec_file_load(2). When flags include KEXEC_ON_CRASH or KEXEC_FILE_ON_CRASH, respectively, these syscalls return success, which is technically correct, but the crash kexec image will never be actually used. Signed-off-by: Petr Tesarik <pt