[Xen-devel] [qemu-mainline baseline-only test] 71581: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71581 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71581/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-winxpsp3 17

[Xen-devel] [linux-next test] 110485: regressions - FAIL

flight 110485 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/110485/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pair20 guest-start/debian fail REGR. vs. 110464

[Xen-devel] [xen-unstable test] 110484: regressions - FAIL

flight 110484 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/110484/ 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. 110465

Re: [Xen-devel] Notes on stubdoms and latency on ARM

Hello Juilen, >> The polling can be minimized if you block the vCPU when there are >> nothing to do. It would get unblock when you have to schedule him >> because of a request. > Thinking a bit more about this. So far, we rely on the domain to use the > vGIC interrupt controller which require the

[Xen-devel] [linux-4.1 baseline-only test] 71580: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71580 linux-4.1 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71580/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run:

Re: [Xen-devel] Notes on stubdoms and latency on ARM

Hello George, On 31 May 2017 at 20:02, George Dunlap wrote: >>> There is no way out: if the stubdom needs events, then we'll have to >>> expose and context switch the vGIC. If it doesn't, then we can skip the >>> vGIC. However, we would have a similar problem with EL0

[Xen-devel] [qemu-mainline test] 110478: tolerable FAIL - PUSHED

flight 110478 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/110478/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 110458 test-armhf-armhf-libvirt 13

Re: [Xen-devel] [PATCH 1/2] arm: smccc: handle SMCs/HVCs according to SMCCC

On Wed, 14 Jun 2017, Volodymyr Babchuk wrote: > SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs. > SMCCC states that both HVC and SMC are valid conduits to call to a different > firmware functions. Thus, for example PSCI calls can be made both by > SMC or HVC. Also SMCCC

Re: [Xen-devel] [PATCH 03/24] xen/arm: setup: Remove bogus xenheap_mfn_end in setup_mm for arm64

On Fri, 16 Jun 2017, Julien Grall wrote: > Hi Stefano, > > On 06/16/2017 06:33 PM, Stefano Stabellini wrote: > > On Fri, 16 Jun 2017, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 15/06/2017 23:28, Stefano Stabellini wrote: > > > > On Tue, 13 Jun 2017, Julien Grall wrote: > > > > >

Re: [Xen-devel] [PATCH 0/2] xen/arm: Move LPAE definition in a separate header.

Please append these two patches at the end of the remaining set of the "xen/arm: Extend the usage of typesafe MFN" series, when you repost. On Thu, 15 Jun 2017, Julien Grall wrote: > This small patch series is moving out LPAE definition from page.h. This is > based on my series "xen/arm: Extend

Re: [Xen-devel] [PATCH 2/2] xen/arm: lpae: Fix comments coding style

On Thu, 15 Jun 2017, Julien Grall wrote: > Also adding one missing full stop. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > xen/include/asm-arm/lpae.h | 45 ++--- > 1 file changed, 30

Re: [Xen-devel] [PATCH 1/2] xen/arm: Move LPAE definition in a separate header

On Thu, 15 Jun 2017, Julien Grall wrote: > page.h is getting bigger. Move out every LPAE definitions in a separate > header. There is no functional changes. > > Signed-off-by: Julien Grall > --- > xen/include/asm-arm/lpae.h | 169 >

[Xen-devel] [PATCH] docs: improve ARM passthrough doc

Add a warning: use passthrough with care. Add a pointer to the gic device tree bindings. Add an explanation on how to calculate irq numbers from device tree. Add a brief explanation of the reg property and a pointer to the xl docs for a description of the iomem property. Add a note that in the

Re: [Xen-devel] [PATCH] xen: idle_loop: either deal with tasklets or go idle

On Fri, 2017-06-16 at 10:41 -0700, Stefano Stabellini wrote: > On Fri, 16 Jun 2017, Dario Faggioli wrote: > > > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > > index 76310ed..86cd612 100644 > > --- a/xen/arch/arm/domain.c > > +++ b/xen/arch/arm/domain.c > > @@ -41,20 +41,28 @@

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

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

Re: [Xen-devel] [PATCH v3 2/2] xen-access: write_ctrlreg_c4 test

