[Xen-devel] [GIT PULL] xen: fixes and cleanups for 5.4-rc2

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.4-rc2-tag

xen: fixes and cleanups for 5.4-rc2

It contains the following patches:

- a fix in the Xen balloon driver avoiding hitting a BUG_ON() in some
  cases, plus a follow-on cleanup series for that driver

- a patch for introducing non-blocking EFI callbacks in Xen's EFI driver,
  plu a cleanup patch for Xen EFI handling merging the x86 and ARM arch
  specific initialization into the Xen EFI driver

- a fix of the Xen xenbus driver avoiding a self-deadlock when cleaning
  up after a user process has died

- a fix for Xen on ARM after removal of ZONE_DMA

- a cleanup patch for avoiding build warnings for Xen on ARM


Thanks.

Juergen

 arch/arm/include/asm/xen/xen-ops.h   |  6 ---
 arch/arm/xen/Makefile|  1 -
 arch/arm/xen/efi.c   | 28 ---
 arch/arm/xen/enlighten.c |  3 +-
 arch/arm/xen/mm.c|  5 +-
 arch/arm64/include/asm/xen/xen-ops.h |  7 ---
 arch/arm64/xen/Makefile  |  1 -
 arch/x86/xen/efi.c   | 14 +-
 drivers/xen/balloon.c| 24 +++--
 drivers/xen/efi.c| 84 ++--
 drivers/xen/xenbus/xenbus_dev_frontend.c | 20 +++-
 include/xen/xen-ops.h| 25 +-
 12 files changed, 79 insertions(+), 139 deletions(-)

David Hildenbrand (4):
  xen/balloon: Set pages PageOffline() in balloon_add_region()
  xen/balloon: Drop __balloon_append()
  xen/balloon: Mark pages PG_offline in balloon_append()
  xen/balloon: Clear PG_offline in balloon_retrieve()

Juergen Gross (2):
  xen/efi: have a common runtime setup function
  xen/xenbus: fix self-deadlock after killing user process

Peng Fan (1):
  arm: xen: mm: use __GPF_DMA32 for arm64

Ross Lagerwall (1):
  xen/efi: Set nonblocking callbacks

Stefano Stabellini (1):
  ARM: xen: unexport HYPERVISOR_platform_op function

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 0/4] docs/sphinx

[Jürgen Groß]

On 03.10.19 22:56, Andrew Cooper wrote:

Various pieces of Sphinx documentation improvements intended for inclusion
into Xen 4.13.  Rendered results can be viewed at

   https://andrewcoop-xen.readthedocs.io/en/docs-devel/index.html

with

   
https://andrewcoop-xen.readthedocs.io/en/docs-devel/admin-guide/introduction.html
   https://andrewcoop-xen.readthedocs.io/en/docs-devel/glossary.html
   https://andrewcoop-xen.readthedocs.io/en/docs-devel/misc/tech-debt.html

being the notable additions from this series.

Andrew Cooper (4):
   docs/sphinx: License content with CC-BY-4.0
   docs/sphinx: Indent cleanup
   docs/sphinx: Introduction
   docs/sphinx: Technical Debt

  COPYING  |   3 +
  docs/README.source   |  32 
  docs/admin-guide/index.rst   |   5 +-
  docs/admin-guide/introduction.rst|  40 ++
  docs/admin-guide/microcode-loading.rst   |   2 +
  docs/admin-guide/xen-overview.drawio.svg |  97 +++
  docs/conf.py |  12 ++-
  docs/glossary.rst|  52 +
  docs/guest-guide/index.rst   |   6 +-
  docs/guest-guide/x86/hypercall-abi.rst   |  52 +++--
  docs/guest-guide/x86/index.rst   |   6 +-
  docs/hypervisor-guide/code-coverage.rst  |   6 +-
  docs/hypervisor-guide/index.rst  |   6 +-
  docs/index.rst   |  38 +++--
  docs/misc/tech-debt.rst  | 130 +++
  15 files changed, 444 insertions(+), 43 deletions(-)
  create mode 100644 docs/README.source
  create mode 100644 docs/admin-guide/introduction.rst
  create mode 100644 docs/admin-guide/xen-overview.drawio.svg
  create mode 100644 docs/glossary.rst
  create mode 100644 docs/misc/tech-debt.rst



For the series:

Release-acked-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13] docs: update all URLs in man pages

[Jürgen Groß]

On 03.10.19 18:12, Lars Kurth wrote:

Specifically
* xen.org to xenproject.org
* http to https
* Replaced pages where page has moved
   (including on xen pages as well as external pages)
* Removed some URLs (e.g. downloads for Linux PV drivers)

Tested-by: Lars Kurth 
Signed-off-by: Lars Kurth 


Thanks for doing this!

Release-acked-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH-for-4.13 v2 0/2] libxl: fix assertion failure

[Jürgen Groß]

On 03.10.19 15:30, Ian Jackson wrote:

Paul Durrant writes ("Re: [Xen-devel] [PATCH-for-4.13 v2 0/2] libxl: fix assertion 
failure"):

On Wed, 2 Oct 2019 at 17:04, Ian Jackson  wrote:

I am continuing to look at the defaulting and config management here
with a view to getting rid of some of the duplicated code and moving
it all into libxl.


That would indeed be beneficial for the likes of libvirt.


I propose the following plan for 4.13:


Fine with me.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13] x86/spec-ctrl: Annotate remaining model names

[Jürgen Groß]

On 03.10.19 16:25, Andrew Cooper wrote:

The names in retpoline_safe() are copied from should_use_eager_fpu().  The
names in mds_calculations() come partly from Linux's intel-family.h, and
partly from conversations with Intel.

Signed-off-by: Andrew Cooper 


Release-acked-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/vvmx: Fix the use of RDTSCP when it is intercepted at L0

[Jürgen Groß]

On 03.10.19 12:47, Andrew Cooper wrote:

Linux has started using RDTSCP as of v5.1.  This has highlighted a bug in Xen,
where virtual vmexit simply gives up.

   (XEN) d1v1 Unhandled nested vmexit: reason 51
   (XEN) domain_crash called from vvmx.c:2671
   (XEN) Domain 1 (vcpu#1) crashed on cpu#2:

Handle RDTSCP in the virtual vmexit hander in the same was as RDTSC
intercepts.

Reported-by: Sarah Newman 
Signed-off-by: Andrew Cooper 
Tested-by: Chris Brannon 


Release-acked-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13] xen/arm: boot with device trees with "mmu-masters" and "iommus"

[Jürgen Groß]

On 02.10.19 19:02, Julien Grall wrote:

+Juergen

Hi,

On 10/1/19 4:16 PM, Oleksandr wrote:


On 30.09.19 23:56, Stefano Stabellini wrote:

Hi Stefano


Some Device Trees may expose both legacy SMMU and generic IOMMU bindings
together. However, the SMMU driver in Xen is only supporting the legacy
SMMU bindings, leading to fatal initialization errors at boot time.

This patch fixes the booting problem by adding a check to
iommu_add_dt_device: if the Xen driver doesn't support the new generic
bindings, and the device is behind an IOMMU, do not return error. The
following iommu_assign_dt_device should succeed.

This check will become superfluous, hence removable, once the Xen SMMU
driver gets support for the generic IOMMU bindings.

Signed-off-by: Stefano Stabellini 


Release-acked-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] x86/xen: Return from panic notifier

[Jürgen Groß]

On 03.10.19 20:12, Boris Ostrovsky wrote:

Currently execution of panic() continues until Xen's panic notifier
(xen_panic_event()) is called at which point we make a hypercall that
never returns.

This means that any notifier that is supposed to be called later as
well as significant part of panic() code (such as pstore writes from
kmsg_dump()) is never executed.

There is no reason for xen_panic_event() to be this last point in
execution since panic()'s emergency_restart() will call into
xen_emergency_restart() from where we can perform our hypercall.

Nevertheless, we will provide xen_legacy_crash boot option that will
preserve original behavior during crash. This option could be used,
for example, if running kernel dumper (which happens after panic
notifiers) is undesirable.

Reported-by: James Dingwall 
Signed-off-by: Boris Ostrovsky 


Reviewed-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v6 00/20] xen: add core scheduling support

[Jürgen Groß]

On 03.10.19 11:47, Sergey Dyasli wrote:

Hi Juergen,

Looks like we've hit the first Xen crash with core scheduling patches applied.
The log is below. From my analysis it seems that CSCHED_PCPU is NULL.
I suspect this is connected to commit bb128adb
("sched: populate cpupool0 only after all cpus are up")

Could you take a look, please?


The main reason is that sched_tick_resume() should call
sched_do_tick_resume() only with the scheduling lock held.

This has been a latent bug since ages, but my patches (especially
"sched: add minimalistic idle scheduler for free cpus" in combination
with "sched: populate cpupool0 only after all cpus are up") is
triggering it much easier now.

In the past you'd need to remove a cpu from a cpupool with null, rt or
arinc653 scheduler with default scheduler being credit in order to have
a chance hitting the bug.

I'll send a patch.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[osstest service owner]

flight 142221 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142221/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 141822
 test-amd64-i386-libvirt-xsm  12 guest-start  fail REGR. vs. 141822
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. 
vs. 141822
 test-amd64-i386-libvirt  12 guest-start  fail REGR. vs. 141822
 test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs. 
141822
 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 
141822
 test-amd64-i386-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs. 
141822
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 141822
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 141822
 test-arm64-arm64-libvirt-xsm 12 guest-start  fail REGR. vs. 141822
 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 141822
 test-armhf-armhf-libvirt 12 guest-start  fail REGR. vs. 141822
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 141822

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-examine 11 examine-serial/bootloader  fail pass in 142119
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeat  fail pass in 142119

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 141822
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 141822
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 141822
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 141822
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 141822
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 141822
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 141822
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 

Re: [Xen-devel] [PATCH v9 0/8] dom0less device assignment

[Stefano Stabellini]

I actually adding Juergen.

On Thu, 3 Oct 2019, Stefano Stabellini wrote:
> Hi all,
> 
> This small patch series adds device assignment support to Dom0less.
> The last patch is the documentation.
> 
> Cheers,
> 
> Stefano
> 
> 
> The following changes since commit 7a4e674905b3cbbe48e81c3222361a7f3579:
> 
>   xen/sched: move struct task_slice into struct sched_unit (2019-09-27 
> 16:03:31 +0200)
> 
> are available in the Git repository at:
> 
>   http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git 
> dom0less-pt-v9
> 
> for you to fetch changes up to 7660f03ca8ddcfde325864ed0bbf80f8e0c20e6c:
> 
>   xen/arm: add dom0-less device assignment info to docs (2019-10-03 10:35:41 
> -0700)
> 
> 
> Stefano Stabellini (8):
>   xen/arm: introduce handle_device_interrupts
>   xen/arm: export device_tree_get_reg and device_tree_get_u32
>   xen/arm: introduce kinfo->phandle_gic
>   xen/arm: copy dtb fragment to guest dtb
>   xen/arm: assign devices to boot domains
>   xen/arm: handle "multiboot,device-tree" compatible nodes
>   xen/arm: introduce nr_spis
>   xen/arm: add dom0-less device assignment info to docs
> 
>  docs/misc/arm/device-tree/booting.txt |  44 +++-
>  docs/misc/arm/passthrough.txt | 106 
>  xen/arch/arm/bootfdt.c|  10 +-
>  xen/arch/arm/domain_build.c   | 459 
> +-
>  xen/arch/arm/kernel.c |  14 +-
>  xen/arch/arm/setup.c  |   1 +
>  xen/include/asm-arm/kernel.h  |   5 +-
>  xen/include/asm-arm/setup.h   |   7 +
>  8 files changed, 579 insertions(+), 67 deletions(-)
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v9 7/8] xen/arm: introduce nr_spis

[Stefano Stabellini]

We don't have a clear way to know how many virtual SPIs we need for the
dom0-less domains. Introduce a new option under xen,domain to specify
the number of SPIs to allocate for a domain.

The property is optional. When absent, we'll use the physical number of
GIC lines for dom0-less domains, or GUEST_VPL011_SPI+1 if vpl011 is
requested, whichever is greater.

Remove the old setting of nr_spis based on the presence of the vpl011.

The implication of this change is that without nr_spis dom0less domains
get the same amount of SPI allocated as dom0, regardless of how many
physical devices they have assigned, and regardless of whether they have
a virtual pl011 (which also needs an emulated SPI). This is done because
the SPIs allocation needs to be done before parsing any passthrough
information, so we have to account for any potential physical SPI
assigned to the domain.

When nr_spis is present, the domain gets exactly nr_spis allocated SPIs.
If the number is too low, it might not be enough for the devices
assigned it to it. If the number is less than GUEST_VPL011_SPI, the
virtual pl011 won't work.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Volodymyr Babchuk 
Acked-by: Julien Grall 
---
Changes in v5:
- improve commit message
- allocate enough SPIs for vpl011

Changes in v4:
- improve commit message

Changes in v3:
- improve commit message
- introduce nr_spis
---
 xen/arch/arm/domain_build.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 030fc32416..d4c4fc40d1 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2410,7 +2410,6 @@ void __init create_domUs(void)
 struct domain *d;
 struct xen_domctl_createdomain d_cfg = {
 .arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
-.arch.nr_spis = 0,
 .flags = XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap,
 .max_evtchn_port = -1,
 .max_grant_frames = 64,
@@ -2420,9 +2419,6 @@ void __init create_domUs(void)
 if ( !dt_device_is_compatible(node, "xen,domain") )
 continue;
 
-if ( dt_property_read_bool(node, "vpl011") )
-d_cfg.arch.nr_spis = GUEST_VPL011_SPI - 32 + 1;
-
 if ( !dt_property_read_u32(node, "cpus", _cfg.max_vcpus) )
 panic("Missing property 'cpus' for domain %s\n",
   dt_node_name(node));
@@ -2430,6 +2426,19 @@ void __init create_domUs(void)
 if ( dt_find_compatible_node(node, NULL, "multiboot,device-tree") )
 d_cfg.flags |= XEN_DOMCTL_CDF_iommu;
 
+if ( !dt_property_read_u32(node, "nr_spis", _cfg.arch.nr_spis) )
+{
+d_cfg.arch.nr_spis = gic_number_lines() - 32;
+
+/*
+ * vpl011 uses one emulated SPI. If vpl011 is requested, make
+ * sure that we allocate enough SPIs for it.
+ */
+if ( dt_property_read_bool(node, "vpl011") )
+d_cfg.arch.nr_spis = MAX(d_cfg.arch.nr_spis,
+ GUEST_VPL011_SPI - 32 + 1);
+}
+
 d = domain_create(++max_init_domid, _cfg, false);
 if ( IS_ERR(d) )
 panic("Error creating domain %s\n", dt_node_name(node));
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v9 4/8] xen/arm: copy dtb fragment to guest dtb

[Stefano Stabellini]

Read the dtb fragment corresponding to a passthrough device from memory
at the location referred to by the "multiboot,device-tree" compatible
node.

Add a new field named dtb_bootmodule to struct kernel_info to keep track
of the dtb fragment location.

Copy the fragment to the guest dtb (only /aliases and /passthrough).

Set kinfo->phandle_gic based on the phandle of the special "/gic"
node in the device tree fragment. "/gic" is a dummy node in the dtb
fragment that represents the gic interrupt controller. Other properties
in the dtb fragment might refer to it (for instance interrupt-parent of
a device node). We reuse the phandle of "/gic" from the dtb fragment as
the phandle of the full GIC node that will be created for the guest
device tree. That way, when we copy properties from the device tree
fragment to the domU device tree the links remain unbroken.

scan_passthrough_prop is introduced here and not used in this patch but
it will be used by later patches.

Some of the code below is taken from tools/libxl/libxl_arm.c. Note that
it is OK to take LGPL 2.1 code and including it into a GPLv2 code base.
The result is GPLv2 code.

Signed-off-by: Stefano Stabellini 
Acked-by: Julien Grall 

Changes in v6:
- code style
- in-code comment
- commit message improvements

Changes in v5:
- code style
- in-code comment
- remove depth parameter from scan_pfdt_node
- for instead of loop in domain_handle_dtb_bootmodule
- move "gic" check to domain_handle_dtb_bootmodule
- add check_partial_fdt
- use DT_ROOT_NODE_ADDR/SIZE_CELLS_DEFAULT
- add scan_passthrough_prop parameter, set it to false for "/aliases"

Changes in v4:
- use recursion in the implementation
- rename handle_properties to handle_prop_pfdt
- rename scan_pt_node to scan_pfdt_node
- pass kinfo to handle_properties
- use uint32_t instead of u32
- rename r to res
- add "passthrough" and "aliases" check
- add a name == NULL check
- code style
- move DTB fragment scanning earlier, before DomU GIC node creation
- set guest_phandle_gic based on "/gic"
- in-code comment

Changes in v3:
- switch to using device_tree_for_each_node for the copy

Changes in v2:
- add a note about the code coming from libxl in the commit message
- copy /aliases
- code style
---
 xen/arch/arm/domain_build.c  | 164 +++
 xen/include/asm-arm/kernel.h |   2 +-
 2 files changed, 165 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d23c0a9b87..84b65b8f25 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1713,6 +1714,157 @@ static int __init make_vpl011_uart_node(struct 
kernel_info *kinfo)
 }
 #endif
 
+static int __init handle_prop_pfdt(struct kernel_info *kinfo,
+   const void *pfdt, int nodeoff,
+   uint32_t address_cells, uint32_t size_cells,
+   bool scan_passthrough_prop)
+{
+void *fdt = kinfo->fdt;
+int propoff, nameoff, res;
+const struct fdt_property *prop;
+
+for ( propoff = fdt_first_property_offset(pfdt, nodeoff);
+  propoff >= 0;
+  propoff = fdt_next_property_offset(pfdt, propoff) )
+{
+if ( !(prop = fdt_get_property_by_offset(pfdt, propoff, NULL)) )
+return -FDT_ERR_INTERNAL;
+
+nameoff = fdt32_to_cpu(prop->nameoff);
+res = fdt_property(fdt, fdt_string(pfdt, nameoff),
+   prop->data, fdt32_to_cpu(prop->len));
+if ( res )
+return res;
+}
+
+/* FDT_ERR_NOTFOUND => There is no more properties for this node */
+return ( propoff != -FDT_ERR_NOTFOUND ) ? propoff : 0;
+}
+
+static int __init scan_pfdt_node(struct kernel_info *kinfo, const void *pfdt,
+ int nodeoff,
+ uint32_t address_cells, uint32_t size_cells,
+ bool scan_passthrough_prop)
+{
+int rc = 0;
+void *fdt = kinfo->fdt;
+int node_next;
+
+rc = fdt_begin_node(fdt, fdt_get_name(pfdt, nodeoff, NULL));
+if ( rc )
+return rc;
+
+rc = handle_prop_pfdt(kinfo, pfdt, nodeoff, address_cells, size_cells,
+  scan_passthrough_prop);
+if ( rc )
+return rc;
+
+address_cells = device_tree_get_u32(pfdt, nodeoff, "#address-cells",
+DT_ROOT_NODE_ADDR_CELLS_DEFAULT);
+size_cells = device_tree_get_u32(pfdt, nodeoff, "#size-cells",
+ DT_ROOT_NODE_SIZE_CELLS_DEFAULT);
+
+node_next = fdt_first_subnode(pfdt, nodeoff);
+while ( node_next > 0 )
+{
+scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells,
+   scan_passthrough_prop);
+node_next = fdt_next_subnode(pfdt, node_next);
+}
+
+return fdt_end_node(fdt);

[Xen-devel] [PATCH v9 3/8] xen/arm: introduce kinfo->phandle_gic

[Stefano Stabellini]

Instead of always hard-coding the GIC phandle (GUEST_PHANDLE_GIC), store
it in a variable under kinfo. This way it can be dynamically chosen per
domain. Remove the fdt pointer argument to the make_*_domU_node
functions and oass a struct kernel_info * instead. The fdt pointer can
be accessed from kinfo->fdt. Remove the struct domain *d parameter to
the make_*_domU_node functions because it becomes unused.

