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

flight 112599 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/112599/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. vs. 112513

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

flight 112598 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/112598/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 112557

[Xen-devel] [ovmf baseline-only test] 71966: all pass

This run is configured for baseline tests only. flight 71966 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71966/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf bee7fe0ef950e2966cbdcd753be326f8a3c782f3 baseline

[Xen-devel] [linux-3.18 test] 112595: trouble: blocked/broken/fail/pass

flight 112595 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/112595/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 3 capture-logs broken REGR. vs. 112102

Re: [Xen-devel] [PATCH v3 03/13] xen/pvcalls: connect to the backend

On 07/31/2017 06:57 PM, Stefano Stabellini wrote: > Implement the probe function for the pvcalls frontend. Read the > supported versions, max-page-order and function-calls nodes from > xenstore. > > Only one frontend<->backend connection is supported at any given time > for a guest. Store the

[Xen-devel] [linux-next test] 112593: regressions - trouble: blocked/broken/fail/pass

flight 112593 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/112593/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 112551

Re: [Xen-devel] [PATCH v3 02/13] xen/pvcalls: implement frontend disconnect

On 07/31/2017 06:57 PM, Stefano Stabellini wrote: > Introduce a data structure named pvcalls_bedata. It contains pointers to > the command ring, the event channel, a list of active sockets and a list > of passive sockets. Lists accesses are protected by a spin_lock. > > Introduce a waitqueue to

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

On 08/11/2017 02:27 PM, Wei Liu wrote: On Fri, Aug 11, 2017 at 12:37:04PM -0600, Jim Fehlig wrote: On 08/11/2017 05:45 AM, Wei Liu wrote: On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote: On 08/08/2017 09:09 AM, Wei Liu wrote: Ian and Stefano Oleksandr discovered that the p9fs

Re: [Xen-devel] [PATCH v3 01/13] xen/pvcalls: introduce the pvcalls xenbus frontend

On 07/31/2017 06:57 PM, Stefano Stabellini wrote: > Introduce a xenbus frontend for the pvcalls protocol, as defined by > https://xenbits.xen.org/docs/unstable/misc/pvcalls.html. > > This patch only adds the stubs, the code will be added by the following > patches. > > Signed-off-by: Stefano

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

On Fri, Aug 11, 2017 at 12:37:04PM -0600, Jim Fehlig wrote: > On 08/11/2017 05:45 AM, Wei Liu wrote: > > On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote: > > > On 08/08/2017 09:09 AM, Wei Liu wrote: > > > > Ian and Stefano > > > > > > > > Oleksandr discovered that the p9fs array in

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

On 08/11/2017 05:45 AM, Wei Liu wrote: On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote: On 08/08/2017 09:09 AM, Wei Liu wrote: Ian and Stefano Oleksandr discovered that the p9fs array in libxl_domain_config is name p9 instead of p9s. This causes problem for his work to rework

[Xen-devel] [PATCH] xen/arm: p2m: Remove p2m_operation

This is a left over of before the P2M code was reworked. So drop it. Signed-off-by: Julien Grall --- xen/arch/arm/p2m.c | 4 1 file changed, 4 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 7b2aac4c90..c484469e6c 100644 ---

Re: [Xen-devel] [PATCH 00/11] xen/arm: Clean-up traps.c

Hi, Please ignore this thread, I forgot to remove the *.patch in the folder before sending another series :/ Sorry for the noise. On 11/08/17 19:11, Julien Grall wrote: Hi all, xen/arch/arm/traps.c is beginning to get very big. This series is moving out the co-processor and sysreg emulate

[Xen-devel] [PATCH] xen/arm: p2m: Remove p2m_operation

This is a left over of before the P2M code was reworked. So drop it. Signed-off-by: Julien Grall --- xen/arch/arm/p2m.c | 4 1 file changed, 4 deletions(-) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 7b2aac4c90..c484469e6c 100644 ---

[Xen-devel] [PATCH 00/11] xen/arm: Clean-up traps.c

Hi all, xen/arch/arm/traps.c is beginning to get very big. This series is moving out the co-processor and sysreg emulate in separate files. This will avoid to grow traps.c when adding more registers emulations (coming soon). A branch with this series has been pushed:

Re: [Xen-devel] [PATCH V2 2/3] xen-pt: bind/unbind interrupt remapping format MSI

On Wed, Aug 09, 2017 at 04:51:21PM -0400, Lan Tianyu wrote: > From: Chao Gao > > If a vIOMMU is exposed to guest, guest will configure the msi to remapping > format. The original code isn't suitable to the new format. A new pair > bind/unbind interfaces are added for this

[Xen-devel] [PATCH 04/11] xen/arm: vgic-v3: Re-order the includes alphabetically

Signed-off-by: Julien Grall --- xen/arch/arm/vgic-v3.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c index 48c7682671..cbeac28b28 100644 --- a/xen/arch/arm/vgic-v3.c +++ b/xen/arch/arm/vgic-v3.c @@

[Xen-devel] [PATCH 06/11] xen/arm: Move arch/arm/vtimer.h to include/asm-arm/vtimer.h

It will be necessary to include vtimer.h from subdirectory making the inclusion a bit awkward. Signed-off-by: Julien Grall --- xen/arch/arm/domain.c | 2 +- xen/arch/arm/traps.c | 2 +- xen/{arch/arm => include/asm-arm}/vtimer.h |

[Xen-devel] [PATCH 09/11] xen/arm: Move co-processor emulation outside of traps.c

The co-processor emulation is quite big and pretty much standalone. Move it in a separate file to shrink down the size of traps.c. At the same time remove unused cpregs.h. No functional change. Signed-off-by: Julien Grall --- xen/arch/arm/Makefile | 1 +

[Xen-devel] [PATCH 07/11] xen/arm: traps: Export a bunch of helpers to handle emulation

A follow-up patch will move some parts of traps.c in separate files. The will require to use helpers that are currently statically defined. Export the following helpers: - inject_undef64_exception - inject_undef_exception - check_conditional_instr - advance_pc - handle_raz_wi

[Xen-devel] [PATCH 03/11] xen/arm: traps: Re-order the includes alphabetically

Signed-off-by: Julien Grall --- xen/arch/arm/traps.c | 42 ++ 1 file changed, 22 insertions(+), 20 deletions(-) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index c07999b518..ca9bef712c 100644 --- a/xen/arch/arm/traps.c

[Xen-devel] [PATCH 00/11] xen/arm: Clean-up traps.c

Hi all, xen/arch/arm/traps.c is beginning to get very big. This series is moving out the co-processor and sysreg emulate in separate files. This will avoid to grow traps.c when adding more registers emulations (coming soon). A branch with this series has been pushed:

[Xen-devel] [PATCH 08/11] xen/arm: Move sysreg emulation outside of traps.c

The sysreg emulation is 64-bit specific and surrounded by #ifdef. Move them in a separate file arm/arm64/vsysreg.c to shrink down a bit traps.c No functional change. Signed-off-by: Julien Grall --- xen/arch/arm/arm64/Makefile | 1 + xen/arch/arm/arm64/vsysreg.c

[Xen-devel] [PATCH 01/11] xen/grant_table: Include mm.h in xen/grant_table.h

While re-ordering the include alphabetically in arch/arm/domain.c, I got a complitation error because grant_table.h is using gfn_t before been defined: In file included from domain.c:14:0: xen/xen/include/xen/grant_table.h:153:29: error: unknown type name ‘gfn_t’

[Xen-devel] [PATCH 05/11] xen/arm: vtimer: Re-order the includes alphabetically

Signed-off-by: Julien Grall --- xen/arch/arm/vtimer.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c index 32ac1279ae..9c7e8f441c 100644 --- a/xen/arch/arm/vtimer.c +++ b/xen/arch/arm/vtimer.c @@

[Xen-devel] [PATCH 11/11] xen/arm: Limit the scope of cpregs.h

Currently, cpregs.h is included in pretty much every files even for arm64. However, the only use for arm64 is when emulating co-processors. For arm32, cpregs.h rely on the presence of processor.h (define *_SYSREG helpers). So move the inclusion in asm-arm/arm32/processor.h. cpregs.h will also be

