Re: [Xen-devel] [PATCH 04/20] xen/domctl: Drop vcpu_alloc_lock

On 20/03/18 18:22, Andrew Cooper wrote: > On 20/03/18 16:58, Jan Beulich wrote: > On 19.03.18 at 20:13, wrote: >>> It is not entirely clear why this interlock was introduced in c/s 8cbb5278e >>> "x86/AMD: Add support for AMD's OSVW feature in guests". >>> >>> At the

[Xen-devel] [Not Xen] Facing issues running guest OS on custom Hypervisor

Hello Julien, As requested I am moving the conversation to email from IRC To summarize my setup: 1. I am running a custom kernel on QEMU ARM64(without KVM) on my linux machine 2. I have my custom implementation of Hypervisor 3. I am trying to run the same custom kernel as guest OS on top of my

[Xen-devel] [xen-unstable-smoke test] 121014: regressions - FAIL

flight 121014 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/121014/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 120949 Tests which

Re: [Xen-devel] [PATCH v1 02/15] arm64: Add config for Cavium Thunder erratum 30115

On 03/20/2018 01:13 PM, Julien Grall wrote: Hi, On 03/16/2018 11:58 AM, Manish Jaggi wrote: Some Cavium Thunder CPUs suffer a problem where a Xen guest may inadvertently cause the host kernel to quit receiving interrupts. This patch adds CONFIG_CAVIUM_ERRATUM_30115. Subsequent patches will

Re: [Xen-devel] [PATCH 03/20] xen/public: Rename xen_domctl_createdomain.config to arch

Hi, On 03/19/2018 07:13 PM, Andrew Cooper wrote: This is a tools only hypercall so fine to change. Altering the name avoids having confusing code such as config->config all over the hypervisor and toolstack. Signed-off-by: Andrew Cooper Acked-by: Julien Grall

Re: [Xen-devel] [PATCH v1 00/15] arm64: Mediate access to GICv3 sysregs at EL2

On 03/21/2018 04:58 AM, Manish Jaggi wrote: Hi Julien, On 03/20/2018 01:16 PM, Julien Grall wrote: On 03/16/2018 11:58 AM, Manish Jaggi wrote: This patchset is a Xen port of Marc's patchset. arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1] The current RFC patchset is a subset of

Re: [Xen-devel] [PATCH v1 00/15] arm64: Mediate access to GICv3 sysregs at EL2

Hi Julien, On 03/20/2018 01:16 PM, Julien Grall wrote: On 03/16/2018 11:58 AM, Manish Jaggi wrote: This patchset is a Xen port of Marc's patchset. arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1] The current RFC patchset is a subset of [1], as it handleing only Group1 traps as a

[Xen-devel] [for-4.11][PATCH v6 16/16] xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN

Most of the users of page_to_mfn and mfn_to_page are either overriding the macros to make them work with mfn_t or use mfn_x/_mfn because the rest of the function use mfn_t. So make page_to_mfn and mfn_to_page return mfn_t by default. The __* version are now dropped as this patch will convert all

[Xen-devel] [for-4.11][PATCH v6 13/16] xen/grant: Switch {create, replace}_grant_p2m_mapping to typesafe MFN

The current prototype is slightly confusing because it takes a guest physical address and a machine physical frame (not address!). Switching to MFN will improve safety and reduce the chance to mistakenly invert the 2 parameters. Signed-off-by: Julien grall Reviewed-by: Wei

[Xen-devel] [for-4.11][PATCH v6 12/16] xen/mm: Switch common/memory.c to use typesafe MFN

A new helper __copy_mfn_to_guest is introduced to easily to copy a MFN to the guest memory. Not functional change intended Signed-off-by: Julien Grall --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson

[Xen-devel] [for-4.11][PATCH v6 14/16] xen/grant: Switch common/grant_table.c to use typesafe MFN

At the same time replace MFN 0 by INVALID_MFN or drop the initializer when it is not necessary. This will make clearer that the MFN initialized is not valid. Other than MFN 0 -> INVALID_MFN, no functional change intended. Signed-off-by: Julien Grall Reviewed-by: Jan

[Xen-devel] [for-4.11][PATCH v6 06/16] xen/x86: Remove unused override of page_to_mfn/mfn_to_page