Initialize phandle_gic to GUEST_PHANDLE_GIC at the beginning of
prepare_dtb_domU for DomUs. Later patches will change the value of
phandle_gic depending on user provided information.

For Dom0, initialize phandle_gic to dt_interrupt_controller->phandle
(current value) at the beginning of prepare_dtb.

Signed-off-by: Stefano Stabellini 
Acked-by: Julien Grall 

---
Changes in v6:
- rename guest_phandle_gic to phandle_gic
- use phandle_gic for dom0 too

Changes in v5:
- improve commit message

Changes in v4:
- new patch
---
 xen/arch/arm/domain_build.c  | 39 
 xen/include/asm-arm/kernel.h |  3 +++
 2 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index fb356603e2..d23c0a9b87 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -626,15 +626,14 @@ static int __init fdt_property_interrupts(const struct 
kernel_info *kinfo,
   unsigned num_irq)
 {
 int res;
-uint32_t phandle = is_hardware_domain(kinfo->d) ?
-   dt_interrupt_controller->phandle : GUEST_PHANDLE_GIC;
 
 res = fdt_property(kinfo->fdt, "interrupts",
intr, sizeof(intr[0]) * num_irq);
 if ( res )
 return res;
 
-res = fdt_property_cell(kinfo->fdt, "interrupt-parent", phandle);
+res = fdt_property_cell(kinfo->fdt, "interrupt-parent",
+kinfo->phandle_gic);
 
 return res;
 }
@@ -1552,8 +1551,9 @@ static int __init handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return res;
 }
 
-static int __init make_gicv2_domU_node(const struct domain *d, void *fdt)
+static int __init make_gicv2_domU_node(struct kernel_info *kinfo)
 {
+void *fdt = kinfo->fdt;
 int res = 0;
 __be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
 __be32 *cells;
@@ -1588,11 +1588,11 @@ static int __init make_gicv2_domU_node(const struct 
domain *d, void *fdt)
 if (res)
 return res;
 
-res = fdt_property_cell(fdt, "linux,phandle", GUEST_PHANDLE_GIC);
+res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_gic);
 if (res)
 return res;
 
-res = fdt_property_cell(fdt, "phandle", GUEST_PHANDLE_GIC);
+res = fdt_property_cell(fdt, "phandle", kinfo->phandle_gic);
 if (res)
 return res;
 
@@ -1601,8 +1601,9 @@ static int __init make_gicv2_domU_node(const struct 
domain *d, void *fdt)
 return res;
 }
 
-static int __init make_gicv3_domU_node(const struct domain *d, void *fdt)
+static int __init make_gicv3_domU_node(struct kernel_info *kinfo)
 {
+void *fdt = kinfo->fdt;
 int res = 0;
 __be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
 __be32 *cells;
@@ -1637,11 +1638,11 @@ static int __init make_gicv3_domU_node(const struct 
domain *d, void *fdt)
 if (res)
 return res;
 
-res = fdt_property_cell(fdt, "linux,phandle", GUEST_PHANDLE_GIC);
+res = fdt_property_cell(fdt, "linux,phandle", kinfo->phandle_gic);
 if (res)
 return res;
 
-res = fdt_property_cell(fdt, "phandle", GUEST_PHANDLE_GIC);
+res = fdt_property_cell(fdt, "phandle", kinfo->phandle_gic);
 if (res)
 return res;
 
@@ -1650,22 +1651,23 @@ static int __init make_gicv3_domU_node(const struct 
domain *d, void *fdt)
 return res;
 }
 
-static int __init make_gic_domU_node(const struct domain *d, void *fdt)
+static int __init make_gic_domU_node(struct kernel_info *kinfo)
 {
-switch ( d->arch.vgic.version )
+switch ( kinfo->d->arch.vgic.version )
 {
 case GIC_V3:
-return make_gicv3_domU_node(d, fdt);
+return make_gicv3_domU_node(kinfo);
 case GIC_V2:
-return make_gicv2_domU_node(d, fdt);
+return make_gicv2_domU_node(kinfo);
 default:
 panic("Unsupported GIC version\n");
 }
 }
 
 #ifdef CONFIG_SBSA_VUART_CONSOLE
-static int __init make_vpl011_uart_node(const struct domain *d, void *fdt)
+static int __init make_vpl011_uart_node(struct kernel_info *kinfo)
 {
+void *fdt = kinfo->fdt;
 int res;
 gic_interrupt_t intr;
 __be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
@@ -1696,7 +1698,7 @@ static int __init make_vpl011_uart_node(const struct 
domain *d, void *fdt)
 return res;
 
 res = fdt_property_cell(fdt, "interrupt-parent",
-GUEST_PHANDLE_GIC);
+kinfo->phandle_gic);
 if ( res )
 return res;
 
@@ -1721,6 

[Xen-devel] [PATCH v9 6/8] xen/arm: handle "multiboot, device-tree" compatible nodes

[Stefano Stabellini]

Detect "multiboot,device-tree" compatible nodes. Add them to the bootmod
array as BOOTMOD_GUEST_DTB.  In kernel_probe, find the right
BOOTMOD_GUEST_DTB and store a pointer to it in dtb_bootmodule.

Signed-off-by: Stefano Stabellini 
Acked-by: Julien Grall 
---
Changes in v4:
- use uint32_t
- remove useless 0 initialization
- add return value check

Changes in v2:
- rename BOOTMOD_DTB to BOOTMOD_GUEST_DTB
- rename multiboot,dtb to multiboot,device-tree
---
 xen/arch/arm/bootfdt.c  |  2 ++
 xen/arch/arm/kernel.c   | 14 +-
 xen/arch/arm/setup.c|  1 +
 xen/include/asm-arm/setup.h |  1 +
 4 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index a7810abb15..08fb59f4e7 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -242,6 +242,8 @@ static void __init process_multiboot_node(const void *fdt, 
int node,
 kind = BOOTMOD_RAMDISK;
 else if ( fdt_node_check_compatible(fdt, node, "xen,xsm-policy") == 0 )
 kind = BOOTMOD_XSM;
+else if ( fdt_node_check_compatible(fdt, node, "multiboot,device-tree") == 
0 )
+kind = BOOTMOD_GUEST_DTB;
 else
 kind = BOOTMOD_UNKNOWN;
 
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 389bef2afa..8eff074836 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -425,7 +425,7 @@ int __init kernel_probe(struct kernel_info *info,
 struct bootmodule *mod = NULL;
 struct bootcmdline *cmd = NULL;
 struct dt_device_node *node;
-u64 kernel_addr, initrd_addr, size;
+u64 kernel_addr, initrd_addr, dtb_addr, size;
 int rc;
 
 /* domain is NULL only for the hardware domain */
@@ -469,6 +469,18 @@ int __init kernel_probe(struct kernel_info *info,
 info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
 BOOTMOD_RAMDISK, initrd_addr);
 }
+else if ( dt_device_is_compatible(node, "multiboot,device-tree") )
+{
+uint32_t len;
+const __be32 *val;
+
+val = dt_get_property(node, "reg", );
+if ( val == NULL )
+continue;
+dt_get_range(, node, _addr, );
+info->dtb_bootmodule = boot_module_find_by_addr_and_kind(
+BOOTMOD_GUEST_DTB, dtb_addr);
+}
 else
 continue;
 }
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 790eab94d6..705a917abf 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -369,6 +369,7 @@ const char * __init 
boot_module_kind_as_string(bootmodule_kind kind)
 case BOOTMOD_KERNEL:  return "Kernel";
 case BOOTMOD_RAMDISK: return "Ramdisk";
 case BOOTMOD_XSM: return "XSM";
+case BOOTMOD_GUEST_DTB: return "DTB";
 case BOOTMOD_UNKNOWN: return "Unknown";
 default: BUG();
 }
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index fa0a8721b2..2f8f24e286 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -16,6 +16,7 @@ typedef enum {
 BOOTMOD_KERNEL,
 BOOTMOD_RAMDISK,
 BOOTMOD_XSM,
+BOOTMOD_GUEST_DTB,
 BOOTMOD_UNKNOWN
 }  bootmodule_kind;
 
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v9 1/8] xen/arm: introduce handle_device_interrupts

[Stefano Stabellini]

Move the interrupt handling code out of handle_device to a new function
so that it can be reused for dom0less VMs (it will be used in later
patches).

Signed-off-by: Stefano Stabellini 
Acked-by: Julien Grall 
---
Changes in v4:
- rename handle_interrupts to handle_device_interrupts
- improve in-code comment
- remove return 1 if mapping is done
- use unsigned

Changes in v3:
- add patch

The diff is hard to read but I just moved the interrupts related code
from handle_devices to a new function handle_device_interrupts, and very
little else.
---
 xen/arch/arm/domain_build.c | 100 ++--
 1 file changed, 61 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 337a89e518..fb356603e2 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1238,6 +1238,62 @@ static int __init map_device_children(struct domain *d,
 return 0;
 }
 
+/*
+ * handle_device_interrupts retrieves the interrupts configuration from
+ * a device tree node and maps those interrupts to the target domain.
+ *
+ * Returns:
+ *   < 0 error
+ *   0   success
+ */
+static int __init handle_device_interrupts(struct domain *d,
+   struct dt_device_node *dev,
+   bool need_mapping)
+{
+unsigned int i, nirq;
+int res;
+struct dt_raw_irq rirq;
+
+nirq = dt_number_of_irq(dev);
+
+/* Give permission and map IRQs */
+for ( i = 0; i < nirq; i++ )
+{
+res = dt_device_get_raw_irq(dev, i, );
+if ( res )
+{
+printk(XENLOG_ERR "Unable to retrieve irq %u for %s\n",
+   i, dt_node_full_name(dev));
+return res;
+}
+
+/*
+ * Don't map IRQ that have no physical meaning
+ * ie: IRQ whose controller is not the GIC
+ */
+if ( rirq.controller != dt_interrupt_controller )
+{
+dt_dprintk("irq %u not connected to primary controller. Connected 
to %s\n",
+  i, dt_node_full_name(rirq.controller));
+continue;
+}
+
+res = platform_get_irq(dev, i);
+if ( res < 0 )
+{
+printk(XENLOG_ERR "Unable to get irq %u for %s\n",
+   i, dt_node_full_name(dev));
+return res;
+}
+
+res = map_irq_to_domain(d, res, need_mapping, dt_node_name(dev));
+if ( res )
+return res;
+}
+
+return 0;
+}
+
 /*
  * For a given device node:
  *  - Give permission to the guest to manage IRQ and MMIO range
@@ -1250,19 +1306,16 @@ static int __init map_device_children(struct domain *d,
 static int __init handle_device(struct domain *d, struct dt_device_node *dev,
 p2m_type_t p2mt)
 {
-unsigned int nirq;
 unsigned int naddr;
 unsigned int i;
 int res;
-struct dt_raw_irq rirq;
 u64 addr, size;
 bool need_mapping = !dt_device_for_passthrough(dev);
 
-nirq = dt_number_of_irq(dev);
 naddr = dt_number_of_address(dev);
 
-dt_dprintk("%s passthrough = %d nirq = %d naddr = %u\n",
-   dt_node_full_name(dev), need_mapping, nirq, naddr);
+dt_dprintk("%s passthrough = %d naddr = %u\n",
+   dt_node_full_name(dev), need_mapping, naddr);
 
 if ( need_mapping )
 {
@@ -1290,40 +1343,9 @@ static int __init handle_device(struct domain *d, struct 
dt_device_node *dev,
 }
 }
 
-/* Give permission and map IRQs */
-for ( i = 0; i < nirq; i++ )
-{
-res = dt_device_get_raw_irq(dev, i, );
-if ( res )
-{
-printk(XENLOG_ERR "Unable to retrieve irq %u for %s\n",
-   i, dt_node_full_name(dev));
-return res;
-}
-
-/*
- * Don't map IRQ that have no physical meaning
- * ie: IRQ whose controller is not the GIC
- */
-if ( rirq.controller != dt_interrupt_controller )
-{
-dt_dprintk("irq %u not connected to primary controller. Connected 
to %s\n",
-  i, dt_node_full_name(rirq.controller));
-continue;
-}
-
-res = platform_get_irq(dev, i);
-if ( res < 0 )
-{
-printk(XENLOG_ERR "Unable to get irq %u for %s\n",
-   i, dt_node_full_name(dev));
-return res;
-}
-
-res = map_irq_to_domain(d, res, need_mapping, dt_node_name(dev));
-if ( res )
-return res;
-}
+res = handle_device_interrupts(d, dev, need_mapping);
+if ( res < 0 )
+return res;
 
 /* Give permission and map MMIOs */
 for ( i = 0; i < naddr; i++ )
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v9 2/8] xen/arm: export device_tree_get_reg and device_tree_get_u32

[Stefano Stabellini]

They'll be used in later patches.

Signed-off-by: Stefano Stabellini 
Acked-by: Julien Grall 

---
Changes in v5:
- move declarations to xen/include/asm-arm/setup.h

Changes in v4:
- new patch
---
 xen/arch/arm/bootfdt.c  | 8 
 xen/include/asm-arm/setup.h | 6 ++
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 623173bc7f..a7810abb15 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -55,15 +55,15 @@ static bool __init device_tree_node_compatible(const void 
*fdt, int node,
 return false;
 }
 
-static void __init device_tree_get_reg(const __be32 **cell, u32 address_cells,
-   u32 size_cells, u64 *start, u64 *size)
+void __init device_tree_get_reg(const __be32 **cell, u32 address_cells,
+u32 size_cells, u64 *start, u64 *size)
 {
 *start = dt_next_cell(address_cells, cell);
 *size = dt_next_cell(size_cells, cell);
 }
 
