Re: [Xen-devel] [PATCH 2/2] xen/input: add multi-touch support

Hi, Dmitry! On 06/07/2017 07:56 PM, Dmitry Torokhov wrote: On Wed, May 31, 2017 at 12:06:56PM +0300, Oleksandr Andrushchenko wrote: Hi, Dmitry! On 05/30/2017 07:37 PM, Dmitry Torokhov wrote: On Tue, May 30, 2017 at 03:50:20PM +0300, Oleksandr Andrushchenko wrote: Hi, Dmitry! On 05/30/2017

Re: [Xen-devel] [for-4.9] Re: HVM guest performance regression

On 07/06/17 20:19, Stefano Stabellini wrote: > On Wed, 7 Jun 2017, Juergen Gross wrote: >> On 06/06/17 21:08, Stefano Stabellini wrote: >>> On Tue, 6 Jun 2017, Juergen Gross wrote: On 06/06/17 18:39, Stefano Stabellini wrote: > On Tue, 6 Jun 2017, Juergen Gross wrote: >> On 26/05/17

[Xen-devel] [xtf test] 110085: all pass - PUSHED

flight 110085 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/110085/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf f099211f2ebdadf61ae6416559220d69b788cd2b baseline version: xtf

[Xen-devel] Delivery Status Notification (Delay)

** Delivery incomplete ** There was a temporary problem delivering your message to curtiskwo...@gmail.com. Gmail will retry for 22 more hours. You'll be notified if the delivery fails permanently. The response was: Receive rate too high Reporting-MTA: dns; googlemail.com Received-From-MTA:

Re: [Xen-devel] [PATCH 0/5] xen/pvh*: Support > 32 VCPUs at restore

On 03/06/17 02:05, Ankur Arora wrote: > This patch series fixes a bunch of issues in the xen_vcpu setup > logic. > > Simplify xen_vcpu related code: code refactoring in advance of the > rest of the patch series. > > Support > 32 VCPUs at restore: unify all vcpu restore logic in >

[Xen-devel] Delivery Status Notification (Delay)

** Delivery incomplete ** There was a temporary problem delivering your message to curtiskwo...@gmail.com. Gmail will retry for 23 more hours. You'll be notified if the delivery fails permanently. Reporting-MTA: dns; googlemail.com Received-From-MTA: dns;

[Xen-devel] [linux-4.9 test] 110082: regressions - trouble: broken/fail/pass

flight 110082 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/110082/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 3 host-install(3)broken REGR. vs. 107358

[Xen-devel] Delivery Status Notification (Delay)

** Delivery incomplete ** There was a temporary problem delivering your message to curtiskwo...@gmail.com. Gmail will retry for 22 more hours. You'll be notified if the delivery fails permanently. Reporting-MTA: dns; googlemail.com Received-From-MTA: dns;

[Xen-devel] Delivery Status Notification (Delay)

** Delivery incomplete ** There was a temporary problem delivering your message to curtiskwo...@gmail.com. Gmail will retry for 21 more hours. You'll be notified if the delivery fails permanently. The response was: Receive rate too high Reporting-MTA: dns; googlemail.com Received-From-MTA:

[Xen-devel] [distros-debian-wheezy test] 71534: tolerable trouble: broken/pass

flight 71534 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71534/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: build-arm64 2 hosts-allocate broken never pass build-arm64-pvops

[Xen-devel] [PATCH v2] xen: avoid type warning in xchg_xen_ulong

The improved type-checking version of container_of() triggers a warning for xchg_xen_ulong, pointing out that 'xen_ulong_t' is unsigned, but atomic64_t contains a signed value: drivers/xen/events/events_2l.c: In function 'evtchn_2l_handle_events': drivers/xen/events/events_2l.c:187:1020: error:

[Xen-devel] [qemu-mainline test] 110084: regressions - FAIL

flight 110084 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/110084/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm 5 xen-install fail REGR. vs. 109975

Re: [Xen-devel] [PATCH v10 17/32] ARM: vITS: add command handling stub and MMIO emulation

