[Xen-devel] [linux-4.1 test] 110472: tolerable FAIL - PUSHED

flight 110472 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/110472/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 109960 test-amd64-i386-xl-qemut-win7-amd64

[Xen-devel] [OSSTEST PATCH v11 07/20] ts-openstack-deploy: Keep CURL_CA_BUNDLE when sudo is called

This is part of commit "ts-openstack-deploy: set CURL_CA_BUNDLE" but also allow pip to work when it is called via sudo without preserving the existing environment variables. Signed-off-by: Anthony PERARD --- ts-openstack-deploy | 1 + 1 file changed, 1 insertion(+)

[Xen-devel] [OSSTEST PATCH v11 03/20] Create a flight to test OpenStack with xen-unstable and libvirt

This patch should create a flight "openstack-nova", with those jobs: build-amd64 build-amd64-xsm build-amd64-pvops build-amd64-libvirt test-amd64-amd64-devstack test-amd64-amd64-devstack-xsm build-armhf build-armhf-libvirt build-armhf-pvops build-armhf-xsm

[Xen-devel] [OSSTEST PATCH v11 09/20] ts-kernel-build: Enable network related modules for Neutron

Those options/modules are needed to run OpenStack Neutron with Open vSwitch. Signed-off-by: Anthony PERARD --- ts-kernel-build | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/ts-kernel-build b/ts-kernel-build index

[Xen-devel] [OSSTEST PATCH v11 04/20] ts-openstack-deploy: Set http proxy

From: Ian Jackson This allows ./stack.sh to access the global internet. CC: Anthony PERARD Signed-off-by: Ian Jackson --- ts-openstack-deploy | 3 +++ 1 file changed, 3 insertions(+) diff --git

[Xen-devel] [OSSTEST PATCH v11 02/20] ts-openstack-tempest: Run Tempest to check OpenStack

This script runs the OpenStack integration test suite, Tempest. Signed-off-by: Anthony PERARD Acked-by: Ian Campbell Acked-by: Ian Jackson --- sg-run-job | 1 + ts-openstack-tempest | 65

[Xen-devel] [OSSTEST PATCH v11 06/20] ts-openstack-deploy: set CURL_CA_BUNDLE

From: Ian Jackson This overrides pip's attempt to specify a specific certificate bundle, and is necessary if we have a MITM SSL proxy. The security implications are not ideal, because the MITM proxy will allow any X.509 cert from any CA, whereas pip would only allow

[Xen-devel] [OSSTEST PATCH v11 01/20] ts-openstack-deploy: Deploy OpenStack on a host with devstack

This script installs any necessary packages and clones all of the OpenStack trees which are used by devstack to deploy OpenStack. Signed-off-by: Anthony PERARD Acked-by: Ian Jackson --- sg-run-job | 5 + ts-openstack-deploy | 148

[Xen-devel] [OSSTEST PATCH v11 05/20] TestSupport: provide target_https_mitm_proxy_cert_path

From: Ian Jackson Signed-off-by: Ian Jackson --- Osstest/TestSupport.pm | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm index ce9ffaa..80b97f8 100644 --- a/Osstest/TestSupport.pm

[Xen-devel] [OSSTEST PATCH v11 00/20] Have OpenStack tested on top of xen's master and libvirt's master.

Changes in V11: - plenty of new patches, on top of the original 3 patches that were acked. - and an attempt at creating a flight for a stable branch of openstack. But there is many git tree to pull the branch from. Anthony PERARD (17): ts-openstack-deploy: Deploy OpenStack on a host with

[Xen-devel] [OSSTEST PATCH v11 08/20] ts-openstack-deploy: Try to disable use of SYSTEMD

There is USE_SYSTEMD off by default, but it is now turn on if USE_SCREEN if off. Try to keep use of systemd disable. Signed-off-by: Anthony PERARD --- ts-openstack-deploy | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ts-openstack-deploy

[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 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 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 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 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 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 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 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 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 ---

[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] [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

[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 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 Reviewed-by: Konrad Rzeszutek Wilk --- drivers/xen/swiotlb-xen.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git

[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 Acked-by: Thierry Reding --- drivers/firmware/tegra/ivc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/tegra/ivc.c

[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 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 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 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 Acked-by: David S. Miller --- drivers/net/ethernet/ibm/ibmveth.c | 159 + 1 file changed,

[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 Acked-by: Dave Jiang Acked-By: Vinod Koul --- drivers/dma/ioat/init.c | 24

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

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

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] [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 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 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 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 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

[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

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

[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 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 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

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] [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 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 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 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 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 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] [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] [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 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 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 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 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 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 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 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 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 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 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 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 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

[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 Acked-by: David S. Miller --- arch/sparc/include/asm/dma-mapping.h | 2 -- arch/sparc/kernel/iommu.c| 12 +--- arch/sparc/kernel/iommu_common.h |

[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 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 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 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

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

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(-)

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] [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, 16 Jun 2017, Dario Faggioli wrote: > On Fri, 2017-06-16 at 02:54 -0600, Jan Beulich wrote: > > > > > On 14.06.17 at 18:53, wrote: > > > > > > --- a/xen/arch/x86/domain.c > > > +++ b/xen/arch/x86/domain.c > > > @@ -112,12 +112,18 @@ static void play_dead(void) >

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] [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. >

[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 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.

  1   2   3   >