-static u32 __init device_tree_get_u32(const void *fdt, int node,
-  const char *prop_name, u32 dflt)
+u32 __init device_tree_get_u32(const void *fdt, int node,
+   const char *prop_name, u32 dflt)
 {
 const struct fdt_property *prop;
 
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index efcba545c2..fa0a8721b2 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -115,6 +115,12 @@ const char *boot_module_kind_as_string(bootmodule_kind 
kind);
 extern uint32_t hyp_traps_vector[];
 void init_traps(void);
 
+void device_tree_get_reg(const __be32 **cell, u32 address_cells,
+ u32 size_cells, u64 *start, u64 *size);
+
+u32 device_tree_get_u32(const void *fdt, int node,
+const char *prop_name, u32 dflt);
+
 #endif
 /*
  * Local variables:
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v9 8/8] xen/arm: add dom0-less device assignment info to docs

[Stefano Stabellini]

Add info about the SPI used for the virtual pl011.

Signed-off-by: Stefano Stabellini 

---
Changes in v9:
- clarify statement

Changes in v8:
- remove sentence about xen,path being optional

Changes in v7:
- add xen,force-assign-without-iommu
- clarify xen,reg and xen,path go together
- remove acked-by due to changes

Changes in v6:
- fix nr_spis description
- add ack

Changes in v5:
- improve wording

Changes in v4:
- fix spelling
- add "multiboot,module"
- improve commit message
- improve doc
- expand the nr_spis and vpl011 sections and include information about
  the vpl011 SPI
- move passthrough information to docs/misc/arm/passthrough.txt

Changes in v3:
- add nr_spis
- change description of interrupts and interrupt-parent

Changes in v2:
- device tree fragment loaded in cacheable memory
- rename multiboot,dtb to multiboot,device-tree
- rename "path" to "xen,path"
- add a note about device memory mapping
- introduce xen,reg
- specify only the GIC is supported
---
 docs/misc/arm/device-tree/booting.txt |  44 ++-
 docs/misc/arm/passthrough.txt | 106 ++
 2 files changed, 149 insertions(+), 1 deletion(-)

diff --git a/docs/misc/arm/device-tree/booting.txt 
b/docs/misc/arm/device-tree/booting.txt
index 317a9e962a..649e00d09f 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -146,7 +146,18 @@ with the following properties:
 
 - vpl011
 
-An empty property to enable/disable a virtual pl011 for the guest to use.
+An empty property to enable/disable a virtual pl011 for the guest to
+use. The virtual pl011 uses SPI number 0 (see GUEST_VPL011_SPI).
+Please note that the SPI used for the virtual pl011 could clash with the
+physical SPI of a physical device assigned to the guest.
+
+- nr_spis
+
+Optional. A 32-bit integer specifying the number of SPIs (Shared
+Peripheral Interrupts) to allocate for the domain. If nr_spis is
+missing, the max number of SPIs supported by the physical GIC is
+used, or GUEST_VPL011_SPI+1 if vpl011 is enabled, whichever is
+greater.
 
 - #address-cells and #size-cells
 
@@ -226,3 +237,34 @@ chosen {
 };
 };
 };
+
+
+Device Assignment
+=
+
+Device Assignment (Passthrough) is supported by adding another module,
+alongside the kernel and ramdisk, with the device tree fragment
+corresponding to the device node to assign to the guest.
+
+The dtb sub-node should have the following properties:
+
+- compatible
+
+"multiboot,device-tree" and "multiboot,module"
+
+- reg
+
+Specifies the physical address of the device tree binary fragment
+RAM and its length.
+
+As an example:
+
+module@0xc00 {
+compatible = "multiboot,device-tree", "multiboot,module";
+reg = <0x0 0xc00 0xff>;
+};
+
+The DTB fragment is loaded at 0xc00 in the example above. It should
+follow the convention explained in docs/misc/arm/passthrough.txt. The
+DTB fragment will be added to the guest device tree, so that the guest
+kernel will be able to discover the device.
diff --git a/docs/misc/arm/passthrough.txt b/docs/misc/arm/passthrough.txt
index 0efbd122de..c85e657bca 100644
--- a/docs/misc/arm/passthrough.txt
+++ b/docs/misc/arm/passthrough.txt
@@ -80,6 +80,112 @@ SPI numbers start from 32, in this example 80 + 32 = 112.
 See man [xl.cfg] for the iomem format. The reg property is just a pair
 of address, then size numbers, each of them can occupy 1 or 2 cells.
 
+
+Dom0-less Device Passthrough
+
+
+The partial device tree for dom0-less guests should have the following
+properties for each node corresponding to a physical device to assign to
+the guest:
+
+- xen,reg
+
+  The xen,reg property is an array of:
+
+
+
+  They specify the physical address and size of the device memory
+  ranges together with the corresponding guest address to map them to.
+  The size of `phys_addr' and `guest_addr' is determined by
+  #address-cells, the size of `size' is determined by #size-cells, of
+  the partial device tree.
+  The memory will be mapped as device memory in the guest (Device-nGnRE).
+
+- xen,path
+
+  A string property representing the path in the host device tree to the
+  corresponding device node.
+
+- xen,force-assign-without-iommu
+  If xen,force-assign-without-iommu is present, Xen allows to assign a
+  device even if it is not behind an IOMMU. This renders your platform
+  *unsafe* if the device is DMA-capable.
+
+In addition, a special /gic node is expected as a placeholder for the
+full GIC node that will be added by Xen for the guest. /gic can be
+referenced by other properties in the device tree fragment. For
+instance, it can be referenced by interrupt-parent under a device node.
+Xen will take care of replacing the "gic" placeholder node for a
+complete GIC node while retaining all the references correctly. The new
+GIC node created by Xen is a regular 

[Xen-devel] [PATCH v9 0/8] dom0less device assignment

[Stefano Stabellini]

Hi all,

This small patch series adds device assignment support to Dom0less.
The last patch is the documentation.

Cheers,

Stefano


The following changes since commit 7a4e674905b3cbbe48e81c3222361a7f3579:

  xen/sched: move struct task_slice into struct sched_unit (2019-09-27 16:03:31 
+0200)

are available in the Git repository at:

  http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git 
dom0less-pt-v9

for you to fetch changes up to 7660f03ca8ddcfde325864ed0bbf80f8e0c20e6c:

  xen/arm: add dom0-less device assignment info to docs (2019-10-03 10:35:41 
-0700)


Stefano Stabellini (8):
  xen/arm: introduce handle_device_interrupts
  xen/arm: export device_tree_get_reg and device_tree_get_u32
  xen/arm: introduce kinfo->phandle_gic
  xen/arm: copy dtb fragment to guest dtb
  xen/arm: assign devices to boot domains
  xen/arm: handle "multiboot,device-tree" compatible nodes
  xen/arm: introduce nr_spis
  xen/arm: add dom0-less device assignment info to docs

 docs/misc/arm/device-tree/booting.txt |  44 +++-
 docs/misc/arm/passthrough.txt | 106 
 xen/arch/arm/bootfdt.c|  10 +-
 xen/arch/arm/domain_build.c   | 459 +-
 xen/arch/arm/kernel.c |  14 +-
 xen/arch/arm/setup.c  |   1 +
 xen/include/asm-arm/kernel.h  |   5 +-
 xen/include/asm-arm/setup.h   |   7 +
 8 files changed, 579 insertions(+), 67 deletions(-)

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v9 5/8] xen/arm: assign devices to boot domains

[Stefano Stabellini]

Scan the user provided dtb fragment at boot. For each device node, map
memory to guests, and route interrupts and setup the iommu.

The memory region to remap is specified by the "xen,reg" property.

The iommu is setup by passing the node of the device to assign on the
host device tree. The path is specified in the device tree fragment as
the "xen,path" string property.

The interrupts are remapped based on the information from the
corresponding node on the host device tree. Call
handle_device_interrupts to remap interrupts. Interrupts related device
tree properties are copied from the device tree fragment, same as all
the other properties.

Require both xen,reg and xen,path to be present, unless
xen,force-assign-without-iommu is also set. In that case, tolerate a
missing xen,path, also tolerate iommu setup failure for the passthrough
device.

Also set add the new flag XEN_DOMCTL_CDF_iommu so that dom0less domU
can use the IOMMU if a partial dtb is specified.

Signed-off-by: Stefano Stabellini 
---
Changes in v9:
- add a check on xen,reg or xen,path missing
- don't continue when IOMMU setup fails with an error

Changes in v8:
- better in-code comment
- code style
- add a prink in case of error

Changes in v7:
- improve in-code comment
- code style
- return 1 instead of ENOENT
- introduce "xen,force-assign-without-iommu"
- require both "xen,reg" and "xen,path" unless
  "xen,force-assign-without-iommu"

Changes in v6:
- turn dprintks into printks
- return error on page alignment check failure
- set XEN_DOMCTL_CDF_iommu if partial dtb is specified

Changes in v5:
- use local variable for name
- use map_regions_p2mt
- add warning for not page aligned addresses/sizes
- introduce handle_passthrough_prop

Changes in v4:
- use unsigned
- improve commit message
- code style
- use dt_prop_cmp
- use device_tree_get_reg
- don't copy over xen,reg and xen,path
- don't create special interrupt properties for domU: copy them from the
  fragment
- in-code comment

Changes in v3:
- improve commit message
- remove superfluous cast
- merge code with the copy code
- add interrup-parent
- demove depth > 2 check
- reuse code from handle_device_interrupts
- copy interrupts from host dt

Changes in v2:
- rename "path" to "xen,path"
- grammar fix
- use gaddr_to_gfn and maddr_to_mfn
- remove depth <= 2 limitation in scanning the dtb fragment
- introduce and parse xen,reg
- code style
- support more than one interrupt per device
- specify only the GIC is supported
---
 xen/arch/arm/domain_build.c | 147 +++-
 1 file changed, 143 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 84b65b8f25..030fc32416 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1714,6 +1714,90 @@ static int __init make_vpl011_uart_node(struct 
kernel_info *kinfo)
 }
 #endif
 
+/*
+ * Scan device tree properties for passthrough specific information.
+ * Returns < 0 on error
+ * 0 on success
+ */
+static int __init handle_passthrough_prop(struct kernel_info *kinfo,
+  const struct fdt_property *xen_reg,
+  const struct fdt_property *xen_path,
+  bool xen_force,
+  uint32_t address_cells, uint32_t 
size_cells)
+{
+const __be32 *cell;
+unsigned int i, len;
+struct dt_device_node *node;
+int res;
+paddr_t mstart, size, gstart;
+
+/* xen,reg specifies where to map the MMIO region */
+cell = (const __be32 *)xen_reg->data;
+len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
+sizeof(uint32_t));
+
+for ( i = 0; i < len; i++ )
+{
+device_tree_get_reg(, address_cells, size_cells,
+, );
+gstart = dt_next_cell(address_cells, );
+
+if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK )
+{
+printk(XENLOG_ERR
+"DomU passthrough config has not page aligned 
addresses/sizes\n");
+return -EINVAL;
+}
+
+res = map_regions_p2mt(kinfo->d,
+   gaddr_to_gfn(gstart),
+   PFN_DOWN(size),
+   maddr_to_mfn(mstart),
+   p2m_mmio_direct_dev);
+if ( res < 0 )
+{
+printk(XENLOG_ERR
+   "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n",
+   mstart, gstart);
+return -EFAULT;
+}
+}
+
+/*
+ * If xen_force, we let the user assign a MMIO region with no
+ * associated path.
+ */
+if ( xen_path == NULL )
+return xen_force ? 0 : -EINVAL;
+
+/*
+ * xen,path specifies the corresponding node in the host DT.
+ * Both interrupt mappings and IOMMU settings 

[Xen-devel] [PATCH v2] xen/arm: platform: fix Raspberry Pi compatible string

[Stewart Hildebrand]

Both upstream [1] and downstream [2] Linux kernels use "brcm,bcm2711"
as the compatible string for Raspberry Pi 4. Add this string to our
platform compatible list.

The brcm,bcm2838 convention is abandoned. Remove it.

Rename the variables within the file to a rpi4_* prefix since the file
is meant to cover the Raspberry Pi 4 platform.

[1] https://patchwork.kernel.org/patch/11165407/
[2] 
https://github.com/raspberrypi/linux/commit/53fdd7b8c8cb9c87190caab4fd459f89e1b4a7f8

Signed-off-by: Stewart Hildebrand 
---
 xen/arch/arm/platforms/brcm-raspberry-pi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c 
b/xen/arch/arm/platforms/brcm-raspberry-pi.c
index e22d2b3184..b697fa2c6c 100644
--- a/xen/arch/arm/platforms/brcm-raspberry-pi.c
+++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c
@@ -19,13 +19,13 @@
 
 #include 
 
-static const char *const brcm_bcm2838_dt_compat[] __initconst =
+static const char *const rpi4_dt_compat[] __initconst =
 {
-"brcm,bcm2838",
+"brcm,bcm2711",
 NULL
 };
 
-static const struct dt_device_match brcm_bcm2838_blacklist_dev[] __initconst =
+static const struct dt_device_match rpi4_blacklist_dev[] __initconst =
 {
 /*
  * The aux SPIs share an IRQ and a page with the aux UART.
@@ -40,9 +40,9 @@ static const struct dt_device_match 
brcm_bcm2838_blacklist_dev[] __initconst =
 { /* sentinel */ },
 };
 