Hi Andre, On 26/05/17 18:35, Andre Przywara wrote: +/** + * Functions that handle ITS commands * + **/ + +static uint64_t its_cmd_mask_field(uint64_t *its_cmd, unsigned int word, + unsigned

[Xen-devel] [xen-unstable baseline-only test] 71532: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71532 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71532/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm 5 xen-install

Re: [Xen-devel] [PATCH v10 18/32] ARM: vITS: introduce translation table walks

Hi Andre, On 26/05/17 18:35, Andre Przywara wrote: +/* + * Queries the collection and device tables to translate the device ID and + * event ID and find the appropriate ITTE. The given collection ID and the + * virtual LPI number are then stored into that entry. + * If vcpu_ptr is provided,

Re: [Xen-devel] [PATCH v10 18/32] ARM: vITS: introduce translation table walks

Hi, On 08/06/17 10:35, Julien Grall wrote: > Hi Andre, > > On 26/05/17 18:35, Andre Przywara wrote: >> +/* >> + * Queries the collection and device tables to translate the device >> ID and >> + * event ID and find the appropriate ITTE. The given collection ID >> and the >> + * virtual LPI number

Re: [Xen-devel] [PATCH v10 24/32] ARM: GICv3: handle unmapped LPIs

Hi Andre, On 26/05/17 18:35, Andre Przywara wrote: +/* + * Find an unused LR to insert an IRQ into, starting with the LR given + * by @lr. If this new interrupt is a PRISTINE LPI, scan the other LRs to + * avoid inserting the same IRQ twice. This situation can occur when an + * event gets

[Xen-devel] [ovmf baseline-only test] 71533: tolerable FAIL

This run is configured for baseline tests only. flight 71533 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71533/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-libvirt 5 libvirt-build

[Xen-devel] [xen-4.9-testing test] 110124: regressions - FAIL

flight 110124 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/110124/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 110063

[Xen-devel] [ovmf test] 110139: regressions - FAIL

flight 110139 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/110139/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 5 xen-buildfail REGR. vs. 110078 build-amd64

Re: [Xen-devel] [PATCH 0/5] xen/pvh*: Support > 32 VCPUs at restore

On 2017-06-08 03:53 PM, Konrad Rzeszutek Wilk wrote: On Thu, Jun 08, 2017 at 10:28:15AM +0200, Juergen Gross wrote: On 03/06/17 02:05, Ankur Arora wrote: This patch series fixes a bunch of issues in the xen_vcpu setup logic. Simplify xen_vcpu related code: code refactoring in advance of the

[Xen-devel] Delivery Status Notification (Delay)

** Delivery incomplete ** There was a temporary problem delivering your message to curtiskwo...@gmail.com. Gmail will retry for 46 more hours. You'll be notified if the delivery fails permanently. Reporting-MTA: dns; googlemail.com Received-From-MTA: dns;

[Xen-devel] [linux-4.9 test] 110112: regressions - FAIL

flight 110112 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/110112/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358

[Xen-devel] [qemu-mainline test] 110114: regressions - FAIL

flight 110114 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/110114/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow210 guest-start fail REGR. vs. 109975

[Xen-devel] Delivery Status Notification (Delay)

** Delivery incomplete ** There was a temporary problem delivering your message to curtiskwo...@gmail.com. Gmail will retry for 46 more hours. You'll be notified if the delivery fails permanently. Reporting-MTA: dns; googlemail.com Received-From-MTA: dns;

[Xen-devel] [PATCH 4/4] libxl/xl: allow to get and set cap on Credit2.

Note that a cap is considered valid only if it is within the [1, nr_vcpus]% interval. Signed-off-by: Dario Faggioli --- Cc: Wei Liu Cc: Ian Jackson Cc: George Dunlap Cc: Anshul Makkar

[Xen-devel] [PATCH 2/4] xen: credit2: allow to set and get utilization cap

As cap is already present in Credit1, as a parameter, all the wiring is there already for it to be percolate down to csched2_dom_cntl() too. In this commit, we actually deal with it, and implement setting, changing or disabling the cap of a domain. Signed-off-by: Dario Faggioli

[Xen-devel] [PATCH 3/4] xen: credit2: improve distribution of budget (for domains with caps)

Instead of letting the vCPU that for first tries to get some budget take it all (although temporarily), allow each vCPU to only get a specific quota of the total budget. This improves fairness, allows for more parallelism, and prevents vCPUs from not being able to get any budget (e.g., because

Re: [Xen-devel] [RFC PATCH v2 5/8] arm/mem_access: Add software guest-page-table walk

Hi Julien, [...] > I know I suggested to move in p2m.c. Looking at the diff stat, this > will increase quite a lot p2m.c which is already big. > > How about introducing a file guest_walk.c which contain the new > functions? > No problem at all. I will gladly move the functionality into a

[Xen-devel] [PATCH 18/44] iommu/amd: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- drivers/iommu/amd_iommu.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index

[Xen-devel] [PATCH 23/44] x86/calgary: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- arch/x86/kernel/pci-calgary_64.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/arch/x86/kernel/pci-calgary_64.c

[Xen-devel] [PATCH 24/44] x86: remove DMA_ERROR_CODE

All dma_map_ops instances now handle their errors through ->mapping_error. Signed-off-by: Christoph Hellwig --- arch/x86/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/include/asm/dma-mapping.h b/arch/x86/include/asm/dma-mapping.h index

[Xen-devel] [PATCH 21/44] powerpc: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Instead define a ->mapping_error method for all IOMMU based dma operation instances. The direct ops don't ever return an error and don't need a ->mapping_error method. Signed-off-by: Christoph Hellwig ---

[Xen-devel] [PATCH 28/44] sparc: remove arch specific dma_supported implementations

Usually dma_supported decisions are done by the dma_map_ops instance. Switch sparc to that model by providing a ->dma_supported instance for sbus that always returns false, and implementations tailored to the sun4u and sun4v cases for sparc64, and leave it unimplemented for PCI on sparc32, which

[Xen-devel] [PATCH 31/44] hexagon: remove arch-specific dma_supported implementation

This implementation is simply bogus - hexagon only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig --- arch/hexagon/include/asm/dma-mapping.h | 2 -- arch/hexagon/kernel/dma.c | 9 - 2

[Xen-devel] [PATCH 26/44] dma-mapping: remove DMA_ERROR_CODE

And update the documentation - dma_mapping_error has been supported everywhere for a long time. Signed-off-by: Christoph Hellwig --- Documentation/DMA-API-HOWTO.txt | 31 +-- include/linux/dma-mapping.h | 5 - 2 files changed, 5 insertions(+),

[Xen-devel] [PATCH 35/44] x86: remove arch specific dma_supported implementation

And instead wire it up as method for all the dma_map_ops instances. Note that this also means the arch specific check will be fully instead of partially applied in the AMD iommu driver. Signed-off-by: Christoph Hellwig --- arch/x86/include/asm/dma-mapping.h | 3 ---

[Xen-devel] [PATCH 33/44] openrisc: remove arch-specific dma_supported implementation

This implementation is simply bogus - hexagon only has a simple direct mapped DMA implementation and thus doesn't care about the address. Signed-off-by: Christoph Hellwig --- arch/openrisc/include/asm/dma-mapping.h | 7 --- 1 file changed, 7 deletions(-) diff --git

[Xen-devel] [PATCH 30/44] dma-virt: remove dma_supported and mapping_error methods

These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig --- lib/dma-virt.c | 12 1 file changed, 12 deletions(-) diff --git a/lib/dma-virt.c b/lib/dma-virt.c index dcd4df1f7174..5c4f11329721 100644 --- a/lib/dma-virt.c +++

[Xen-devel] [PATCH 32/44] hexagon: remove the unused dma_is_consistent prototype

Signed-off-by: Christoph Hellwig --- arch/hexagon/include/asm/dma-mapping.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/hexagon/include/asm/dma-mapping.h b/arch/hexagon/include/asm/dma-mapping.h index 9c15cb5271a6..463dbc18f853 100644 ---

[Xen-devel] [PATCH 29/44] dma-noop: remove dma_supported and mapping_error methods

These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig --- lib/dma-noop.c | 12 1 file changed, 12 deletions(-) diff --git a/lib/dma-noop.c b/lib/dma-noop.c index de26c8b68f34..643a074f139d 100644 --- a/lib/dma-noop.c +++

[Xen-devel] [PATCH 34/44] arm: remove arch specific dma_supported implementation

And instead wire it up as method for all the dma_map_ops instances. Note that the code seems a little fishy for dmabounce and iommu, but for now I'd like to preserve the existing behavior 1:1. Signed-off-by: Christoph Hellwig --- arch/arm/common/dmabounce.c| 1 +

[Xen-devel] [PATCH 25/44] arm: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- arch/arm/common/dmabounce.c| 16 --- arch/arm/include/asm/dma-iommu.h | 2 ++ arch/arm/include/asm/dma-mapping.h | 1 - arch/arm/mm/dma-mapping.c | 41

[Xen-devel] [PATCH 27/44] sparc: remove leon_dma_ops

We can just use pci32_dma_ops. Btw, given that leon is 32-bit and appears to be PCI based, do even need the special case for it in get_arch_dma_ops at all? Signed-off-by: Christoph Hellwig --- arch/sparc/include/asm/dma-mapping.h | 3 +-- arch/sparc/kernel/ioport.c | 5

[Xen-devel] [PATCH 16/44] arm64: remove DMA_ERROR_CODE

The dma alloc interface returns an error by return NULL, and the mapping interfaces rely on the mapping_error method, which the dummy ops already implement correctly. Thus remove the DMA_ERROR_CODE define. Signed-off-by: Christoph Hellwig --- arch/arm64/include/asm/dma-mapping.h |

[Xen-devel] [PATCH 19/44] s390: implement ->mapping_error

s390 can also use noop_dma_ops, and while that currently does not return errors it will so in the future. Implementing the mapping_error method is the proper way to have per-ops error conditions. Signed-off-by: Christoph Hellwig --- arch/s390/include/asm/dma-mapping.h | 2 --

[Xen-devel] [PATCH 20/44] sparc: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- arch/sparc/include/asm/dma-mapping.h | 2 -- arch/sparc/kernel/iommu.c| 12 +--- arch/sparc/kernel/iommu_common.h | 2 ++ arch/sparc/kernel/pci_sun4v.c|

[Xen-devel] [PATCH 22/44] x86/pci-nommu: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- arch/x86/kernel/pci-nommu.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c index

[Xen-devel] [PATCH 14/44] sh: remove DMA_ERROR_CODE

sh does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig --- arch/sh/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/sh/include/asm/dma-mapping.h b/arch/sh/include/asm/dma-mapping.h index d99008af5f73..9b06be07db4d 100644 ---

[Xen-devel] [PATCH 15/44] xtensa: remove DMA_ERROR_CODE

xtensa already implements the mapping_error method for its only dma_map_ops instance. Signed-off-by: Christoph Hellwig --- arch/xtensa/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/xtensa/include/asm/dma-mapping.h

[Xen-devel] [PATCH 12/44] microblaze: remove DMA_ERROR_CODE

microblaze does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig --- arch/microblaze/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/microblaze/include/asm/dma-mapping.h b/arch/microblaze/include/asm/dma-mapping.h index

[Xen-devel] [PATCH 11/44] m32r: remove DMA_ERROR_CODE

dma-noop is the only dma_mapping_ops instance for m32r and does not return errors. Signed-off-by: Christoph Hellwig --- arch/m32r/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/m32r/include/asm/dma-mapping.h

[Xen-devel] [PATCH 10/44] ia64: remove DMA_ERROR_CODE

All ia64 dma_mapping_ops instances already have a mapping_error member. Signed-off-by: Christoph Hellwig --- arch/ia64/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/ia64/include/asm/dma-mapping.h b/arch/ia64/include/asm/dma-mapping.h index

[Xen-devel] [PATCH 13/44] openrisc: remove DMA_ERROR_CODE

openrisc does not return errors for dma_map_page. Signed-off-by: Christoph Hellwig --- arch/openrisc/include/asm/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/openrisc/include/asm/dma-mapping.h b/arch/openrisc/include/asm/dma-mapping.h index

[Xen-devel] [PATCH 09/44] c6x: remove DMA_ERROR_CODE

Signed-off-by: Christoph Hellwig --- arch/c6x/include/asm/dma-mapping.h | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/c6x/include/asm/dma-mapping.h b/arch/c6x/include/asm/dma-mapping.h index aca9f755e4f8..05daf1038111 100644 --- a/arch/c6x/include/asm/dma-mapping.h

[Xen-devel] [PATCH 17/44] hexagon: switch to use ->mapping_error for error reporting

Signed-off-by: Christoph Hellwig --- arch/hexagon/include/asm/dma-mapping.h | 2 -- arch/hexagon/kernel/dma.c | 12 +--- arch/hexagon/kernel/hexagon_ksyms.c| 1 - 3 files changed, 9 insertions(+), 6 deletions(-) diff --git

Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

On 6/7/2017 5:06 PM, Boris Ostrovsky wrote: On 06/07/2017 03:14 PM, Tom Lendacky wrote: The cr3 register entry can contain the SME encryption bit that indicates the PGD is encrypted. The encryption bit should not be used when creating a virtual address for the PGD table. Create a new

Re: [Xen-devel] [PATCH 06/44] iommu/dma: don't rely on DMA_ERROR_CODE

Hi Christoph, On 08/06/17 14:25, Christoph Hellwig wrote: > DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu > driver already implements a proper ->mapping_error method, so it's only > using the value internally. Add a new local define using the value > that arm64 which

Re: [Xen-devel] [PATCH 3/4] ui/input: Add activate/remove for keyboard handlers

diff --git a/ui/input-legacy.c b/ui/input-legacy.c > index 7159747..fbe1ce7 100644 > --- a/ui/input-legacy.c > +++ b/ui/input-legacy.c > @@ -142,6 +142,18 @@ QEMUPutKbdEntry > *qemu_add_kbd_event_handler(QEMUPutKBDEvent *func, void *opaque) >  return entry; >  } >   > +void

Re: [Xen-devel] [PATCH 2/3] x86/altp2m: Add a hvmop for setting the suppress #VE bit

On Tue, Jun 06, 2017 at 07:08:43AM -0600, Jan Beulich wrote: > >>> On 06.06.17 at 15:00, wrote: > > On Mon, May 29, 2017 at 08:38:33AM -0600, Jan Beulich wrote: > >> >>> On 18.05.17 at 17:07, wrote: > >> > + > >> > +if ( !cpu_has_vmx ) > >> > +

Re: [Xen-devel] [PATCH] xen: avoid deadlock in xenbus driver

On 07/06/17 18:24, Juergen Gross wrote: > There has been a report about a deadlock in the xenbus driver: > > [ 247.979498] == > [ 247.985688] WARNING: possible circular locking dependency detected > [ 247.991882] 4.12.0-rc4-00022-gc4b25c0

[Xen-devel] [PATCH 04/44] drm/exynos: don't use DMA_ERROR_CODE

DMA_ERROR_CODE already isn't a valid API to user for drivers and will go away soon. exynos_drm_fb_dma_addr uses it a an error return when the passed in index is invalid, but the callers never check for it but instead pass the address straight to the hardware. Add a WARN_ON instead and just

[Xen-devel] [PATCH 03/44] dmaengine: ioat: don't use DMA_ERROR_CODE

DMA_ERROR_CODE is not a public API and will go away. Instead properly unwind based on the loop counter. Signed-off-by: Christoph Hellwig --- drivers/dma/ioat/init.c | 24 +++- 1 file changed, 7 insertions(+), 17 deletions(-) diff --git

[Xen-devel] clean up and modularize arch dma_mapping interface

Hi all, for a while we have a generic implementation of the dma mapping routines that call into per-arch or per-device operations. But right now there still are various bits in the interfaces where don't clearly operate on these ops. This series tries to clean up a lot of those (but not all

[Xen-devel] [PATCH 02/44] ibmveth: properly unwind on init errors

That way the driver doesn't have to rely on DMA_ERROR_CODE, which is not a public API and going away. Signed-off-by: Christoph Hellwig --- drivers/net/ethernet/ibm/ibmveth.c | 159 + 1 file changed, 74 insertions(+), 85 deletions(-) diff --git

[Xen-devel] [PATCH 06/44] iommu/dma: don't rely on DMA_ERROR_CODE

DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu driver already implements a proper ->mapping_error method, so it's only using the value internally. Add a new local define using the value that arm64 which is the only current user of dma-iommu. Signed-off-by: Christoph

[Xen-devel] [PATCH 05/44] drm/armada: don't abuse DMA_ERROR_CODE

dev_addr isn't even a dma_addr_t, and DMA_ERROR_CODE has never been a valid driver API. Add a bool mapped flag instead. Signed-off-by: Christoph Hellwig --- drivers/gpu/drm/armada/armada_fb.c | 2 +- drivers/gpu/drm/armada/armada_gem.c | 5 ++---

[Xen-devel] [PATCH 08/44] xen-swiotlb: implement ->mapping_error

DMA_ERROR_CODE is going to go away, so don't rely on it. Signed-off-by: Christoph Hellwig --- drivers/xen/swiotlb-xen.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index

[Xen-devel] [PATCH 39/44] xen-swiotlb: remove xen_swiotlb_set_dma_mask

This just duplicates the generic implementation. Signed-off-by: Christoph Hellwig --- drivers/xen/swiotlb-xen.c | 12 1 file changed, 12 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index c3a04b2d7532..82fc54f8eb77 100644 ---

[Xen-devel] [PATCH 37/44] mips/loongson64: implement ->dma_supported instead of ->set_dma_mask

Same behavior, less code duplication. Signed-off-by: Christoph Hellwig --- arch/mips/loongson64/common/dma-swiotlb.c | 19 +-- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/arch/mips/loongson64/common/dma-swiotlb.c

[Xen-devel] [PATCH 38/44] arm: implement ->dma_supported instead of ->set_dma_mask

Same behavior, less code duplication. Signed-off-by: Christoph Hellwig --- arch/arm/common/dmabounce.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c index 4aabf117e136..d89a0b56b245 100644 ---

[Xen-devel] [PATCH 42/44] powerpc/cell: use the dma_supported method for ops switching

Besides removing the last instance of the set_dma_mask method this also reduced the code duplication. Signed-off-by: Christoph Hellwig --- arch/powerpc/platforms/cell/iommu.c | 25 + 1 file changed, 9 insertions(+), 16 deletions(-) diff --git

[Xen-devel] [PATCH 43/44] dma-mapping: remove the set_dma_mask method

Signed-off-by: Christoph Hellwig --- arch/powerpc/kernel/dma.c | 4 include/linux/dma-mapping.h | 6 -- 2 files changed, 10 deletions(-) diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c index 41c749586bd2..466c9f07b288 100644 ---

[Xen-devel] [PATCH 44/44] powerpc: merge __dma_set_mask into dma_set_mask

Signed-off-by: Christoph Hellwig --- arch/powerpc/include/asm/dma-mapping.h | 1 - arch/powerpc/kernel/dma.c | 13 - 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/include/asm/dma-mapping.h

[Xen-devel] [PATCH 36/44] dma-mapping: remove HAVE_ARCH_DMA_SUPPORTED

Signed-off-by: Christoph Hellwig --- include/linux/dma-mapping.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index a57875309bfd..3e5908656226 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h

[Xen-devel] [PATCH 40/44] tile: remove dma_supported and mapping_error methods

These just duplicate the default behavior if no method is provided. Signed-off-by: Christoph Hellwig --- arch/tile/kernel/pci-dma.c | 30 -- 1 file changed, 30 deletions(-) diff --git a/arch/tile/kernel/pci-dma.c b/arch/tile/kernel/pci-dma.c index

[Xen-devel] [PATCH 41/44] powerpc/cell: clean up fixed mapping dma_ops initialization

By the time cell_pci_dma_dev_setup calls cell_dma_dev_setup no device can have the fixed map_ops set yet as it's only set by the set_dma_mask method. So move the setup for the fixed case to be only called in that place instead of indirecting through cell_dma_dev_setup. Signed-off-by: Christoph

Re: [Xen-devel] [PATCH v10 24/32] ARM: GICv3: handle unmapped LPIs

Hi, On 08/06/17 10:45, Julien Grall wrote: > Hi Andre, > > On 26/05/17 18:35, Andre Przywara wrote: >> +/* >> + * Find an unused LR to insert an IRQ into, starting with the LR given >> + * by @lr. If this new interrupt is a PRISTINE LPI, scan the other >> LRs to >> + * avoid inserting the same

[Xen-devel] [PATCH v2] xen: avoid deadlock in xenbus driver

There has been a report about a deadlock in the xenbus driver: [ 247.979498] == [ 247.985688] WARNING: possible circular locking dependency detected [ 247.991882] 4.12.0-rc4-00022-gc4b25c0 #575 Not tainted [ 247.997040]

Re: [Xen-devel] clean up and modularize arch dma_mapping interface

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:25 +0200 > for a while we have a generic implementation of the dma mapping routines > that call into per-arch or per-device operations. But right now there > still are various bits in the interfaces where don't clearly operate >

Re: [Xen-devel] [PATCH 02/44] ibmveth: properly unwind on init errors

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:27 +0200 > That way the driver doesn't have to rely on DMA_ERROR_CODE, which > is not a public API and going away. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller

[Xen-devel] [xen-4.9-testing test] 110095: regressions - FAIL

flight 110095 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/110095/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-2 74 xtf/test-pv64-xsa-188fail REGR. vs. 110063

Re: [Xen-devel] [PATCH 28/44] sparc: remove arch specific dma_supported implementations

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:53 +0200 > Usually dma_supported decisions are done by the dma_map_ops instance. > Switch sparc to that model by providing a ->dma_supported instance for > sbus that always returns false, and implementations tailored to the sun4u

Re: [Xen-devel] [PATCH for-next v3 06/22] x86/traps: move PV hypercall handlers to pv/traps.c

On Thu, Jun 08, 2017 at 12:30:02PM +0100, Andrew Cooper wrote: > I'd prefer not to have individual files for individual functions; that > is going too far IMO. I'd also prefer not to mix misc hypercalls into > this file. > > pv/misc-hypercalls.c ? > Sure this is fine by me. I will move the

Re: [Xen-devel] [PATCH 02/15] xen: tracing: avoid checking tb_init_done multiple times.

On 07/06/17 17:06, Jan Beulich wrote: On 07.06.17 at 17:55, wrote: >> On Wed, 2017-06-07 at 08:46 -0600, Jan Beulich wrote: >> On 01.06.17 at 19:33, wrote: In fact, when calling __trace_var() directly, we can assume

Re: [Xen-devel] [PATCH 01/15] xen: in do_softirq() sample smp_processor_id() once and for all.

>>> On 08.06.17 at 16:20, wrote: > On 01/06/17 18:33, Dario Faggioli wrote: >> In fact, right now, we read it at every iteration of the loop. >> The reason it's done like this is how context switch was handled >> on IA64 (see commit ae9bfcdc, "[XEN] Various softirq

Re: [Xen-devel] [PATCH 25/44] arm: implement ->mapping_error

BOn Thu, Jun 08, 2017 at 03:25:50PM +0200, Christoph Hellwig wrote: > +static int dmabounce_mapping_error(struct device *dev, dma_addr_t dma_addr) > +{ > + if (dev->archdata.dmabounce) > + return 0; I'm not convinced that we need this check here: dev->archdata.dmabounce =

[Xen-devel] [PATCH 07/44] xen-swiotlb: consolidate xen_swiotlb_dma_ops

ARM and x86 had duplicated versions of the dma_ops structure, the only difference is that x86 hasn't wired up the set_dma_mask, mmap, and get_sgtable ops yet. On x86 all of them are identical to the generic version, so they aren't needed but harmless. All the symbols used only for

[Xen-devel] [PATCH 01/44] firmware/ivc: use dma_mapping_error

DMA_ERROR_CODE is not supposed to be used by drivers. Signed-off-by: Christoph Hellwig --- drivers/firmware/tegra/ivc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/tegra/ivc.c b/drivers/firmware/tegra/ivc.c index

Re: [Xen-devel] [PATCH 28/44] sparc: remove arch specific dma_supported implementations

Hi Christoph, On Thu, Jun 8, 2017 at 11:25 PM, Christoph Hellwig wrote: > Usually dma_supported decisions are done by the dma_map_ops instance. > Switch sparc to that model by providing a ->dma_supported instance for > sbus that always returns false, and implementations tailored to

Re: [Xen-devel] [PATCH 27/44] sparc: remove leon_dma_ops

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:52 +0200 > We can just use pci32_dma_ops. > > Btw, given that leon is 32-bit and appears to be PCI based, do even need > the special case for it in get_arch_dma_ops at all? I would need to defer to the LEON developers on that,

Re: [Xen-devel] [PATCH 01/15] xen: in do_softirq() sample smp_processor_id() once and for all.

On 01/06/17 18:33, Dario Faggioli wrote: > In fact, right now, we read it at every iteration of the loop. > The reason it's done like this is how context switch was handled > on IA64 (see commit ae9bfcdc, "[XEN] Various softirq cleanups" [1]). > > However: > 1) we don't have IA64 any longer, and

Re: [Xen-devel] DESIGN: CPUID part 3

>>> On 08.06.17 at 15:12, wrote: > # Proposal > > First and foremost, split the current **max\_policy** notion into separate > **max** and **default** policies. This allows for the provision of features > which are unused by default, but may be opted in to, both at

Re: [Xen-devel] [RFC v2][PATCH] arm-acpi: Add ITS Support for Dom0

Hi, Please CC all relevant maintainers. On 08/06/17 14:03, Manish Jaggi wrote: Spurious newline This patch supports ITS in hardware domain, supports ITS in Xen when booting with ACPI. Signed-off-by: Manish Jaggi --- Changes since v1: - Moved its specific code to

Re: [Xen-devel] [PATCH 16/44] arm64: remove DMA_ERROR_CODE

On 08/06/17 14:25, Christoph Hellwig wrote: > The dma alloc interface returns an error by return NULL, and the > mapping interfaces rely on the mapping_error method, which the dummy > ops already implement correctly. > > Thus remove the DMA_ERROR_CODE define. Reviewed-by: Robin Murphy

Re: [Xen-devel] [PATCH] xen: avoid deadlock in xenbus driver

Hi Jürgen, On 08/06/17 15:00, Juergen Gross wrote: > On 07/06/17 18:24, Juergen Gross wrote: >> There has been a report about a deadlock in the xenbus driver: >> >> [ 247.979498] == >> [ 247.985688] WARNING: possible circular locking

Re: [Xen-devel] [PATCH 2/3] x86/altp2m: Add a hvmop for setting the suppress #VE bit

>>> On 08.06.17 at 15:49, wrote: > On Tue, Jun 06, 2017 at 07:08:43AM -0600, Jan Beulich wrote: >> >>> On 06.06.17 at 15:00, wrote: >> > On Mon, May 29, 2017 at 08:38:33AM -0600, Jan Beulich wrote: >> >> >>> On 18.05.17 at 17:07,

Re: [Xen-devel] [PATCH 01/15] xen: in do_softirq() sample smp_processor_id() once and for all.

On 07/06/17 15:38, Jan Beulich wrote: On 01.06.17 at 19:33, wrote: >> In fact, right now, we read it at every iteration of the loop. >> The reason it's done like this is how context switch was handled >> on IA64 (see commit ae9bfcdc, "[XEN] Various softirq

Re: [Xen-devel] [PATCH 20/44] sparc: implement ->mapping_error

From: Christoph Hellwig Date: Thu, 8 Jun 2017 15:25:45 +0200 > DMA_ERROR_CODE is going to go away, so don't rely on it. > > Signed-off-by: Christoph Hellwig Acked-by: David S. Miller ___ Xen-devel

Re: [Xen-devel] [PATCH 02/15] xen: tracing: avoid checking tb_init_done multiple times.

On 01/06/17 18:33, Dario Faggioli wrote: > In fact, when calling __trace_var() directly, we can > assume that tb_init_done has been checked to be true, > and the if is hence redundant. You probably want to adjust the comment before the smp_rmb() that mentions tb_init_done as well. Other than

  1   2   3   >