On 06/16/2017 10:20 PM, Petre Pircalabu wrote: > Add test for write_ctrlreg event handling. > > Signed-off-by: Petre Pircalabu > --- > tools/tests/xen-access/xen-access.c | 53 > - > 1 file changed, 52 insertions(+), 1 deletion(-)

[Xen-devel] [libvirt test] 110480: regressions - FAIL

flight 110480 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/110480/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 110460

[Xen-devel] [PATCH v3 1/2] x86/monitor: add masking support for write_ctrlreg events

Add support for filtering out the write_ctrlreg monitor events if they are generated only by changing certains bits. A new parameter (bitmask) was added to the xc_monitor_write_ctrlreg function in order to mask the event generation if the changed bits are set. Signed-off-by: Petre Pircalabu

[Xen-devel] [PATCH v3 0/2] write_ctrlreg event masking

This patchset enables masking the reception of write_ctrlreg events depending on the value of certain bits in that register. The most representative example is filtering out events when the CR4.PGE bit is being flipped (global TLB flushes) --- Changed since v2 * fix coding style. * use

[Xen-devel] [PATCH v3 2/2] xen-access: write_ctrlreg_c4 test

Add test for write_ctrlreg event handling. Signed-off-by: Petre Pircalabu --- tools/tests/xen-access/xen-access.c | 53 - 1 file changed, 52 insertions(+), 1 deletion(-) diff --git a/tools/tests/xen-access/xen-access.c

Re: [Xen-devel] [RFC PATCH v3 10/10] arm/mem_access: Walk the guest's pt in software

Hi Tamas, [...] >> + >> +if ( ((flag & GV2M_WRITE) == GV2M_WRITE) && !(perms & GV2M_WRITE) ) > > Wouldn't it be enough to do (flag & GV2M_WRITE) without the following > comparison? Also, a comment explaining why this is an error-condition > would be nice. > Yes, you are absolutely

[Xen-devel] [PATCH v7 36/36] x86/mm: Add support to make use of Secure Memory Encryption

Add support to check if SME has been enabled and if memory encryption should be activated (checking of command line option based on the configuration of the default state). If memory encryption is to be activated, then the encryption mask is set and the kernel is encrypted "in place."