-PLATFORM_START(brcm_bcm2838, "Raspberry Pi 4")
-.compatible = brcm_bcm2838_dt_compat,
-.blacklist_dev  = brcm_bcm2838_blacklist_dev,
+PLATFORM_START(rpi4, "Raspberry Pi 4")
+.compatible = rpi4_dt_compat,
+.blacklist_dev  = rpi4_blacklist_dev,
 PLATFORM_END
 
 /*
-- 
2.23.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen/arm: platform: additional Raspberry Pi compatible string

[Stewart Hildebrand]

On Tuesday, September 17, 2019 7:05 AM, Julien Grall  
wrote:
>Hi Stewart,
>
>On 9/14/19 2:22 AM, Stewart Hildebrand wrote:
>> On Friday, September 13, 2019 5:42 PM, Julien Grall  
>> wrote:
>>> 2) Is the patch [1] merged? If so, which version?
>>
>> No.
>
>I would rather wait until the patch is merged in Linux before adding the
>compatible.

The downstream kernel has changed their compatible to "brcm,bcm2711" [8],
so "brcm,bcm2838" is obsolete now. While the upstream series has not been
merged yet [9], the lack of "brcm,bcm2711" in our compatible list is
preventing us from booting the downstream kernel. I will send a v2 of the
patch.

>This also raise the question on what's going to happen for blacklist
>device? Are they still going to contain "bcm2835"?

The peripherals/devices still have the same "brcm,bcm2835" prefix. No change.

[8] 
https://github.com/raspberrypi/linux/commit/53fdd7b8c8cb9c87190caab4fd459f89e1b4a7f8
[9] v3 https://patchwork.kernel.org/cover/11165395/
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Errors with Loading Xen at a Certain Address

[Brian Woods]

On Thu, Oct 03, 2019 at 10:20:36PM +0100, Julien Grall wrote:
> Hi Brian,
> 
> On 10/3/19 9:24 PM, Brian Woods wrote:
> >On Thu, Oct 03, 2019 at 07:23:23PM +, Julien Grall wrote:
> >There's a WARN_ON() between the two debug printks calls I shared above.
> 
> Looking at the log, the MFN seems to correspond to the one right after Xen
> (0140 - 015328f1) in memory.
> 
> So it is normal to have the page given to the boot allocator. However, I am
> not entirely sure which bit of init_done() is giving the page again to
> xenheap.
> 
> It is unlikely to be free_init_memory() because it deal with the init
> section that is not at the end of the binary.
> 
> This would leave discard_initial_modules() but there are a check to skip Xen
> module.
> 
> The call stack only print the address and not the symbol because it
> unregistered the symbols for init. See unregister_init_virtual_memory().
> 
> (XEN) Xen call trace:
> (XEN)[<0021c1a8>] page_alloc.c#free_heap_pages+0x1a8/0x614 (PC)
> (XEN)[<0021c1a8>] page_alloc.c#free_heap_pages+0x1a8/0x614 (LR)
> (XEN)[<0021e900>] page_alloc.c#init_heap_pages+0x3d4/0x564
> (XEN)[<0021eb24>] init_domheap_pages+0x94/0x9c
> (XEN)[<002b83ec>] 002b83ec
> (XEN)[<002b8904>] 002b8904
> (XEN)[<00260a3c>] setup.c#init_done+0x10/0x20
> (XEN)[<002b99ac>] 002b99ac
> 
> You should be able to use addr2line on the address with Xen binary.
> I have the feeling this will point to discard_initial_modules() as this is
> an init function and the symbol should not be printed.
> 
> But, I can't see anything obviously wrong in the function... So I am not
> entirely sure what could be the next steps.
> 
> Cheers,
> 
> -- 
> Julien Grall

In the log, there's:
(XEN) MODULE[0]: 0140 - 015328f1 Xen
(XEN) MODULE[1]: 076d2000 - 076dc080 Device Tree
(XEN) MODULE[2]: 076df000 - 07fff364 Ramdisk
(XEN) MODULE[3]: 0008 - 0318 Kernel
(XEN)  RESVD[0]: 076d2000 - 076dc000
(XEN)  RESVD[1]: 076df000 - 07fff364

Linux kernel->   8_ - 318_
Xen -> 140_ - 153_28f1

There's something not quite right here... I'm guessing Xen was working
at the address before because it was out of the "range" of the Linux
kernel.  Now I guess I need to look into if it's a Xen or u-boot issue.

-- 
Brian Woods

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[osstest service owner]

flight 142220 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142220/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
140282
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail 
REGR. vs. 140282
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 140282
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
140282
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail REGR. vs. 140282
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 140282
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 140282
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 140282
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
140282
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 140282
 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 140282
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 140282
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. 
vs. 140282
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail 
REGR. vs. 140282
 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 140282
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 140282
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail REGR. vs. 140282
 test-amd64-i386-freebsd10-amd64 11 guest-start   fail REGR. vs. 140282
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. 
vs. 140282
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 140282
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 140282
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 140282
 test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 142108 REGR. 
vs. 140282

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail in 142108 pass in 142220
 test-armhf-armhf-xl-vhd  18 leak-check/check fail in 142108 pass in 142220
 test-amd64-amd64-xl-pvshim   18 guest-localmigrate/x10 fail pass in 142108

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 140282
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 140282
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-check

Re: [Xen-devel] Errors with Loading Xen at a Certain Address

[Julien Grall]

Hi Brian,

On 10/3/19 9:24 PM, Brian Woods wrote:

On Thu, Oct 03, 2019 at 07:23:23PM +, Julien Grall wrote:
There's a WARN_ON() between the two debug printks calls I shared above.


Looking at the log, the MFN seems to correspond to the one right after 
Xen (0140 - 015328f1) in memory.


So it is normal to have the page given to the boot allocator. However, I 
am not entirely sure which bit of init_done() is giving the page again 
to xenheap.


It is unlikely to be free_init_memory() because it deal with the init 
section that is not at the end of the binary.


This would leave discard_initial_modules() but there are a check to skip 
Xen module.


The call stack only print the address and not the symbol because it 
unregistered the symbols for init. See unregister_init_virtual_memory().


(XEN) Xen call trace:
(XEN)[<0021c1a8>] page_alloc.c#free_heap_pages+0x1a8/0x614 (PC)
(XEN)[<0021c1a8>] page_alloc.c#free_heap_pages+0x1a8/0x614 (LR)
(XEN)[<0021e900>] page_alloc.c#init_heap_pages+0x3d4/0x564
(XEN)[<0021eb24>] init_domheap_pages+0x94/0x9c
(XEN)[<002b83ec>] 002b83ec
(XEN)[<002b8904>] 002b8904
(XEN)[<00260a3c>] setup.c#init_done+0x10/0x20
(XEN)[<002b99ac>] 002b99ac

You should be able to use addr2line on the address with Xen binary.
I have the feeling this will point to discard_initial_modules() as this 
is an init function and the symbol should not be printed.


But, I can't see anything obviously wrong in the function... So I am not 
entirely sure what could be the next steps.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] I want to participate in Outreachy with CONFIG_PDX related project

[Andrew Cooper]

On 25/09/2019 10:27, Kateryna Razumova wrote:
> Hello xen,
> I would like to participate in Outreachy. I was registered on the site
> few days ago, filled some quite a big form but still can't see tasks'
> descriptions.
> Since, I like C programming I would like to know more about "Introduce
> CONFIG_PDX and use it in Xen hypervisor". What hardware do I need? I
> think I can find an old laptop with virtualization support. Also, how
> can I start contributing?
> I have few years of C programming experience but never had contributed
> to open-source projects before.

Apologies I haven't got this sorted sooner, but
https://andrewcoop-xen.readthedocs.io/en/docs-devel/misc/tech-debt.html#config-pdx
is a brief introduction to the problem and intended outcome.

I hope the description is clear enough to follow.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 3/4] docs/sphinx: Introduction

[Andrew Cooper]

Put together an introduction page for the Sphinx/RST docs, along with a
glossary which will accumulate over time.

Signed-off-by: Andrew Cooper 
---
CC: Lars Kurth 
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
CC: Julien Grall 
CC: Roger Pau Monné 
CC: Juergen Gross 
---
 docs/admin-guide/index.rst   |  1 +
 docs/admin-guide/introduction.rst| 40 +
 docs/admin-guide/xen-overview.drawio.svg | 97 
 docs/glossary.rst| 52 +
 docs/index.rst   | 12 
 5 files changed, 202 insertions(+)
 create mode 100644 docs/admin-guide/introduction.rst
 create mode 100644 docs/admin-guide/xen-overview.drawio.svg
 create mode 100644 docs/glossary.rst

diff --git a/docs/admin-guide/index.rst b/docs/admin-guide/index.rst
index 1da7c8bf4d..54e6f65de3 100644
--- a/docs/admin-guide/index.rst
+++ b/docs/admin-guide/index.rst
@@ -4,4 +4,5 @@ Admin Guide
 ===
 
 .. toctree::
+   introduction
microcode-loading
diff --git a/docs/admin-guide/introduction.rst 
b/docs/admin-guide/introduction.rst
new file mode 100644
index 00..6da2758d70
--- /dev/null
+++ b/docs/admin-guide/introduction.rst
@@ -0,0 +1,40 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Introduction
+
+
+Xen is an open source, bare metal hypervisor.  It runs as the most privileged
+piece of software, and shares the resources of the hardware between virtual
+machines.
+
+In Xen terminology, there are :term:`domains`, commonly abbreviated to
+dom, which are identified by their numeric :term:`domid`.
+
+When Xen boots, dom0 is automatically started as well.  Dom0 is a virtual
+machine which, by default, is granted full permissions [1]_.  A typical setup
+might be:
+
+.. image:: xen-overview.drawio.svg
+
+Dom0 takes the role of :term:`control domain`, responsible for creating and
+managing other virtual machines, and the role of :term:`hardware domain`,
+responsible for hardware and marshalling guest I/O.
+
+Xen is deliberately minimal, and has no device drivers [2]_.  Xen manages RAM,
+schedules virtual CPUs on the available physical CPUs, and marshals
+interrupts.
+
+Xen also provides a hypercall interface to guests, including event channels
+(virtual interrupts), grant tables (shared memory), on which a lot of higher
+level functionality is built.
+
+.. rubric:: Footnotes
+
+.. [1] A common misconception with Xen's architecture is that dom0 is somehow
+   different to other guests.  The choice of id 0 is not an accident, and
+   follows in UNIX heritage.
+
+.. [2] This definition might be fuzzy.  Xen can talk to common serial UARTs,
+   and knows how to drive various CPU internal devices such as IOMMUs, but
+   has no knowledge of network cards, disks, etc.  All of that is the
+   hardware domains responsibility.
diff --git a/docs/admin-guide/xen-overview.drawio.svg 
b/docs/admin-guide/xen-overview.drawio.svg
new file mode 100644
index 00..f120cdf77a
--- /dev/null
+++ b/docs/admin-guide/xen-overview.drawio.svg
@@ -0,0 +1,97 @@
+
+http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd;>
+http://www.w3.org/2000/svg; 
xmlns:xlink="http://www.w3.org/1999/xlink; version="1.1" width="701px" 
height="461px" viewBox="-0.5 -0.5 701 461" content="mxfile 
modified=2019-08-04T17:05:55.267Z host= 
agent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like 
Gecko) draw.io/11.1.1 Chrome/76.0.3809.88 Electron/6.0.0 Safari/537.36 
etag=M7ISh4Ny83I7m1UfK1F2 version=11.1.1 
type=devicediagram id=7q-U8ZVDCMAbtjTOF8Vq 

[Xen-devel] [PATCH 4/4] docs/sphinx: Technical Debt

[Andrew Cooper]

This identifies various of areas technical debt, which either need to be, or
are being worked on, along with enough clarifying details for people to
follow.

Signed-off-by: Andrew Cooper 
---
CC: Lars Kurth 
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
CC: Julien Grall 
CC: Roger Pau Monné 
---
 docs/conf.py|  11 +++-
 docs/index.rst  |   8 +++
 docs/misc/tech-debt.rst | 130 
 3 files changed, 148 insertions(+), 1 deletion(-)
 create mode 100644 docs/misc/tech-debt.rst

diff --git a/docs/conf.py b/docs/conf.py
index 50e41501db..0d2227f52e 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -53,7 +53,7 @@
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
-extensions = []
+extensions = ['sphinx.ext.extlinks']
 
 # Add any paths that contain templates here, relative to this directory.
 templates_path = ['_templates']
@@ -192,3 +192,12 @@
 
 # A list of files that should not be packed into the epub file.
 epub_exclude_files = ['search.html']
+
+
+# -- Configuration for external links 
+
+extlinks = {
+'xen-cs':
+('https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=%s',
+ 'Xen c/s '),
+}
diff --git a/docs/index.rst b/docs/index.rst
index b8ab13178c..0a2af2db9d 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -59,3 +59,11 @@ Miscellanea
 .. toctree::
 
glossary
+
+Unsorted
+
+
+.. toctree::
+   :maxdepth: 2
+
+   misc/tech-debt
diff --git a/docs/misc/tech-debt.rst b/docs/misc/tech-debt.rst
new file mode 100644
index 00..172ba3bd51
--- /dev/null
+++ b/docs/misc/tech-debt.rst
@@ -0,0 +1,130 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Technical Debt
+==
+
+Hypervisor
+--
+
+CONFIG_PDX
+~~
+
+Xen uses the term MFN for Machine Frame Number, which is synonymous with
+Linux's PFN, and maps linearly to system/host/machine physical addresses.
+
+For every page of RAM, a ``struct page_info`` is needed for tracking purposes.
+In the simple case, the frametable is an array of ``struct page_info[]``
+indexed by MFN.
+
+However, this is inefficient when a system has banks of RAM at spread out in
+address space, as a large amount of space is wasted on frametable entries for
+non-existent frames.  This wastes both virtual address space and RAM.
+
+As a consequence, Xen has a compression scheme known as PDX which removes
+unused bits out of the middle of MFNs, to make a more tightly packed Page
+inDeX, which in turn reduces the size of the frametable for system.
+
+At the moment, PDX compression is unconditionally used.
+
+However, PDX compression does come with a cost in terms of the complexity to
+convert between PFNs and pages, which is a common operation in Xen.
+
+Typically, ARM32 systems do have RAM banks in discrete locations, and want to
+use PDX compression, while typically ARM64 and x86 systems have RAM packed
+from 0 with no holes.
+
+The goal of this work is to have ``CONFIG_PDX`` selected by ARM32 only.  This
+requires slightly untangling the memory management code in ARM and x86 to give
+it a clean compile boundary where PDX conversions are used.
+
+
+Waitqueue infrastructure
+
+
+Livepatching safety in Xen depends on all CPUs rendezvousing on the return to
+guest path, with no stack frame.  The vCPU waitqueue infrastructure undermines
+this safety by copying a stack frame sideways, and ``longjmp()``\-ing away.
+
+Waitqueues are only used by the introspection/mem_event/paging infrastructure,
+where the design of the rings causes some problems.  There is a single 4k page
+used for the ring, which serves both synchronous requests, and lossless async
+requests.  In practice, introspecting an 11-vcpu guest is sufficient to cause
+the waitqueue infrastructure to start to be used.
+
+A better design of ring would be to have a slot per vcpu for synchronous
+requests (simplifies producing and consuming of requests), and a multipage
+ring buffer (of negotiable size) with lossy semantics for async requests.
+
+A design such as this would guarantee that Xen never has to block waiting for
+userspace to create enough space on the ring for a vcpu to write state out.
+
+.. note::
+
+   There are other aspects of the existing ring infrastructure which are
+   driving a redesign, but these don't relate directly to the waitqueue
+   infrastructure and livepatching safety.
+
+   The most serious problem is that the ring infrastructure is GFN based,
+   which leaves the guest either able to mess with the ring, or a shattered
+   host superpage where the ring used to be, and the guest balloon driver able
+   to prevent the introspection agent from connecting/reconnecting the ring.
+
+As there are multiple compelling reasons to redesign the ring 

[Xen-devel] [PATCH 1/4] docs/sphinx: License content with CC-BY-4.0

[Andrew Cooper]

Creative Commons is a more common license than GPL for documentation purposes.
Switch to using CC-BY-4.0 to explicitly permit re-purposing and remixing of
the content.

Signed-off-by: Andrew Cooper 
---
CC: Lars Kurth 
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
CC: Julien Grall 
CC: Rich Persaud 
CC: Juergen Gross 
---
 COPYING |  3 +++
 docs/README.source  | 32 
 docs/admin-guide/index.rst  |  2 ++
 docs/admin-guide/microcode-loading.rst  |  2 ++
 docs/conf.py|  1 +
 docs/guest-guide/index.rst  |  2 ++
 docs/guest-guide/x86/hypercall-abi.rst  |  2 ++
 docs/guest-guide/x86/index.rst  |  2 ++
 docs/hypervisor-guide/code-coverage.rst |  2 ++
 docs/hypervisor-guide/index.rst |  2 ++
 docs/index.rst  |  2 ++
 11 files changed, 52 insertions(+)
 create mode 100644 docs/README.source

diff --git a/COPYING b/COPYING
index 310fd52c27..80fac091d3 100644
--- a/COPYING
+++ b/COPYING
@@ -47,6 +47,9 @@ various drivers, support functions and header files within 
Xen-aware
 Linux source trees. In all such cases, license terms are stated at the
 top of the file or in a COPYING file in the same directory.
 
+Sphinx documentation is licensed under CC-BY 4.0.  See
+docs/README.source for more specific information.
+
 In some cases, compatible 3rd party code has been imported into the
 Xen tree, retaining the original license, such as
   - AES-128 3.0
diff --git a/docs/README.source b/docs/README.source
new file mode 100644
index 00..f20fa92c28
--- /dev/null
+++ b/docs/README.source
@@ -0,0 +1,32 @@
+Sphinx documentation:
+
+All source rendered by Sphinx is licensed under CC-BY-4.0.
+
+You are free to:
+  Share:
+Copy and redistribute the material in any medium or format.
+  Adapt:
+Remix, transform, and build upon the material for any purpose, even
+commercially.
+
+Under the following terms:
+  Attribution:
+You must give appropriate credit, provide a link to the license, and
+indicate if changes were made. You may do so in any reasonable manner, but
+not in any way that suggests the licensor endorses you or your use.
+  No additional restrictions:
+You may not apply legal terms or technological measures that legally
+restrict others from doing anything the license permits.
+
+See https://creativecommons.org/licenses/by/4.0/ for full details.
+
+This includes:
+  * All ReStructured Text files:  docs/*/*.rst
+  * The Sphinx configuration file:docs/conf.py
+  * Content in Sphinx-exclusive subdirs:  docs/*-guide/*
+
+
+Other documentation:
+
+There are a variety of text documents in various formats.  These, given no
+explicit license guidance, fall under Xen's default GPL-2.0 license.
diff --git a/docs/admin-guide/index.rst b/docs/admin-guide/index.rst
index f725d75ebe..ad1f508a79 100644
--- a/docs/admin-guide/index.rst
+++ b/docs/admin-guide/index.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
 Admin Guide
 ===
 
diff --git a/docs/admin-guide/microcode-loading.rst 
b/docs/admin-guide/microcode-loading.rst
index 1858ed4627..8265b917a9 100644
--- a/docs/admin-guide/microcode-loading.rst
+++ b/docs/admin-guide/microcode-loading.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
 Microcode Loading
 =
 
diff --git a/docs/conf.py b/docs/conf.py
index 73b7b9bfa2..50e41501db 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -1,4 +1,5 @@
 # -*- coding: utf-8 -*-
+# SPDX-License-Identifier: CC-BY-4.0
 #
 # Configuration file for the Sphinx documentation builder.
 #
diff --git a/docs/guest-guide/index.rst b/docs/guest-guide/index.rst
index 108e0b8d77..03c5b37bd1 100644
--- a/docs/guest-guide/index.rst
+++ b/docs/guest-guide/index.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
 Guest documentation
 ===
 
diff --git a/docs/guest-guide/x86/hypercall-abi.rst 
b/docs/guest-guide/x86/hypercall-abi.rst
index dee25853d4..edb10b1b2e 100644
--- a/docs/guest-guide/x86/hypercall-abi.rst
+++ b/docs/guest-guide/x86/hypercall-abi.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
 Hypercall ABI
 =
 
diff --git a/docs/guest-guide/x86/index.rst b/docs/guest-guide/x86/index.rst
index a368392087..121cddca62 100644
--- a/docs/guest-guide/x86/index.rst
+++ b/docs/guest-guide/x86/index.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
 x86
 ===
 
diff --git a/docs/hypervisor-guide/code-coverage.rst 
b/docs/hypervisor-guide/code-coverage.rst
index 6c7552d691..641aac25fc 100644
--- a/docs/hypervisor-guide/code-coverage.rst
+++ b/docs/hypervisor-guide/code-coverage.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
 Code Coverage
 =
 
diff --git a/docs/hypervisor-guide/index.rst b/docs/hypervisor-guide/index.rst

[Xen-devel] [PATCH for-4.13 0/4] docs/sphinx

[Andrew Cooper]

Various pieces of Sphinx documentation improvements intended for inclusion
into Xen 4.13.  Rendered results can be viewed at

  https://andrewcoop-xen.readthedocs.io/en/docs-devel/index.html

with

  
https://andrewcoop-xen.readthedocs.io/en/docs-devel/admin-guide/introduction.html
  https://andrewcoop-xen.readthedocs.io/en/docs-devel/glossary.html
  https://andrewcoop-xen.readthedocs.io/en/docs-devel/misc/tech-debt.html

being the notable additions from this series.

Andrew Cooper (4):
  docs/sphinx: License content with CC-BY-4.0
  docs/sphinx: Indent cleanup
  docs/sphinx: Introduction
  docs/sphinx: Technical Debt

 COPYING  |   3 +
 docs/README.source   |  32 
 docs/admin-guide/index.rst   |   5 +-
 docs/admin-guide/introduction.rst|  40 ++
 docs/admin-guide/microcode-loading.rst   |   2 +
 docs/admin-guide/xen-overview.drawio.svg |  97 +++
 docs/conf.py |  12 ++-
 docs/glossary.rst|  52 +
 docs/guest-guide/index.rst   |   6 +-
 docs/guest-guide/x86/hypercall-abi.rst   |  52 +++--
 docs/guest-guide/x86/index.rst   |   6 +-
 docs/hypervisor-guide/code-coverage.rst  |   6 +-
 docs/hypervisor-guide/index.rst  |   6 +-
 docs/index.rst   |  38 +++--
 docs/misc/tech-debt.rst  | 130 +++
 15 files changed, 444 insertions(+), 43 deletions(-)
 create mode 100644 docs/README.source
 create mode 100644 docs/admin-guide/introduction.rst
 create mode 100644 docs/admin-guide/xen-overview.drawio.svg
 create mode 100644 docs/glossary.rst
 create mode 100644 docs/misc/tech-debt.rst

-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 2/4] docs/sphinx: Indent cleanup

[Andrew Cooper]

Sphinx, its linters, and RST modes in common editors, expect 3 spaces of
indentation.  Some bits already conform to this expectation.  Update the
rest to match.

Signed-off-by: Andrew Cooper 
---
CC: Lars Kurth 
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
CC: Julien Grall 
CC: Juergen Gross 
---
 docs/admin-guide/index.rst  |  2 +-
 docs/guest-guide/index.rst  |  4 +--
 docs/guest-guide/x86/hypercall-abi.rst  | 50 -
 docs/guest-guide/x86/index.rst  |  4 +--
 docs/hypervisor-guide/code-coverage.rst |  4 +--
 docs/hypervisor-guide/index.rst |  4 +--
 docs/index.rst  | 16 +--
 7 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/docs/admin-guide/index.rst b/docs/admin-guide/index.rst
index ad1f508a79..1da7c8bf4d 100644
--- a/docs/admin-guide/index.rst
+++ b/docs/admin-guide/index.rst
@@ -4,4 +4,4 @@ Admin Guide
 ===
 
 .. toctree::
-  microcode-loading
+   microcode-loading
diff --git a/docs/guest-guide/index.rst b/docs/guest-guide/index.rst
index 03c5b37bd1..5455c67479 100644
--- a/docs/guest-guide/index.rst
+++ b/docs/guest-guide/index.rst
@@ -4,6 +4,6 @@ Guest documentation
 ===
 
 .. toctree::
-  :maxdepth: 2
+   :maxdepth: 2
 
-  x86/index
+   x86/index
diff --git a/docs/guest-guide/x86/hypercall-abi.rst 
b/docs/guest-guide/x86/hypercall-abi.rst
index edb10b1b2e..14c48929d7 100644
--- a/docs/guest-guide/x86/hypercall-abi.rst
+++ b/docs/guest-guide/x86/hypercall-abi.rst
@@ -14,22 +14,22 @@ Registers
 The registers used for hypercalls depends on the operating mode of the guest.
 
 .. list-table::
-  :header-rows: 1
+   :header-rows: 1
 
-  * - ABI
-- Hypercall Index
-- Parameters (1 - 6)
-- Result
+   * - ABI
+ - Hypercall Index
+ - Parameters (1 - 6)
+ - Result
 
-  * - 64bit
-- RAX
-- RDI RSI RDX R10 R8 R9
-- RAX
+   * - 64bit
+ - RAX
+ - RDI RSI RDX R10 R8 R9
+ - RAX
 
-  * - 32bit
-- EAX
-- EBX ECX EDX ESI EDI EBP
-- EAX
+   * - 32bit
+ - EAX
+ - EBX ECX EDX ESI EDI EBP
+ - EAX
 
 32 and 64bit PV guests have an ABI fixed by their guest type.  The ABI for an
 HVM guest depends on whether the vCPU is operating in a 64bit segment or not
@@ -53,22 +53,22 @@ The exact sequence of instructions required to issue a 
hypercall differs
 between virtualisation mode and hardware vendor.
 
 .. list-table::
-  :header-rows: 1
+   :header-rows: 1
 
-  * - Guest
-- Transfer instruction
+   * - Guest
+ - Transfer instruction
 
-  * - 32bit PV
-- INT 0x82
+   * - 32bit PV
+ - INT 0x82
 
-  * - 64bit PV
-- SYSCALL
+   * - 64bit PV
+ - SYSCALL
 
-  * - Intel HVM
-- VMCALL
+   * - Intel HVM
+ - VMCALL
 
-  * - AMD HVM
-- VMMCALL
+   * - AMD HVM
+ - VMMCALL
 
 To abstract away the details, Xen implements an interface known as the
 Hypercall Page.  This allows a guest to make a hypercall without needing to
@@ -91,7 +91,7 @@ To invoke a specific hypercall, ``call`` the relevant stub 
[3]_:
 
 .. code-block:: none
 
-  call hypercall_page + index * 32
+   call hypercall_page + index * 32
 
 There result is an ABI which is invariant of the exact operating mode or
 hardware vendor.  This is intended to simplify guest kernel interfaces by
diff --git a/docs/guest-guide/x86/index.rst b/docs/guest-guide/x86/index.rst
index 121cddca62..502968490d 100644
--- a/docs/guest-guide/x86/index.rst
+++ b/docs/guest-guide/x86/index.rst
@@ -4,6 +4,6 @@ x86
 ===
 
 .. toctree::
-  :maxdepth: 2
+   :maxdepth: 2
 
-  hypercall-abi
+   hypercall-abi
diff --git a/docs/hypervisor-guide/code-coverage.rst 
b/docs/hypervisor-guide/code-coverage.rst
index 641aac25fc..49c4a8ad3b 100644
--- a/docs/hypervisor-guide/code-coverage.rst
+++ b/docs/hypervisor-guide/code-coverage.rst
@@ -10,8 +10,8 @@ so some extra steps are required to collect and process the 
data.
 
 .. warning::
 
-  ARM doesn't currently boot when the final binary exceeds 2MB in size,
-  and the coverage build tends to exceed this limit.
+   ARM doesn't currently boot when the final binary exceeds 2MB in size,
+   and the coverage build tends to exceed this limit.
 
 
 Compiling Xen
diff --git a/docs/hypervisor-guide/index.rst b/docs/hypervisor-guide/index.rst
index 7ba37b6e54..8ea8fcb145 100644
--- a/docs/hypervisor-guide/index.rst
+++ b/docs/hypervisor-guide/index.rst
@@ -4,6 +4,6 @@ Hypervisor documentation
 
 
 .. toctree::
-  :maxdepth: 2
+   :maxdepth: 2
 
-  code-coverage
+   code-coverage
diff --git a/docs/index.rst b/docs/index.rst
index 7bd9955a97..7b441c4180 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -5,8 +5,8 @@ The Xen Hypervisor documentation
 
 .. note::
 
-  Xen's Sphinx/RST documentation is a work in progress.  The existing
-  documentation can be found at https://xenbits.xen.org/docs/
+   Xen's Sphinx/RST 

Re: [Xen-devel] Errors with Loading Xen at a Certain Address

[Brian Woods]

On Thu, Oct 03, 2019 at 07:23:23PM +, Julien Grall wrote:
> Hi,
> 
> On 03/10/2019 19:15, Brian Woods wrote:
> > On Thu, Oct 03, 2019 at 06:08:45PM +0100, Julien Grall wrote:
> > (XEN) BW_DEBUG: .6 count_info=0x
> > (XEN) Domain heap initialised
> > (XEN) BW_DEBUG: 01 count_info=0x0180
> > 
> > Those debug messages sandwich end_boot_allocator() in start_xen().
> 
> hmmm, looking back at the thread, the WARN_ON() I suggested is actually 
> incorrect. :/ Sorry for that. It should be:
> 
> WARN_ON(mfn_x(page_to_mfn(pg + i)) == 0x01533);
> 
> Note the "i" instead of "1".
> 
> If the WARN_ON() is triggered between the two calls, then it would mean 
> we are giving page to the boot allocator.
> 
> This would imply that next_modules() or dt_unreserved_regions() is not 
> working as expected (i.e. carving out any modules).
> 
> Also, could you send your log with early printk enabled?
> 
> Cheers,
> 
> -- 
> Julien Grall

Attached are the log and diff.

There's a WARN_ON() between the two debug printks calls I shared above.

-- 
Brian Woods
PMU Firmware 2019.1 May 25 2019   06:57:33
PMU_ROM Version: xpbr-v8.1.0-0
NOTICE:  ATF running on XCZUUNKN/QEMU v4/RTL0.0 at 0xfffea000
NOTICE:  BL31: Secure code at 0x6000
NOTICE:  BL31: Non secure code at 0x1008
NOTICE:  BL31: v2.0(release):xilinx-v2018.3-720-g80d1c790
NOTICE:  BL31: Built : 06:54:23, May 25 2019
PMUFW:  v1.1


U-Boot 2019.01 (May 25 2019 - 06:55:09 +)

Model: ZynqMP ZCU102 Rev1.0
Board: Xilinx ZynqMP
DRAM:  4 GiB
EL Level:   EL2
Chip ID:unknown
MMC:   mmc@ff17: 0
Loading Environment from SPI Flash... SF: Detected n25q512a with page size 512 
Bytes, erase size 128 KiB, total 128 MiB
*** Warning - bad CRC, using default environment

In:serial@ff00
Out:   serial@ff00
Err:   serial@ff00
Model: ZynqMP ZCU102 Rev1.0
Board: Xilinx ZynqMP
Bootmode: JTAG_MODE
Reset reason:   EXTERNAL 
Net:   ZYNQ GEM: ff0e, phyaddr c, interface rgmii-id
eth0: ethernet@ff0e
U-BOOT for xilinx-zcu102-2019_1

BOOTP broadcast 1
DHCP client bound to address 10.0.5.15 (2 ms)
Hit any key to stop autoboot:  4  3  0 
ZynqMP> setenv serverip 10.0.5.2; tftpb 128 xen-qemu-mod.dtb; tftpb 0x8 
yocto-Image; tftpb 140 xen-custom.ub; tftpb 900 
yocto-rootfs.cpio.gz.ub; bootm 140 900 128 
Using ethernet@ff0e device
TFTP from server 10.0.5.2; our IP address is 10.0.5.15
Filename 'xen-qemu-mod.dtb'.
Load address: 0x128
Loading: *###
 6 MiB/s
done
Bytes transferred = 38019 (9483 hex)
Using ethernet@ff0e device
TFTP from server 10.0.5.2; our IP address is 10.0.5.15
Filename 'yocto-Image'.
Load address: 0x8
Loading: *#
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 36.6 MiB/s
done
Bytes transferred = 18215424 (115f200 hex)
Using ethernet@ff0e device
TFTP from server 10.0.5.2; our IP address is 10.0.5.15
Filename 'xen-custom.ub'.
Load address: 0x140
Loading: *#
 
 22.4 MiB/s
done
Bytes transferred = 984464 (f0590 hex)
Using ethernet@ff0e device
TFTP from server 10.0.5.2; our IP address is 10.0.5.15
Filename 'yocto-rootfs.cpio.gz.ub'.
Load address: 0x900
Loading: *#
 #
 #
 #
 

Re: [Xen-devel] Errors with Loading Xen at a Certain Address

[Julien Grall]

Hi,

On 03/10/2019 19:15, Brian Woods wrote:
> On Thu, Oct 03, 2019 at 06:08:45PM +0100, Julien Grall wrote:
> (XEN) BW_DEBUG: .6 count_info=0x
> (XEN) Domain heap initialised
> (XEN) BW_DEBUG: 01 count_info=0x0180
> 
> Those debug messages sandwich end_boot_allocator() in start_xen().

hmmm, looking back at the thread, the WARN_ON() I suggested is actually 
incorrect. :/ Sorry for that. It should be:

WARN_ON(mfn_x(page_to_mfn(pg + i)) == 0x01533);

Note the "i" instead of "1".

If the WARN_ON() is triggered between the two calls, then it would mean 
we are giving page to the boot allocator.

This would imply that next_modules() or dt_unreserved_regions() is not 
working as expected (i.e. carving out any modules).

Also, could you send your log with early printk enabled?

Cheers,

-- 
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Errors with Loading Xen at a Certain Address

[Brian Woods]

On Thu, Oct 03, 2019 at 06:08:45PM +0100, Julien Grall wrote:
> Hi,
> 
> On 03/10/2019 00:20, Brian Woods wrote:
> >On Wed, Oct 02, 2019 at 02:22:49PM -0700, Brian Woods wrote:
> >>That's odd.  I know I copied your and Stefano's email addresses from the
> >>MAINTAINERS file but under my sent emails it shows it has having no
> >>CCs...  PEBCAK I guess.  My apologies.
> >>
> >>I'll go ahead add those and see if that leads to anything.
> >>
> >>-- 
> >>Brian Woods
> >
> >Ok, I added:
> > printk("BW_DEBUG: 01 count_info=0x%016lx\n",
> > mfn_to_page(_mfn(0x01533))->count_info);
> >In some places.  I'm not sure about some of the earlier ones (the ones
> >before the UART is set up),  but all of the ones afterwards that
> >actually get output are:
> > BW_DEBUG: 11 count_info=0x0180
> >
> >Is it worth trying to figure out where the printk buffer is and reading
> >it really early on?
> >
> 
> If you haven't enable EARLY_PRINTK in Xen, then you may want to do it. This
> would help you to understand where the page->count_info is not zeroed.
> 
> 
> Cheers,
> 
> -- 
> Julien Grall

Ah, I'm not used to some of the Arm-isms in Xen yet.

(XEN) BW_DEBUG: .6 count_info=0x
(XEN) Domain heap initialised
(XEN) BW_DEBUG: 01 count_info=0x0180

Those debug messages sandwich end_boot_allocator() in start_xen().

-- 
Brian Woods

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2] x86/xen: Return from panic notifier

[Boris Ostrovsky]

Currently execution of panic() continues until Xen's panic notifier
(xen_panic_event()) is called at which point we make a hypercall that
never returns.

This means that any notifier that is supposed to be called later as
well as significant part of panic() code (such as pstore writes from
kmsg_dump()) is never executed.

There is no reason for xen_panic_event() to be this last point in
execution since panic()'s emergency_restart() will call into
xen_emergency_restart() from where we can perform our hypercall.

Nevertheless, we will provide xen_legacy_crash boot option that will
preserve original behavior during crash. This option could be used,
for example, if running kernel dumper (which happens after panic
notifiers) is undesirable.

Reported-by: James Dingwall 
Signed-off-by: Boris Ostrovsky 
---

v2: Added xen_legacy_crash boot option to preserve current behaviour. My
earlier suggestion to create an external dumper (for Xen toolstack)
had some corner cases and dealing with them was becoming too much logic
for my taste.


 .../admin-guide/kernel-parameters.txt |  4 +++
 arch/x86/xen/enlighten.c  | 28 +--
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 4c1971960afa..5ea005c9e2d6 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5267,6 +5267,10 @@
the unplug protocol
never -- do not unplug even if version check succeeds
 
+   xen_legacy_crash[X86,XEN]
+   Crash from Xen panic notifier, without executing late
+   panic() code such as dumping handler.
+
xen_nopvspin[X86,XEN]
Disables the ticketlock slowpath using Xen PV
optimizations.
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 750f46ad018a..205b1176084f 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -269,19 +269,41 @@ void xen_reboot(int reason)
BUG();
 }
 
+static int reboot_reason = SHUTDOWN_reboot;
+static bool xen_legacy_crash;
 void xen_emergency_restart(void)
 {
-   xen_reboot(SHUTDOWN_reboot);
+   xen_reboot(reboot_reason);
 }
 
 static int
 xen_panic_event(struct notifier_block *this, unsigned long event, void *ptr)
 {
-   if (!kexec_crash_loaded())
-   xen_reboot(SHUTDOWN_crash);
+   if (!kexec_crash_loaded()) {
+   if (xen_legacy_crash)
+   xen_reboot(SHUTDOWN_crash);
+
+   reboot_reason = SHUTDOWN_crash;
+
+   /*
+* If panic_timeout==0 then we are supposed to wait forever.
+* However, to preserve original dom0 behavior we have to drop
+* into hypervisor. (domU behavior is controlled by its
+* config file)
+*/
+   if (panic_timeout == 0)
+   panic_timeout = -1;
+   }
return NOTIFY_DONE;
 }
 