A few files override page_to_mfn/mfn_to_page but actually never use those macros. So drop them. Signed-off-by: Julien Grall Acked-by: George Dunlap Acked-by: Jan Beulich --- Cc: George Dunlap Cc:

[Xen-devel] [for-4.11][PATCH v6 11/16] xen/mm: Switch some of page_alloc.c to typesafe MFN

No functional change intended. Signed-off-by: Julien Grall Reviewed-by: Wei Liu Reviewed-by: George Dunlap --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson

[Xen-devel] [for-4.11][PATCH v6 00/16] xen: Convert page_to_mfn and mfn_to_page to use typesafe MFN

Hi all, This is v6 of the series. For all the changes see in each patch. To avoid the last patch (#16) to be a huge patch some files are converted to use typesafe upfront. I have tried my best to push _mfn/mfn_x as down as possible in the callers. Some of them was not feasible without major

[Xen-devel] [for-4.11][PATCH v6 03/16] xen/arm: mm: Use gaddr_to_gfn rather than _gfn(paddr_to_pfn(...))

Signed-off-by: Julien Grall --- Cc: Stefano Stabellini Changes in v6: - Remove the justification from the commit message - Add George's reviewed-by Changes in v4: - Patch added --- xen/arch/arm/mm.c | 4 ++-- 1

[Xen-devel] [for-4.11][PATCH v6 10/16] xen/mm: Switch map_pages_to_xen to use MFN typesafe

The current prototype is slightly confusing because it takes a virtual address and a physical frame (not address!). Switching to MFN will improve safety and reduce the chance to mistakenly invert the 2 parameters. Also, take the opportunity to switch (a - b) >> PAGE_SHIFT to PFN_DOWN(a - b) in

[Xen-devel] [for-4.11][PATCH v6 05/16] xen/arm: mm: Remove unused relinquish_shared_pages

relinquish_shared_pages is never called on Arm. Signed-off-by: Julien Grall Reviewed-by: George Dunlap --- Cc: Stefano Stabellini Changes in v6: - Add George's reviewed-by Changes in v4: - Patch

[Xen-devel] [for-4.11][PATCH v6 07/16] xen/x86: mm: Switch x86/mm.c to use typesafe for virt_to_mfn

No functional change intended. While we are here, use PFN_DOWN() rather than open coding it. Signed-off Julien Grall Acked-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper Changes in v6:

[Xen-devel] [for-4.11][PATCH v6 04/16] xen/arm: mm: Remove unused M2P code

Arm does not have an M2P and very unlikely to get one in the future, therefore don't keep defines that are not necessary in the common code. At the same time move the remaining M2P define just above set_gpfn_from_mfn to keep all the dummy helpers for M2P together. Signed-off-by: Julien Grall

[Xen-devel] [for-4.11][PATCH v6 15/16] xen/x86: Switch mfn_to_page in x86_64/mm.c to use typesafe MFN

Other than MFN 0 -> INVALID_MFN, no functional change intended. Signed-off-by: Julien Grall Acked-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper Changes in v6: - s/_mfn(0)/MFN 0/

[Xen-devel] [for-4.11][PATCH v6 08/16] xen/mm: Drop the parameter mfn from populate_pt_range

The function populate_pt_range is used to populate in advance the page-table but it will not do the actual mapping. So passing the MFN in parameter is pointless. Note that the only caller pass 0... At the same time replace 0 by INVALID_MFNs. While this does not matter as the entry will marked as

[Xen-devel] [for-4.11][PATCH v6 09/16] xen/pdx: Introduce helper to convert MFN <-> PDX

This will avoid use of pfn_to_pdx(mfn_x(mfn)) over the code base. Signed-off-by: Julien Grall Reviewed-by: Wei Liu Acked-by: Andrew Cooper --- Cc: Andrew Cooper Cc: George Dunlap

Re: [Xen-devel] [PATCH v2 40/45] ARM: new VGIC: vgic-init: register VGIC

On 03/20/2018 05:11 PM, Andre Przywara wrote: Hi, On 20/03/18 01:17, Julien Grall wrote: Hi Andre, On 03/15/2018 08:30 PM, Andre Przywara wrote: diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c index 002fec57e6..4b9664f313 100644 --- a/xen/arch/arm/vgic/vgic.c +++

Re: [Xen-devel] [xen-unstable-smoke test] 121001: regressions - FAIL

Hi Andrew, On 03/20/2018 07:55 PM, Andrew Cooper wrote: On 20/03/18 19:48, osstest service owner wrote: flight 121001 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/121001/ Regressions :-( Tests which did not succeed and are blocking, including tests which

Re: [Xen-devel] [PATCH v2 02/45] ARM: Implement vcpu_kick()

Hi Jan, On 03/20/2018 10:35 AM, Jan Beulich wrote: On 15.03.18 at 21:30, wrote: If we change something in a vCPU that affects its runnability or otherwise needs the vCPU's attention, we might need to tell the scheduler about it. We are using this in one place (vIRQ

[Xen-devel] [PATCH] xen/arm: gic: Read unconditionally the source from the LRs

Commit 5cb00d1 "ARM: GIC: extend LR read/write functions to cover EOI and source" extended gic_lr to cover the source. The new field was only set for SGIs interrupt in the read function. However, the write function is writing the field unconditionally for virtual interrupt. This means that if the

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

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

[Xen-devel] [PATCH v3 0/8] Using GitLab CI for build testing

Really early work on switching over to using GitLab CI over Travis CI. GitLab is a competitor to GitHub with some advantages such as an integrated CI system with a lot more flexibility and control. It additionally is fully open sourced unlike GitHub and Travis CI. We can even run an instance if

[Xen-devel] [PATCH v3 8/8] ci: add new bits to MAINTAINERS combine with Travis

Created a new section just called 'CI' since this is adding GitLab CI and still leaving the old Travis CI files around. This consolidates the two sections and adds the new files as well as adding another Travis file that was missing. Signed-off-by: Doug Goldstein Reviewed-by:

[Xen-devel] [PATCH v3 1/8] ci: add README and makefile for containers

Add a basic README explaining the containers and how people can use them to locally test with if they see an error in CI and want to reproduce it locally. Added a makefile to help with building and pushing the containers to the container registry. Signed-off-by: Doug Goldstein

[Xen-devel] [PATCH v3 4/8] ci: add Dockerfile for Ubuntu 16.04

Added a Dockerfile which captures all the necessary dependencies to build Xen on a Ubuntu 16.04 system. Signed-off-by: Doug Goldstein Reviewed-by: Konrad Rzeszutek Wilk --- automation/build/ubuntu/xenial.dockerfile | 47 - 1

[Xen-devel] [PATCH v3 7/8] ci: use GitLab CI to build

Added a GitLab CI config which has a lot more flexibility to allow us to test a lot more distro configurations than Travis can and even build test on FreeBSD. This includes a modified copy of scripts/travis-build that is expected to diverge future over time as we build more than what Travis is

[Xen-devel] [PATCH v3 6/8] ci: add Dockerfile for Debian stretch

Added a Dockerfile which captures all the necessary dependencies to build Xen on a Debian stretch system. Signed-off-by: Doug Goldstein Reviewed-by: Konrad Rzeszutek Wilk --- automation/build/debian/stretch.dockerfile | 47 +++- 1

[Xen-devel] [PATCH v3 2/8] ci: add Dockerfile for CentOS 7.2

Added a Dockerfile which captures all the necessary dependencies to build Xen on a CentOS 7.2 system. Signed-off-by: Doug Goldstein Reviewed-by: Konrad Rzeszutek Wilk --- change since v2: - added missing checkpolicy ---

[Xen-devel] [PATCH v3 5/8] ci: add Dockerfile for Debian jessie

Added a Dockerfile which captures all the necessary dependencies to build Xen on a Debian jessie system. Signed-off-by: Doug Goldstein Reviewed-by: Konrad Rzeszutek Wilk --- automation/build/debian/jessie.dockerfile | 47 - 1

[Xen-devel] [PATCH v3 3/8] ci: add Dockerfile for Ubuntu 14.04

Added a Dockerfile which captures all the necessary dependencies to build Xen on a Ubuntu 14.04 system. Signed-off-by: Doug Goldstein Reviewed-by: Konrad Rzeszutek Wilk --- automation/build/ubuntu/trusty.dockerfile | 47 - 1

[Xen-devel] [PATCH] x86/boot: Disable IBRS in intr/nmi exit path at bootup stage

After reset, IBRS is disabled by processor, but a coming intr/nmi leave IBRS enabled after their exit. It's not necessory for bootup code to run in low performance with IBRS enabled. On ORACLE X6-2(500GB/88 cpus, dom0 11GB/20 vcpus), we observed an 200s+ delay in construct_dom0. By initializing

[Xen-devel] [xen-unstable-smoke test] 121009: regressions - FAIL

flight 121009 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/121009/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 120949 Tests which

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

On Tue, 20 Mar 2018 08:50:48 + Roger Pau Monné wrote: >On Tue, Mar 20, 2018 at 05:49:22AM +1000, Alexey G wrote: >> On Mon, 19 Mar 2018 15:58:02 + >> Roger Pau Monné wrote: >> >> >On Tue, Mar 13, 2018 at 04:33:52AM +1000, Alexey Gerasimenko

[Xen-devel] [xen-unstable-smoke test] 121004: regressions - FAIL

flight 121004 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/121004/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 120949 Tests which

Re: [Xen-devel] [RFC PATCH 06/12] hvmloader: add basic Q35 support

On Tue, 20 Mar 2018 09:20:01 + Roger Pau Monné wrote: >On Tue, Mar 20, 2018 at 09:44:33AM +1000, Alexey G wrote: >> On Mon, 19 Mar 2018 15:30:14 + >> Roger Pau Monné wrote: >> >> >On Tue, Mar 13, 2018 at 04:33:51AM +1000, Alexey Gerasimenko

Re: [Xen-devel] [RFC PATCH 10/12] libacpi: build ACPI MCFG table if requested

On Tue, 20 Mar 2018 09:03:56 + Roger Pau Monné wrote: >On Tue, Mar 20, 2018 at 07:46:04AM +1000, Alexey G wrote: >> On Mon, 19 Mar 2018 17:33:34 + >> Roger Pau Monné wrote: >> >> >On Tue, Mar 13, 2018 at 04:33:55AM +1000, Alexey Gerasimenko

Re: [Xen-devel] [PATCH v5 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

On 3/20/2018 12:23 PM, Randy Dunlap wrote: Hi, On 03/20/2018 12:18 PM, Maran Wilson wrote: In order to pave the way for hypervisors other then Xen to use the PVH than entry point for VMs, we need to factor the PVH entry code into Xen

Re: [Xen-devel] [RFC PATCH 11/12] hvmloader: use libacpi to build MCFG table

On Tue, 20 Mar 2018 03:36:57 -0600 "Jan Beulich" wrote: On 19.03.18 at 22:20, wrote: >> On Mon, 19 Mar 2018 17:49:09 + >> Roger Pau Monné wrote: >>>On Tue, Mar 13, 2018 at 04:33:56AM +1000, Alexey Gerasimenko wrote:

Re: [Xen-devel] [PATCH v3 0/5] sndif: add explicit back and front synchronization

On Mon, 19 Mar 2018 08:22:19 +0100, Oleksandr Andrushchenko wrote: > > From: Oleksandr Andrushchenko > > Hello, all! > > In order to provide explicit synchronization between backend and > frontend the following changes are introduced in the protocol: > - bump

Re: [Xen-devel] [xen-unstable-smoke test] 121001: regressions - FAIL

On 20/03/18 19:48, osstest service owner wrote: > flight 121001 xen-unstable-smoke real [real] > http://logs.test-lab.xenproject.org/osstest/logs/121001/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-arm64-arm64-xl-xsm

[Xen-devel] [xen-unstable-smoke test] 121001: regressions - FAIL

flight 121001 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/121001/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 120949 Tests which

Re: [Xen-devel] [PATCH 08/20] tools/ocaml: Pass a full domctl_create_config into stub_xc_domain_create()

> On 19. Mar 2018, at 19:13, Andrew Cooper wrote: > > The underlying C function is about to make the same change, and the structure > is going to gain extra fields. > > Signed-off-by: Andrew Cooper Acked-by: Christian Lindig

Re: [Xen-devel] [PATCH 06/20] tools/ocaml: Drop domain_create_flag_table[]

> On 19. Mar 2018, at 19:13, Andrew Cooper wrote: > > This is a logarithm in disguise. Update the logic to match how > x86_arch_emulation_flags works in c/s 9d683b5e37 and b38d96f596. Acked-by: Christian Lindig

Re: [Xen-devel] [PATCH 10/20] xen/domctl: Merge set_max_evtchn into createdomain

> On 19. Mar 2018, at 19:13, Andrew Cooper wrote: > > set_max_evtchn is somewhat weird. It was introduced with the event_fifo work, > but has never been used. Still, it is a bounding on resources consumed by the > event channel infrastructure, and should be part of

Re: [Xen-devel] [PATCH 09/20] tools: Rework xc_domain_create() to take a full xen_domctl_createdomain

> On 19. Mar 2018, at 19:13, Andrew Cooper wrote: > > In future patches, the structure will be extended with further information, > and this is far cleaner than adding extra parameters. > > The python stubs are the only user which passes NULL for the existing config

Re: [Xen-devel] [PATCH 12/20] xen/domctl: Merge max_vcpus into createdomain

> On 19. Mar 2018, at 19:13, Andrew Cooper wrote: > > XEN_DOMCTL_max_vcpus is a mandatory hypercall, but nothing actually prevents a > toolstack from unpausing a domain with no vcpus. > > Originally, d->vcpus[] was an embedded array in struct domain, but c/s >

Re: [Xen-devel] [PATCH 11/20] xen/domctl: Merge set_gnttab_limits into createdomain

> On 20. Mar 2018, at 10:11, Andrew Cooper wrote: > > That said, while ssidref might plausibly need a full 32 bits of range > (and even then, I'm not entirely sure, but it is an opaque handle at the > end of the day), none of the max_* fields do. vcpus is currently

Re: [Xen-devel] Spectre Mitigations in Xen 4.6

On Tue, Mar 20, 2018 at 11:20 AM, Jan Beulich wrote: On 20.03.18 at 13:58, wrote: >> With that in place, I'm seeing Dom0 receive a general protection fault on >> boot >> >> [ 25.460035] general protection fault: [#1] SMP >> [ 25.460292] EIP:

Re: [Xen-devel] [PATCH 10/20] xen/domctl: Merge set_max_evtchn into createdomain

On 03/19/2018 03:13 PM, Andrew Cooper wrote: set_max_evtchn is somewhat weird. It was introduced with the event_fifo work, but has never been used. Still, it is a bounding on resources consumed by the event channel infrastructure, and should be part of createdomain, rather than editable after

Re: [Xen-devel] [PATCH 12/20] xen/domctl: Merge max_vcpus into createdomain

On 03/19/2018 03:13 PM, Andrew Cooper wrote: XEN_DOMCTL_max_vcpus is a mandatory hypercall, but nothing actually prevents a toolstack from unpausing a domain with no vcpus. Originally, d->vcpus[] was an embedded array in struct domain, but c/s fb442e217 "x86_64: allow more vCPU-s per guest" in

Re: [Xen-devel] [PATCH v5 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

Hi, On 03/20/2018 12:18 PM, Maran Wilson wrote: > In order to pave the way for hypervisors other then Xen to use the PVH than > entry point for VMs, we need to factor the PVH entry code into Xen specific > and hypervisor agnostic components. The

[Xen-devel] [PATCH v5 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

For certain applications it is desirable to rapidly boot a KVM virtual machine. In cases where legacy hardware and software support within the guest is not needed, Qemu should be able to boot directly into the uncompressed Linux kernel binary without the need to run firmware. There already exists

[Xen-devel] [PATCH v5 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

The start info structure that is defined as part of the x86/HVM direct boot ABI and used for starting Xen PVH guests would be more versatile if it also included a way to pass information about the memory map to the guest. This would allow KVM guests to share the same entry point. Signed-off-by:

[Xen-devel] [PATCH v5 5/7] xen/pvh: Move Xen code for getting mem map via hcall out of common file

We need to refactor PVH entry code so that support for other hypervisors like Qemu/KVM can be added more easily. The original design for PVH entry in Xen guests relies on being able to obtain the memory map from the hypervisor using a hypercall. When we extend the PVH entry ABI to support other

[Xen-devel] [PATCH v5 2/7] xen/pvh: Move PVH entry code out of Xen specific tree

Once hypervisors other than Xen start using the PVH entry point for starting VMs, we would like the option of being able to compile PVH entry capable kernels without enabling CONFIG_XEN and all the code that comes along with that. To allow that, we are moving the PVH code out of Xen and into files

[Xen-devel] [PATCH v5 4/7] xen/pvh: Move Xen specific PVH VM initialization out of common file

We need to refactor PVH entry code so that support for other hypervisors like Qemu/KVM can be added more easily. This patch moves the small block of code used for initializing Xen PVH virtual machines into the Xen specific file. This initialization is not going to be needed for Qemu/KVM guests.

[Xen-devel] [PATCH v5 3/7] xen/pvh: Create a new file for Xen specific PVH code

We need to refactor PVH entry code so that support for other hypervisors like Qemu/KVM can be added more easily. The first step in that direction is to create a new file that will eventually hold the Xen specific routines. Signed-off-by: Maran Wilson ---

[Xen-devel] [PATCH v5 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

In order to pave the way for hypervisors other then Xen to use the PVH entry point for VMs, we need to factor the PVH entry code into Xen specific and hypervisor agnostic components. The first step in doing that, is to create a new config option for PVH entry that can be enabled independently from

[Xen-devel] [PATCH v5 0/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

For certain applications it is desirable to rapidly boot a KVM virtual machine. In cases where legacy hardware and software support within the guest is not needed, Qemu should be able to boot directly into the uncompressed Linux kernel binary without the need to run firmware. There already exists

Re: [Xen-devel] [PATCH v2] hvm/svm: Implement Debug events

On Tue, Mar 20, 2018 at 11:07 AM, Alexandru Stefan ISAILA wrote: > On Ma, 2018-03-20 at 10:49 -0600, Tamas K Lengyel wrote: >> On Tue, Mar 20, 2018 at 3:40 AM, Alexandru Isaila >> wrote: >> > >> > At this moment the Debug events for the AMD

[Xen-devel] [PATCH v3 4/4] x86/hvm: add stricter permissions checks to ioreq server control plane

There has always been an intention in the ioreq server API that only the domain that creates an ioreq server should be able to manipulate it. However, so far, nothing has enforced this. This means that two domains with DM_PRIV over a target domain can currently manipulate each others ioreq

[Xen-devel] [PATCH v3 1/4] x86/hvm: stop passing explicit domid to hvm_create_ioreq_server()

Only in the legacy 'default server' case do we pass anything other than current->domain->domain_id, and in that case we pass the value of HVM_PARAM_DM_DOMAIN. The only known user of HVM_PARAM_DM_DOMAIN is qemu-trad, which always sets it to DOMID_SELF (ignoring the return value of

[Xen-devel] [PATCH v3 2/4] x86/hvm: take a reference on ioreq server emulating domain

When an ioreq server is created the code currently stores the id of the emulating domain, but does not take a reference on that domain. This patch modifies the code to hold a reference for the lifetime of the ioreq server. NOTE: ioreq servers are either destroyed explicitly or destroyed

[Xen-devel] [PATCH v3 0/4] stricter ioreq server permissions checks

This series tightens up permissions checking on ioreq server control plane operations. Paul Durrant (4): x86/hvm: stop passing explicit domid to hvm_create_ioreq_server() x86/hvm: take a reference on ioreq server emulating domain x86/hvm: re-structure some of the ioreq server look-up loops

[Xen-devel] [PATCH v3 3/4] x86/hvm: re-structure some of the ioreq server look-up loops

This patch is a cosmetic re-structuring of some of the loops with look up an ioreq server based on target domain and server id. The restructuring is done separately here to ease review of a subsquent patch. Signed-off-by: Paul Durrant Reviewed-by: Jan Beulich

Re: [Xen-devel] [Qemu-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 05:34:01PM +, Daniel P. Berrangé wrote: > On Tue, Mar 20, 2018 at 07:10:42PM +0200, Michael S. Tsirkin wrote: > > On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote: > > > Using <> for system include files and "" for local include files is a > > > convention,

Re: [Xen-devel] [Qemu-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote: > > Very large projects often split in sub projects, maybe one of them > describing the API. Then that API headers are similar to system headers > and can be included using <>, although they still belong to the same > larger project. Do

Re: [Xen-devel] [Qemu-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 07:10:42PM +0200, Michael S. Tsirkin wrote: > On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote: > > Using <> for system include files and "" for local include files is a > > convention, and as far as I know most projects adhere to that > > convention. So does

Re: [Xen-devel] [PATCH v5 03/14] x86emul: abstract out XCRn accesses

On 03/15/2018 01:04 PM, Jan Beulich wrote: > Use hooks, just like done for other special purpose registers. > > This includes moving XCR0 checks from hvmemul_get_fpu() to the emulator > itself as well as adding support for XGETBV emulation. > > For now fuzzer reads will obtain the real values

Re: [Xen-devel] [PATCH 04/20] xen/domctl: Drop vcpu_alloc_lock

On 20/03/18 16:58, Jan Beulich wrote: On 19.03.18 at 20:13, wrote: >> It is not entirely clear why this interlock was introduced in c/s 8cbb5278e >> "x86/AMD: Add support for AMD's OSVW feature in guests". >> >> At the time, svm_handle_osvw() could have seen an

Re: [Xen-devel] [PATCH v2 2/4] x86/hvm: take a reference on ioreq server emulating domain

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 20 March 2018 16:37 > To: Paul Durrant > Cc: Andrew Cooper ; xen- > de...@lists.xenproject.org > Subject: Re: [PATCH v2 2/4] x86/hvm: take a reference on ioreq

Re: [Xen-devel] [PATCH v2] hvm/svm: Implement Debug events

On 20/03/18 16:49, Tamas K Lengyel wrote: > On Tue, Mar 20, 2018 at 3:40 AM, Alexandru Isaila > wrote: >> At this moment the Debug events for the AMD architecture are not >> forwarded to the monitor layer. >> >> This patch adds the Debug event to the common capabilities,

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 02:54:37PM +0100, Max Reitz wrote: > But I guess the main advantage with using this rule I see is that it's > better for people reading the code. It's just nice to know whether a > file belongs to qemu or not by just looking at the #include statement. > (Note that this

Re: [Xen-devel] [PATCH v2 40/45] ARM: new VGIC: vgic-init: register VGIC

Hi, On 20/03/18 01:17, Julien Grall wrote: > Hi Andre, > > On 03/15/2018 08:30 PM, Andre Przywara wrote: >> diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c >> index 002fec57e6..4b9664f313 100644 >> --- a/xen/arch/arm/vgic/vgic.c >> +++ b/xen/arch/arm/vgic/vgic.c >> @@ -946,6

Re: [Xen-devel] [Qemu-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote: > Using <> for system include files and "" for local include files is a > convention, and as far as I know most projects adhere to that > convention. So does QEMU currently. Such conventions are not only > important for humans, but also

Re: [Xen-devel] [PATCH v2] hvm/svm: Implement Debug events

On Ma, 2018-03-20 at 10:49 -0600, Tamas K Lengyel wrote: > On Tue, Mar 20, 2018 at 3:40 AM, Alexandru Isaila > wrote: > > > > At this moment the Debug events for the AMD architecture are not > > forwarded to the monitor layer. > > > > This patch adds the Debug event to

Re: [Xen-devel] [PATCH v4 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

>>> On 20.03.18 at 17:48, wrote: > The start info structure that is defined as part of the x86/HVM direct boot > ABI and used for starting Xen PVH guests would be more versatile if it also > included a way to pass information about the memory map to the guest. This >

Re: [Xen-devel] [PATCH 04/20] xen/domctl: Drop vcpu_alloc_lock

>>> On 19.03.18 at 20:13, wrote: > It is not entirely clear why this interlock was introduced in c/s 8cbb5278e > "x86/AMD: Add support for AMD's OSVW feature in guests". > > At the time, svm_handle_osvw() could have seen an unexpected change in OSVW > (not the case

[Xen-devel] [PATCH v4 3/4] libxl: Store e820 map in xc_dom_image

From: Boris Ostrovsky We will later copy it to hvm_start_info. (Also remove stale comment claming that xc_dom_image.start_info_seg is only used for HVMlite guests) Signed-off-by: Boris Ostrovsky --- tools/libxc/include/xc_dom.h | 7

[Xen-devel] [PATCH v4 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

The start info structure that is defined as part of the x86/HVM direct boot ABI and used for starting Xen PVH guests would be more versatile if it also included a way to pass information about the memory map to the guest. This would allow KVM guests to share the same entry point. Signed-off-by:

[Xen-devel] [PATCH v4 4/4] libxc: Pass e820 map to HVM/PVH guests via hvm_start_info

From: Boris Ostrovsky Signed-off-by: Boris Ostrovsky Signed-off-by: Maran Wilson --- tools/libxc/xc_dom_x86.c | 29 - 1 file changed, 28 insertions(+), 1 deletion(-) diff --git

[Xen-devel] [PATCH v4 0/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

Here is the patch series for updating the canonical definition of the hvm_start_info struct corresponding to the discussion happening on the linux-kernel and kvm mailing lists regarding Qemu/KVM use of the PVH entry point: KVM: x86: Allow Qemu/KVM to use PVH entry point

Re: [Xen-devel] [PATCH 03/20] xen/public: Rename xen_domctl_createdomain.config to arch

>>> On 19.03.18 at 20:13, wrote: > This is a tools only hypercall so fine to change. Altering the name avoids > having confusing code such as config->config all over the hypervisor and > toolstack. > > Signed-off-by: Andrew Cooper

[Xen-devel] [xen-unstable-smoke test] 120993: regressions - FAIL

flight 120993 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120993/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 120949 Tests which

[Xen-devel] [PATCH v4 2/4] libxl/x86: Build e820 map earlier for HVM/PVH guests

From: Boris Ostrovsky Since hvm_start_info has now been expanded to include memory map (i.e. e820) we need to know size of this map by the time we create dom->start_info_seg in alloc_magic_pages_hvm(). To do so we have to call libxl__arch_domain_construct_memmap()

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 11:12:00AM -0500, Eric Blake wrote: > > Why can't we fix Makefile to include BOTH the build and the source > directories (to pick up generated files first, and then version-controlled > files), and possibly include logic to simplify to a single -I instead of two > when

Re: [Xen-devel] [PATCH v2] hvm/svm: Implement Debug events

On Tue, Mar 20, 2018 at 3:40 AM, Alexandru Isaila wrote: > At this moment the Debug events for the AMD architecture are not > forwarded to the monitor layer. > > This patch adds the Debug event to the common capabilities, adds > the VMEXIT_ICEBP then forwards the event to

Re: [Xen-devel] [PATCH v2] hvm/svm: Implement Debug events

>>> On 20.03.18 at 17:14, wrote: > On 20/03/18 16:05, Jan Beulich wrote: > On 20.03.18 at 16:53, wrote: >>> Please could you delete this function and use: >>> >>> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h

Re: [Xen-devel] [PATCH v2 4/4] x86/hvm: add stricter permissions checks to ioreq server control plane

>>> On 16.03.18 at 17:58, wrote: > There has always been an intention in the ioreq server API that only the > domain that creates an ioreq server should be able to manipulate it. > However, so far, nothing has enforced this. This means that two domains > with DM_PRIV over

Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""

On Tue, Mar 20, 2018 at 11:12:00AM -0500, Eric Blake wrote: > On 03/19/2018 08:54 PM, Michael S. Tsirkin wrote: > > QEMU coding style at the moment asks for all non-system > > include files to be used with #include "foo.h". > > [I'm replying without having read the rest of the thread, so bear

Re: [Xen-devel] [PATCH v2 3/4] x86/hvm: re-structure some of the ioreq server look-up loops

>>> On 16.03.18 at 17:58, wrote: > --- a/xen/arch/x86/hvm/ioreq.c > +++ b/xen/arch/x86/hvm/ioreq.c > @@ -839,37 +839,37 @@ int hvm_map_io_range_to_ioreq_server(struct domain *d, > ioservid_t id, >>arch.hvm_domain.ioreq_server.list, >

Re: [Xen-devel] [RFC PATCH] Make Security Policy Doc ready to become a CNA

On 03/19/2018 04:37 PM, Lars Kurth wrote: > And this time with patch: note to myself - never try sendmail with --compose > again (-; > > This patch contains a proposal to change > https://xenproject.org/security-policy.html > such that it points to SUPPORT.md. Having scope and process

Re: [Xen-devel] [PATCH v2 2/4] x86/hvm: take a reference on ioreq server emulating domain

>>> On 16.03.18 at 17:58, wrote: > @@ -305,6 +305,7 @@ static int hvm_ioreq_server_add_vcpu(struct > hvm_ioreq_server *s, > bool is_default, struct vcpu *v) > { > struct hvm_ioreq_vcpu *sv; > +domid_t domid; > int rc;

Re: [Xen-devel] [PATCH v2] hvm/svm: Implement Debug events

On Ma, 2018-03-20 at 16:14 +, Andrew Cooper wrote: > On 20/03/18 16:05, Jan Beulich wrote: > > > > > > > > > > > > > > > > > > > On 20.03.18 at 16:53, wrote: > > > On 20/03/18 09:40, Alexandru Isaila wrote: > > > > > > > > @@ -2438,16 +2439,15 @@ static bool > > > >

  1   2   3   >