[Xen-devel] [PATCH 02/11] xen/arm: domain: Re-order the includes alphabetically

Signed-off-by: Julien Grall --- xen/arch/arm/domain.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 2dc8b0ab5a..1d835d321d 100644 --- a/xen/arch/arm/domain.c +++

[Xen-devel] [PATCH 10/11] xen/arm: Move sysregs.h in arm64 sub-directory

sysregs.h contains only code protected by #ifdef CONFIG_ARM_64. Move it in arm64 sub-directory to reflect that and remove the #ifdef. At the same time, fixup the guards. Signed-off-by: Julien Grall --- xen/include/asm-arm/arm64/processor.h | 2 ++

[Xen-devel] [ovmf test] 112594: all pass - PUSHED

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

Re: [Xen-devel] [PATCH 3/5] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

On Wed, 2017-08-09 at 12:38 +0100, Tim Deegan wrote: > Hi, > Hey! :-) > At 10:01 +0200 on 27 Jul (1501149684), Dario Faggioli wrote: > > In Xen, that is impossible, and that's particularly problematic > > when system is idle (or lightly loaded) systems, as CPUs that > > are idle may never have

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

flight 112588 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/112588/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 112544 Tests which

Re: [Xen-devel] [PATCH for-2.10 1/2] hw/acpi: Call acpi_set_pci_info when no ACPI tables needed

On Fri, Aug 11, 2017 at 04:11:37PM +0100, Anthony PERARD wrote: > To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be > set, but this was done only when ACPI tables are built which is not > needed for a Xen guest. The need for the property starts with commit > "pc: pcihp:

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

On Fri, 11 Aug 2017, Wei Liu wrote: > On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote: > > On 08/08/2017 09:09 AM, Wei Liu wrote: > > > Ian and Stefano > > > > > > Oleksandr discovered that the p9fs array in libxl_domain_config is name > > > p9 instead of p9s. This causes problem for

[Xen-devel] [PATCH 3/5] ARM: ITS: Deny hardware domain access to its

From: Manish Jaggi This patch extends the gicv3_iomem_deny_access functionality by adding support for its region as well. Added function gicv3_its_deny_access. Signed-off-by: Manish Jaggi --- xen/arch/arm/gic-v3-its.c| 19 +++

[Xen-devel] [PATCH 4/5] ARM: Introduce get_hwdom_madt_size in gic_hw_operations

From: Manish Jaggi estimate_acpi_efi_size needs to be updated to provide correct size of hardware domains MADT, which now adds ITS information as well. Introducing gic_get_hwdom_madt_size. Signed-off-by: Manish Jaggi --- xen/arch/arm/domain_build.c

[Xen-devel] [PATCH 2/2] ARM: ITS: Populate host_its_list from ACPI MADT Table

From: Manish Jaggi Added gicv3_its_acpi_init to update host_its_list from MADT table. Signed-off-by: Manish Jaggi --- xen/arch/arm/gic-v3-its.c| 14 ++ xen/arch/arm/gic-v3.c| 8 xen/include/asm-arm/gic_v3_its.h |

[Xen-devel] [PATCH 5/5] ARM: ITS: Pass ITS in Hardware Domain MADT

From: Manish Jaggi Adds gicv3_its_make_hwdom_madt to update hwdom MADT ITS information. Signed-off-by: Manish Jaggi --- xen/arch/arm/gic-v3-its.c| 24 xen/arch/arm/gic-v3.c| 1 +

[Xen-devel] [PATCH 1/5] ARM: ITS: Introduce common function add_to_host_its_list

From: Manish Jaggi add_to_host_its_list will update the host_its_list. This common function to be invoked from gicv3_its_dt_init and gic_v3_its_acpi_init. Signed-off-by: Manish Jaggi --- xen/arch/arm/gic-v3-its.c | 36 +++-

[Xen-devel] [PATCH v2 0/5] ARM: ACPI: ITS: Add ITS Support for ACPI hardware domain

From: Manish Jaggi This patch is split into 5 patches. First two add support for updating host_its_list from ACPI MADT table. The rest patches provide support to update the hardware domain MADT table with ITS information. Changes since v1: - split patches into smaller ones -