+static int __init parse_xen_legacy_crash(char *arg)
+{
+   xen_legacy_crash = true;
+   return 0;
+}
+early_param("xen_legacy_crash", parse_xen_legacy_crash);
+
 static struct notifier_block xen_panic_block = {
.notifier_call = xen_panic_event,
.priority = INT_MIN
-- 
2.17.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC for-4.13 03/10] xen/arm: traps: Rework entry/exit from the guest path

[Julien Grall]

Hi,

On 03/10/2019 18:48, Stefano Stabellini wrote:

On Thu, 3 Oct 2019, Julien Grall wrote:

Hi Stefano,

On 02/10/2019 23:26, Stefano Stabellini wrote:

On Wed, 2 Oct 2019, Julien Grall wrote:
That was my reflection on whether it would be a good idea or a bad idea
to have a SERROR check on the fiq hypervisor entries. Not necessarely in
this patch. Probably not in this patch.


If you receive a FIQ exception on Arm64, then you are already doomed because
the hypervisor will crash (see do_bad_mode()). So receiving the SError is
going to be your last concern here.


I realize that Xen is doomed anyway, but if I was the user, I would
still want to know about the SError: it is not going to save the
platform in any way but it might make me realize there is something
wrong with the guest configuration (in addition to the FIQ problem.)


This is not something I am going to look at in the near future. There are more 
concerning problem in arch/arm*/entry.S. Although, patches are welcomed.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC for-4.13 03/10] xen/arm: traps: Rework entry/exit from the guest path

[Stefano Stabellini]

On Thu, 3 Oct 2019, Julien Grall wrote:
> Hi Stefano,
> 
> On 02/10/2019 23:26, Stefano Stabellini wrote:
> > On Wed, 2 Oct 2019, Julien Grall wrote:
> > That was my reflection on whether it would be a good idea or a bad idea
> > to have a SERROR check on the fiq hypervisor entries. Not necessarely in
> > this patch. Probably not in this patch.
> 
> If you receive a FIQ exception on Arm64, then you are already doomed because
> the hypervisor will crash (see do_bad_mode()). So receiving the SError is
> going to be your last concern here.

I realize that Xen is doomed anyway, but if I was the user, I would
still want to know about the SError: it is not going to save the
platform in any way but it might make me realize there is something
wrong with the guest configuration (in addition to the FIQ problem.)

But because there is no way to get a FIQ in Xen, at least on paper, this
is kind of a theoretical exercise.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v8 8/8] xen/arm: add dom0-less device assignment info to docs

[Stefano Stabellini]

On Thu, 3 Oct 2019, Julien Grall wrote:
> Hi Stefano,
> 
> On 03/10/2019 02:35, Stefano Stabellini wrote:
> > Add info about the SPI used for the virtual pl011.
> > 
> > Signed-off-by: Stefano Stabellini 
> > 
> > ---
> > Changes in v8:
> > - remove sentence about xen,path being optional
> > 
> > Changes in v7:
> > - add xen,force-assign-without-iommu
> > - clarify xen,reg and xen,path go together
> > - remove acked-by due to changes
> > 
> > Changes in v6:
> > - fix nr_spis description
> > - add ack
> > 
> > Changes in v5:
> > - improve wording
> > 
> > Changes in v4:
> > - fix spelling
> > - add "multiboot,module"
> > - improve commit message
> > - improve doc
> > - expand the nr_spis and vpl011 sections and include information about
> >the vpl011 SPI
> > - move passthrough information to docs/misc/arm/passthrough.txt
> > 
> > Changes in v3:
> > - add nr_spis
> > - change description of interrupts and interrupt-parent
> > 
> > Changes in v2:
> > - device tree fragment loaded in cacheable memory
> > - rename multiboot,dtb to multiboot,device-tree
> > - rename "path" to "xen,path"
> > - add a note about device memory mapping
> > - introduce xen,reg
> > - specify only the GIC is supported
> > ---
> >   docs/misc/arm/device-tree/booting.txt |  44 ++-
> >   docs/misc/arm/passthrough.txt | 106 ++
> >   2 files changed, 149 insertions(+), 1 deletion(-)
> > 
> > diff --git a/docs/misc/arm/device-tree/booting.txt
> > b/docs/misc/arm/device-tree/booting.txt
> > index 317a9e962a..649e00d09f 100644
> > --- a/docs/misc/arm/device-tree/booting.txt
> > +++ b/docs/misc/arm/device-tree/booting.txt
> > @@ -146,7 +146,18 @@ with the following properties:
> > - vpl011
> >   -An empty property to enable/disable a virtual pl011 for the guest to
> > use.
> > +An empty property to enable/disable a virtual pl011 for the guest to
> > +use. The virtual pl011 uses SPI number 0 (see GUEST_VPL011_SPI).
> > +Please note that the SPI used for the virtual pl011 could clash with
> > the
> > +physical SPI of a physical device assigned to the guest.
> > +
> > +- nr_spis
> > +
> > +Optional. A 32-bit integer specifying the number of SPIs (Shared
> > +Peripheral Interrupts) to allocate for the domain. If nr_spis is
> > +missing, the max number of SPIs supported by the physical GIC is
> > +used, or GUEST_VPL011_SPI+1 if vpl011 is enabled, whichever is
> > +greater.
> > - #address-cells and #size-cells
> >   @@ -226,3 +237,34 @@ chosen {
> >   };
> >   };
> >   };
> > +
> > +
> > +Device Assignment
> > +=
> > +
> > +Device Assignment (Passthrough) is supported by adding another module,
> > +alongside the kernel and ramdisk, with the device tree fragment
> > +corresponding to the device node to assign to the guest.
> > +
> > +The dtb sub-node should have the following properties:
> > +
> > +- compatible
> > +
> > +"multiboot,device-tree" and "multiboot,module"
> > +
> > +- reg
> > +
> > +Specifies the physical address of the device tree binary fragment
> > +RAM and its length.
> > +
> > +As an example:
> > +
> > +module@0xc00 {
> > +compatible = "multiboot,device-tree", "multiboot,module";
> > +reg = <0x0 0xc00 0xff>;
> > +};
> > +
> > +The DTB fragment is loaded at 0xc00 in the example above. It should
> > +follow the convention explained in docs/misc/arm/passthrough.txt. The
> > +DTB fragment will be added to the guest device tree, so that the guest
> > +kernel will be able to discover the device.
> > diff --git a/docs/misc/arm/passthrough.txt b/docs/misc/arm/passthrough.txt
> > index 0efbd122de..6826e1f341 100644
> > --- a/docs/misc/arm/passthrough.txt
> > +++ b/docs/misc/arm/passthrough.txt
> > @@ -80,6 +80,112 @@ SPI numbers start from 32, in this example 80 + 32 =
> > 112.
> >   See man [xl.cfg] for the iomem format. The reg property is just a pair
> >   of address, then size numbers, each of them can occupy 1 or 2 cells.
> >   +
> > +Dom0-less Device Passthrough
> > +
> > +
> > +The partial device tree for dom0-less guests should have the following
> > +properties for each node corresponding to a physical device to assign to
> > +the guest:
> > +
> > +- xen,reg
> > +
> > +  The xen,reg property is an array of:
> > +
> > +
> > +
> > +  They specify the physical address and size of the device memory
> > +  ranges together with the corresponding guest address to map them to.
> > +  The size of `phys_addr' and `guest_addr' is determined by
> > +  #address-cells, the size of `size' is determined by #size-cells, of
> > +  the partial device tree.
> > +  The memory will be mapped as device memory in the guest (Device-nGnRE).
> > +
> > +- xen,path
> > +
> > +  A string property representing the path in the host device tree to the
> > +  corresponding device node.
> > +
> > +- xen,force-assign-without-iommu
> > +  If 

Re: [Xen-devel] [PATCH v8 5/8] xen/arm: assign devices to boot domains

[Stefano Stabellini]

On Thu, 3 Oct 2019, Julien Grall wrote:
> Hi Stefano,
> 
> On 03/10/2019 02:35, Stefano Stabellini wrote:
> > Scan the user provided dtb fragment at boot. For each device node, map
> > memory to guests, and route interrupts and setup the iommu.
> > 
> > The memory region to remap is specified by the "xen,reg" property.
> > 
> > The iommu is setup by passing the node of the device to assign on the
> > host device tree. The path is specified in the device tree fragment as
> > the "xen,path" string property.
> > 
> > The interrupts are remapped based on the information from the
> > corresponding node on the host device tree. Call
> > handle_device_interrupts to remap interrupts. Interrupts related device
> > tree properties are copied from the device tree fragment, same as all
> > the other properties.
> > 
> > Require both xen,reg and xen,path to be present, unless
> > xen,force-assign-without-iommu is also set. In that case, tolerate a
> > missing xen,path, also tolerate iommu setup failure for the passthrough
> > device.
> > 
> > Also set add the new flag XEN_DOMCTL_CDF_iommu so that dom0less domU
> > can use the IOMMU if a partial dtb is specified.
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> > Changes in v8:
> > - better in-code comment
> > - code style
> > - add a prink in case of error
> > 
> > Changes in v7:
> > - improve in-code comment
> > - code style
> > - return 1 instead of ENOENT
> > - introduce "xen,force-assign-without-iommu"
> > - require both "xen,reg" and "xen,path" unless
> >"xen,force-assign-without-iommu"
> > 
> > Changes in v6:
> > - turn dprintks into printks
> > - return error on page alignment check failure
> > - set XEN_DOMCTL_CDF_iommu if partial dtb is specified
> > 
> > Changes in v5:
> > - use local variable for name
> > - use map_regions_p2mt
> > - add warning for not page aligned addresses/sizes
> > - introduce handle_passthrough_prop
> > 
> > Changes in v4:
> > - use unsigned
> > - improve commit message
> > - code style
> > - use dt_prop_cmp
> > - use device_tree_get_reg
> > - don't copy over xen,reg and xen,path
> > - don't create special interrupt properties for domU: copy them from the
> >fragment
> > - in-code comment
> > 
> > Changes in v3:
> > - improve commit message
> > - remove superfluous cast
> > - merge code with the copy code
> > - add interrup-parent
> > - demove depth > 2 check
> > - reuse code from handle_device_interrupts
> > - copy interrupts from host dt
> > 
> > Changes in v2:
> > - rename "path" to "xen,path"
> > - grammar fix
> > - use gaddr_to_gfn and maddr_to_mfn
> > - remove depth <= 2 limitation in scanning the dtb fragment
> > - introduce and parse xen,reg
> > - code style
> > - support more than one interrupt per device
> > - specify only the GIC is supported
> > ---
> >   xen/arch/arm/domain_build.c | 139 ++--
> >   1 file changed, 135 insertions(+), 4 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 84b65b8f25..b90902ad97 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1714,6 +1714,88 @@ static int __init make_vpl011_uart_node(struct
> > kernel_info *kinfo)
> >   }
> >   #endif
> >   +/*
> > + * Scan device tree properties for passthrough specific information.
> > + * Returns < 0 on error
> > + * 0 on success
> > + */
> > +static int __init handle_passthrough_prop(struct kernel_info *kinfo,
> > +  const struct fdt_property
> > *xen_reg,
> > +  const struct fdt_property
> > *xen_path,
> > +  bool xen_force,
> > +  uint32_t address_cells, uint32_t
> > size_cells)
> > +{
> > +const __be32 *cell;
> > +unsigned int i, len;
> > +struct dt_device_node *node;
> > +int res;
> > +paddr_t mstart, size, gstart;
> > +
> > +/* xen,reg specifies where to map the MMIO region */
> > +cell = (const __be32 *)xen_reg->data;
> > +len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
> > +sizeof(uint32_t));
> > +
> > +for ( i = 0; i < len; i++ )
> > +{
> > +device_tree_get_reg(, address_cells, size_cells,
> > +, );
> > +gstart = dt_next_cell(address_cells, );
> > +
> > +if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size &
> > ~PAGE_MASK )
> > +{
> > +printk(XENLOG_ERR
> > +"DomU passthrough config has not page aligned
> > addresses/sizes\n");
> > +return -EINVAL;
> > +}
> > +
> > +res = map_regions_p2mt(kinfo->d,
> > +   gaddr_to_gfn(gstart),
> > +   PFN_DOWN(size),
> > +   maddr_to_mfn(mstart),
> > +   p2m_mmio_direct_dev);
> > 

Re: [Xen-devel] [PATCH v8 5/8] xen/arm: assign devices to boot domains

[Stefano Stabellini]

On Thu, 3 Oct 2019, Julien Grall wrote:
> Hi Stefano,
> 
> A couple of comments below, mostly because I wasn't clear enough on the
> previous version. I am not sure if it is worth resending the series, maybe
> just resending this one would be sufficient?
> 
> On 03/10/2019 02:35, Stefano Stabellini wrote:
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 84b65b8f25..b90902ad97 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1714,6 +1714,88 @@ static int __init make_vpl011_uart_node(struct
> > kernel_info *kinfo)
> >   }
> >   #endif
> >   +/*
> > + * Scan device tree properties for passthrough specific information.
> > + * Returns < 0 on error
> > + * 0 on success
> > + */
> > +static int __init handle_passthrough_prop(struct kernel_info *kinfo,
> > +  const struct fdt_property
> > *xen_reg,
> > +  const struct fdt_property
> > *xen_path,
> > +  bool xen_force,
> > +  uint32_t address_cells, uint32_t
> > size_cells)
> > +{
> > +const __be32 *cell;
> > +unsigned int i, len;
> > +struct dt_device_node *node;
> > +int res;
> > +paddr_t mstart, size, gstart;
> > +
> > +/* xen,reg specifies where to map the MMIO region */
> > +cell = (const __be32 *)xen_reg->data;
> > +len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
> > +sizeof(uint32_t));
> 
> Apologies for this, I misread you previous code. I am happy with this version
> or the previous one.
> 
> [...]
> 
> > +/*
> > + * Only handle passthrough properties if both xen,reg and xen,path
> > + * are present, or if xen,force-assign-without-iommu is specified.
> > + */
> > +if ( xen_reg != NULL && (xen_path != NULL || xen_force) )
> > +{
> > +res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force,
> > +  address_cells, size_cells);
> > +if ( res < 0 )
> > +{
> > +printk(XENLOG_ERR "Failed to assign device to %pd\n",
> > kinfo->d);
> 
> This is not the error path I meant.
> 
> The one I was referring is the case where xen,path is present but not xen,reg.
> At the moment you will continue without telling the user. We should at least
> print a warning and probably return an error as someone specifying "xen,path"
> may expect to assign the device.

Are you OK with me adding the following:

else if ( (xen_path && !xen_reg) || (xen_reg && !xen_path && !xen_force) )
{
printk(XENLOG_ERR "xen,reg or xen,path missing for %pd\n",
   kinfo->d);
return -EINVAL;
}


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Errors with Loading Xen at a Certain Address

[Julien Grall]

Hi,

On 03/10/2019 00:20, Brian Woods wrote:

On Wed, Oct 02, 2019 at 02:22:49PM -0700, Brian Woods wrote:

On Wed, Oct 02, 2019 at 08:59:28PM +0100, Julien Grall wrote:

Hi,

On 10/2/19 7:56 PM, Brian Woods wrote:

Hmmm, the first e-mail didn't land in my inbox directly (I have a filter
send to a separate directory any e-mail I not CCed on). Did you BCC me by
any change?

