Re: [Xen-devel] [PATCH v2] x86/HVM: use available linear->phys translations in REP MOVS/STOS handling

On 21 June 2016, at 20:50, Andrew Cooper wrote: > > >On 20/06/16 12:29, Jan Beulich wrote: >> If we have the translation result available already, we should also use >> it here. In my tests with Linux guests this eliminates all calls to >> hvmemul_linear_to_phys() from the STOS path and most from

Re: [Xen-devel] [PATCH v2 3/4] xen/init: Move initcall infrastructure into .init.data

>>> On 21.06.16 at 18:59, wrote: > Its contents is constant. > > Signed-off-by: Andrew Cooper Non-ARM part: Reviewed-by: Jan Beulich > @@ -154,14 +160,6 @@ SECTIONS > *(.init_array) > __ctors_end = .; >} :text > - . = ALIGN(32); > - .initcall.init : { > - __initcal

[Xen-devel] [PATCH 1/3] xen: update xen headers

Update some Xen headers to be able to use new functionality. Signed-off-by: Juergen Gross --- include/xen/interface/vcpu.h | 24 +++- include/xen/interface/xen.h | 17 - 2 files changed, 31 insertions(+), 10 deletions(-) diff --git a/include/xen/interface/vc

Re: [Xen-devel] [PATCH v3 2/8] xen/mm: Introduce a bunch of helpers for the typesafes mfn and gfn

>>> On 21.06.16 at 15:20, wrote: > Those helpers will be useful to do common operations without having to > unbox/box manually the GFNs/MFNs. > > Signed-off-by: Julien Grall Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org h

[Xen-devel] [PATCH 0/3] xen: add full support for CONFIG_PARAVIRT_TIME_ACCOUNTING

With most recent Xen hypervisor (4.8) it is now possible to add full support of CONFIG_PARAVIRT_TIME_ACCOUNTING. To be applied on top of commit ed2f61fdd2356c2a1d1239aa1507ce4e2e059306 "xen: add steal_clock support on x86" of kernel/git/xen/tip.git Runtime tested on x86_64, compile tested on arm6

[Xen-devel] [PATCH 3/3] xen: support runqueue steal time on xen

Up to now reading the stolen time of a remote cpu was not possible in a performant way under Xen. This made support of runqueue steal time via paravirt_steal_rq_enabled impossible. With the addition of an appropriate hypervisor interface this is now possible, so add the support. Signed-off-by: Ju

[Xen-devel] [PATCH 2/3] arm/xen: add support for vm_assist hypercall

Add support for the Xen HYPERVISOR_vm_assist hypercall. Signed-off-by: Juergen Gross --- arch/arm/include/asm/xen/hypercall.h | 1 + arch/arm/xen/enlighten.c | 1 + arch/arm/xen/hypercall.S | 1 + arch/arm64/xen/hypercall.S | 1 + 4 files changed, 4 insertions(+

[Xen-devel] [PATCH v2 2/2] xen/arm: drivers: scif: Drop clock source configuration

Besides the 14MHz external clock, the SCIF might be clocked by an internal 66MHz clock. If this is the case, the current clock source selection breaks this configuration. Completely drop this and rely on the settings done by the firmware. Signed-off-by: Dirk Behme --- xen/drivers/char/scif-uart.

[Xen-devel] [PATCH v2 1/2] xen/arm: drivers: scif: Remove dead code

The two struct members baud and clock_hz are in the end read only variables nowhere used for anything useful. Removing them makes the code much simpler without changing any functionality. Signed-off-by: Dirk Behme --- xen/drivers/char/scif-uart.c| 24 +--- xen/include/asm

Re: [Xen-devel] [PATCH v2] x86/HVM: use available linear->phys translations in REP MOVS/STOS handling

>>> On 21.06.16 at 21:50, wrote: > On 20/06/16 12:29, Jan Beulich wrote: >> If we have the translation result available already, we should also use >> it here. In my tests with Linux guests this eliminates all calls to >> hvmemul_linear_to_phys() from the STOS path and most from the MOVS one. >> >

Re: [Xen-devel] [PATCH v1 Altp2m cleanup 0/3] Cleaning up altp2m code

>>> On 21.06.16 at 18:04, wrote: > Cleaning up altp2m code per request of xen-devel mailing list. > > Paul Lai (3): > altp2m cleanup work > Move altp2m specific functions to altp2m files. > Making altp2m struct dynamically allocated. Much appreciated. But having peeked into patch 1 (as the

[Xen-devel] [PATCH v10 0/3] Check VT-d Device-TLB flush error

From: Quan Xu This patch set is a prereq patch set for Patch:'VT-d Device-TLB flush issue'. While IOMMU Device-TLB flush timed out, xen calls panic() at present. However the existing panic() is going to be eliminated, so we must propagate the IOMMU Device-TLB flush error up to the call trees.

[Xen-devel] [PATCH v10 1/3] vt-d: fix the IOMMU flush issue

From: Quan Xu The propagation value from IOMMU flush interfaces may be positive, which indicates callers need to flush cache, not one of faliures. when the propagation value is positive, this patch fixes this flush issue as follows: - call iommu_flush_write_buffer() to flush cache. - return

[Xen-devel] [PATCH v10 2/3] vt-d: propagate the IOMMU Device-TLB flush error up to ME phantom functions

From: Quan Xu Signed-off-by: Quan Xu Acked-by: Kevin Tian Reviewed-by: Jan Beulich CC: Jan Beulich CC: Kevin Tian CC: Feng Wu --- xen/drivers/passthrough/vtd/extern.h | 3 ++- xen/drivers/passthrough/vtd/iommu.c | 8 xen/drivers/passthrough/vtd/quirks.c | 27 +-

[Xen-devel] [PATCH v10 3/3] vt-d: add __must_check annotation to IOMMU flush pointers and handlers

From: Quan Xu Signed-off-by: Quan Xu Acked-by: Kevin Tian Reviewed-by: Jan Beulich CC: Jan Beulich CC: Kevin Tian CC: Feng Wu --- xen/drivers/passthrough/vtd/iommu.c | 50 ++-- xen/drivers/passthrough/vtd/iommu.h | 11 +--- xen/drivers/passthrough/vtd

Re: [Xen-devel] [PATCH 2/7] vm-event: VM_EVENT_FLAG_DENY requires VM_EVENT_FLAG_VCPU_PAUSED

On 6/21/2016 6:09 PM, Tamas K Lengyel wrote: On Jun 21, 2016 05:26, "Corneliu ZUZU" > wrote: > > On 6/16/2016 7:11 PM, Tamas K Lengyel wrote: >> >> On Thu, Jun 16, 2016 at 8:07 AM, Corneliu ZUZU mailto:cz...@bitdefender.com>> wrote: >>> >>> For VM_EVENT_FLAG_DEN

Re: [Xen-devel] [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions

Hi Shannon, On 22/06/2016 04:24, Shannon Zhao wrote: On 2016/6/6 20:16, Wei Liu wrote: On Mon, Jun 06, 2016 at 06:27:25PM +0800, Shannon Zhao wrote: On 2016/6/6 18:11, Julien Grall wrote: Hi Stefano, On 06/06/2016 11:04, Stefano Stabellini wrote: On Tue, 31 May 2016, Shannon Zhao wrote:

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

On 6/22/2016 2:39 PM, Jan Beulich wrote: On 21.06.16 at 16:38, wrote: On 21/06/16 10:47, Jan Beulich wrote: And then - didn't we mean to disable that part of XenGT during migration, i.e. temporarily accept the higher performance overhead without the p2m_ioreq_server entries? In which case fl

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: drivers: scif: Remove dead code

Hello Dirk, On 22/06/2016 08:18, Dirk Behme wrote: The two struct members baud and clock_hz are in the end read only variables nowhere used for anything useful. Removing them makes the code much simpler without changing any functionality. While you are dropping those members, should we do the

[Xen-devel] [PATCH v3 0/2] qemu-qdisk: Implementation of grant copy operation.

Hi, It is a proposition for implementation of grant copy operation in qemu-qdisk and interface in libxc/libs. Changes since v2: Interface: - dropped the changes in libxc/include/xenctrl_compat - changed the MINOR version in Makefile - replaced 'return -1' -> 'abort()'in libs/gnttab/gnttab_unim

[Xen-devel] [PATCH v3 2/2] qdisk - hw/block/xen_disk: grant copy implementation

Copy data operated on during request from/to local buffers to/from the grant references. Before grant copy operation local buffers must be allocated what is done by calling ioreq_init_copy_buffers. For the 'read' operation, first, the qemu device invokes the read operation on local buffers and on

[Xen-devel] [PATCH v3 1/2] Interface for grant copy operation in libs.

In a linux part an ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..) system call is invoked. In mini-os the operation is yet not implemented. For other OSs there is a dummy implementation. Signed-off-by: Paulina Szubarczyk --- Changes since v2: - dropped the changes in libxc/include/xenctrl_compat - cha

Re: [Xen-devel] [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions

On 2016/6/22 16:35, Julien Grall wrote: > Hi Shannon, > > On 22/06/2016 04:24, Shannon Zhao wrote: >> On 2016/6/6 20:16, Wei Liu wrote: >>> On Mon, Jun 06, 2016 at 06:27:25PM +0800, Shannon Zhao wrote: > > > On 2016/6/6 18:11, Julien Grall wrote: >>> Hi Stefano, >>> >>> O

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

flight 96054 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/96054/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 94856 test-amd64-i3

Re: [Xen-devel] [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions

Hi Shannon, On 22/06/2016 09:50, Shannon Zhao wrote: You could define our own u8, u32 types in libxc. They are just aliased to uint8_t, uint32_t. Ah, right. But looking at the types.h it defines u64 differently for ARM_32 and ARM_64. Do we need to do that? If so, how could we get the CONFIG_ARM

[Xen-devel] [PATCH v2] xen: arm: Update arm64 image header

With the Linux kernel commits https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/arm64/booting.txt?id=4370eec05a887b0cd4392cd5dc5b2713174745c0 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/arm64/booting.txt?id=a2c1d73b94ed49

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

>>> On 22.06.16 at 10:38, wrote: > > On 6/22/2016 2:39 PM, Jan Beulich wrote: > On 21.06.16 at 16:38, wrote: >>> On 21/06/16 10:47, Jan Beulich wrote: And then - didn't we mean to disable that part of XenGT during migration, i.e. temporarily accept the higher performance >

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

On 22/06/16 07:39, Jan Beulich wrote: On 21.06.16 at 16:38, wrote: >> On 21/06/16 10:47, Jan Beulich wrote: >>> And then - didn't we mean to disable that part of XenGT during >>> migration, i.e. temporarily accept the higher performance >>> overhead without the p2m_ioreq_server en

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

>>> On 22.06.16 at 11:16, wrote: > On 22/06/16 07:39, Jan Beulich wrote: > On 21.06.16 at 16:38, wrote: >>> On 21/06/16 10:47, Jan Beulich wrote: And then - didn't we mean to disable that part of XenGT during migration, i.e. temporarily accept the higher performance

Re: [Xen-devel] [PATCH v3 1/2] Interface for grant copy operation in libs.

On 22/06/16 09:38, Paulina Szubarczyk wrote: > In a linux part an ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..) > system call is invoked. In mini-os the operation is yet not > implemented. For other OSs there is a dummy implementation. [...] > --- a/tools/libs/gnttab/linux.c > +++ b/tools/libs/gnttab/

Re: [Xen-devel] [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions (and more)

On Wed, Jun 22, 2016 at 11:24:07AM +0800, Shannon Zhao wrote: [...] > > But please make sure the CFLAGS doesn't get modified when it is not > > necessary. I would expect the CFLAGS is explicitly altered for a list > > of files. > I'm trying to do this. Make the libxl acpi codes compile like below

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

On 22/06/16 10:29, Jan Beulich wrote: On 22.06.16 at 11:16, wrote: >> On 22/06/16 07:39, Jan Beulich wrote: >> On 21.06.16 at 16:38, wrote: On 21/06/16 10:47, Jan Beulich wrote: > And then - didn't we mean to disable that part of XenGT during > migration, i.e. tempor

Re: [Xen-devel] [PATCH v3 1/2] Interface for grant copy operation in libs.

On Wed, 22 Jun 2016 10:37:24 +0100 David Vrabel wrote: > On 22/06/16 09:38, Paulina Szubarczyk wrote: > > In a linux part an ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..) > > system call is invoked. In mini-os the operation is yet not > > implemented. For other OSs there is a dummy implementation. >

Re: [Xen-devel] [PATCH v3 10/16] xen/arm: cpufeature: Provide an helper to check if a capability is supported

On Tue, 7 Jun 2016, Julien Grall wrote: > The CPU capabilities will be set depending on the value found in the CPU > registers. This patch provides a generic to go through a set of capabilities > and find which one should be enabled. > > The parameter "info" is used to display the kind of capabili

Re: [Xen-devel] [PATCH v3 11/16] xen/arm: Detect silicon revision and set cap bits accordingly

On Tue, 7 Jun 2016, Julien Grall wrote: > After each CPU has been started, we iterate through a list of CPU > errata to detect CPUs which need from hypervisor code patches. > > For each bug there is a function which check if that a particular CPU is > affected. This needs to be done on every CPUs

Re: [Xen-devel] [PATCH v3 12/16] xen/arm: Document the errata implemented in Xen

On Tue, 7 Jun 2016, Julien Grall wrote: > The new document will help to keep track of each erratum Xen is able to > handle. > > The text is based on the Linux doc in Documents/arm64/silicon-errata.txt. > > Also list the current errata that Xen is aware of. > > Signed-off-by: Julien Grall > > -

Re: [Xen-devel] [PATCH v3 13/16] xen/arm: arm64: Add Cortex-A53 cache errata workaround

On Tue, 7 Jun 2016, Julien Grall wrote: > The ARM errata 819472, 827319 and 824069 define the same workaround for > these hardware issues in certain Cortex-A53 parts. > > The cache instructions "dc cvac" and "dc cvau" need to be upgraded to > "dc civac". > > Use the alternative framework to repla

Re: [Xen-devel] [PATCH v3 16/16] xen/arm: arm64: Document Cortex-A57 erratum 834220

On Tue, 7 Jun 2016, Julien Grall wrote: > The ARM erratum applies to certain revisions of Cortex-A57. The > processor may report a Stage 2 translation fault as the result of > Stage 1 fault for load crossing a page boundary when there is a > permission fault or device memory fault at stage 1 and a

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

On 6/22/2016 5:47 PM, George Dunlap wrote: On 22/06/16 10:29, Jan Beulich wrote: On 22.06.16 at 11:16, wrote: On 22/06/16 07:39, Jan Beulich wrote: On 21.06.16 at 16:38, wrote: On 21/06/16 10:47, Jan Beulich wrote: And then - didn't we mean to disable that part of XenGT during migration,

Re: [Xen-devel] [PATCH v3 10/16] xen/arm: cpufeature: Provide an helper to check if a capability is supported

Hi Stefano, On 22/06/16 10:59, Stefano Stabellini wrote: On Tue, 7 Jun 2016, Julien Grall wrote: The CPU capabilities will be set depending on the value found in the CPU registers. This patch provides a generic to go through a set of capabilities and find which one should be enabled. The param

Re: [Xen-devel] [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions (and more)

On 2016/6/22 17:38, Wei Liu wrote: > On Wed, Jun 22, 2016 at 11:24:07AM +0800, Shannon Zhao wrote: > [...] >>> > > But please make sure the CFLAGS doesn't get modified when it is not >>> > > necessary. I would expect the CFLAGS is explicitly altered for a list >>> > > of files. >> > I'm trying t

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

>>> On 22.06.16 at 11:47, wrote: > On 22/06/16 10:29, Jan Beulich wrote: > On 22.06.16 at 11:16, wrote: >>> On 22/06/16 07:39, Jan Beulich wrote: >>> On 21.06.16 at 16:38, wrote: > On 21/06/16 10:47, Jan Beulich wrote: >> And then - didn't we mean to disable that part of XenG

Re: [Xen-devel] [PATCH v3 14/16] xen/arm: arm64: Add cortex-A57 erratum 832075 workaround

On Tue, 7 Jun 2016, Julien Grall wrote: > The ARM erratum 832075 applies to certain revisions of Cortex-A57, one > of the workarounds is to change device loads into using load-acquire > semantics. > > Use the alternative framework to enable the workaround only on affected > cores. > > Whilst a gu

[Xen-devel] [libvirt test] 96095: tolerable FAIL - PUSHED

flight 96095 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/96095/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saver

Re: [Xen-devel] [PATCH v3 10/16] xen/arm: cpufeature: Provide an helper to check if a capability is supported

On Wed, 22 Jun 2016, Julien Grall wrote: > Hi Stefano, > > On 22/06/16 10:59, Stefano Stabellini wrote: > > On Tue, 7 Jun 2016, Julien Grall wrote: > > > The CPU capabilities will be set depending on the value found in the CPU > > > registers. This patch provides a generic to go through a set of >

[Xen-devel] [PATCH] xen: x86: remove duplicated MSR_IA32_FEATURE_CONTROL definition

From: Kai Huang MSR_IA32_FEATURE_CONTROL was introduced in below commit. Actually this MSR has already been defined as IA32_FEATURE_CONTROL_MSR. Remove it as a duplication. Also introduce a new macro for SGX_ENABLE bit in this MSR for better code and further use. The code of below commit is chan

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

On 22/06/16 11:10, Jan Beulich wrote: On 22.06.16 at 11:47, wrote: >> On 22/06/16 10:29, Jan Beulich wrote: >> On 22.06.16 at 11:16, wrote: On 22/06/16 07:39, Jan Beulich wrote: On 21.06.16 at 16:38, wrote: >> On 21/06/16 10:47, Jan Beulich wrote: >>> And then

Re: [Xen-devel] [PATCH v3 16/16] xen/arm: arm64: Document Cortex-A57 erratum 834220

Hi Stefano, On 22/06/16 11:08, Stefano Stabellini wrote: On Tue, 7 Jun 2016, Julien Grall wrote: The ARM erratum applies to certain revisions of Cortex-A57. The processor may report a Stage 2 translation fault as the result of Stage 1 fault for load crossing a page boundary when there is a perm

Re: [Xen-devel] [PATCH v3 16/16] xen/arm: arm64: Document Cortex-A57 erratum 834220

On Wed, 22 Jun 2016, Julien Grall wrote: > Hi Stefano, > > On 22/06/16 11:08, Stefano Stabellini wrote: > > On Tue, 7 Jun 2016, Julien Grall wrote: > > > The ARM erratum applies to certain revisions of Cortex-A57. The > > > processor may report a Stage 2 translation fault as the result of > > > St

[Xen-devel] [xen-unstable-coverity test] 96110: all pass - PUSHED

flight 96110 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/96110/ Perfect :-) All tests in this flight passed version targeted for testing: xen c6f7d21747805b50123fc1b8d73518fea2aa9096 baseline version: xen 08754333892407f415

Re: [Xen-devel] [RFC 1/8] xen/arm: gic: Consolidate the IRQ affinity set in a single place

On Tue, 7 Jun 2016, Julien Grall wrote: > The code to set the IRQ affinity is duplicated: once in > gicv{2,3}_set_properties and the other is gicv{2,3}_irq_set_affinity. > > Remove the code from gicv{2,3}_set_properties and call directly the > affinity set helper from the common code. > > Signed-

Re: [Xen-devel] [PATCHv2] x86/xen: avoid m2p lookup when setting early page table entries

On 21/06/16 20:31, Boris Ostrovsky wrote: > On 06/21/2016 12:09 PM, David Vrabel wrote: >> When page tables entries are set using xen_set_pte_init() during early >> boot there is no page fault handler that could handle a fault when >> performing an M2P lookup. >> >> In 64 guest (usually dom0) early

Re: [Xen-devel] [RFC 2/8] xen/arm: gic: Do not configure affinity for guest IRQ during routing

On Tue, 7 Jun 2016, Julien Grall wrote: > The affinity of a guest IRQ is set every time the guest enable it (see > vgic_enable_irqs). > > It is not necessary to set the affinity when the IRQ is routed to the > guest because Xen will never receive the IRQ until it hass been enabled > by the guest.

Re: [Xen-devel] [RFC 3/8] xen/arm: gic: split set_irq_properties

On Tue, 7 Jun 2016, Julien Grall wrote: > The callback set_irq_properties will configure the GIC for a specific > IRQ with the type and the priority. > > In a follow-up patch, Xen will configure the type and the priority at > different stage of the routing. So split it in 2 separate callbacks. >

Re: [Xen-devel] [RFC 5/8] xen/arm: gic: Document how gic_set_irq_type should be called

On Tue, 7 Jun 2016, Julien Grall wrote: > Changing the value of Int_config is UNPREDICTABLE when the corresponding > interrupt is not disabled. > > The driver is assuming the interrupt will be disabled by the caller of > gic_set_irq_type. Add an ASSERT to ensure it. > > Signed-off-by: Julien Gral

Re: [Xen-devel] [RFC 6/8] Revert "xen/arm: warn the user that we cannot route SPIs to Dom0 on ACPI"

On Tue, 7 Jun 2016, Julien Grall wrote: > This reverts commit f91c84edebe67296e4051af055dbf0adafb13a37. SPI > routing for ACPI support will be added in a follow-up patch. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > xen/arch/arm/vgic.c | 15 --- > 1 file chan

[Xen-devel] [xen-4.3-testing test] 96068: regressions - FAIL

flight 96068 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/96068/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt5 libvirt-build fail REGR. vs. 87893 build-amd64-libvi

[Xen-devel] [PATCH v4 01/15] xen/arm: Makefile: Sort the entries alphabetically

Signed-off-by: Julien Grall Acked-by: Stefano Stabellini --- Changes in v3: - Rebase on staging (conflict with s/xsplice/livepatch). Changes in v2: - Add Stefano's acked-by --- xen/arch/arm/Makefile | 40 +--- xen/arch/arm/a

[Xen-devel] [PATCH v4 05/15] xen/arm64: Add an helper to invalidate all instruction caches

Signed-off-by: Julien Grall Acked-by: Stefano Stabellini --- Changes in v2: - Add Stefano's acked-by --- xen/include/asm-arm/arm64/page.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h index 29a32cf..fbdc

[Xen-devel] [PATCH v4 06/15] xen/arm: arm64: Move the define BRK_BUG_FRAME into a separate header

New immediates will be defined in the future. To keep track of the immediates allocated, gather all of them in a separate header. Also rename BRK_BUG_FRAME to BKR_BUG_FRAME_IMM. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Changes in v2: - Add Stefano's reviewed-

[Xen-devel] [PATCH v4 14/15] xen/arm: arm64: Add cortex-A57 erratum 832075 workaround

The ARM erratum 832075 applies to certain revisions of Cortex-A57, one of the workarounds is to change device loads into using load-acquire semantics. Use the alternative framework to enable the workaround only on affected cores. Whilst a guest could trigger the deadlock, it can be broken when th

[Xen-devel] [PATCH v4 04/15] xen/arm: Add cpu_hwcap bitmap

This will be used to know if a feature, which Xen cares, is available accross all the CPUs. This code is a light version of arch/arm64/kernel/cpufeature.c from Linux v4.6-rc3. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Changes in v3: - Add Stefano's reviewed-by

[Xen-devel] [PATCH v4 02/15] xen/arm: Include the header asm-arm/system.h in asm-arm/page.h

The header asm-arm/page.h makes use of the macro dsb defined in the header asm-arm/system.h. Currently, the includer has to specify both of them. This can be avoided by including asm-arm/system.h in asm-arm/page.h. Signed-off-by: Julien Grall Acked-by: Stefano Stabellini --- Changes in v2:

[Xen-devel] [PATCH v4 07/15] xen/arm: arm64: Reserve a brk immediate to fault on purpose

It may not possible to return a proper error when encoding an instruction. Instead, a handcrafted instruction will be returned. Also, provide the encoding for the faulting instruction. Signed-off-by: Julien Grall Acked-by: Stefano Stabellini --- Changes in v2: - Add Stefano's acked

[Xen-devel] [PATCH v4 15/15] xen/arm: traps: Don't inject a fault if the translation VA -> IPA fails

Based on ARM ARM (D4.5.3 in ARM DDI 0486A and B3.12.7 in ARM DDI 0406C.c), a Stage 1 translation error has priority over a Stage 2 translation error. Therefore gva_to_ipa can only fail if another vCPU is playing with the page table. Rather than injecting a custom fault, replay the instruction and

[Xen-devel] [PATCH v4 03/15] xen/arm: Add macros to handle the MIDR

Add new macros to easily get different parts of the register and to check if a given MIDR match a CPU model range. The latter will be really useful to handle errata later. The macros have been imported from the header arch/arm64/include/asm/cputype.h in Linux v4.6-rc3. Also remove MIDR_MASK which

[Xen-devel] [PATCH v4 08/15] xen/arm: arm64: Add helpers to decode and encode branch instructions

We may need to update branch instruction when patching Xen. The code has been imported from the files arch/arm64/kernel/insn.c and arch/arm64/include/asm/insn.h in Linux v4.6. Note that only the necessary helpers have been imported. Signed-off-by: Julien Grall Acked-by: Stefano Stabellini ---

[Xen-devel] [PATCH v4 11/15] xen/arm: Detect silicon revision and set cap bits accordingly

After each CPU has been started, we iterate through a list of CPU errata to detect CPUs which need from hypervisor code patches. For each bug there is a function which check if that a particular CPU is affected. This needs to be done on every CPUs to cover heterogenous system properly. If a certa

[Xen-devel] [PATCH v4 00/15] xen/arm: Introduce alternative runtime patching for ARM64

Hello, Some of the processor errata will require to modify code sequence. As those modifications may impact the performance, they should only be enabled on affected cores. Furthermore, Xen may also want to take advantage of new hardware features coming up with v8.1 and v8.2. The first part of the

[Xen-devel] [PATCH v4 13/15] xen/arm: arm64: Add Cortex-A53 cache errata workaround

The ARM errata 819472, 827319 and 824069 define the same workaround for these hardware issues in certain Cortex-A53 parts. The cache instructions "dc cvac" and "dc cvau" need to be upgraded to "dc civac". Use the alternative framework to replace those instructions only on affected cores. Whilst

[Xen-devel] [PATCH v4 09/15] xen/arm: Introduce alternative runtime patching

Some of the processor erratum will require to modify code sequence. As those modifications may impact the performance, they should only be enabled on affected cores. Furthermore, Xen may also want to take advantage of new hardware features coming up with v8.1 and v8.2. This patch adds an infrastru

[Xen-devel] [PATCH v4 10/15] xen/arm: cpufeature: Provide an helper to check if a capability is supported

The CPU capabilities will be set depending on the value found in the CPU registers. This patch provides a generic to go through a set of capabilities and find which one should be enabled. The parameter "info" is used to display the kind of capability updated (e.g workaround, feature...). Signed-o

[Xen-devel] [PATCH v4 12/15] xen/arm: Document the errata implemented in Xen

The new document will help to keep track of each erratum Xen is able to handle. The text is based on the Linux doc in Documents/arm64/silicon-errata.txt. Also list the current errata that Xen is aware of. Signed-off-by: Julien Grall Acked-by: Stefano Stabellini --- Changes in v4:

Re: [Xen-devel] [PATCHv2] x86/xen: avoid m2p lookup when setting early page table entries

On 22/06/16 11:54, David Vrabel wrote: > On 21/06/16 20:31, Boris Ostrovsky wrote: >> On 06/21/2016 12:09 PM, David Vrabel wrote: >>> When page tables entries are set using xen_set_pte_init() during early >>> boot there is no page fault handler that could handle a fault when >>> performing an M2P l

Re: [Xen-devel] [RFC 2/8] xen/arm: gic: Do not configure affinity for guest IRQ during routing

Hi Stefano, On 22/06/16 11:54, Stefano Stabellini wrote: On Tue, 7 Jun 2016, Julien Grall wrote: The affinity of a guest IRQ is set every time the guest enable it (see vgic_enable_irqs). It is not necessary to set the affinity when the IRQ is routed to the guest because Xen will never receive

Re: [Xen-devel] [PATCH v3 1/2] Interface for grant copy operation in libs.

On Wed, Jun 22, 2016 at 10:37:24AM +0100, David Vrabel wrote: > On 22/06/16 09:38, Paulina Szubarczyk wrote: > > In a linux part an ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..) > > system call is invoked. In mini-os the operation is yet not > > implemented. For other OSs there is a dummy implementati

[Xen-devel] [PATCH 1/6] xen/build: Allow the use of C freestanding headers

The C standard defines two types of conforming implementation; hosted and freestanding. A subset of the standard headers are the freestanding headers, requiring no library support at all to use, and therefore usable by Xen. Unfortunately, -nostdinc is an overly large switch, and there is no alter

Re: [Xen-devel] [PATCH v3 1/2] Interface for grant copy operation in libs.

On Wed, Jun 22, 2016 at 11:53:00AM +0200, Paulina Szubarczyk wrote: [...] > > I know Wei asked for this but you've replaced what should be a single > > pointer assignment with a memory allocation and two loops over all the > > segments. > > > > This is a hot path and the two structures (the libxen

[Xen-devel] [PATCH 4/6] xen/build: Use the system limits.h header

The C spec identifies limits.h as freestanding, and available for use in non-hosted environments, such as Xen. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Konrad Rzeszutek Wilk CC: Stefano Stabellini CC: Tim Deegan CC: Wei Liu --- xen/common/lib.

Re: [Xen-devel] [RFC 7/8] xen/arm: Allow DOM0 to set the irq type when ACPI is inuse

On Tue, 7 Jun 2016, Julien Grall wrote: > The function route_irq_to_guest mandates the IRQ type, stored in > desc->arch.type, to be valid. However, in case of ACPI, these > information is not part of the static tables. Therefore Xen needs to > rely on DOM0 to provide a valid type based on the firmw

[Xen-devel] [PATCH 3/6] xen/build: Use the system stdint.h header

The C spec identifies stdint.h as freestanding, and available for use in non-hosted environments, such as Xen. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Konrad Rzeszutek Wilk CC: Stefano Stabellini CC: Tim Deegan CC: Wei Liu --- xen/crypto/vmac

[Xen-devel] [PATCH 2/6] xen/build: Use the system stdarg.h header

The C spec identifies stdarg.h as freestanding, and available for use in non-hosted environments, such as Xen. This replaces the in-tree xen/stdarg.h, which is completely tied to GCC. Signed-off-by: Andrew Cooper --- CC: Stefano Stabellini CC: Julien Grall CC: George Dunlap CC: Ian Jackson C

[Xen-devel] [PATCH 5/6] xen/build: Use the system stddef.h and inttypes.h headers

These two headers must be changed in unison, because as noted in c/s 65808a8e "libelf: check all pointer accesses", PRIxPTR is broken in Xen's local copy of inttypes.h in 32bit builds. This is precisely why we shouldn't have our own local copies of the standard header files. Signed-off-by: Andrew

[Xen-devel] [PATCH 0/6] xen/build: Use system headers

Make use of C standard freestanding headers, to avoid bugs in our own local versions of inttypes.h and booleans. Andrew Cooper (6): xen/build: Allow the use of C freestanding headers xen/build: Use the system stdarg.h header xen/build: Use the system stdint.h header xen/build: Use the syst

[Xen-devel] [PATCH 6/6] xen/build: Use the system stdbool.h header

and switch bool_t to being of type _Bool rather than char. Using bool_t as char causes several subtle problems; first that a bool_t actually has more than two values, and that (bool_t)0x100 actually has the value 0 rather than the expected 1, due to truncation. Making this change reveals two bugs

Re: [Xen-devel] [RFC 4/8] xen/arm: gic: set_type: Pass the type in parameter rather than in desc->arch.type

On Tue, 7 Jun 2016, Julien Grall wrote: > A follow-up patch will not store the type in desc->arch.type. Also, the > callback prototype is more logical. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini > xen/arch/arm/gic-v2.c | 3 +-- > xen/arch/arm/gic-v3.c | 3 +-- >

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

On 22/06/16 11:07, Yu Zhang wrote: > > > On 6/22/2016 5:47 PM, George Dunlap wrote: >> On 22/06/16 10:29, Jan Beulich wrote: >> On 22.06.16 at 11:16, wrote: On 22/06/16 07:39, Jan Beulich wrote: On 21.06.16 at 16:38, wrote: >> On 21/06/16 10:47, Jan Beulich wrote:

[Xen-devel] monitor access to pages with a specific p2m_type_t

Hi, Is it possible to monitor the access on the pages withp2m_type_t p2m_ram_shared? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC 8/8] xen/arm: acpi: route all unused IRQs to DOM0

On Tue, 7 Jun 2016, Julien Grall wrote: > It is not possible to know which IRQs will be used by DOM0 when ACPI is > inuse. The approach implemented by this patch, will route all unused > IRQs to DOM0 before it has booted. > > The number of IRQs routed is based on the maximum SPIs supported by the

Re: [Xen-devel] [PATCH] xen: x86: remove duplicated MSR_IA32_FEATURE_CONTROL definition

>>> On 22.06.16 at 12:17, wrote: > @@ -288,7 +289,6 @@ > #define MSR_IA32_PLATFORM_ID 0x0017 > #define MSR_IA32_EBL_CR_POWERON 0x002a > #define MSR_IA32_EBC_FREQUENCY_ID0x002c > -#define MSR_IA32_FEATURE_CONTROL 0x003a > #define MSR_IA32_TSC_ADJUST

Re: [Xen-devel] [RFC 7/8] xen/arm: Allow DOM0 to set the irq type when ACPI is inuse

Hi Stefano, On 22/06/16 12:23, Stefano Stabellini wrote: On Tue, 7 Jun 2016, Julien Grall wrote: The function route_irq_to_guest mandates the IRQ type, stored in desc->arch.type, to be valid. However, in case of ACPI, these information is not part of the static tables. Therefore Xen needs to re

[Xen-devel] [PULL 2/3] xen: fix qdisk BLKIF_OP_DISCARD for 32/64 word size mix

From: Juergen Gross In case the word size of the domU and qemu running the qdisk backend differ BLKIF_OP_DISCARD will not work reliably, as the request structure in the ring have different layouts for different word size. Correct this by copying the request structure in case of different word si

[Xen-devel] [PULL 0/3] xen-20160622-tag

emu-dm.git tags/xen-20160622-tag for you to fetch changes up to 25f8f6b4c295940ae5d83c19509353afc1dbc9a4: xen: move xen_sysdev to xen_backend.c (2016-06-22 11:28:42 +0100) ---- xe

[Xen-devel] [PULL 3/3] xen: move xen_sysdev to xen_backend.c

From: Juergen Gross Commit 9432e53a5bc88681b2d3aec4dac9db07c5476d1b added xen_sysdev as a system device to serve as an anchor for removable virtual buses. This introduced a build failure for non-x86 builds with CONFIG_XEN_BACKEND set, as xen_sysdev was defined in a x86 specific file while being c

Re: [Xen-devel] [PATCH 1/6] xen/build: Allow the use of C freestanding headers

On 22/06/16 12:24, Andrew Cooper wrote: > The C standard defines two types of conforming implementation; hosted and > freestanding. A subset of the standard headers are the freestanding headers, > requiring no library support at all to use, and therefore usable by Xen. > > Unfortunately, -nostdin

[Xen-devel] [PULL 1/3] xen: fix style of hw/block/xen_blkif.h

From: Juergen Gross Fix hw/block/xen_blkif.h to match qemu coding style. Signed-off-by: Juergen Gross Acked-by: Stefano Stabellini Signed-off-by: Stefano Stabellini --- hw/block/xen_blkif.h | 151 +++ 1 file changed, 81 insertions(+), 70 deleti

Re: [Xen-devel] [RFC 7/8] xen/arm: Allow DOM0 to set the irq type when ACPI is inuse

On Wed, 22 Jun 2016, Julien Grall wrote: > > > @@ -356,6 +375,8 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int > > > n) > > > { > > > irq_set_affinity(p->desc, cpumask_of(v_target->processor)); > > > spin_lock_irqsave(&p->desc->lock, flags); > > > +

[Xen-devel] [PATCH v3 1/2] xen/arm: drivers: scif: Remove dead code

The two struct members baud and clock_hz are in the end read only variables nowhere used for anything useful. Removing them makes the code much simpler without changing any functionality. Signed-off-by: Dirk Behme --- xen/drivers/char/scif-uart.c| 24 +--- xen/include/asm

[Xen-devel] [PATCH v3 2/2] xen/arm: drivers: scif: Don't overwrite firmware settings

Besides the 14MHz external clock, the SCIF might be clocked by an internal 66MHz clock. If this is the case, the current clock source selection breaks this configuration. Same for the settings done by the firmware for data bits, stop bits and parity. Completely drop this and rely on the settings d

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

>>> On 22.06.16 at 12:15, wrote: > On 22/06/16 11:10, Jan Beulich wrote: > On 22.06.16 at 11:47, wrote: >>> So you're afraid of this sequence of events? >>> 1) Server A de-registered, triggering a ioreq_server -> ram_rw type change >>> 2) gfn N is marked as misconfigured >>> 3) Server B regis

  1   2   3   >