[Xen-devel] [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel in-place

Add the support to encrypt the kernel in-place. This is done by creating new page mappings for the kernel - a decrypted write-protected mapping and an encrypted mapping. The kernel is encrypted by copying it through a temporary buffer. Signed-off-by: Tom Lendacky ---

[Xen-devel] [PATCH v7 35/36] x86/boot: Add early cmdline parsing for options with arguments

Add a cmdline_find_option() function to look for cmdline options that take arguments. The argument is returned in a supplied buffer and the argument length (regardless of whether it fits in the supplied buffer) is returned, with -1 indicating not found. Signed-off-by: Tom Lendacky

[Xen-devel] [PATCH v7 33/36] x86/mm: Use proper encryption attributes with /dev/mem

When accessing memory using /dev/mem (or /dev/kmem) use the proper encryption attributes when mapping the memory. To insure the proper attributes are applied when reading or writing /dev/mem, update the xlate_dev_mem_ptr() function to use memremap() which will essentially perform the same steps

[Xen-devel] [PATCH v7 27/36] iommu/amd: Allow the AMD IOMMU to work with memory encryption

The IOMMU is programmed with physical addresses for the various tables and buffers that are used to communicate between the device and the driver. When the driver allocates this memory it is encrypted. In order for the IOMMU to access the memory as encrypted the encryption mask needs to be

[Xen-devel] [PATCH v7 32/36] xen/x86: Remove SME feature in PV guests

Xen does not currently support SME for PV guests. Clear the SME cpu capability in order to avoid any ambiguity. Signed-off-by: Tom Lendacky --- arch/x86/xen/enlighten_pv.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/xen/enlighten_pv.c

[Xen-devel] [PATCH v7 30/36] kvm: x86: svm: Support Secure Memory Encryption within KVM

Update the KVM support to work with SME. The VMCB has a number of fields where physical addresses are used and these addresses must contain the memory encryption mask in order to properly access the encrypted memory. Also, use the memory encryption mask when creating and using the nested page

[Xen-devel] [PATCH v7 31/36] x86/mm, kexec: Allow kexec to be used with SME

Provide support so that kexec can be used to boot a kernel when SME is enabled. Support is needed to allocate pages for kexec without encryption. This is needed in order to be able to reboot in the kernel in the same manner as originally booted. Additionally, when shutting down all of the CPUs

[Xen-devel] [PATCH v7 29/36] x86, drm, fbdev: Do not specify encrypted memory for video mappings

Since video memory needs to be accessed decrypted, be sure that the memory encryption mask is not set for the video ranges. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/include/asm/vga.h | 14 +-

[Xen-devel] [PATCH v7 28/36] x86, realmode: Check for memory encryption on the APs

Add support to check if memory encryption is active in the kernel and that it has been enabled on the AP. If memory encryption is active in the kernel but has not been enabled on the AP, then set the memory encryption bit (bit 23) of MSR_K8_SYSCFG to enable memory encryption on that AP and allow

[Xen-devel] [PATCH v7 26/36] x86/CPU/AMD: Make the microcode level available earlier in the boot

Move the setting of the cpuinfo_x86.microcode field from amd_init() to early_amd_init() so that it is available earlier in the boot process. This avoids having to read MSR_AMD64_PATCH_LEVEL directly during early boot. Signed-off-by: Tom Lendacky ---

[Xen-devel] [PATCH v7 25/36] swiotlb: Add warnings for use of bounce buffers with SME

Add warnings to let the user know when bounce buffers are being used for DMA when SME is active. Since the bounce buffers are not in encrypted memory, these notifications are to allow the user to determine some appropriate action - if necessary. Actions can range from utilizing an IOMMU,

[Xen-devel] [PATCH v7 23/36] x86, realmode: Decrypt trampoline area if memory encryption is active

When Secure Memory Encryption is enabled, the trampoline area must not be encrypted. A CPU running in real mode will not be able to decrypt memory that has been encrypted because it will not be able to use addresses with the memory encryption mask. Signed-off-by: Tom Lendacky

[Xen-devel] [PATCH v7 24/36] x86, swiotlb: Add memory encryption support

Since DMA addresses will effectively look like 48-bit addresses when the memory encryption mask is set, SWIOTLB is needed if the DMA mask of the device performing the DMA does not support 48-bits. SWIOTLB will be initialized to create decrypted bounce buffers for use by these devices.

[Xen-devel] [PATCH v7 22/36] x86/mm: Add support for changing the memory encryption attribute

Add support for changing the memory encryption attribute for one or more memory pages. This will be useful when we have to change the AP trampoline area to not be encrypted. Or when we need to change the SWIOTLB area to not be encrypted in support of devices that can't support the encryption mask

[Xen-devel] [PATCH v7 21/36] x86/mm: Add support to access persistent memory in the clear

Persistent memory is expected to persist across reboots. The encryption key used by SME will change across reboots which will result in corrupted persistent memory. Persistent memory is handed out by block devices through memory remapping functions, so be sure not to map this memory as encrypted.

[Xen-devel] [PATCH v7 20/36] x86, mpparse: Use memremap to map the mpf and mpc data

The SMP MP-table is built by UEFI and placed in memory in a decrypted state. These tables are accessed using a mix of early_memremap(), early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses to use early_memremap()/early_memunmap(). This allows for proper setting of the

[Xen-devel] [PATCH v7 19/36] x86/mm: Add support to access boot related data in the clear

Boot data (such as EFI related data) is not encrypted when the system is booted because UEFI/BIOS does not run with SME active. In order to access this data properly it needs to be mapped decrypted. Update early_memremap() to provide an arch specific routine to modify the pagetable protection

[Xen-devel] [PATCH v7 18/36] x86/efi: Update EFI pagetable creation to work with SME

When SME is active, pagetable entries created for EFI need to have the encryption mask set as necessary. When the new pagetable pages are allocated they are mapped encrypted. So, update the efi_pgt value that will be used in cr3 to include the encryption mask so that the PGD table can be read

[Xen-devel] [PATCH v7 17/36] efi: Update efi_mem_type() to return an error rather than 0

The efi_mem_type() function currently returns a 0, which maps to EFI_RESERVED_TYPE, if the function is unable to find a memmap entry for the supplied physical address. Returning EFI_RESERVED_TYPE implies that a memmap entry exists, when it doesn't. Instead of returning 0, change the function to

[Xen-devel] [PATCH v7 16/36] efi: Add an EFI table address match function

Add a function that will determine if a supplied physical address matches the address of an EFI table. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky --- drivers/firmware/efi/efi.c | 33 + include/linux/efi.h

[Xen-devel] [PATCH v7 14/36] x86/mm: Insure that boot memory areas are mapped properly

The boot data and command line data are present in memory in a decrypted state and are copied early in the boot process. The early page fault support will map these areas as encrypted, so before attempting to copy them, add decrypted mappings so the data is accessed properly when copied. For the

[Xen-devel] [PATCH v7 15/36] x86/boot/e820: Add support to determine the E820 type of an address

Add a function that will return the E820 type associated with an address range. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/include/asm/e820/api.h |2 ++ arch/x86/kernel/e820.c | 26 +++--- 2

[Xen-devel] [PATCH v7 12/36] x86/mm: Extend early_memremap() support with additional attrs

Add early_memremap() support to be able to specify encrypted and decrypted mappings with and without write-protection. The use of write-protection is necessary when encrypting data "in place". The write-protect attribute is considered cacheable for loads, but not stores. This implies that the

[Xen-devel] [PATCH v7 13/36] x86/mm: Add support for early encrypt/decrypt of memory

Add support to be able to either encrypt or decrypt data in place during the early stages of booting the kernel. This does not change the memory encryption attribute - it is used for ensuring that data present in either an encrypted or decrypted memory area is in the proper state (for example the

[Xen-devel] [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()

The cr3 register entry can contain the SME encryption mask that indicates the PGD is encrypted. The encryption mask should not be used when creating a virtual address from the cr3 register, so remove the SME encryption mask in the read_cr3_pa() function. During early boot SME will need to use a

[Xen-devel] [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

Add support to the early boot code to use Secure Memory Encryption (SME). Since the kernel has been loaded into memory in a decrypted state, encrypt the kernel in place and update the early pagetables with the memory encryption mask so that new pagetable entries will use memory encryption. The

[Xen-devel] [PATCH v7 06/36] x86/mm: Add Secure Memory Encryption (SME) support

Add support for Secure Memory Encryption (SME). This initial support provides a Kconfig entry to build the SME support into the kernel and defines the memory encryption mask that will be used in subsequent patches to mark pages as encrypted. Reviewed-by: Borislav Petkov

[Xen-devel] [PATCH v7 10/36] x86/mm: Provide general kernel support for memory encryption

Changes to the existing page table macros will allow the SME support to be enabled in a simple fashion with minimal changes to files that use these macros. Since the memory encryption mask will now be part of the regular pagetable macros, we introduce two new macros (_PAGE_TABLE_NOENC and

[Xen-devel] [PATCH v7 09/36] x86/mm: Simplify p[gum]d_page() macros

Create a pgd_pfn() macro similar to the p[um]d_pfn() macros and then use the p[gum]d_pfn() macros in the p[gum]d_page() macros instead of duplicating the code. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/include/asm/pgtable.h |

[Xen-devel] [PATCH v7 07/36] x86/mm: Don't use phys_to_virt in ioremap() if SME is active

Currently there is a check if the address being mapped is in the ISA range (is_ISA_range()), and if it is then phys_to_virt() is used to perform the mapping. When SME is active, however, this will result in the mapping having the encryption bit set when it is expected that an ioremap() should not

[Xen-devel] [PATCH v7 05/36] x86/CPU/AMD: Handle SME reduction in physical address size

When System Memory Encryption (SME) is enabled, the physical address space is reduced. Adjust the x86_phys_bits value to reflect this reduction. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/kernel/cpu/amd.c | 10 +++--- 1

[Xen-devel] [PATCH v7 03/36] x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap for RAM mappings

The ioremap() function is intended for mapping MMIO. For RAM, the memremap() function should be used. Convert calls from ioremap() to memremap() when re-mapping RAM. This will be used later by SME to control how the encryption mask is applied to memory mappings, with certain memory locations

[Xen-devel] [PATCH v7 04/36] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

Update the CPU features to include identifying and reporting on the Secure Memory Encryption (SME) feature. SME is identified by CPUID 0x801f, but requires BIOS support to enable it (set bit 23 of MSR_K8_SYSCFG). Only show the SME feature as available if reported by CPUID and enabled by

[Xen-devel] [PATCH v7 02/36] x86/mm/pat: Set write-protect cache mode for full PAT support

For processors that support PAT, set the write-protect cache mode (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05). Acked-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/mm/pat.c |6 +++--- 1 file changed, 3

[Xen-devel] [PATCH v7 00/36] x86: Secure Memory Encryption (AMD)

This patch series provides support for AMD's new Secure Memory Encryption (SME) feature. SME can be used to mark individual pages of memory as encrypted through the page tables. A page of memory that is marked encrypted will be automatically decrypted when read from DRAM and will be automatically

[Xen-devel] [PATCH v7 01/36] x86: Document AMD Secure Memory Encryption (SME)

Create a Documentation entry to describe the AMD Secure Memory Encryption (SME) feature and add documentation for the mem_encrypt= kernel parameter. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky ---

Re: [Xen-devel] [RFC PATCH v3 05/10] arm/p2m: Make PTE helpers publicly available

Hi Julien, On 06/16/2017 08:23 PM, Julien Grall wrote: > Hi Sergej, > > On 06/16/2017 04:44 PM, Sergej Proskurin wrote: >> Thanks. I have moved the upper helpers to page.h for now and renamed >> them to lpae_* helpers as part of my most recent patch version. The >> submission will follow soon. >

Re: [Xen-devel] [RFC PATCH v3 05/10] arm/p2m: Make PTE helpers publicly available

Hi Sergej, On 06/16/2017 04:44 PM, Sergej Proskurin wrote: Thanks. I have moved the upper helpers to page.h for now and renamed them to lpae_* helpers as part of my most recent patch version. The submission will follow soon. They should go in the new file lpae.h (you were CCed on the patch

Re: [Xen-devel] [PATCH 03/24] xen/arm: setup: Remove bogus xenheap_mfn_end in setup_mm for arm64

Hi Stefano, On 06/16/2017 06:33 PM, Stefano Stabellini wrote: On Fri, 16 Jun 2017, Julien Grall wrote: Hi Stefano, On 15/06/2017 23:28, Stefano Stabellini wrote: On Tue, 13 Jun 2017, Julien Grall wrote: xenheap_mfn_end is storing an MFN and not a physical address. Thankfully xenheap_mfn_end

[Xen-devel] [OSSTEST PATCH v11 11/20] ts-openstack-deploy: Increase fd and memory limits for rabbitmq

Signed-off-by: Anthony PERARD --- ts-openstack-deploy | 14 ++ 1 file changed, 14 insertions(+) diff --git a/ts-openstack-deploy b/ts-openstack-deploy index 2107760..04317a0 100755 --- a/ts-openstack-deploy +++ b/ts-openstack-deploy @@ -130,6 +130,20 @@

[Xen-devel] [OSSTEST PATCH v11 14/20] ts-openstack-deploy: Ignore libvirt-python version and use latest

Devstack is going to try to install a specific version of libvirt-python (currently 2.5.0) but this fail with libvirt installed by osstest. Remove the requirement and use the latest available instead. Signed-off-by: Anthony PERARD --- ts-openstack-deploy | 15

[Xen-devel] [OSSTEST PATCH v11 10/20] ts-openstack-deploy: Switch to Neutron for network

nova-network is not supported anymore and Neutron is the default. Signed-off-by: Anthony PERARD --- ap-common | 3 ++- make-flight | 2 +- ts-openstack-deploy | 8 +--- 3 files changed, 4 insertions(+), 9 deletions(-) diff --git a/ap-common

[Xen-devel] [OSSTEST PATCH v11 12/20] make-flight: Increase dom0_mem for openstack flight

With 4G for dom0_mem, a host running devstack is using about 1.5G of swap. Signed-off-by: Anthony PERARD --- make-flight | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/make-flight b/make-flight index ff4f17e..a0c9d2b 100755 --- a/make-flight +++

[Xen-devel] [OSSTEST PATCH v11 19/20] ts-openstack-deploy: Increase devstack timeout

Signed-off-by: Anthony PERARD --- ts-openstack-deploy | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ts-openstack-deploy b/ts-openstack-deploy index cffbb5d..c21689d 100755 --- a/ts-openstack-deploy +++ b/ts-openstack-deploy @@ -177,7 +177,7 @@ sub

[Xen-devel] [OSSTEST PATCH v11 20/20] Introduce flight for stable branches of OpenStack

OpenStack have many different repo which should be in sync, so this patch should grab the revisions of the stable branch of every OpenStack tree. Tempest does not have stable branch and should be able to test any OpenStack version. This patch also create flight for the latest release of OpenStack

[Xen-devel] [OSSTEST PATCH v11 18/20] ts-logs-capture: Capture OpenStack logs

Signed-off-by: Anthony PERARD --- ts-logs-capture | 6 ++ 1 file changed, 6 insertions(+) diff --git a/ts-logs-capture b/ts-logs-capture index 061a118..0e3d267 100755 --- a/ts-logs-capture +++ b/ts-logs-capture @@ -171,6 +171,12 @@ sub fetch_logs_host () {

[Xen-devel] [OSSTEST PATCH v11 15/20] ts-openstack-tempest: Fix tempest invocation

./run_tempest.sh is deprecated. Signed-off-by: Anthony PERARD --- ts-openstack-tempest | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ts-openstack-tempest b/ts-openstack-tempest index 82e9a71..b95043a 100755 --- a/ts-openstack-tempest +++

[Xen-devel] [OSSTEST PATCH v11 17/20] ts-openstack-deploy: Move logs to /var/log/openstack

Signed-off-by: Anthony PERARD --- ts-openstack-deploy | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ts-openstack-deploy b/ts-openstack-deploy index 8f6c7a2..cffbb5d 100755 --- a/ts-openstack-deploy +++ b/ts-openstack-deploy @@ -58,7 +58,7 @@

[Xen-devel] [OSSTEST PATCH v11 16/20] ts-openstack-tempest: Update list of skipped tests

Signed-off-by: Anthony PERARD --- ts-openstack-tempest | 19 --- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/ts-openstack-tempest b/ts-openstack-tempest index b95043a..ae3662f 100755 --- a/ts-openstack-tempest +++

[Xen-devel] [OSSTEST PATCH v11 13/20] ts-openstack-deploy: Apply a Tempest patch

Signed-off-by: Anthony PERARD --- ts-openstack-deploy | 10 ++ 1 file changed, 10 insertions(+) diff --git a/ts-openstack-deploy b/ts-openstack-deploy index 04317a0..04053de 100755 --- a/ts-openstack-deploy +++ b/ts-openstack-deploy @@ -144,6 +144,16 @@ END

[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 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 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 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 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 6ecd5be5d37e..9a92de63426f 100644 ---

[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

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

This implementation is simply bogus - openrisc 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 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 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 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 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 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 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 Acked-by: Richard Kuo --- arch/hexagon/include/asm/dma-mapping.h | 2 --

[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 27/44] sparc: remove leon_dma_ops

We can just use pci32_dma_ops directly. Signed-off-by: Christoph Hellwig Acked-by: David S. Miller --- arch/sparc/include/asm/dma-mapping.h | 3 +-- arch/sparc/kernel/ioport.c | 5 + 2 files changed, 2 insertions(+), 6 deletions(-) diff --git

[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 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 17/44] hexagon: switch to use ->mapping_error for error reporting

Signed-off-by: Christoph Hellwig Acked-by: Richard Kuo --- 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(-)

[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 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 Acked-by: Michael

[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 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| 13 +--- 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 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 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 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 Reviewed-by: Robin Murphy

[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 Acked-by: Gerald Schaefer

  1   2   3   >