[Xen-devel] [PATCH v2 3/4] x86/vtd: introduce a PVH implementation of iommu_inclusive_mapping

On certain Intel systems, as far as I can tell almost all pre-Haswell ones, trying to boot a PVH Dom0 will freeze the box completely, up to the point that not even the watchdog works. The freeze happens exactly when enabling the DMA remapping in the IOMMU, the last line seen is: (XEN)

[Xen-devel] [PATCH v2 1/4] x86/dom0: prevent access to MMCFG areas for PVH Dom0

They are emulated by Xen, so they must not be mapped into Dom0 p2m. Introduce a helper function to add the MMCFG areas to the list of denied iomem regions for PVH Dom0. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper

[Xen-devel] [PATCH v2 2/4] x86/dom0: prevent PVH Dom0 from mapping read-only the IO APIC area

This is emulated by Xen and must not be mapped into PVH Dom0 p2m. Signed-off-by: Roger Pau Monné --- Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/dom0_build.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[Xen-devel] [PATCH v2 4/4] x86/dom0: re-order DMA remapping enabling for PVH Dom0

Make sure the reserved regions are setup before enabling the DMA remapping in the IOMMU, by calling dom0_setup_permissions before iommu_hwdom_init. Also, in order to workaround IOMMU issues seen on pre-Haswell Intel hardware, as described in patch "introduce a PVH implementation of

[Xen-devel] [PATCH v2 0/4] x86/pvh: implement iommu_inclusive_mapping for PVH Dom0

Hello, Currently iommu_inclusive_mapping is not working for PVH Dom0, this patch series allows using it for a PVH Dom0, which seems to be required in order to boot on older boxes. Git branch can be found at: git://xenbits.xen.org/people/royger/xen.git iommu_inclusive_v2 Thanks, Roger.

[Xen-devel] [PATCH v3] xen: Implement hypercall for tracing of program counters

This commit makes the changes to the hypervisor, the build system as well as libxc necessary in order to facilitate tracing of program counters. A discussion of the design can be found in the mailing list: https://lists.xen.org/archives/html/xen-devel/2017-05/threads.html#02210 The list of files

[Xen-devel] [PATCH for-2.10 0/2] Fix hotplug of PCI passthrought device on Xen

Adding PCI passthrough before the guest start works fine (broken in 2.9 but now fixed), but hotplug does not work anymore. Anthony PERARD (2): hw/acpi: Call acpi_set_pci_info when no ACPI tables needed Revert "ACPI: don't call acpi_pcihp_device_plug_cb on xen" hw/acpi/piix4.c | 11

[Xen-devel] [PATCH for-2.10 2/2] Revert "ACPI: don't call acpi_pcihp_device_plug_cb on xen"