That's odd.  I know I copied your and Stefano's email addresses from the
MAINTAINERS file but under my sent emails it shows it has having no
CCs...  PEBCAK I guess.  My apologies.


Let see try to troubleshoot it first :).

Well, any attachment you send on the ML will store to each subscribers
mailbox. I let you do the math here ;)

So yeah, pastebin is always the preferred way when you have to send the full
log.

Thank you for the log. So that's probably not a double-init then.

Looking back at the log, the values look quite sane. So I am not entirely
sure what is happening.

I would check that the frametable is correctly zeroed. You could add a print
at the end of setup_frametable_mappings(...) to dump the count_info for the
page. Something like:
  mfn_to_page(_mfn(0x01533))->count_info;

If it is correctly initialized, it should be zero.

The next step would be to add a similar print in start_xen()
(xen/arch/arm/setup.c) and see where the value is not 0 anymore.

Cheers,

--
Julien Grall


I'll go ahead add those and see if that leads to anything.

--
Brian Woods


Ok, I added:
printk("BW_DEBUG: 01 count_info=0x%016lx\n",
mfn_to_page(_mfn(0x01533))->count_info);
In some places.  I'm not sure about some of the earlier ones (the ones
before the UART is set up),  but all of the ones afterwards that
actually get output are:
BW_DEBUG: 11 count_info=0x0180

Is it worth trying to figure out where the printk buffer is and reading
it really early on?



If you haven't enable EARLY_PRINTK in Xen, then you may want to do it. This 
would help you to understand where the page->count_info is not zeroed.



Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH for-4.13] docs: update all URLs in man pages

[Lars Kurth]

Specifically
* xen.org to xenproject.org
* http to https
* Replaced pages where page has moved
  (including on xen pages as well as external pages)
* Removed some URLs (e.g. downloads for Linux PV drivers)

Tested-by: Lars Kurth 
Signed-off-by: Lars Kurth 
---
 docs/man/xen-pci-device-reservations.7.pod |  2 +-
 docs/man/xen-pv-channel.7.pod  |  2 +-
 docs/man/xen-vtpm.7.pod|  2 +-
 docs/man/xenstore-chmod.1.pod  |  4 ++--
 docs/man/xenstore-ls.1.pod |  4 ++--
 docs/man/xenstore-read.1.pod   |  4 ++--
 docs/man/xenstore-write.1.pod  |  4 ++--
 docs/man/xenstore.1.pod|  4 ++--
 docs/man/xentop.1.pod  |  2 +-
 docs/man/xl-disk-configuration.5.pod   |  4 ++--
 docs/man/xl-network-configuration.5.pod|  8 
 docs/man/xl-numa-placement.7.pod   |  4 ++--
 docs/man/xl.1.pod.in   | 22 +++---
 docs/man/xl.cfg.5.pod.in   | 20 ++--
 docs/man/xl.conf.5.pod |  4 ++--
 docs/man/xlcpupool.cfg.5.pod   |  4 ++--
 16 files changed, 47 insertions(+), 47 deletions(-)

diff --git a/docs/man/xen-pci-device-reservations.7.pod 
b/docs/man/xen-pci-device-reservations.7.pod
index 0df41bcd29..bc7398409c 100644
--- a/docs/man/xen-pci-device-reservations.7.pod
+++ b/docs/man/xen-pci-device-reservations.7.pod
@@ -29,7 +29,7 @@ multiple Xen vendors using conflicting IDs.
 
 =item 3. The vendor is responsible for allocations within the range and should
  try to record specific device IDs in PCI ID databases such as
- http://pciids.sourceforge.net and http//www.pcidatabase.com
+ http://pci-ids.ucw.cz and https://devicehunt.com
 
 =back
 
diff --git a/docs/man/xen-pv-channel.7.pod b/docs/man/xen-pv-channel.7.pod
index 07898f6dde..ab4577d1da 100644
--- a/docs/man/xen-pv-channel.7.pod
+++ b/docs/man/xen-pv-channel.7.pod
@@ -186,4 +186,4 @@ that no-one's name clashes with yours, please add yours to 
this list.
 N: org.xenproject.guest.clipboard.0.1
 C: David Scott 
 D: Share clipboard data via an in-guest agent. See:
-   http://wiki.xenproject.org/wiki/Clipboard_sharing_protocol
+   https://wiki.xenproject.org/wiki/Clipboard_sharing_protocol
diff --git a/docs/man/xen-vtpm.7.pod b/docs/man/xen-vtpm.7.pod
index 1d8185616a..d033072584 100644
--- a/docs/man/xen-vtpm.7.pod
+++ b/docs/man/xen-vtpm.7.pod
@@ -380,4 +380,4 @@ C will copy pcrs 5, 12, 13, 14, 15, and 
16.
 
 =head1 REFERENCES
 
-Berlios TPM Emulator: L
+Berlios TPM Emulator: L
diff --git a/docs/man/xenstore-chmod.1.pod b/docs/man/xenstore-chmod.1.pod
index cb1dc2ef82..d76f34723d 100644
--- a/docs/man/xenstore-chmod.1.pod
+++ b/docs/man/xenstore-chmod.1.pod
@@ -58,5 +58,5 @@ Apply the permissions to the key and all its I.
 
 =head1 BUGS
 
-Send bugs to xen-de...@lists.xen.org, see
-http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
+Send bugs to xen-devel@lists.xenproject.org, see
+https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project on how to 
send bug reports.
diff --git a/docs/man/xenstore-ls.1.pod b/docs/man/xenstore-ls.1.pod
index e04a509fa7..8dac931e94 100644
--- a/docs/man/xenstore-ls.1.pod
+++ b/docs/man/xenstore-ls.1.pod
@@ -58,5 +58,5 @@ Connect to the Xenstore daemon using a local socket only.
 
 =head1 BUGS
 
-Send bugs to xen-de...@lists.xen.org, see
-http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
+Send bugs to xen-devel@lists.xenproject.org, see
+https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project on how to 
send bug reports.
diff --git a/docs/man/xenstore-read.1.pod b/docs/man/xenstore-read.1.pod
index 5496de17a8..f5a7bb7e46 100644
--- a/docs/man/xenstore-read.1.pod
+++ b/docs/man/xenstore-read.1.pod
@@ -28,5 +28,5 @@ Read raw value, skip escaping non-printable characters (\x..).
 
 =head1 BUGS
 
-Send bugs to xen-de...@lists.xen.org, see
-http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
+Send bugs to xen-devel@lists.xenproject.org, see
+https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project on how to 
send bug reports.
diff --git a/docs/man/xenstore-write.1.pod b/docs/man/xenstore-write.1.pod
index 78cbbe1a69..d1b011236a 100644
--- a/docs/man/xenstore-write.1.pod
+++ b/docs/man/xenstore-write.1.pod
@@ -25,5 +25,5 @@ Write raw value, skip parsing escaped characters (\x..).
 
 =head1 BUGS
 
-Send bugs to xen-de...@lists.xen.org, see
-http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
+Send bugs to xen-devel@lists.xenproject.org, see
+https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project on how to 
send bug reports.
diff --git a/docs/man/xenstore.1.pod b/docs/man/xenstore.1.pod
index dd8f80647d..ab9fb4a79c 100644
--- a/docs/man/xenstore.1.pod
+++ b/docs/man/xenstore.1.pod
@@ 

Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm

[Julien Grall]

Hi,

On 03/10/2019 16:55, Volodymyr Babchuk wrote:

Julien Grall writes:


Hi Stefano,

On 10/2/19 2:05 AM, Stefano Stabellini wrote:

On Tue, 24 Sep 2019, Julien Grall wrote:

The documentation is using a mix of ARM (old) and Arm (new). To stay
consistent, use only the new name.


Thank you for the patch, it must have been "not fun" to write this
patch.

However, let me suggest a radical maybe controversial idea. What about
keeping "ARM" instead of switching? There are several advantages: it is
easier to grep, no need to worry about case-sensitivity. It is what
people are used to, and what still use (in my experience at conference
and at work.) Would it make sense to ignore Arm's marketing and keep the
old "ARM" nomenclature?


Pretty much all the new documentation on Arm website are now using Arm
(the spec is now called Arm Arm).

This confuses me, because I believed that second "Arm" stands for
Architecture Reference Manual.
Sorry it is Arm ARM. But they tend to use the longer name Arm Architecture 
Reference Manual.






If not, I'd suggest to also replace "arm" with "Arm" so that at least
with have consistent cases everywhere. But then the pathnames would
remain xen/arch/arm, leading to sentences such as:

   (non-zImage)" protocol described in arm/Booting.
  There are no exception on 64-bit Arm.

With "arm" and "ARM" the distinction was clear between pathnames and
text (at least to me.) With "arm" and "Arm", I know it is silly but it
kind of bothers me :-)


How do you deal with Xilinx then? ;)



I am not going to insist on this one though.


This is quite similar to a company renaming itself (or got acquired
and the name completely disappear) but in a less radical way. Would
you still keep the old name company in your documentation and/or
mixing the both?

BTW, this if what happened with Freescale/NXP. Linux and U-Boot still
use "freescale" even for i.MX8 chips.


Maybe because nobody bothered to do it? I would like some consistency in the 
documentation and hence using the new name makes sense. But I am not bothered 
enough to argue whether we should stay in the past.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-smoke test] 142228: tolerable all pass - PUSHED

[osstest service owner]

flight 142228 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142228/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  e0a66a207465b76b3e45383776a0a1ac0938a56b
baseline version:
 xen  b01b1dc046da70a2621a4d1f032ddb22b0cdde6b

Last test of basis   142217  2019-10-03 10:00:24 Z0 days
Testing same since   142228  2019-10-03 13:01:35 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   b01b1dc046..e0a66a2074  e0a66a207465b76b3e45383776a0a1ac0938a56b -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 v2 2/2] docs: Replace all instance of ARM by Arm

[Volodymyr Babchuk]

Hi Julien,

Julien Grall writes:

> Hi Stefano,
>
> On 10/2/19 2:05 AM, Stefano Stabellini wrote:
>> On Tue, 24 Sep 2019, Julien Grall wrote:
>>> The documentation is using a mix of ARM (old) and Arm (new). To stay
>>> consistent, use only the new name.
>>
>> Thank you for the patch, it must have been "not fun" to write this
>> patch.
>>
>> However, let me suggest a radical maybe controversial idea. What about
>> keeping "ARM" instead of switching? There are several advantages: it is
>> easier to grep, no need to worry about case-sensitivity. It is what
>> people are used to, and what still use (in my experience at conference
>> and at work.) Would it make sense to ignore Arm's marketing and keep the
>> old "ARM" nomenclature?
>
> Pretty much all the new documentation on Arm website are now using Arm
> (the spec is now called Arm Arm).
This confuses me, because I believed that second "Arm" stands for
Architecture Reference Manual.

>>
>> If not, I'd suggest to also replace "arm" with "Arm" so that at least
>> with have consistent cases everywhere. But then the pathnames would
>> remain xen/arch/arm, leading to sentences such as:
>>
>>   (non-zImage)" protocol described in arm/Booting.
>>  There are no exception on 64-bit Arm.
>>
>> With "arm" and "ARM" the distinction was clear between pathnames and
>> text (at least to me.) With "arm" and "Arm", I know it is silly but it
>> kind of bothers me :-)
>
> How do you deal with Xilinx then? ;)
>
>>
>> I am not going to insist on this one though.
>
> This is quite similar to a company renaming itself (or got acquired
> and the name completely disappear) but in a less radical way. Would
> you still keep the old name company in your documentation and/or
> mixing the both?
BTW, this if what happened with Freescale/NXP. Linux and U-Boot still
use "freescale" even for i.MX8 chips.

-- 
Volodymyr Babchuk at EPAM
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH-for-4.13 v2 0/2] libxl: fix assertion failure

[Anthony PERARD]

On Thu, Oct 03, 2019 at 02:30:31PM +0100, Ian Jackson wrote:
> Paul Durrant writes ("Re: [Xen-devel] [PATCH-for-4.13 v2 0/2] libxl: fix 
> assertion failure"):
> > On Wed, 2 Oct 2019 at 17:04, Ian Jackson  wrote:
> > > I am continuing to look at the defaulting and config management here
> > > with a view to getting rid of some of the duplicated code and moving
> > > it all into libxl.
> > 
> > That would indeed be beneficial for the likes of libvirt.
> 
> I propose the following plan for 4.13:
> 
>  * Move the default calculations of b_info->shadow_memkb and
>b_info->iommu_memkb from xl_vmcontrol.c into libxl, in a new
>function libxl__need_memory_setdefault, called from
>initiate_domain_create.  That has access to the whole of c_info and
>b_info.
> 
>  * Change the API/ABI for libxl_domain_need_memory to take a
>libxl_domain_config.  Internally, this will call an implementation
>function libxl__domain_need_memory which takes the b_info and
>c_info separately, and which calls libxl__need_memory_setdefault.
>(This is the only other call site for
>libxl__domain_build_info_setdefault.)
> 
>  * There will be the usual backward compatible arrangement: here, a
>function libxl_domain_need_memory_0x040c00, which will pass NULL
>for c_info.  The code in libxl__need_memory_setdefault will use 0
>for the two additional memory amounts when c_info is NULL.
> 
>  * The overall effect is that old callers will get the old behaviour.
>New callers get the new right behaviour.  This is the same as the
>present libxl 4.13 code.  Note that libxl_domain_need_memory
>already has an API stability caveat.
> 
>  * Consequently, the need for libxl_get_required_shadow_memory and
>libxl_get_required_iommu_memory goes away.  Delete them (they have
>not been in any release so we can just do this).

libxl_get_required_shadow_memory is old, and libvirt is using.
Only libxl_get_required_iommu_memory is new.

>  * Invent a new value for c_info->passthrough "enabled".  Defaulting
>will be 1. turn "unknown" into "disabled" or "enabled" according to
>the current logic based on pcidevs/dtdefs; 2. turn "enabled" into
>something specific according to the current logic based on type,
>hap_pt_share, etc.  Make sure this is all correct inside libxl.
> 
>  * Delete the defaulting code in xl.  xl can just leave settings not
>specified by the user as blank, and libxl will DTRT with them.
> 
> What do people think ?  I really want to fix this for 4.13 because the
> current 4.13 API is not one I want to support.

That plan sound fine to me.

-- 
Anthony PERARD

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH for-4.13] x86/spec-ctrl: Annotate remaining model names

[Andrew Cooper]

The names in retpoline_safe() are copied from should_use_eager_fpu().  The
names in mds_calculations() come partly from Linux's intel-family.h, and
partly from conversations with Intel.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Juergen Gross 

Only comment changes.  0 risk for 4.13
---
 xen/arch/x86/spec_ctrl.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 4761be81bd..731d5a767b 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -505,13 +505,13 @@ static bool __init retpoline_safe(uint64_t caps)
 /*
  * Skylake, Kabylake and Cannonlake processors are not retpoline-safe.
  */
-case 0x4e:
-case 0x55:
-case 0x5e:
-case 0x66:
-case 0x67:
-case 0x8e:
-case 0x9e:
+case 0x4e: /* Skylake M */
+case 0x55: /* Skylake X */
+case 0x5e: /* Skylake D */
+case 0x66: /* Cannonlake */
+case 0x67: /* Cannonlake? */
+case 0x8e: /* Kabylake M */
+case 0x9e: /* Kabylake D */
 return false;
 
 /*
@@ -842,10 +842,10 @@ static __init void mds_calculations(uint64_t caps)
 case 0x4c: /* Cherrytrail / Brasswell */
 case 0x4d: /* Avaton / Rangely (Silvermont) */
 case 0x5a: /* Moorefield */
-case 0x5d:
-case 0x65:
-case 0x6e:
-case 0x75:
+case 0x5d: /* SoFIA 3G Granite/ES2.1 */
+case 0x65: /* SoFIA LTE AOSP */
+case 0x6e: /* Cougar Mountain */
+case 0x75: /* Lightning Mountain */
 /*
  * Knights processors (which are based on the Silvermont/Airmont
  * microarchitecture) are similarly only affected by the Store Buffer
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] I want to participate in Outreachy with CONFIG_PDX related project

[Wei Liu]

On Wed, Oct 02, 2019 at 06:19:44PM +0200, Kateryna Razumova wrote:
> Dear Liu,
> 
> oh, I thought that xen participates in Outreachy in order to get new
> contributors via easing the entrance process.
> But it seems that a potential contributor to xen should already have some
> knowledge of xen (for example, how to find a bug, since there are no issues
> on github and no visible link to bugzilla). I didn't know that!
> I am really sorry for this inconvenience!!!

There is no need to be sorry for anything.

To be clear, we don't assume prior knowledge of Xen. We require interns
to get familiarised with the development process by reading relevant
materials.  After reading the materials they should ask specific
questions about the process.

We used to have a centralised place for easy bugs, but I think most
low-hanging fruits are already gone.  That's why I asked potential
interns to submit patches to fix typos in the hypervisor code base --
just open a file that interests you and see if you find any typos in
comments.  Being able to find and fix a real bug would be nice, but
that's not a hard requirement. The key point is to go through the
development process and interact with the community.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 0/2] EFI GOP fixes

[Igor Druzhinin]

Igor Druzhinin (2):
  efi/boot: fix set_color function
  efi/boot: make sure chosen mode is set even if firmware tell it is

 xen/common/efi/boot.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 1/2] efi/boot: fix set_color function

[Igor Druzhinin]

- 0 is a possible and allowed value for a color mask accroding to
  UEFI Spec 2.6 (11.9) especially for reserved mask
- add missing pointer dereference

Without these changes non-TrueColor modes won't work which will cause
GOP init to fail - observed while trying to boot EFI Xen with Cirrus VGA.

Signed-off-by: Igor Druzhinin 
---
 xen/common/efi/boot.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 9a89414..933db88 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1113,10 +1113,14 @@ static int __init __maybe_unused set_color(u32 mask, 
int bpp, u8 *pos, u8 *sz)
if ( bpp < 0 )
return bpp;
if ( !mask )
-   return -EINVAL;
+   {
+   *pos = 0;
+   *sz = 0;
+   return bpp;
+   }
for ( *pos = 0; !(mask & 1); ++*pos )
mask >>= 1;
-   for ( *sz = 0; mask & 1; ++sz)
+   for ( *sz = 0; mask & 1; ++*sz)
mask >>= 1;
if ( mask )
return -EINVAL;
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 2/2] efi/boot: make sure chosen mode is set even if firmware tell it is

[Igor Druzhinin]

If a bootloader is using native driver instead of EFI GOP it might
reset graphics mode to be different from what firmware thinks it
currently is. Set chosen mode unconditionally to fix this possible
misalignment.

Observed with EFI GRUB2 compiled with all possible video drivers where
native drivers take priority over firmware.

Signed-off-by: Igor Druzhinin 
---
 xen/common/efi/boot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 933db88..4067721 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1052,7 +1052,7 @@ static void __init 
efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN gop
 UINTN info_size;
 
 /* Set graphics mode. */