This reverts commit 153eba4726dfa1bdfc31d1fe973b2a61b9035492. This patch prevents PCI passthrough hotplug on Xen. Even if the Xen tool stack prepares its own ACPI tables, we still rely on QEMU for hotplug ACPI notifications. The original issue is fixed by the previous patch (hw/acpi: Call

[Xen-devel] [PATCH for-2.10 1/2] hw/acpi: Call acpi_set_pci_info when no ACPI tables needed

To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be set, but this was done only when ACPI tables are built which is not needed for a Xen guest. The need for the property starts with commit "pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice"

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Fri, Aug 11, 2017 at 5:41 AM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> Changes: >> - v2: >>- Add support for global stack cookie while compiler default to fs without >> mcmodel=kernel >>- Change patch 7 to correctly jump out of

Re: [Xen-devel] [RFC v2 13/23] x86/power/64: Adapt assembly for PIE support

On Fri, Aug 11, 2017 at 5:36 AM, Pavel Machek wrote: > On Thu 2017-08-10 10:26:05, Thomas Garnier wrote: >> Change the assembly code to use only relative references of symbols for the >> kernel to be PIE compatible. >> >> Position Independent Executable (PIE) support will allow to

[Xen-devel] [PATCH v4] xen: get rid of paravirt op adjust_exception_frame

When running as Xen pv-guest the exception frame on the stack contains %r11 and %rcx additional to the other data pushed by the processor. Instead of having a paravirt op being called for each exception type prepend the Xen specific code to each exception entry. When running as Xen pv-guest just

Re: [Xen-devel] [PATCH] xen/events: Fix interrupt lost during irq_disable and irq_enable

On 29/07/17 18:59, Liu Shuo wrote: > Here is a device has xen-pirq-MSI interrupt. Dom0 might lost interrupt > during driver irq_disable/irq_enable. Here is the scenario, > 1. irq_disable -> disable_dynirq -> mask_evtchn(irq channel) > 2. dev interrupt raised by HW and Xen mark its evtchn as

[Xen-devel] [PATCH v2 10/12] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page

This patch adjusts the IOREQ server code to use type-safe gfn_t values where possible. No functional change. Signed-off-by: Paul Durrant --- Cc: Andrew Cooper Cc: Jan Beulich --- xen/arch/x86/hvm/ioreq.c | 42

[Xen-devel] [PATCH v2 12/12] x86/hvm/ioreq: add a new mappable resource type...

... XENMEM_resource_ioreq_server This patch adds support for a new resource type that can be mapped using the XENMEM_acquire_resource memory op. If an emulator makes use of this resource type then, instead of mapping gfns, the IOREQ server will allocate pages from the heap. These pages will

[Xen-devel] [PATCH v2 11/12] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

A subsequent patch will introduce a new scheme to allow an emulator to map IOREQ server pages directly from Xen rather than the guest P2M. This patch lays the groundwork for that change by deferring mapping of gfns until their values are requested by an emulator. To that end, the pad field of the

Re: [Xen-devel] [RFC PATCH v2 09/22] ARM: vITS: protect LPI priority update with pending_irq lock

Hi Andre, On 21/07/17 20:59, Andre Przywara wrote: As the priority value is now officially a member of struct pending_irq, we need to take its lock when manipulating it via ITS commands. Make sure we take the IRQ lock after the VCPU lock when we need both. Signed-off-by: Andre Przywara

Re: [Xen-devel] [RFC PATCH v2 08/22] ARM: vGIC: move virtual IRQ priority from rank to pending_irq

Hi Andre, On 21/07/17 20:59, Andre Przywara wrote: So far a virtual interrupt's priority is stored in the irq_rank structure, which covers multiple IRQs and has a single lock for this group. Generalize the already existing priority variable in struct pending_irq to not only cover LPIs, but

[Xen-devel] [PATCH v2 02/12] x86/mm: allow a privileged PV domain to map guest mfns

In the case where a PV domain is mapping guest resources then it needs make the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest domid, so that the passed in gmfn values are correctly treated as mfns rather than gfns present in the guest p2m. This patch removes a check which

[Xen-devel] [PATCH v2 09/12] x86/hvm/ioreq: simplify code and use consistent naming

This patch re-works much of the IOREQ server initialization and teardown code: - The hvm_map/unmap_ioreq_gfn() functions are expanded to call through to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called separately by outer functions. - Several functions now test the validity

[Xen-devel] [PATCH v2 03/12] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

Certain memory resources associated with a guest are not necessarily present in the guest P2M and so are not necessarily available to be foreign-mapped by a tools domain unless they are inserted, which risks shattering a super-page mapping. This patch adds a new memory op to allow such resourced

[Xen-devel] [PATCH v2 04/12] tools/libxenforeignmemory: add support for resource mapping

A previous patch introduced a new HYPERVISOR_memory_op to acquire guest resources for direct priv-mapping. This patch adds new functionality into libxenforeignmemory to make use of a new privcmd ioctl [1] that uses the new memory op to make such resources available via mmap(2). [1]

[Xen-devel] [PATCH v2 05/12] tools/libxenctrl: use new xenforeignmemory API to seed grant table

A previous patch added support for priv-mapping guest resources directly (rather than having to foreign-map, which requires P2M modification for HVM guests). This patch makes use of the new API to seed the guest grant table unless the underlying infrastructure (i.e. privcmd) doesn't support it,

[Xen-devel] [PATCH v2 00/12] x86: guest resource mapping

This series introduces support for direct mapping of guest resources. The resources are: - Grant tables - IOREQ server pages Paul Durrant (12): [x86|arm]: remove code duplication x86/mm: allow a privileged PV domain to map guest mfns x86/mm: add HYPERVISOR_memory_op to acquire guest

[Xen-devel] [PATCH v2 01/12] [x86|arm]: remove code duplication

There is a substantial amount of code duplicated between the x86 and arm implementations of mm.c:xenmem_add_to_physmap_one() for XENMAPSPACE_grant_table. Also, the code in question looks like it really should be in common/grant_table.c This patch introduces a new function in common/grant_table.c

[Xen-devel] [PATCH v2 07/12] x86/hvm/ioreq: use bool rather than bool_t

This patch changes use of bool_t to bool in the IOREQ server code. It also fixes an incorrect indentation in a continuation line. This patch is purely cosmetic. No semantic or functional change. Signed-off-by: Paul Durrant --- Cc: Jan Beulich Cc:

[Xen-devel] [PATCH v2 08/12] x86/hvm/ioreq: move is_default into struct hvm_ioreq_server

Legacy emulators use the 'default' IOREQ server which has slightly different semantics than other, explicitly created, IOREQ servers. Because of this, most of the initialization and teardown code needs to know whether the server is default or not. This is currently achieved by passing an

[Xen-devel] [PATCH v2 06/12] x86/hvm/ioreq: rename .*pfn and .*gmfn to .*gfn

Since IOREQ servers are only relevant to HVM guests and all the names in question unequivocally refer to guest frame numbers, name them all .*gfn to avoid any confusion. This patch is purely cosmetic. No semantic or functional change. Signed-off-by: Paul Durrant --- Cc:

Re: [Xen-devel] [RFC PATCH v2 07/22] ARM: vGIC: introduce priority setter/getter

Hi Andre, On 21/07/17 20:59, Andre Przywara wrote: Since the GICs MMIO access always covers a number of IRQs at once, introduce wrapper functions which loop over those IRQs, take their locks and read or update the priority values. This will be used in a later patch. Signed-off-by: Andre

[Xen-devel] Alloc Page from fixed physical memory range

Hello All, Is there any way in linux e.g using device tree, to give a driver a fixed physical memory range to alloc pages from? All pages are allocated from kernel memory assigned using memory node in device tree. Is there any way to create a memory node and assign it to driver so that buddy

[Xen-devel] [xen-unstable-smoke test] 112596: tolerable trouble: broken/pass - PUSHED

flight 112596 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/112596/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-pvops 2

Re: [Xen-devel] [PATCH v2 2/4] arm: processor: add new struct hsr_smc32 into hsr union

On 11/08/17 14:26, Volodymyr Babchuk wrote: On 10.08.17 00:22, Julien Grall wrote: On 09/08/2017 22:06, Volodymyr Babchuk wrote: Hi Julien, On 09.08.17 23:34, Julien Grall wrote: On 09/08/2017 20:44, Volodymyr Babchuk wrote: On ARMv8, one of conditional exceptions (SMC that

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On Fri, Aug 11, 2017 at 03:07:29PM +0200, Juergen Gross wrote: > On 11/08/17 14:54, Peter Zijlstra wrote: > > On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote: > >> Aah, okay. Now I understand the problem. The TLB isn't the issue but the > >> IPI is serving two purposes here: TLB

[Xen-devel] [PATCH] x86/config: Fix stale documentation concerning virtual layout

The hypercall argument translation area lives in the per-domain mappings in PML4 slot 260. Nothing currently resides in the lower canonical half above the 4GB boundary in a 32bit PV guest. Signed-off-by: Andrew Cooper --- CC: Jan Beulich ---

Re: [Xen-devel] [PATCH v2 2/4] arm: processor: add new struct hsr_smc32 into hsr union

On 10.08.17 00:22, Julien Grall wrote: On 09/08/2017 22:06, Volodymyr Babchuk wrote: Hi Julien, On 09.08.17 23:34, Julien Grall wrote: On 09/08/2017 20:44, Volodymyr Babchuk wrote: On ARMv8, one of conditional exceptions (SMC that originates from aarch32 state) have extra field in

[Xen-devel] [PATCH v3 3/3] x86/p2m-pt: pass level instead of page type to p2m_next_level()

This in turn calls for p2m_alloc_ptp() also being passed the numeric level. Signed-off-by: Jan Beulich Reviewed-by: George Dunlap --- v2: New. --- Question is whether passing the level to p2m_alloc_ptp() is really all that useful: p2m-ept.c's passes

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

flight 112581 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/112581/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 112557

[Xen-devel] [PATCH v3 2/3] x86/p2m: make p2m_alloc_ptp() return an MFN

None of the callers really needs the struct page_info pointer. Signed-off-by: Jan Beulich Acked-by: George Dunlap --- v3: Re-base over changes to patch 1. v2: Re-base over changes to patch 1. --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c

[Xen-devel] [PATCH v3 1/3] x86/p2m-pt: simplify p2m_next_level()

Calculate entry PFN and flags just once. Convert the two successive main if()-s to and if/else-if chain. Restrict variable scope where reasonable. Take the opportunity and also make the induction variable unsigned. This at once fixes excessive permissions granted in the 2M PTEs resulting from

[Xen-devel] [PATCH v3 0/3] x86/p2m: some code simplification

1: simplify p2m_next_level() 2: make p2m_alloc_ptp() return an MFN 3: pass level instead of page type to p2m_next_level() Signed-off-by: Jan Beulich See individual patches for change info. ___ Xen-devel mailing list

[Xen-devel] [PATCH v2] x86: check for allocation errors in modify_xen_mappings()

Reported-by: Julien Grall Signed-off-by: Jan Beulich --- v2: Comment the pl2e related ASSERT(). --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -5903,7 +5903,7 @@ int modify_xen_mappings(unsigned long s, { l3_pgentry_t *pl3e =

Re: [Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

Hi Julien, On 11.08.17 00:09, Julien Grall wrote: On 10/08/2017 21:09, Volodymyr Babchuk wrote: Hi, On 10.08.17 21:18, Julien Grall wrote: Hi, On 10/08/17 18:40, Volodymyr Babchuk wrote: On 10.08.17 19:11, Julien Grall wrote: On 10/08/17 16:33, Volodymyr Babchuk wrote: Hi Julien,

Re: [Xen-devel] [PATCH v2 3/3] x86/p2m-pt: pass level instead of page type to p2m_next_level()

>>> On 27.07.17 at 18:50, wrote: > On Wed, Jul 5, 2017 at 11:06 AM, Jan Beulich wrote: >> This in turn calls for p2m_alloc_ptp() also being passed the numeric >> level. >> >> Signed-off-by: Jan Beulich >> --- >> v2: New. >> ---

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On 11/08/17 14:54, Peter Zijlstra wrote: > On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote: >> Aah, okay. Now I understand the problem. The TLB isn't the issue but the >> IPI is serving two purposes here: TLB flushing (which is allowed to >> happen at any time) and serialization

[Xen-devel] [ovmf baseline-only test] 71963: all pass

This run is configured for baseline tests only. flight 71963 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71963/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf f8daac8121e66c46d3374f63f80308a777c2a2e7 baseline

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote: > Aah, okay. Now I understand the problem. The TLB isn't the issue but the > IPI is serving two purposes here: TLB flushing (which is allowed to > happen at any time) and serialization regarding access to critical pages > (which seems

Re: [Xen-devel] [PATCH v2 0/3] fix xen hvm guest with kaslr enabled

* Juergen Gross wrote: > On 08/08/17 16:00, Boris Ostrovsky wrote: > > On 08/08/2017 02:46 AM, Juergen Gross wrote: > >> On 28/07/17 12:23, Juergen Gross wrote: > >>> This patch series fixes a regression introduced in 4.13-rc1: A Xen > >>> HVM guest with KASLR enabled wouldn't

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On 11/08/17 14:35, Peter Zijlstra wrote: > On Fri, Aug 11, 2017 at 02:22:25PM +0200, Juergen Gross wrote: >> Wait - the TLB can be cleared at any time, as Andrew was pointing out. >> No cpu can rely on an address being accessible just because IF is being >> cleared. All that matters is the

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

* Thomas Garnier wrote: > Changes: > - v2: >- Add support for global stack cookie while compiler default to fs without > mcmodel=kernel >- Change patch 7 to correctly jump out of the identity mapping on kexec > load > preserve. > > These patches make

Re: [Xen-devel] [RFC v2 13/23] x86/power/64: Adapt assembly for PIE support

On Thu 2017-08-10 10:26:05, Thomas Garnier wrote: > Change the assembly code to use only relative references of symbols for the > kernel to be PIE compatible. > > Position Independent Executable (PIE) support will allow to extended the > KASLR randomization range below the -2G memory limit. > >

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On Fri, Aug 11, 2017 at 02:22:25PM +0200, Juergen Gross wrote: > Wait - the TLB can be cleared at any time, as Andrew was pointing out. > No cpu can rely on an address being accessible just because IF is being > cleared. All that matters is the existing and valid page table entry. > > So clearing

[Xen-devel] [linux-linus test] 112577: regressions - trouble: blocked/broken/fail/pass

flight 112577 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/112577/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-examine 7 reboot fail REGR. vs. 110515

Re: [Xen-devel] [PATCH v2 1/3] x86/p2m-pt: simplify p2m_next_level()

>>> On 27.07.17 at 18:19, wrote: > On Wed, Jul 5, 2017 at 11:05 AM, Jan Beulich wrote: >> Calculate entry PFN and flags just once. Convert the two successive >> main if()-s to and if/elf-if chain. Restrict variable scope where >> reasonable. Take

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On 11/08/17 12:56, Peter Zijlstra wrote: > On Fri, Aug 11, 2017 at 11:23:10AM +0200, Vitaly Kuznetsov wrote: >> Peter Zijlstra writes: >> >>> On Thu, Aug 10, 2017 at 07:08:22PM +, Jork Loeser wrote: >>> >> Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall

[Xen-devel] [libvirt test] 112586: tolerable trouble: blocked/broken/pass - PUSHED

flight 112586 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/112586/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On Fri, Aug 11, 2017 at 12:05:45PM +0100, Andrew Cooper wrote: > >> Oh, I see your concern. Hyper-V, however, is not the first x86 > >> hypervisor trying to avoid IPIs on remote TLB flush, Xen does this > >> too. Briefly looking at xen_flush_tlb_others() I don't see anything > >> special, do we

Re: [Xen-devel] [PATCH v2 1/3] x86/p2m-pt: simplify p2m_next_level()

>>> On 27.07.17 at 18:19, wrote: > On Wed, Jul 5, 2017 at 11:05 AM, Jan Beulich wrote: >> Calculate entry PFN and flags just once. Convert the two successive >> main if()-s to and if/elf-if chain. Restrict variable scope where >> reasonable. Take

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

On Thu, Aug 10, 2017 at 03:42:24PM -0600, Jim Fehlig wrote: > On 08/08/2017 09:09 AM, Wei Liu wrote: > > Ian and Stefano > > > > Oleksandr discovered that the p9fs array in libxl_domain_config is name > > p9 instead of p9s. This causes problem for his work to rework device > > framework. > > > >

Re: [Xen-devel] [RFC] xen/arm: Suspend to RAM Support in Xen for ARM

Hi Andrii, Thank you very much for your feedback, please see my answers below. On Thu, Aug 10, 2017 at 1:13 PM, Andrii Anisov wrote: > Dear Mirela, > > Please see my comments below: > > > > On 09.08.17 20:43, Mirela Simonovic wrote: > >> This document contains our draft

[Xen-devel] [linux-3.18 test] 112579: trouble: blocked/broken/fail/pass

flight 112579 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/112579/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 3 capture-logs broken REGR. vs. 112102

Re: [Xen-devel] [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

On 11/08/17 11:56, Peter Zijlstra wrote: > On Fri, Aug 11, 2017 at 11:23:10AM +0200, Vitaly Kuznetsov wrote: >> Peter Zijlstra writes: >> >>> On Thu, Aug 10, 2017 at 07:08:22PM +, Jork Loeser wrote: >>> >> Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall

  1   2   >