-if ( gop_mode < gop->Mode->MaxMode && gop_mode != gop->Mode->Mode )
+if ( gop_mode < gop->Mode->MaxMode )
 gop->SetMode(gop, gop_mode);
 
 /* Get graphics and frame buffer info. */
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH-for-4.13 v2 0/2] libxl: fix assertion failure

[Ian Jackson]

Paul Durrant writes ("Re: [Xen-devel] [PATCH-for-4.13 v2 0/2] libxl: fix 
assertion failure"):
> On Wed, 2 Oct 2019 at 17:04, Ian Jackson  wrote:
> > I am continuing to look at the defaulting and config management here
> > with a view to getting rid of some of the duplicated code and moving
> > it all into libxl.
> 
> That would indeed be beneficial for the likes of libvirt.

I propose the following plan for 4.13:

 * Move the default calculations of b_info->shadow_memkb and
   b_info->iommu_memkb from xl_vmcontrol.c into libxl, in a new
   function libxl__need_memory_setdefault, called from
   initiate_domain_create.  That has access to the whole of c_info and
   b_info.

 * Change the API/ABI for libxl_domain_need_memory to take a
   libxl_domain_config.  Internally, this will call an implementation
   function libxl__domain_need_memory which takes the b_info and
   c_info separately, and which calls libxl__need_memory_setdefault.
   (This is the only other call site for
   libxl__domain_build_info_setdefault.)

 * There will be the usual backward compatible arrangement: here, a
   function libxl_domain_need_memory_0x040c00, which will pass NULL
   for c_info.  The code in libxl__need_memory_setdefault will use 0
   for the two additional memory amounts when c_info is NULL.

 * The overall effect is that old callers will get the old behaviour.
   New callers get the new right behaviour.  This is the same as the
   present libxl 4.13 code.  Note that libxl_domain_need_memory
   already has an API stability caveat.

 * Consequently, the need for libxl_get_required_shadow_memory and
   libxl_get_required_iommu_memory goes away.  Delete them (they have
   not been in any release so we can just do this).

 * Invent a new value for c_info->passthrough "enabled".  Defaulting
   will be 1. turn "unknown" into "disabled" or "enabled" according to
   the current logic based on pcidevs/dtdefs; 2. turn "enabled" into
   something specific according to the current logic based on type,
   hap_pt_share, etc.  Make sure this is all correct inside libxl.

 * Delete the defaulting code in xl.  xl can just leave settings not
   specified by the user as blank, and libxl will DTRT with them.

What do people think ?  I really want to fix this for 4.13 because the
current 4.13 API is not one I want to support.

> Perhaps it would be reasonable to unify the create and build info at
> a libxl level (even though they may feed into distinct domctls
> underneath for the moment)?

Yes, but we are probably too late for such an API change at this point
for 4.13.

Thanks,
Ian.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-smoke test] 142217: tolerable all pass - PUSHED

[osstest service owner]

flight 142217 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142217/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  b01b1dc046da70a2621a4d1f032ddb22b0cdde6b
baseline version:
 xen  057a2956212a29377c0f2f6d38e5bec787fb78e4

Last test of basis   142099  2019-10-01 10:09:57 Z2 days
Testing same since   142217  2019-10-03 10:00:24 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Chao Gao 
  Christian Lindig 
  Ian Jackson 
  Igor Druzhinin 
  Jan Beulich 
  Julien Grall 
  Oleksandr Tyshchenko 
  Paul Durrant 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Stefano Stabellini 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   057a295621..b01b1dc046  b01b1dc046da70a2621a4d1f032ddb22b0cdde6b -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] xen/arm: domain_build: Don't expose IOMMU specific properties to the guest

[Oleksandr]

On 01.10.19 22:07, Julien Grall wrote:

Hi Oleksandr,


Hi Julien




On 10/1/19 5:07 PM, Oleksandr wrote:


On 01.10.19 18:36, Julien Grall wrote:

On 01/10/2019 16:25, Oleksandr wrote:


On 01.10.19 18:04, Julien Grall wrote:

> 1. Giving the IOMMU to Dom0 is a bad idea.


Please to try expand your thoughts in the same e-mail when you say 
"this is a bad idea".


Well, this was a conclusion I had got from the discussion [1]. Sorry for 
not being clear here.





But, this is clearly what happen in current Xen setup if the driver is 
not enabled. What I want to avoid is exposing an half complete 
bindings to the guest (you don't know how it will behave).


So we either remove all the properties and node related to the IOMMUs 
or nothing.
I think, I got it. Our target is *not* to add a way for Dom0 to use 
IOMMU, but to be consistent in removing IOMMU node/master device 
properties. Now, we remove the IOMMU node if Xen identifies it (the 
IOMMU driver is present in Xen),
so looks like we have to remove master device properties only if this 
master device is behind the IOMMU which node is removed. This, I hope, 
will avoid exposing an half complete bindings to guest. Am I right?



[1] 
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00858.html



--

If you happy with that logic I will craft a proper patch.


diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 67021d9..6d45e55 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -480,10 +480,26 @@ static int __init write_properties(struct domain 
*d, struct kernel_info *kinfo,

 const struct dt_property *prop, *status = NULL;
 int res = 0;
 int had_dom0_bootargs = 0;
+    struct dt_device_node *iommu_node;

 if ( kinfo->cmdline && kinfo->cmdline[0] )
 bootargs = >cmdline[0];

+    /*
+ * If we skip the IOMMU device when creating DT for Dom0 (even if
+ * the IOMMU device is not used by Xen), we should also skip the IOMMU
+ * specific properties of the master device behind it in order to avoid
+ * exposing an half complete IOMMU bindings to Dom0.
+ * Use "iommu_node" as an indicator of the master device which 
properties

+ * should be skipped.
+ */
+    iommu_node = dt_parse_phandle(node, "iommus", 0);
+    if ( iommu_node )
+    {
+    if ( device_get_class(iommu_node) != DEVICE_IOMMU )
+    iommu_node = NULL;
+    }
+
 dt_for_each_property_node (node, prop)
 {
 const void *prop_data = prop->value;
@@ -540,6 +556,19 @@ static int __init write_properties(struct domain 
*d, struct kernel_info *kinfo,

 continue;
 }

+    if ( iommu_node )
+    {
+    /* Don't expose IOMMU specific properties to Dom0 */
+    if ( dt_property_name_is_equal(prop, "iommus") )
+    continue;
+
+    if ( dt_property_name_is_equal(prop, "iommu-map") )
+    continue;
+
+    if ( dt_property_name_is_equal(prop, "iommu-map-mask") )
+    continue;
+    }
+
 res = fdt_property(kinfo->fdt, prop->name, prop_data, prop_len);

 if ( res )


--
Regards,

Oleksandr Tyshchenko


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 6/6] xen/arm: traps: Mark check_stack_alignment_constraints as unused

[Julien Grall]

Hi Stefano,

On 02/10/2019 23:26, Stefano Stabellini wrote:

On Wed, 2 Oct 2019, Julien Grall wrote:

Clang will throw an error if a function is unused unless you tell
to ignore it. This can be done using __maybe_unused.

While modifying the declaration, update it to match prototype of similar
functions (see build_assertions). This helps to understand that the sole
purpose of the function is to hold BUILD_BUG_ON().

Signed-off-by: Julien Grall 


Same small note about build_assertions becoming __init.


Similar to the previous version this is already implied by "update it to match 
prototype of similar functions".


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] x86/vvmx: Fix the use of RDTSCP when it is intercepted at L0

[Andrew Cooper]

Linux has started using RDTSCP as of v5.1.  This has highlighted a bug in Xen,
where virtual vmexit simply gives up.

  (XEN) d1v1 Unhandled nested vmexit: reason 51
  (XEN) domain_crash called from vvmx.c:2671
  (XEN) Domain 1 (vcpu#1) crashed on cpu#2:

Handle RDTSCP in the virtual vmexit hander in the same was as RDTSC
intercepts.

Reported-by: Sarah Newman 
Signed-off-by: Andrew Cooper 
Tested-by: Chris Brannon 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Juergen Gross 

This probably wants backporting to all stable trees, even though nested virt
isn't supported, and therefore ought to qualify for 4.13 at this point.
---
 xen/arch/x86/hvm/vmx/vvmx.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index fdf449bfd1..6696bd6240 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -2491,6 +2491,7 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs,
 nvcpu->nv_vmexit_pending = 1;
 break;
 case EXIT_REASON_RDTSC:
+case EXIT_REASON_RDTSCP:
 ctrl = __n2_exec_control(v);
 if ( ctrl & CPU_BASED_RDTSC_EXITING )
 nvcpu->nv_vmexit_pending = 1;
@@ -2501,6 +2502,8 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs,
  * avoiding changing guest_tsc and messing up timekeeping in L1
  */
 msr_split(regs, hvm_get_guest_tsc(v) + get_vvmcs(v, TSC_OFFSET));
+if ( exit_reason == EXIT_REASON_RDTSCP )
+regs->rcx = v->arch.msrs->tsc_aux;
 update_guest_eip();
 
 return 1;
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 5/6] xen/arm: mm: Mark check_memory_layout_alignment_constraints as unused

[Julien Grall]

On 02/10/2019 23:26, Stefano Stabellini wrote:

On Wed, 2 Oct 2019, Julien Grall wrote:

Clang will throw an error if a function is unused unless you tell
to ignore it. This can be done using __maybe_unused.

While modifying the declaration, update it to match prototype of similar
functions (see build_assertions). This helps to understand that the sole
purpose of the function is to hold BUILD_BUG_ON().

Signed-off-by: Julien Grall 


I'd like something like "Note that the function is now marked as __init"
to the commit message, but in any case:


This is already implied with "update it to match prototype of similar 
functions".

42sh> grep "build_assertions"



Acked-by: Stefano Stabellini 



---
 Changes in v2:
 - Update the prototype to match style of other functions holding
 on build assertions.
---
  xen/arch/arm/mm.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 9e0fdc39f9..be23acfe26 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -190,7 +190,8 @@ unsigned long total_pages;
  extern char __init_begin[], __init_end[];
  
  /* Checking VA memory layout alignment. */

-static inline void check_memory_layout_alignment_constraints(void) {
+static void __init __maybe_unused build_assertions(void)
+{
  /* 2MB aligned regions */
  BUILD_BUG_ON(XEN_VIRT_START & ~SECOND_MASK);
  BUILD_BUG_ON(FIXMAP_ADDR(0) & ~SECOND_MASK);
--
2.11.0



--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v6.1 08/20] xen/sched: make vcpu_wake() and vcpu_sleep() core scheduling aware

[Dario Faggioli]

On Wed, 2019-10-02 at 15:52 +0100, Julien Grall wrote:
> On 10/2/19 3:43 PM, Juergen Gross wrote:
> > vcpu_wake() and vcpu_sleep() need to be made core scheduling aware:
> > [...]
> > Signed-off-by: Juergen Gross 
> > Reviewed-by: Dario Faggioli 
> 
> Acked-by: Julien Grall 
> 
> Dario, can you confirm you are happy with the slight changes to cater
> Arm?
> 
It's not super pretty, but I think it's good enough for now.

In case it's needed:

Reviewed-by: Dario Faggioli 

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC for-4.13 03/10] xen/arm: traps: Rework entry/exit from the guest path

[Julien Grall]

Hi Stefano,

On 02/10/2019 23:26, Stefano Stabellini wrote:

On Wed, 2 Oct 2019, Julien Grall wrote:
That was my reflection on whether it would be a good idea or a bad idea
to have a SERROR check on the fiq hypervisor entries. Not necessarely in
this patch. Probably not in this patch.


If you receive a FIQ exception on Arm64, then you are already doomed because the 
hypervisor will crash (see do_bad_mode()). So receiving the SError is going to 
be your last concern here.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v8 8/8] xen/arm: add dom0-less device assignment info to docs

[Julien Grall]

Hi Stefano,

On 03/10/2019 02:35, Stefano Stabellini wrote:

Add info about the SPI used for the virtual pl011.

Signed-off-by: Stefano Stabellini 

---
Changes in v8:
- remove sentence about xen,path being optional

Changes in v7:
- add xen,force-assign-without-iommu
- clarify xen,reg and xen,path go together
- remove acked-by due to changes

Changes in v6:
- fix nr_spis description
- add ack

Changes in v5:
- improve wording

Changes in v4:
- fix spelling
- add "multiboot,module"
- improve commit message
- improve doc
- expand the nr_spis and vpl011 sections and include information about
   the vpl011 SPI
- move passthrough information to docs/misc/arm/passthrough.txt

Changes in v3:
- add nr_spis
- change description of interrupts and interrupt-parent

Changes in v2:
- device tree fragment loaded in cacheable memory
- rename multiboot,dtb to multiboot,device-tree
- rename "path" to "xen,path"
- add a note about device memory mapping
- introduce xen,reg
- specify only the GIC is supported
---
  docs/misc/arm/device-tree/booting.txt |  44 ++-
  docs/misc/arm/passthrough.txt | 106 ++
  2 files changed, 149 insertions(+), 1 deletion(-)

diff --git a/docs/misc/arm/device-tree/booting.txt 
b/docs/misc/arm/device-tree/booting.txt
index 317a9e962a..649e00d09f 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -146,7 +146,18 @@ with the following properties:
  
  - vpl011
  
-An empty property to enable/disable a virtual pl011 for the guest to use.

+An empty property to enable/disable a virtual pl011 for the guest to
+use. The virtual pl011 uses SPI number 0 (see GUEST_VPL011_SPI).
+Please note that the SPI used for the virtual pl011 could clash with the
+physical SPI of a physical device assigned to the guest.
+
+- nr_spis
+
+Optional. A 32-bit integer specifying the number of SPIs (Shared
+Peripheral Interrupts) to allocate for the domain. If nr_spis is
+missing, the max number of SPIs supported by the physical GIC is
+used, or GUEST_VPL011_SPI+1 if vpl011 is enabled, whichever is
+greater.
  
  - #address-cells and #size-cells
  
@@ -226,3 +237,34 @@ chosen {

  };
  };
  };
+
+
+Device Assignment
+=
+
+Device Assignment (Passthrough) is supported by adding another module,
+alongside the kernel and ramdisk, with the device tree fragment
+corresponding to the device node to assign to the guest.
+
+The dtb sub-node should have the following properties:
+
+- compatible
+
+"multiboot,device-tree" and "multiboot,module"
+
+- reg
+
+Specifies the physical address of the device tree binary fragment
+RAM and its length.
+
+As an example:
+
+module@0xc00 {
+compatible = "multiboot,device-tree", "multiboot,module";
+reg = <0x0 0xc00 0xff>;
+};
+
+The DTB fragment is loaded at 0xc00 in the example above. It should
+follow the convention explained in docs/misc/arm/passthrough.txt. The
+DTB fragment will be added to the guest device tree, so that the guest
+kernel will be able to discover the device.
diff --git a/docs/misc/arm/passthrough.txt b/docs/misc/arm/passthrough.txt
index 0efbd122de..6826e1f341 100644
--- a/docs/misc/arm/passthrough.txt
+++ b/docs/misc/arm/passthrough.txt
@@ -80,6 +80,112 @@ SPI numbers start from 32, in this example 80 + 32 = 112.
  See man [xl.cfg] for the iomem format. The reg property is just a pair
  of address, then size numbers, each of them can occupy 1 or 2 cells.
  
+

+Dom0-less Device Passthrough
+
+
+The partial device tree for dom0-less guests should have the following
+properties for each node corresponding to a physical device to assign to
+the guest:
+
+- xen,reg
+
+  The xen,reg property is an array of:
+
+
+
+  They specify the physical address and size of the device memory
+  ranges together with the corresponding guest address to map them to.
+  The size of `phys_addr' and `guest_addr' is determined by
+  #address-cells, the size of `size' is determined by #size-cells, of
+  the partial device tree.
+  The memory will be mapped as device memory in the guest (Device-nGnRE).
+
+- xen,path
+
+  A string property representing the path in the host device tree to the
+  corresponding device node.
+
+- xen,force-assign-without-iommu
+  If xen,force-assign-without-iommu is present Xen continues booting
+  even on IOMMU setup errors for the device (i.e. the device is not
+  protected by an IOMMU).


Reading again, this suggest the option can be used to force assignment if a 
Device is behind an IOMMU but the setup failed.


All IOMMUs should be configured to deny any transaction. So your device is not 
going to work. We should also probably state the consequence of using this option.


It would be better to say:

"If xen,force-assign-without-iommu is present, Xen will allow to assign a device 
even if it is not behind an IOMMU. This 

Re: [Xen-devel] [PATCH v8 5/8] xen/arm: assign devices to boot domains

[Julien Grall]

Hi Stefano,

On 03/10/2019 02:35, Stefano Stabellini wrote:

Scan the user provided dtb fragment at boot. For each device node, map
memory to guests, and route interrupts and setup the iommu.

The memory region to remap is specified by the "xen,reg" property.

The iommu is setup by passing the node of the device to assign on the
host device tree. The path is specified in the device tree fragment as
the "xen,path" string property.

The interrupts are remapped based on the information from the
corresponding node on the host device tree. Call
handle_device_interrupts to remap interrupts. Interrupts related device
tree properties are copied from the device tree fragment, same as all
the other properties.

Require both xen,reg and xen,path to be present, unless
xen,force-assign-without-iommu is also set. In that case, tolerate a
missing xen,path, also tolerate iommu setup failure for the passthrough
device.

Also set add the new flag XEN_DOMCTL_CDF_iommu so that dom0less domU
can use the IOMMU if a partial dtb is specified.

Signed-off-by: Stefano Stabellini 
---
Changes in v8:
- better in-code comment
- code style
- add a prink in case of error

Changes in v7:
- improve in-code comment
- code style
- return 1 instead of ENOENT
- introduce "xen,force-assign-without-iommu"
- require both "xen,reg" and "xen,path" unless
   "xen,force-assign-without-iommu"

Changes in v6:
- turn dprintks into printks
- return error on page alignment check failure
- set XEN_DOMCTL_CDF_iommu if partial dtb is specified

Changes in v5:
- use local variable for name
- use map_regions_p2mt
- add warning for not page aligned addresses/sizes
- introduce handle_passthrough_prop

Changes in v4:
- use unsigned
- improve commit message
- code style
- use dt_prop_cmp
- use device_tree_get_reg
- don't copy over xen,reg and xen,path
- don't create special interrupt properties for domU: copy them from the
   fragment
- in-code comment

Changes in v3:
- improve commit message
- remove superfluous cast
- merge code with the copy code
- add interrup-parent
- demove depth > 2 check
- reuse code from handle_device_interrupts
- copy interrupts from host dt

Changes in v2:
- rename "path" to "xen,path"
- grammar fix
- use gaddr_to_gfn and maddr_to_mfn
- remove depth <= 2 limitation in scanning the dtb fragment
- introduce and parse xen,reg
- code style
- support more than one interrupt per device
- specify only the GIC is supported
---
  xen/arch/arm/domain_build.c | 139 ++--
  1 file changed, 135 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 84b65b8f25..b90902ad97 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1714,6 +1714,88 @@ static int __init make_vpl011_uart_node(struct 
kernel_info *kinfo)
  }
  #endif
  
+/*

+ * Scan device tree properties for passthrough specific information.
+ * Returns < 0 on error
+ * 0 on success
+ */
+static int __init handle_passthrough_prop(struct kernel_info *kinfo,
+  const struct fdt_property *xen_reg,
+  const struct fdt_property *xen_path,
+  bool xen_force,
+  uint32_t address_cells, uint32_t 
size_cells)
+{
+const __be32 *cell;
+unsigned int i, len;
+struct dt_device_node *node;
+int res;
+paddr_t mstart, size, gstart;
+
+/* xen,reg specifies where to map the MMIO region */
+cell = (const __be32 *)xen_reg->data;
+len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
+sizeof(uint32_t));
+
+for ( i = 0; i < len; i++ )
+{
+device_tree_get_reg(, address_cells, size_cells,
+, );
+gstart = dt_next_cell(address_cells, );
+
+if ( gstart & ~PAGE_MASK || mstart & ~PAGE_MASK || size & ~PAGE_MASK )
+{
+printk(XENLOG_ERR
+"DomU passthrough config has not page aligned 
addresses/sizes\n");
+return -EINVAL;
+}
+
+res = map_regions_p2mt(kinfo->d,
+   gaddr_to_gfn(gstart),
+   PFN_DOWN(size),
+   maddr_to_mfn(mstart),
+   p2m_mmio_direct_dev);
+if ( res < 0 )
+{
+printk(XENLOG_ERR
+   "Failed to map %"PRIpaddr" to the guest at%"PRIpaddr"\n",
+   mstart, gstart);
+return -EFAULT;
+}
+}
+
+/*
+ * If xen_force, we let the user assign a MMIO region with no
+ * associated path.
+ */
+if ( xen_path == NULL )
+return xen_force ? 0 : -EINVAL;
+
+/*
+ * xen,path specifies the corresponding node in the host DT.
+ * Both interrupt mappings and IOMMU settings are based on it,
+ * as they are done based 

[Xen-devel] [OSSTEST PATCH] Osstest.pm: Fix main_revision_job_cond after 0964bab7a9ea

[Ian Jackson]

In
  other_revision_job_suffix: Take and pass referring runvar name
we updated main_revision_job_cond to pass a dummy 'x' for the new
parameter.  But the parameter is a sql expression, not a value,
and so an extra pair of quotes are needed.

This error broke sg-check-tested and this fix fixes it.

Signed-off-by: Ian Jackson 
---
 Osstest.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest.pm b/Osstest.pm
index c14531e3..d6c1b709 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -388,7 +388,7 @@ END
 
 sub main_revision_job_cond ($) {
 my ($jobfield) = @_;
-return "(${\ other_revision_job_suffix($jobfield,'x','x') } = '')";
+return "(${\ other_revision_job_suffix($jobfield,\"'x'\",'x') } = '')";
 }
 
 sub get_harness_rev () {
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v6 00/20] xen: add core scheduling support

[Sergey Dyasli]

Hi Juergen,

Looks like we've hit the first Xen crash with core scheduling patches applied.
The log is below. From my analysis it seems that CSCHED_PCPU is NULL.
I suspect this is connected to commit bb128adb
("sched: populate cpupool0 only after all cpus are up")

Could you take a look, please?

(XEN) [  164.775206] Brought up 448 CPUs
(XEN) [  164.827979] Testing NMI watchdog on all CPUs: ok
(XEN) [  168.064678] [ Xen-4.13.0-8.0.12-d  x86_64  debug=y   Not tainted 
]
(XEN) [  168.128822] CPU:79
(XEN) [  168.191394] RIP:e008:[] set_timer+0x39/0x1f7
(XEN) [  168.255921] RFLAGS: 00010002   CONTEXT: hypervisor
(XEN) [  168.319752] rax: 0048   rbx: 0020   rcx: 
82d0805b8008
(XEN) [  168.382563] rdx: 8462efce7fff   rsi: 002721c0ad80   rdi: 
0020
(XEN) [  168.445194] rbp: 8462efce7de0   rsp: 8462efce7da0   r8:  
8eea
(XEN) [  168.507630] r9:     r10:    r11: 
0008
(XEN) [  168.569849] r12: 82d080488f20   r13: 0027216dad05   r14: 
00272167bef6
(XEN) [  168.631879] r15: 0008   cr0: 8005003b   cr4: 
003526e0
(XEN) [  168.693743] cr3: a5a9d000   cr2: 0048
(XEN) [  168.754868] fsb:    gsb:    gss: 

(XEN) [  168.816304] ds:    es:    fs:    gs:    ss:    cs: 
e008
(XEN) [  168.877390] Xen code around  (set_timer+0x39/0x1f7):
(XEN) [  168.938117]  48 8d 47 28 48 89 45 c0 <66> 44 8b 67 28 45 0f b7 e4 41 
81 fc ff ff 00 00
(XEN) [  169.015525] Xen stack trace from rsp=8462efce7da0:
(XEN) [  169.075579]0048 0286 8382cd650f08 
004f
(XEN) [  169.139205]82d080488f20 0027216dad05 00272167bef6 
0008
(XEN) [  169.202660]8462efce7e00 82d08022c1f4 004f 
8382cd650e70
(XEN) [  169.265928]8462efce7e20 82d080241dfe 00272167bef6 
8382cd650f08
(XEN) [  169.329022]8462efce7ea0 82d0802eda52 846200ff 
0020802ae6a5
(XEN) [  169.392015]8462efce7e60 82d0802ae7d1 82d0805c0200 

(XEN) [  169.455119]  2780 
2780
(XEN) [  169.518238]82d0805bda80 004f 82d0805b7270 
004f
(XEN) [  169.581477]8462efce7ef0 82d08027939e  
004f00c8
(XEN) [  169.644501]8382cd64a000 8382cd64a000 8382cd50ab30 
004f
(XEN) [  169.707365]  8462efce7ec0 

(XEN) [  169.770036]   

(XEN) [  169.832519]   

(XEN) [  169.894813]   

(XEN) [  169.956916]   

(XEN) [  170.018831]   

(XEN) [  170.080574]   

(XEN) [  170.142124]e010004f 8382cd64a000 00b24d08e000 
003526e0
(XEN) [  170.203508]  0601 

(XEN) [  170.264698] Xen call trace:
(XEN) [  170.321356][] set_timer+0x39/0x1f7
(XEN) [  170.378154][] 
sched_credit.c#csched_tick_resume+0x54/0x59
(XEN) [  170.435049][] sched_tick_resume+0x67/0x86
(XEN) [  170.491383][] mwait-idle.c#mwait_idle+0x32b/0x357
(XEN) [  170.547579][] domain.c#idle_loop+0xa6/0xc2
(XEN) [  170.603301]
(XEN) [  170.657509] Running stub recovery selftests...
(XEN) [  170.701789] Pagetable walk from 0048:
(XEN) [  170.755603] traps.c:1564: GPF (): 82d0b041 
[82d0b041] -> 82d0803893f2
(XEN) [  170.800367]  L4[0x000] = 0082cfb9c063 
(XEN) [  170.854150] traps.c:759: Trap 12: 82d0b040 [82d0b040] 
-> 82d0803893f2
(XEN) [  170.900493]  L3[0x000] = 0082cfb9b063 
(XEN) [  170.954060] traps.c:1098: Trap 3: 82d0b041 [82d0b041] 
-> 82d0803893f2
(XEN) [  170.998631]  L2[0x000] = 0082cfb9a063 
(XEN) [  171.058140]  L1[0x000] =  
(XEN) [  171.130737]
(XEN) [  171.190190] 
(XEN) [  171.254241] Panic on CPU 79:
(XEN) [  171.315034] FATAL PAGE FAULT
(XEN) [  171.375744] [error_code=]
(XEN) [  171.436129] Faulting linear address: 0048
(XEN) [  171.499198] 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v7b 5/8] xen/arm: assign devices to boot domains

[Oleksandr]

On 01.10.19 02:30, Stefano Stabellini wrote:

Hi Stefano


+
+/* If xen_force, we ignore IOMMU failures. */
+res = iommu_add_dt_device(node);
+if ( res < 0 )
+return xen_force ? 0 : -EINVAL;


Any specific reason to return -EINVAL if not forcing (why don't return 
res)?




+
+res = iommu_assign_dt_device(kinfo->d, node);
+return res;


could be optimized:

return iommu_assign_dt_device(kinfo->d, node);


--
Regards,

Oleksandr Tyshchenko


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v8 8/8] xen/arm: add dom0-less device assignment info to docs

[Julien Grall]

Hi Stefano,

On 03/10/2019 02:35, Stefano Stabellini wrote:

Add info about the SPI used for the virtual pl011.

Signed-off-by: Stefano Stabellini 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v8 5/8] xen/arm: assign devices to boot domains

[Julien Grall]

Hi Stefano,

A couple of comments below, mostly because I wasn't clear enough on the previous 
version. I am not sure if it is worth resending the series, maybe just resending 
this one would be sufficient?


On 03/10/2019 02:35, Stefano Stabellini wrote:

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 84b65b8f25..b90902ad97 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1714,6 +1714,88 @@ static int __init make_vpl011_uart_node(struct 
kernel_info *kinfo)
  }
  #endif
  
+/*

+ * Scan device tree properties for passthrough specific information.
+ * Returns < 0 on error
+ * 0 on success
+ */
+static int __init handle_passthrough_prop(struct kernel_info *kinfo,
+  const struct fdt_property *xen_reg,
+  const struct fdt_property *xen_path,
+  bool xen_force,
+  uint32_t address_cells, uint32_t 
size_cells)
+{
+const __be32 *cell;
+unsigned int i, len;
+struct dt_device_node *node;
+int res;
+paddr_t mstart, size, gstart;
+
+/* xen,reg specifies where to map the MMIO region */
+cell = (const __be32 *)xen_reg->data;
+len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
+sizeof(uint32_t));


Apologies for this, I misread you previous code. I am happy with this version or 
the previous one.


[...]


+/*
+ * Only handle passthrough properties if both xen,reg and xen,path
+ * are present, or if xen,force-assign-without-iommu is specified.
+ */
+if ( xen_reg != NULL && (xen_path != NULL || xen_force) )
+{
+res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force,
+  address_cells, size_cells);
+if ( res < 0 )
+{
+printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d);


This is not the error path I meant.

The one I was referring is the case where xen,path is present but not xen,reg. 
At the moment you will continue without telling the user. We should at least 
print a warning and probably return an error as someone specifying "xen,path" 
may expect to assign the device.


Cheers,


--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v7b 5/8] xen/arm: assign devices to boot domains

[Julien Grall]

Hi Stefano,

On 02/10/2019 23:43, Stefano Stabellini wrote:

On Wed, 2 Oct 2019, Julien Grall wrote:

+if ( !found )
+{
+res = fdt_property(fdt, name, prop->data,
fdt32_to_cpu(prop->len));
+if ( res )
+return res;
+}
+}
+
+/*
+ * Only handle passthrough properties if both xen,reg and xen,path
+ * are present, or if xen,force-assign-without-iommu is specified.
+ */
+if ( xen_reg != NULL && (xen_path != NULL || xen_force) )
+{
+res = handle_passthrough_prop(kinfo, xen_reg, xen_path, xen_force,
+  address_cells, size_cells);
+if ( res < 0 )
   return res;
   }


I would print an error so the user knows what happen here.


All right, I'll add:

   printk(XENLOG_ERR "Failed to assign device to %pd\n", kinfo->d);

More specific information about the type of failure is already printed
by handle_passthrough_prop.


I am less concerned about the error when handle_passthrough_prop. What I am 
concerned about if the fact you will ignore xen,path if xen,reg is not present.


We should at least warn the user if not returning an error.

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v7b 5/8] xen/arm: assign devices to boot domains

[Julien Grall]

Hi Stefano,

On 02/10/2019 23:48, Stefano Stabellini wrote:

On Wed, 2 Oct 2019, Stefano Stabellini wrote:

On Wed, 2 Oct 2019, Julien Grall wrote:

Hi Stefano,

On 10/1/19 12:30 AM, Stefano Stabellini wrote:

Scan the user provided dtb fragment at boot. For each device node, map
memory to guests, and route interrupts and setup the iommu.

The memory region to remap is specified by the "xen,reg" property.

The iommu is setup by passing the node of the device to assign on the
host device tree. The path is specified in the device tree fragment as
the "xen,path" string property.

The interrupts are remapped based on the information from the
corresponding node on the host device tree. Call
handle_device_interrupts to remap interrupts. Interrupts related device
tree properties are copied from the device tree fragment, same as all
the other properties.

Require both xen,reg and xen,path to be present, unless
xen,force-assign-without-iommu is also set. In that case, tolerate a
missing xen,path, also tolerate iommu setup failure for the passthrough
device.

Also set add the new flag XEN_DOMCTL_CDF_iommu so that dom0less domU
can use the IOMMU if a partial dtb is specified.


The patch looks good a few comments below.


Thanks



[...]


   xen/arch/arm/domain_build.c | 133 ++--
   1 file changed, 129 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 84b65b8f25..47f9bb31df 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1714,6 +1714,88 @@ static int __init make_vpl011_uart_node(struct
kernel_info *kinfo)
   }
   #endif
   +/*
+ * Scan device tree properties for passthrough specific information.
+ * Returns < 0 on error
+ * 0 on success
+ */
+static int __init handle_passthrough_prop(struct kernel_info *kinfo,
+  const struct fdt_property
*xen_reg,
+  const struct fdt_property
*xen_path,
+  bool xen_force,
+  uint32_t address_cells, uint32_t
size_cells)
+{
+const __be32 *cell;
+unsigned int i, len;
+struct dt_device_node *node;
+int res;
+paddr_t mstart, size, gstart;
+
+/* xen,reg specifies where to map the MMIO region */
+cell = (const __be32 *)xen_reg->data;
+len = fdt32_to_cpu(xen_reg->len) /
+  ((address_cells * 2 + size_cells) * sizeof(uint32_t));


Coding style again. I was kind of expecting you configured your editor
properly after the last discussion...


Actually I fail to see the coding style issue on this one. Is it still
an alignment issue you are talking about?


Is it because you would like it to look like this?

 len = fdt32_to_cpu(xen_reg->len) / ((address_cells * 2 + size_cells) *
 sizeof(uint32_t));


No, I completely misread the line and thought the division was part of the 
fdt32_to_cpu argument. Apologies for the noise :(.


This is fixable on commit.

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.13 0/6] xen/arm: Add support to build with clang

[Artem Mygaiev]

Hi Julien

Just to confirm - with this series, we are able to run xen master
(4.13-unstable) on R-Car H3:
 * built using clang
 * built using clang-based arm compiler (with further modifications
needed for armlink)

Note we didn't perform full testing, just start xen on its own.

 -- Artem

On Wed, 2019-10-02 at 19:00 +0100, Julien Grall wrote:
> Hi all,
> 
> After this series, I am able to build Xen on Arm64 with clang 7.0.
> There
> are still some issues when building Xen on Arm32 and also using lld.
> 
> Cross-compilation is left outside for now, but this is still a good
> start
> for clang (and armclang).
> 
> Cheers,
> 
> Julien Grall (6):
>   xen/arm: fix get_cpu_info() when built with clang
>   xen/arm64: bitops: Match the register size with the value size in
> flsl
>   xen/arm: cpuerrata: Match register size with value size in
> check_workaround_*
>   xen/arm: cpufeature: Match register size with value size in
> cpus_have_const_cap
>   xen/arm: mm: Mark check_memory_layout_alignment_constraints as
> unused
>   xen/arm: traps: Mark check_stack_alignment_constraints as unused
> 
>  xen/arch/arm/mm.c  |  3 ++-
>  xen/arch/arm/traps.c   |  3 ++-
>  xen/include/asm-arm/arm64/bitops.h |  3 ++-
>  xen/include/asm-arm/cpuerrata.h|  4 ++--
>  xen/include/asm-arm/cpufeature.h   |  4 ++--
>  xen/include/asm-arm/current.h  | 10 +-
>  6 files changed, 19 insertions(+), 8 deletions(-)
> 
> 
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-qemuu-rhel6hvm-intel

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-intel
testid xen-boot

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c
  Bug not present: 01ccc3ad44130458769646204449e2e4124f15da
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/142210/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-qemuu-rhel6hvm-intel.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-qemuu-rhel6hvm-intel.xen-boot
 --summary-out=tmp/142210.bisection-summary --basis-template=133580 
--blessings=real,real-bisect linux-linus test-amd64-i386-qemuu-rhel6hvm-intel 
xen-boot
Searching for failure / basis pass:
 142110 fail [host=italia1] / 138849 [host=elbling1] 138813 [host=chardonnay0] 
138780 [host=chardonnay1] 138754 [host=albana0] 138735 [host=elbling0] 138710 
[host=fiano0] 138680 [host=albana1] 138661 [host=italia0] 138639 [host=debina0] 
138612 [host=baroque1] 138584 [host=baroque0] 138488 [host=elbling1] 138386 
[host=debina1] 138245 [host=albana0] 138073 [host=chardonnay1] 137986 
[host=albana1] 137896 [host=italia0] 137739 [host=debina0] 137686 [host=fiano1] 
137589 ok.
Failure / basis pass flights: 142110 / 137589
(tree with no url: minios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
f835e1d4c187014742fbd766ec2fbc07ef5384ba 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
43f5df79dad6738d52ea79d072de2b56eb96a91f 
f93abf0315efef861270c25d83c8047fd6a54ec4
Basis pass 01ccc3ad44130458769646204449e2e4124f15da 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
fe0c2770a72af3a34f79c84676b7bf0c97090bda 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
0932c20560574696cf87ddd12623e8c423ee821b 
844aa0a13d34e9a341a8374119d2ed67d4dcd6bb
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#01ccc3ad44130458769646204449e2e4124f15da-54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/osstest/ovmf.git#fe0c2770a72af3a34f79c84676b7bf0c97090bda-f835e1d4c187014742fbd766ec2fbc07ef5384ba
 git://xenbits.xen.org/qemu-xen-traditional.\
 
git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-933ebad2470a169504799a1d95b8e410bd9847ef
 
git://xenbits.xen.org/osstest/seabios.git#0932c20560574696cf87ddd12623e8c423ee821b-43f5df79dad6738d52ea79d072de2b56eb96a91f
 
git://xenbits.xen.org/xen.git#844aa0a13d34e9a341a8374119d2ed67d4dcd6bb-f93abf0315efef861270c25d83c8047fd6a54ec4
adhoc-revtuple-generator: tree discontiguous: linux-2.6
adhoc-revtuple-generator: tree discontiguous: qemu-xen
Loaded 3003 nodes in revision graph
Searching for test results:
 137388 [host=chardonnay1]
 137484 [host=baroque0]
 137589 pass 01ccc3ad44130458769646204449e2e4124f15da 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
fe0c2770a72af3a34f79c84676b7bf0c97090bda 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
0932c20560574696cf87ddd12623e8c423ee821b 
844aa0a13d34e9a341a8374119d2ed67d4dcd6bb
 137739 [host=debina0]
 137686 [host=fiano1]
 137896 [host=italia0]
 137986 [host=albana1]
 138073 [host=chardonnay1]
 138245 [host=albana0]
 138386 [host=debina1]
 138488 [host=elbling1]
 138584 [host=baroque0]
 138612 [host=baroque1]
 138639 [host=debina0]
 138661 [host=italia0]
 138680 [host=albana1]
 138710 [host=fiano0]
 138735 [host=elbling0]
 138754 [host=albana0]
 138780 [host=chardonnay1]
 138813 [host=chardonnay0]
 138849 [host=elbling1]
 138878 fail 

Re: [Xen-devel] [PATCH for-4.13 0/6] xen/arm: Add support to build with clang

[Jürgen Groß]

On 02.10.19 20:00, Julien Grall wrote:

Hi all,

After this series, I am able to build Xen on Arm64 with clang 7.0. There
are still some issues when building Xen on Arm32 and also using lld.

Cross-compilation is left outside for now, but this is still a good start
for clang (and armclang).

Cheers,

Julien Grall (6):
   xen/arm: fix get_cpu_info() when built with clang
   xen/arm64: bitops: Match the register size with the value size in flsl
   xen/arm: cpuerrata: Match register size with value size in
 check_workaround_*
   xen/arm: cpufeature: Match register size with value size in
 cpus_have_const_cap
   xen/arm: mm: Mark check_memory_layout_alignment_constraints as unused
   xen/arm: traps: Mark check_stack_alignment_constraints as unused


For the series:

Release-acked-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel