Re: [Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

[Juergen Gross]

On 12/03/18 20:26, Sander Eikelenboom wrote:
> Hi Juergen,
> 
> I don't know by which tree those patches should arrive at Linus,
> so i can't check if they fell through the cracks somewhere, but 4.16-rc5
> hasn't got them yet.

They are queued for 4.17 in:

git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/boot


Juergen

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

[Xen-devel] [PATCH] tools/xl: fix uninitialized variable in xl_vdispl

[Doug Goldstein]

The code added in 7a48622a78a0b452e8afa55b8442c958abd226a7 could use rc
uninitialized in main_vdisplattach().

Signed-off-by: Doug Goldstein 
---
CC: Oleksandr Grytsov 
---
 tools/xl/xl_vdispl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/xl/xl_vdispl.c b/tools/xl/xl_vdispl.c
index 3cc99b6aed..8fbad5be68 100644
--- a/tools/xl/xl_vdispl.c
+++ b/tools/xl/xl_vdispl.c
@@ -25,7 +25,7 @@
 int main_vdisplattach(int argc, char **argv)
 {
 int opt;
-int rc;
+int rc = ERROR_FAIL;
 uint32_t domid;
 libxl_device_vdispl vdispl;
 
-- 
2.16.1


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

Re: [Xen-devel] [RFC PATCH 0/6] Using GitLab CI for build testing

[Doug Goldstein]

On 3/12/18 10:31 PM, Doug Goldstein wrote:
> Really early work on switching over to using GitLab CI over
> Travis CI. GitLab is a competitor to GitHub with some advantages
> such as an integrated CI system with a lot more flexibility
> and control. It additionally is fully open sourced unlike GitHub
> and Travis CI. We can even run an instance if that is preferred
> over using the hosted instance.
> 
> This change uses GitLab CI's ability to use Docker based runners
> for running tests. With GitHub we also use a Docker based runner
> but we are limited to one Docker container that is then morphed
> a number of different ways. With this approach we can specify
> different Docker containers for every run (or use the same). By
> using different Docker containers we can build environments that
> match systems where Xen can and should build. Using this
> approach we should be able to cutdown on the number of surpise
> build failures encountered by users.
> 
> An example run can be seen here:
> https://gitlab.com/cardoe/xen/pipelines/18789907
> 
> If there is interest in this I will move it over to the "xen-project"
> name space in the next version.

Worth noting another advantage is that builders can be VMs or even
physical hosts as well. So we can have a FreeBSD VM that can be a build
environment.

Further more the above link is to a GitLab pipeline, pipelines are made
of stages which are further composed of jobs. Currently the example uses
one stage called build and all the different distros are different jobs.
But there's a lot of flexibility as to what can be done here. There can
be stages that check code style or other pre-flight checks that people
may be interested. There can be stages that happen after the build stage
as well such as some simple tests (e.g. I use it to run the just built
xen.gz with an initramfs only dom0 that contains a small Alpine Linux VM
that spits out a string to an HTTP endpoint which decides that Xen build
is good enough to allow it to be merged into our testing branch).

Overall there are a lot more possibilities than what I've put together
so far.
-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-linus test] 120441: regressions - FAIL

[osstest service owner]

flight 120441 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120441/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
118324
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 118324
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start   fail REGR. vs. 118324
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 118324
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 118324
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail REGR. vs. 118324
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 118324
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 118324
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 118324
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 118324
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 118324
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
118324
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 118324

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118324
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-pvshim 7 xen-boot fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 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-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-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-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 

[Xen-devel] [PATCH v4] tools: detect appropriate debug optimization level

[Doug Goldstein]

When building debug use -Og as the optimization level if its available,
otherwise retain the use of -O0. -Og has been added by GCC to enable all
optimizations that to not affect debugging while retaining full
debugability.

Signed-off-by: Doug Goldstein 
---
 tools/Rules.mk | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/Rules.mk b/tools/Rules.mk
index 296b722372..3848bcf1f7 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -164,8 +164,13 @@ LDLIBS_libxenvchan = $(SHDEPS_libxenvchan) 
$(XEN_LIBVCHAN)/libxenvchan$(libexten
 SHLIB_libxenvchan  = $(SHDEPS_libxenvchan) -Wl,-rpath-link=$(XEN_LIBVCHAN)
 
 ifeq ($(debug),y)
-# Disable optimizations
-CFLAGS += -O0 -fno-omit-frame-pointer
+CFLAGS += -fno-omit-frame-pointer
+# Use optimizations compatible with debugging otherwise disable optimizations
+ifneq ($(call cc-option,$(CC),-Og,n),n)
+CFLAGS += -Og
+else
+CFLAGS += -O0
+endif
 # But allow an override to -O0 in case Python enforces -D_FORTIFY_SOURCE=.
 PY_CFLAGS += $(PY_NOOPT_CFLAGS)
 else
-- 
2.16.1


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

[Xen-devel] [RFC PATCH 6/6] ci: add a README about the containers

[Doug Goldstein]

Add a basic README explaining the containers and how people can use them
to locally test with if they see an error in CI and want to reproduce it
locally.

Signed-off-by: Doug Goldstein 
---
 extras/testing/README.md | 29 +
 1 file changed, 29 insertions(+)
 create mode 100644 extras/testing/README.md

diff --git a/extras/testing/README.md b/extras/testing/README.md
new file mode 100644
index 000..0908a66
--- /dev/null
+++ b/extras/testing/README.md
@@ -0,0 +1,29 @@
+Docker Containers
+=
+
+These Docker containers should make it possible to build Xen in
+any of the available environments on any system that supports
+running Docker. They are organized by distro and tagged with
+the version of that distro. They are available from the GitLab
+Container Registry under the Xen project at:
+
+registry.gitlab.com/cardoe/xen/DISTRO:VERSION
+
+The available ones are:
+- centos:7.2
+- debian:jessie
+- ubuntu:trusty
+- ubuntu:xenial
+
+To Build Xen
+
+
+From the top level of the source tree it should be possible to
+run the following:
+
+docker run --rm -it -v $(PWD):/build -u $(id -u) -e CC=gcc $(CONTAINER) make
+
+There are other modifications that can be made but this will run
+the `make` command inside the specified container. It will use your
+currently checked out source tree to build with, ensure that file
+permissions remain consistent and clean up after itself.
-- 
git-series 0.9.1

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

[Xen-devel] [RFC PATCH 5/6] ci: add cfg to use GitLab CI to build

[Doug Goldstein]

Added a GitLab CI config which has a lot more flexibility to allow us to
test a lot more distro configurations than Travis can and even build
test on FreeBSD.

Signed-off-by: Doug Goldstein 
---
 .gitlab-ci.yml | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 .gitlab-ci.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 000..ccc2237
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,34 @@
+stages:
+  - build
+
+centos-7-2:
+  stage: build
+  image: registry.gitlab.com/cardoe/xen/centos:7.2
+  variables:
+CC: gcc
+  script:
+- ./scripts/travis-build
+
+debian-jessie:
+  stage: build
+  image: registry.gitlab.com/cardoe/xen/debian:jessie
+  variables:
+CC: gcc
+  script:
+- ./scripts/travis-build
+
+ubuntu-trusty:
+  stage: build
+  image: registry.gitlab.com/cardoe/xen/ubuntu:trusty
+  variables:
+CC: gcc
+  script:
+- ./scripts/travis-build
+
+ubuntu-xenial:
+  stage: build
+  image: registry.gitlab.com/cardoe/xen/ubuntu:xenial
+  variables:
+CC: gcc
+  script:
+- ./scripts/travis-build
-- 
git-series 0.9.1

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

[Xen-devel] [RFC PATCH 3/6] ci: add Dockerfile for Ubuntu 16.04

[Doug Goldstein]

Added a Dockerfile which captures all the necessary dependencies to
build Xen on a Ubuntu 16.04 system.

Signed-off-by: Doug Goldstein 
---
 extras/testing/ubuntu/Dockerfile.xenial | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 extras/testing/ubuntu/Dockerfile.xenial

diff --git a/extras/testing/ubuntu/Dockerfile.xenial 
b/extras/testing/ubuntu/Dockerfile.xenial
new file mode 100644
index 000..b9ce27f
--- /dev/null
+++ b/extras/testing/ubuntu/Dockerfile.xenial
@@ -0,0 +1,21 @@
+FROM ubuntu:16.04
+LABEL maintainer.name="Doug Goldstein" \
+  maintainer.email="car...@cardoe.com"
+
+ENV DEBIAN_FRONTEND=noninteractive
+ENV USER root
+
+RUN mkdir /build
+WORKDIR /build
+
+# build depends
+RUN apt-get update && \
+apt-get --quiet --yes install \
+build-essential zlib1g-dev libncurses5-dev libssl-dev python2.7-dev \
+xorg-dev uuid-dev libyajl-dev libaio-dev libglib2.0-dev clang \
+libpixman-1-dev pkg-config flex bison gettext acpica-tools bin86 \
+bcc libc6-dev-i386 libnl-3-dev ocaml-nox libfindlib-ocaml-dev \
+markdown transfig pandoc checkpolicy wget git && \
+apt-get autoremove -y && \
+apt-get clean && \
+rm -rf /var/lib/apt/lists* /tmp/* /var/tmp/*
-- 
git-series 0.9.1

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

[Xen-devel] [RFC PATCH 0/6] Using GitLab CI for build testing

[Doug Goldstein]

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

This change uses GitLab CI's ability to use Docker based runners
for running tests. With GitHub we also use a Docker based runner
but we are limited to one Docker container that is then morphed
a number of different ways. With this approach we can specify
different Docker containers for every run (or use the same). By
using different Docker containers we can build environments that
match systems where Xen can and should build. Using this
approach we should be able to cutdown on the number of surpise
build failures encountered by users.

An example run can be seen here:
https://gitlab.com/cardoe/xen/pipelines/18789907

If there is interest in this I will move it over to the "xen-project"
name space in the next version.

Doug Goldstein (6):
  ci: add Dockerfile for CentOS 7.2
  ci: add Dockerfile for Ubuntu 14.04
  ci: add Dockerfile for Ubuntu 16.04
  ci: add Dockerfile for Debian jessie
  ci: add cfg to use GitLab CI to build
  ci: add a README about the containers

 .gitlab-ci.yml  | 34 ++-
 extras/testing/README.md| 29 ++-
 extras/testing/centos/CentOS-7.2.repo   | 35 ++-
 extras/testing/centos/Dockerfile.7.2| 41 ++-
 extras/testing/debian/Dockerfile.jessie | 21 +-
 extras/testing/ubuntu/Dockerfile.trusty | 21 +-
 extras/testing/ubuntu/Dockerfile.xenial | 21 +-
 7 files changed, 202 insertions(+)
 create mode 100644 .gitlab-ci.yml
 create mode 100644 extras/testing/README.md
 create mode 100644 extras/testing/centos/CentOS-7.2.repo
 create mode 100644 extras/testing/centos/Dockerfile.7.2
 create mode 100644 extras/testing/debian/Dockerfile.jessie
 create mode 100644 extras/testing/ubuntu/Dockerfile.trusty
 create mode 100644 extras/testing/ubuntu/Dockerfile.xenial

base-commit: 966f154c58bacf07690135d7da3f1d5281d84ab0
-- 
git-series 0.9.1

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

[Xen-devel] [RFC PATCH 1/6] ci: add Dockerfile for CentOS 7.2

[Doug Goldstein]

Added a Dockerfile which captures all the necessary dependencies to
build Xen on a CentOS 7.2 system.

Signed-off-by: Doug Goldstein 
---
 extras/testing/centos/CentOS-7.2.repo | 35 -
 extras/testing/centos/Dockerfile.7.2  | 41 -
 2 files changed, 76 insertions(+)
 create mode 100644 extras/testing/centos/CentOS-7.2.repo
 create mode 100644 extras/testing/centos/Dockerfile.7.2

diff --git a/extras/testing/centos/CentOS-7.2.repo 
b/extras/testing/centos/CentOS-7.2.repo
new file mode 100644
index 000..4da27fa
--- /dev/null
+++ b/extras/testing/centos/CentOS-7.2.repo
@@ -0,0 +1,35 @@
+# CentOS-Base.repo
+#
+# This is a replacement file that pins things to just use CentOS 7.2
+# from the CentOS Vault.
+#
+
+[base]
+name=CentOS-7.2.1511 - Base
+baseurl=http://vault.centos.org/7.2.1511/os/$basearch/
+gpgcheck=1
+gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
+
+#released updates 
+[updates]
+name=CentOS-7.2.1511 - Updates
+baseurl=http://vault.centos.org/7.2.1511/updates/$basearch/
+gpgcheck=1
+gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
+
+#additional packages that may be useful
+[extras]
+name=CentOS-7.2.1511 - Extras
+baseurl=http://vault.centos.org/7.2.1511/extras/$basearch/
+gpgcheck=1
+gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
+
+#additional packages that extend functionality of existing packages
+[centosplus]
+name=CentOS-7.2.1511 - Plus
+baseurl=http://vault.centos.org/7.2.1511/centosplus/$basearch/
+gpgcheck=1
+gpgcheck=1
+enabled=0
+gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
+
diff --git a/extras/testing/centos/Dockerfile.7.2 
b/extras/testing/centos/Dockerfile.7.2
new file mode 100644
index 000..40780b4
--- /dev/null
+++ b/extras/testing/centos/Dockerfile.7.2
@@ -0,0 +1,41 @@
+FROM centos:7.2.1511
+LABEL maintainer.name="Doug Goldstein" \
+  maintainer.email="car...@cardoe.com"
+
+# ensure we only get bits from the vault for
+# the version we want
+COPY CentOS-7.2.repo /etc/yum.repos.d/CentOS-Base.repo
+
+RUN mkdir /build
+WORKDIR /build
+
+# work around https://github.com/moby/moby/issues/10180
+# and install Xen depends
+RUN rpm --rebuilddb && \
+yum -y install \
+yum-plugin-ovl \
+gcc \
+gcc-c++ \
+ncurses-devel \
+zlib-devel \
+openssl-devel \
+python-devel \
+libuuid-devel \
+pkgconfig \
+gettext \
+flex \
+bison \
+libaio-devel \
+glib2-devel \
+yajl-devel \
+pixman-devel \
+glibc-devel \
+glibc-devel.i686 \
+make \
+binutils \
+git \
+wget \
+acpica-tools \
+python-markdown \
+patch \
+&& yum clean all
-- 
git-series 0.9.1

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

[Xen-devel] [RFC PATCH 2/6] ci: add Dockerfile for Ubuntu 14.04

[Doug Goldstein]

Added a Dockerfile which captures all the necessary dependencies to
build Xen on a Ubuntu 14.04 system.

Signed-off-by: Doug Goldstein 
---
 extras/testing/ubuntu/Dockerfile.trusty | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 extras/testing/ubuntu/Dockerfile.trusty

diff --git a/extras/testing/ubuntu/Dockerfile.trusty 
b/extras/testing/ubuntu/Dockerfile.trusty
new file mode 100644
index 000..c5d761e
--- /dev/null
+++ b/extras/testing/ubuntu/Dockerfile.trusty
@@ -0,0 +1,21 @@
+FROM ubuntu:14.04
+LABEL maintainer.name="Doug Goldstein" \
+  maintainer.email="car...@cardoe.com"
+
+ENV DEBIAN_FRONTEND=noninteractive
+ENV USER root
+
+RUN mkdir /build
+WORKDIR /build
+
+# build depends
+RUN apt-get update && \
+apt-get --quiet --yes install \
+build-essential zlib1g-dev libncurses5-dev libssl-dev python2.7-dev \
+xorg-dev uuid-dev libyajl-dev libaio-dev libglib2.0-dev clang \
+libpixman-1-dev pkg-config flex bison gettext acpica-tools bin86 \
+bcc libc6-dev-i386 libnl-3-dev ocaml-nox libfindlib-ocaml-dev \
+markdown transfig pandoc checkpolicy wget git && \
+apt-get autoremove -y && \
+apt-get clean && \
+rm -rf /var/lib/apt/lists* /tmp/* /var/tmp/*
-- 
git-series 0.9.1

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

[Xen-devel] [RFC PATCH 4/6] ci: add Dockerfile for Debian jessie

[Doug Goldstein]

Added a Dockerfile which captures all the necessary dependencies to
build Xen on a Debian jessie system.

Signed-off-by: Doug Goldstein 
---
 extras/testing/debian/Dockerfile.jessie | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 extras/testing/debian/Dockerfile.jessie

diff --git a/extras/testing/debian/Dockerfile.jessie 
b/extras/testing/debian/Dockerfile.jessie
new file mode 100644
index 000..be0dccc
--- /dev/null
+++ b/extras/testing/debian/Dockerfile.jessie
@@ -0,0 +1,21 @@
+FROM debian:jessie
+LABEL maintainer.name="Doug Goldstein" \
+  maintainer.email="car...@cardoe.com"
+
+ENV DEBIAN_FRONTEND=noninteractive
+ENV USER root
+
+RUN mkdir /build
+WORKDIR /build
+
+# build depends
+RUN apt-get update && \
+apt-get --quiet --yes install \
+build-essential zlib1g-dev libncurses5-dev libssl-dev python2.7-dev \
+xorg-dev uuid-dev libyajl-dev libaio-dev libglib2.0-dev clang \
+libpixman-1-dev pkg-config flex bison gettext acpica-tools bin86 \
+bcc libc6-dev-i386 libnl-3-dev ocaml-nox libfindlib-ocaml-dev \
+markdown transfig pandoc checkpolicy wget git && \
+apt-get autoremove -y && \
+apt-get clean && \
+rm -rf /var/lib/apt/lists* /tmp/* /var/tmp/*
-- 
git-series 0.9.1

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

Re: [Xen-devel] [RFC PATCH 01/12] libacpi: new DSDT ACPI table for Q35

[Tian, Kevin]

> From: Alexey G [mailto:x19...@gmail.com]
> Sent: Tuesday, March 13, 2018 5:20 AM
> 
> On Mon, 12 Mar 2018 16:32:27 -0400
> Konrad Rzeszutek Wilk  wrote:
> 
> >On Tue, Mar 13, 2018 at 06:10:35AM +1000, Alexey G wrote:
> >> On Mon, 12 Mar 2018 15:38:03 -0400
> >> Konrad Rzeszutek Wilk  wrote:
> >>
> >> >On Tue, Mar 13, 2018 at 04:33:46AM +1000, Alexey Gerasimenko
> >> >wrote:
> >> >> This patch adds the DSDT table for Q35 (new
> >> >> tools/libacpi/dsdt_q35.asl file). There are not many differences
> >> >> with dsdt.asl (for i440) at the moment, namely:
> >> >>
> >> >> - BDF location of LPC Controller
> >> >> - Minor changes related to FDC detection
> >> >> - Addition of _OSC method to inform OSPM about PCIe features
> >> >> supported
> >> >>
> >> >> As we are still using 4 PCI router links and their corresponding
> >> >> device/register addresses are same (offset 0x60), no need to
> >> >> change PCI routing descriptions.
> >> >>
> >> >> Also, ACPI hotplug is still used to control passed through device
> >> >> hot (un)plug (as it was for i440).
> >> >>
> >> >> Signed-off-by: Alexey Gerasimenko 
> >> >> ---
> >> >>  tools/libacpi/dsdt_q35.asl | 551
> >> >> + 1 file changed,
> 551
> >> >> insertions(+) create mode 100644 tools/libacpi/dsdt_q35.asl
> >> >>
> >> >> diff --git a/tools/libacpi/dsdt_q35.asl
> >> >> b/tools/libacpi/dsdt_q35.asl new file mode 100644
> >> >> index 00..cd02946a07
> >> >> --- /dev/null
> >> >> +++ b/tools/libacpi/dsdt_q35.asl
> >> >> @@ -0,0 +1,551 @@
> >> >>
> +/
> **
> >> >> + * DSDT for Xen with Qemu device model (for Q35 machine)
> >> >> + *
> >> >> + * Copyright (c) 2004, Intel Corporation.
> >> >> + *
> >> >> + * This program is free software; you can redistribute it and/or
> >> >> modify
> >> >> + * it under the terms of the GNU Lesser General Public License as
> >> >> published
> >> >> + * by the Free Software Foundation; version 2.1 only. with the
> >> >> special
> >> >> + * exception on linking described in file LICENSE.
> >> >
> >> >I don't see the 'LICENSE' file in Xen's directory?
> >> >
> >> >Also, your email does not seem to be coming from Intel, so I have to
> >> >ask, where did this file originally come from?
> >>
> >> It's basically Xen's dsdt.asl with some modifications related to Q35.
> >> Currently only few modifications needed, but in the future dsdt.asl
> >> and dsdt_q35.asl will diverge more from each other -- that's the
> >> reason why a separate file was forked instead applying these changes
> >> to dsdt.asl directly, for example, as #ifdef-parts.
> >
> >OK, as such you should make a seperate patch that adds this file (and
> >be completly unmodified) and make sure you CC Intel folks (Kevin, et
> >all) so they can Ack it.
> 
> Kevin -- I assume you mean Kevin Tian ? Cc'ing
> him.
> Please let me know other persons from Intel who are also responsible,
> the MAINTAINERS file doesn't tell much about Intel people
> regarding /libacpi, unfortunately.

I'm not the maintainer of libacpi (should be Jan?). But CC my
colleague (Chao Peng) here who did some study of Q35 support
before and can help review.

Thanks
Kevin

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

[Xen-devel] [linux-4.1 test] 120468: regressions - FAIL

[osstest service owner]

flight 120468 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120468/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 6 kernel-build fail REGR. vs. 118294
 build-i386-pvops  6 kernel-build fail REGR. vs. 118294

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-examine  6 xen-installfail pass in 120380
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeat  fail pass in 120380

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-examine   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118294
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118294
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118294
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118294
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-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-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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 

[Xen-devel] [xen-4.10-testing bisection] complete build-armhf-xsm

[osstest service owner]

branch xen-4.10-testing
xenbranch xen-4.10-testing
job build-armhf-xsm
testid xen-build

Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  da3a46d017d6c786230cc74589ef3ed35b96cfa9
  Bug not present: b6a6458b13dc6f04e17620447a760ff70b1eb4c6
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/120624/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.10-testing/build-armhf-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.10-testing/build-armhf-xsm.xen-build
 --summary-out=tmp/120624.bisection-summary --basis-template=120244 
--blessings=real,real-bisect xen-4.10-testing build-armhf-xsm xen-build
Searching for failure / basis pass:
 120352 fail [host=cubietruck-metzinger] / 120244 [host=cubietruck-braque] 
120065 ok.
Failure / basis pass flights: 120352 / 120065
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest bb019fb2cbbe23e2419e07bf347f45415360677d 
0d2f9c89f77ad0342d38c88377ef97b3a1337c7d
Basis pass bb019fb2cbbe23e2419e07bf347f45415360677d 
a6780c122b863d2b626747a6b93ad6bd89fa11ec
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen.git#bb019fb2cbbe23e2419e07bf347f45415360677d-bb019fb2cbbe23e2419e07bf347f45415360677d
 
git://xenbits.xen.org/xen.git#a6780c122b863d2b626747a6b93ad6bd89fa11ec-0d2f9c89f77ad0342d38c88377ef97b3a1337c7d
Loaded 1001 nodes in revision graph
Searching for test results:
 120065 pass bb019fb2cbbe23e2419e07bf347f45415360677d 
a6780c122b863d2b626747a6b93ad6bd89fa11ec
 120244 [host=cubietruck-braque]
 120352 fail bb019fb2cbbe23e2419e07bf347f45415360677d 
0d2f9c89f77ad0342d38c88377ef97b3a1337c7d
 120570 fail bb019fb2cbbe23e2419e07bf347f45415360677d 
186c2f57bd2ef58a473b25b728d6f1c61f22391c
 120590 pass bb019fb2cbbe23e2419e07bf347f45415360677d 
b6a6458b13dc6f04e17620447a760ff70b1eb4c6
 120574 fail bb019fb2cbbe23e2419e07bf347f45415360677d 
7027acfc1fa33aa538b4bd378c8fd5236ad66ffa
 120576 fail bb019fb2cbbe23e2419e07bf347f45415360677d 
da3a46d017d6c786230cc74589ef3ed35b96cfa9
 120553 pass bb019fb2cbbe23e2419e07bf347f45415360677d 
a6780c122b863d2b626747a6b93ad6bd89fa11ec
 120560 fail bb019fb2cbbe23e2419e07bf347f45415360677d 
0d2f9c89f77ad0342d38c88377ef97b3a1337c7d
 120579 pass bb019fb2cbbe23e2419e07bf347f45415360677d 
e3dfd5d1dda9be764273f36e04380a6cd66401bc
 120585 pass bb019fb2cbbe23e2419e07bf347f45415360677d 
b6a6458b13dc6f04e17620447a760ff70b1eb4c6
 120588 fail bb019fb2cbbe23e2419e07bf347f45415360677d 
da3a46d017d6c786230cc74589ef3ed35b96cfa9
 120605 fail bb019fb2cbbe23e2419e07bf347f45415360677d 
da3a46d017d6c786230cc74589ef3ed35b96cfa9
 120612 pass bb019fb2cbbe23e2419e07bf347f45415360677d 
b6a6458b13dc6f04e17620447a760ff70b1eb4c6
 120624 fail bb019fb2cbbe23e2419e07bf347f45415360677d 
da3a46d017d6c786230cc74589ef3ed35b96cfa9
Searching for interesting versions
 Result found: flight 120065 (pass), for basis pass
 Result found: flight 120352 (fail), for basis failure
 Repro found: flight 120553 (pass), for basis pass
 Repro found: flight 120560 (fail), for basis failure
 0 revisions at bb019fb2cbbe23e2419e07bf347f45415360677d 
b6a6458b13dc6f04e17620447a760ff70b1eb4c6
No revisions left to test, checking graph state.
 Result found: flight 120585 (pass), for last pass
 Result found: flight 120588 (fail), for first failure
 Repro found: flight 120590 (pass), for last pass
 Repro found: flight 120605 (fail), for first failure
 Repro found: flight 120612 (pass), for last pass
 Repro found: flight 120624 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  da3a46d017d6c786230cc74589ef3ed35b96cfa9
  Bug not present: b6a6458b13dc6f04e17620447a760ff70b1eb4c6
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/120624/


  (Revision log too long, omitted.)

Revision graph left in 
/home/logs/results/bisect/xen-4.10-testing/build-armhf-xsm.xen-build.{dot,ps,png,html,svg}.

120624: tolerable ALL FAIL

flight 120624 xen-4.10-testing real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/120624/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-armhf-xsm   6 xen-build   fail baseline untested


jobs:
 build-armhf-xsm  fail



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

Logs, config files, etc. are 

[Xen-devel] [linux-4.1 bisection] complete build-i386-pvops

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-i386-pvops
testid kernel-build

Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
  Bug introduced:  6f20f6d4c095967c3debdb1d4c224ebf3da85452
  Bug not present: 200d858d94b4d8ed7a287e3a3c2b860ae9e17e83
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/120621/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.1/build-i386-pvops.kernel-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-4.1/build-i386-pvops.kernel-build 
--summary-out=tmp/120621.bisection-summary --basis-template=118294 
--blessings=real,real-bisect linux-4.1 build-i386-pvops kernel-build
Searching for failure / basis pass:
 120468 fail [host=chardonnay1] / 118294 [host=huxelrebe0] 118279 
[host=huxelrebe1] 117197 [host=baroque0] 117118 [host=huxelrebe0] 116976 
[host=baroque1] 116949 [host=baroque0] 116145 [host=rimava1] 116124 
[host=huxelrebe1] 116104 [host=huxelrebe0] 115724 [host=huxelrebe1] 115709 
[host=elbling0] 115693 ok.
Failure / basis pass flights: 120468 / 115693
Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Latest 6f20f6d4c095967c3debdb1d4c224ebf3da85452 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
Basis pass 200d858d94b4d8ed7a287e3a3c2b860ae9e17e83 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#200d858d94b4d8ed7a287e3a3c2b860ae9e17e83-6f20f6d4c095967c3debdb1d4c224ebf3da85452
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
adhoc-revtuple-generator: tree discontiguous: linux-stable
Loaded 2 nodes in revision graph
Searching for test results:
 109834 [host=italia1]
 109844 [host=huxelrebe1]
 109845 [host=huxelrebe1]
 109869 [host=nobling1]
 109936 [host=nobling1]
 109983 [host=elbling0]
 110002 pass irrelevant
 110472 [host=chardonnay0]
 95 [host=fiano0]
 113603 [host=elbling1]
 114665 [host=rimava0]
 114678 [host=fiano1]
 114646 [host=italia1]
 114699 [host=merlot1]
 115693 pass 200d858d94b4d8ed7a287e3a3c2b860ae9e17e83 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 115709 [host=elbling0]
 115724 [host=huxelrebe1]
 115745 [host=huxelrebe1]
 116104 [host=huxelrebe0]
 116124 [host=huxelrebe1]
 116145 [host=rimava1]
 116976 [host=baroque1]
 116949 [host=baroque0]
 117012 [host=chardonnay0]
 117026 [host=merlot0]
 117118 [host=huxelrebe0]
 117197 [host=baroque0]
 118279 [host=huxelrebe1]
 118294 [host=huxelrebe0]
 118293 [host=huxelrebe1]
 120380 fail 6f20f6d4c095967c3debdb1d4c224ebf3da85452 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120338 fail 6f20f6d4c095967c3debdb1d4c224ebf3da85452 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120529 pass 200d858d94b4d8ed7a287e3a3c2b860ae9e17e83 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120468 fail 6f20f6d4c095967c3debdb1d4c224ebf3da85452 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120592 fail 6f20f6d4c095967c3debdb1d4c224ebf3da85452 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120609 pass 200d858d94b4d8ed7a287e3a3c2b860ae9e17e83 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 120621 fail 6f20f6d4c095967c3debdb1d4c224ebf3da85452 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 63996 [host=nocera1]
 65699 pass irrelevant
 65782 [host=italia0]
 65781 [host=italia0]
 66399 [host=pinot1]
 59031 [host=nocera1]
 59054 [host=pinot1]
 59092 [host=elbling1]
 59141 [host=nocera1]
 59143 [host=nocera1]
 59198 [host=nocera1]
 59275 [host=nocera0]
 59393 [host=nocera0]
 59826 [host=nocera1]
 59811 [host=nocera1]
 59895 [host=italia0]
 59911 [host=italia1]
 59960 [host=pinot0]
 59909 [host=pinot0]
 60030 [host=fiano0]
 60547 [host=nocera0]
 60654 [host=nocera1]
 60785 [host=nocera1]
 60746 [host=nocera1]
 61947 [host=nocera0]
 62053 [host=nocera1]
 62256 [host=nocera1]
 62318 [host=nocera0]
 62317 [host=nocera0]
 62540 [host=nocera1]
 62690 [host=nocera0]
 62610 [host=nocera1]
 62655 [host=nocera1]
 62659 [host=nocera1]
 62738 [host=nocera0]
 62831 [host=nocera0]
 62963 [host=nocera0]
 62951 [host=nocera0]
 62935 [host=nocera1]
 62962 [host=nocera0]
 63000 [host=nocera1]
 62976 [host=nocera1]
 62987 [host=nocera0]
 63030 [host=nocera1]
 63013 [host=nocera1]
 63067 [host=nocera1]
 63223 [host=nocera1]
 63341 [host=rimava0]
 79008 [host=fiano1]
 79090 [host=huxelrebe1]
 79218 [host=italia1]
 79162 [host=chardonnay0]
 79387 [host=rimava0]
 79430 [host=italia0]
 79527 

Re: [Xen-devel] [RFC PATCH 16/30] q35/xen: Add Xen platform device support for Q35

[Eduardo Habkost]

On Tue, Mar 13, 2018 at 06:56:37AM +1000, Alexey G wrote:
> On Mon, 12 Mar 2018 16:44:06 -0300
> Eduardo Habkost  wrote:
> 
> >On Tue, Mar 13, 2018 at 04:34:01AM +1000, Alexey Gerasimenko wrote:
> >> Current Xen/QEMU method to control Xen Platform device on i440 is a
> >> bit odd -- enabling/disabling Xen platform device actually modifies
> >> the QEMU emulated machine type, namely xenfv <--> pc.
> >> 
> >> In order to avoid multiplying machine types, use a new way to
> >> control Xen Platform device for QEMU -- "xen-platform-dev" machine
> >> property (bool). To maintain backward compatibility with existing
> >> Xen/QEMU setups, this is only applicable to q35 machine currently.
> >> i440 emulation still uses the old method (i.e. xenfv/pc machine
> >> selection) to control Xen Platform device, this may be changed later
> >> to xen-platform-dev property as well.
> >> 
> >> This way we can use a single machine type (q35) and change just
> >> xen-platform-dev value to on/off to control Xen platform device.
> >> 
> >> Signed-off-by: Alexey Gerasimenko 
> >> ---  
> >[...]
> >> diff --git a/qemu-options.hx b/qemu-options.hx
> >> index 6585058c6c..cee0b92028 100644
> >> --- a/qemu-options.hx
> >> +++ b/qemu-options.hx
> >> @@ -38,6 +38,7 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
> >>  "dump-guest-core=on|off include guest memory in
> >> a core dump (default=on)\n" "mem-merge=on|off
> >> controls memory merge support (default: on)\n" "
> >> igd-passthru=on|off controls IGD GFX passthrough support
> >> (default=off)\n"
> >> +"xen-platform-dev=on|off controls Xen Platform
> >> device (default=off)\n" "aes-key-wrap=on|off
> >> controls support for AES key wrapping (default=on)\n"
> >> "dea-key-wrap=on|off controls support for DEA key
> >> wrapping (default=on)\n" "suppress-vmdesc=on|off
> >> disables self-describing migration (default=off)\n"  
> >
> >What are the obstacles preventing "-device xen-platform" from
> >working?  It would be better than adding a new boolean option to
> >-machine.
> 
> I guess the initial assumption was that changing the
> xen_platform_device value in Xen's options may cause some additional
> changes in platform configuration besides adding (or not) the Xen
> Platform device, hence a completely different machine type was chosen
> (xenfv).
> 
> At the moment pc,accel=xen/xenfv selection mostly governs
> only the Xen Platform device presence. Also setting max_cpus to
> HVM_MAX_VCPUS depends on it, but this doesn't applicable to a
> 'pc,accel=xen' machine for some reason.
> 
> If applying HVM_MAX_VCPUS to max_cpus is really necessary I think it's
> better to set it unconditionally for all 'accel=xen' HVM machine
> types inside xen_enabled() block. Right now it's missing for
> pc,accel=xen and q35,accel=xen.

If you are talking about MachineClass::max_cpus, note that it is
returned by query-machines, so it's supposed to be a static
value.  Changing it a runtime would mean the query-machines value
is incorrect.

Is HVM_MAX_CPUS higher or lower than 255?  If it's higher, does
it mean the current value on pc and q35 isn't accurate?


> 
> I'll check if supplying the Xen platform device via the '-device' option
> will be ok for all usage cases.

Is HVM_MAX_CPUS something that needs to be enabled because of
accel=xen or because or the xen-platform device?

If it's just because of accel=xen, we could introduce a
AccelClass::max_cpus() method (we also have KVM-imposed CPU count
limits, currently implemented inside kvm_init()).

-- 
Eduardo

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

Re: [Xen-devel] [RFC PATCH 01/12] libacpi: new DSDT ACPI table for Q35

[Alexey G]

On Mon, 12 Mar 2018 16:32:27 -0400
Konrad Rzeszutek Wilk  wrote:

>On Tue, Mar 13, 2018 at 06:10:35AM +1000, Alexey G wrote:
>> On Mon, 12 Mar 2018 15:38:03 -0400
>> Konrad Rzeszutek Wilk  wrote:
>>   
>> >On Tue, Mar 13, 2018 at 04:33:46AM +1000, Alexey Gerasimenko
>> >wrote:  
>> >> This patch adds the DSDT table for Q35 (new
>> >> tools/libacpi/dsdt_q35.asl file). There are not many differences
>> >> with dsdt.asl (for i440) at the moment, namely:
>> >> 
>> >> - BDF location of LPC Controller
>> >> - Minor changes related to FDC detection
>> >> - Addition of _OSC method to inform OSPM about PCIe features
>> >> supported
>> >> 
>> >> As we are still using 4 PCI router links and their corresponding
>> >> device/register addresses are same (offset 0x60), no need to
>> >> change PCI routing descriptions.
>> >> 
>> >> Also, ACPI hotplug is still used to control passed through device
>> >> hot (un)plug (as it was for i440).
>> >> 
>> >> Signed-off-by: Alexey Gerasimenko 
>> >> ---
>> >>  tools/libacpi/dsdt_q35.asl | 551
>> >> + 1 file changed, 551
>> >> insertions(+) create mode 100644 tools/libacpi/dsdt_q35.asl
>> >> 
>> >> diff --git a/tools/libacpi/dsdt_q35.asl
>> >> b/tools/libacpi/dsdt_q35.asl new file mode 100644
>> >> index 00..cd02946a07
>> >> --- /dev/null
>> >> +++ b/tools/libacpi/dsdt_q35.asl
>> >> @@ -0,0 +1,551 @@
>> >> +/**
>> >> + * DSDT for Xen with Qemu device model (for Q35 machine)
>> >> + *
>> >> + * Copyright (c) 2004, Intel Corporation.
>> >> + *
>> >> + * This program is free software; you can redistribute it and/or
>> >> modify
>> >> + * it under the terms of the GNU Lesser General Public License as
>> >> published
>> >> + * by the Free Software Foundation; version 2.1 only. with the
>> >> special
>> >> + * exception on linking described in file LICENSE.
>> >
>> >I don't see the 'LICENSE' file in Xen's directory?
>> >
>> >Also, your email does not seem to be coming from Intel, so I have to
>> >ask, where did this file originally come from?  
>> 
>> It's basically Xen's dsdt.asl with some modifications related to Q35.
>> Currently only few modifications needed, but in the future dsdt.asl
>> and dsdt_q35.asl will diverge more from each other -- that's the
>> reason why a separate file was forked instead applying these changes
>> to dsdt.asl directly, for example, as #ifdef-parts.  
>
>OK, as such you should make a seperate patch that adds this file (and
>be completly unmodified) and make sure you CC Intel folks (Kevin, et
>all) so they can Ack it.

Kevin -- I assume you mean Kevin Tian ? Cc'ing
him.
Please let me know other persons from Intel who are also responsible,
the MAINTAINERS file doesn't tell much about Intel people
regarding /libacpi, unfortunately.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-livepatch 7 xen-boot fail REGR. vs. 120037
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 120037
 test-amd64-i386-migrupgrade  11 xen-boot/dst_hostfail REGR. vs. 120037
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 120037
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 120037
 test-amd64-i386-qemuu-rhel6hvm-intel 8 host-ping-check-xen fail REGR. vs. 
120037
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 120037
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 120037
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 120037
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 120037
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 120037
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 120037
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 120037
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
120037
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 120037
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 120037
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 120037
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 120037
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 120037
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
120037
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 120037
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 120037
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 120037
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 120037
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 120037
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 120037
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 120037
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 120037
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 120037
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 120037
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 120037
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 120037
 test-amd64-amd64-i386-pvgrub 10 debian-di-installfail REGR. vs. 120037

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 120001
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 120037
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 120037
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 120037
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 120037
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 120037
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 120037
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-xl-pvshim 7 xen-boot fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 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-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never 

Re: [Xen-devel] [RFC PATCH 16/30] q35/xen: Add Xen platform device support for Q35

[Alexey G]

On Mon, 12 Mar 2018 16:44:06 -0300
Eduardo Habkost  wrote:

>On Tue, Mar 13, 2018 at 04:34:01AM +1000, Alexey Gerasimenko wrote:
>> Current Xen/QEMU method to control Xen Platform device on i440 is a
>> bit odd -- enabling/disabling Xen platform device actually modifies
>> the QEMU emulated machine type, namely xenfv <--> pc.
>> 
>> In order to avoid multiplying machine types, use a new way to
>> control Xen Platform device for QEMU -- "xen-platform-dev" machine
>> property (bool). To maintain backward compatibility with existing
>> Xen/QEMU setups, this is only applicable to q35 machine currently.
>> i440 emulation still uses the old method (i.e. xenfv/pc machine
>> selection) to control Xen Platform device, this may be changed later
>> to xen-platform-dev property as well.
>> 
>> This way we can use a single machine type (q35) and change just
>> xen-platform-dev value to on/off to control Xen platform device.
>> 
>> Signed-off-by: Alexey Gerasimenko 
>> ---  
>[...]
>> diff --git a/qemu-options.hx b/qemu-options.hx
>> index 6585058c6c..cee0b92028 100644
>> --- a/qemu-options.hx
>> +++ b/qemu-options.hx
>> @@ -38,6 +38,7 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
>>  "dump-guest-core=on|off include guest memory in
>> a core dump (default=on)\n" "mem-merge=on|off
>> controls memory merge support (default: on)\n" "
>> igd-passthru=on|off controls IGD GFX passthrough support
>> (default=off)\n"
>> +"xen-platform-dev=on|off controls Xen Platform
>> device (default=off)\n" "aes-key-wrap=on|off
>> controls support for AES key wrapping (default=on)\n"
>> "dea-key-wrap=on|off controls support for DEA key
>> wrapping (default=on)\n" "suppress-vmdesc=on|off
>> disables self-describing migration (default=off)\n"  
>
>What are the obstacles preventing "-device xen-platform" from
>working?  It would be better than adding a new boolean option to
>-machine.

I guess the initial assumption was that changing the
xen_platform_device value in Xen's options may cause some additional
changes in platform configuration besides adding (or not) the Xen
Platform device, hence a completely different machine type was chosen
(xenfv).

At the moment pc,accel=xen/xenfv selection mostly governs
only the Xen Platform device presence. Also setting max_cpus to
HVM_MAX_VCPUS depends on it, but this doesn't applicable to a
'pc,accel=xen' machine for some reason.

If applying HVM_MAX_VCPUS to max_cpus is really necessary I think it's
better to set it unconditionally for all 'accel=xen' HVM machine
types inside xen_enabled() block. Right now it's missing for
pc,accel=xen and q35,accel=xen.

I'll check if supplying the Xen platform device via the '-device' option
will be ok for all usage cases.

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

Re: [Xen-devel] [RFC PATCH 01/12] libacpi: new DSDT ACPI table for Q35

[Konrad Rzeszutek Wilk]

On Tue, Mar 13, 2018 at 06:10:35AM +1000, Alexey G wrote:
> On Mon, 12 Mar 2018 15:38:03 -0400
> Konrad Rzeszutek Wilk  wrote:
> 
> >On Tue, Mar 13, 2018 at 04:33:46AM +1000, Alexey Gerasimenko wrote:
> >> This patch adds the DSDT table for Q35 (new
> >> tools/libacpi/dsdt_q35.asl file). There are not many differences
> >> with dsdt.asl (for i440) at the moment, namely:
> >> 
> >> - BDF location of LPC Controller
> >> - Minor changes related to FDC detection
> >> - Addition of _OSC method to inform OSPM about PCIe features
> >> supported
> >> 
> >> As we are still using 4 PCI router links and their corresponding
> >> device/register addresses are same (offset 0x60), no need to change
> >> PCI routing descriptions.
> >> 
> >> Also, ACPI hotplug is still used to control passed through device hot
> >> (un)plug (as it was for i440).
> >> 
> >> Signed-off-by: Alexey Gerasimenko 
> >> ---
> >>  tools/libacpi/dsdt_q35.asl | 551
> >> + 1 file changed, 551
> >> insertions(+) create mode 100644 tools/libacpi/dsdt_q35.asl
> >> 
> >> diff --git a/tools/libacpi/dsdt_q35.asl b/tools/libacpi/dsdt_q35.asl
> >> new file mode 100644
> >> index 00..cd02946a07
> >> --- /dev/null
> >> +++ b/tools/libacpi/dsdt_q35.asl
> >> @@ -0,0 +1,551 @@
> >> +/**
> >> + * DSDT for Xen with Qemu device model (for Q35 machine)
> >> + *
> >> + * Copyright (c) 2004, Intel Corporation.
> >> + *
> >> + * This program is free software; you can redistribute it and/or
> >> modify
> >> + * it under the terms of the GNU Lesser General Public License as
> >> published
> >> + * by the Free Software Foundation; version 2.1 only. with the
> >> special
> >> + * exception on linking described in file LICENSE.  
> >
> >I don't see the 'LICENSE' file in Xen's directory?
> >
> >Also, your email does not seem to be coming from Intel, so I have to
> >ask, where did this file originally come from?
> 
> It's basically Xen's dsdt.asl with some modifications related to Q35.
> Currently only few modifications needed, but in the future dsdt.asl and
> dsdt_q35.asl will diverge more from each other -- that's the reason why
> a separate file was forked instead applying these changes to dsdt.asl
> directly, for example, as #ifdef-parts.

OK, as such you should make a seperate patch that adds this file (and
be completly unmodified) and make sure you CC Intel folks (Kevin, et all) so
they can Ack it.

Thank you.


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

Re: [Xen-devel] Regression with commit "x86/pv: Drop int80_bounce from struct pv_vcpu" f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1

[Sander Eikelenboom]

On 12/03/18 21:04, Boris Ostrovsky wrote:
> On 03/12/2018 03:05 PM, Andrew Cooper wrote:
>> On 10/03/18 16:27, Andrew Cooper wrote:
>>> On 10/03/2018 16:14, Sander Eikelenboom wrote:
 Hi Andrew,

 It seems commit "x86/pv: Drop int80_bounce from struct pv_vcpu" 
 (f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1) causes an issue on my machine, 
 an AMD phenom X6.

 When trying to installing a new kernel package which runs the Debian
 update-initramfs tools with xen-unstable which happened to be at commit 
 c9bd8a73656d7435b1055ee8825823aee995993e as last commit the tool stalls
 and i get this kernel splat:

 [  284.910674] BUG: unable to handle kernel NULL pointer dereference at 
 
 [  284.919696] IP:   (null)
 [  284.928315] PGD 0 P4D 0 
 [  284.943343] Oops: 0010 [#1] SMP NOPTI
 [  284.957008] Modules linked in:
 [  284.965521] CPU: 5 PID: 24729 Comm: ld-linux.so.2 Not tainted 
 4.16.0-rc4-20180305-linus-pvhpatches-doflr+ #1
 [  284.974154] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS 
 V1.8B1 09/13/2010
 [  284.983198] RIP: e030:  (null)
 [  284.992006] RSP: e02b:c90001497ed8 EFLAGS: 00010286
 [  285.000612] RAX:  RBX: 880074c64500 RCX: 
 82f8d1c0
 [  285.009122] RDX: 82f8d1c0 RSI: 20020002 RDI: 
 82f8d1c0
 [  285.017598] RBP: 880074c64b7c R08:  R09: 
 
 [  285.025999] R10:  R11:  R12: 
 82f8d1c0
 [  285.034400] R13:  R14:  R15: 
 880074c64b50
 [  285.042718] FS:  7f919fe2eb40() GS:88007d14() 
 knlGS:
 [  285.051001] CS:  e033 DS: 002b ES: 002b CR0: 80050033
 [  285.059458] CR2:  CR3: 02824000 CR4: 
 0660
 [  285.067813] Call Trace:
 [  285.075947]  ? task_work_run+0x85/0xa0
 [  285.084025]  ? exit_to_usermode_loop+0x72/0x80
 [  285.091980]  ? do_int80_syscall_32+0xfe/0x120
 [  285.099896]  ? entry_INT80_compat+0x7f/0x90
 [  285.107688]  ? fpu__drop+0x23/0x40
 [  285.115362] Code:  Bad RIP value.
 [  285.123072] RIP:   (null) RSP: c90001497ed8
 [  285.130714] CR2: 
 [  285.138219] ---[ end trace 4d3317497f4ba022 ]---
 [  285.145671] Fixing recursive fault but reboot is needed!

 After updating xen-unstable to the latest available commit 
 185413355fe331cbc926d48568838227234c9a20,
 the tool doesn't stall anymore but i still get a kernel splat:

 [  198.594638] [ cut here ]
 [  198.594641] Invalid address limit on user-mode return
 [  198.594651] WARNING: CPU: 1 PID: 75 at ./include/linux/syscalls.h:236 
 do_int80_syscall_32+0xe5/0x120
 [  198.594652] Modules linked in:
 [  198.594655] CPU: 1 PID: 75 Comm: kworker/1:1 Not tainted 
 4.16.0-rc4-20180305-linus-pvhpatches-doflr+ #1
 [  198.594656] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS 
 V1.8B1 09/13/2010
 [  198.594658] Workqueue: events free_work
 [  198.594660] RIP: e030:do_int80_syscall_32+0xe5/0x120
 [  198.594661] RSP: e02b:c9b8ff40 EFLAGS: 00010086
 [  198.594662] RAX: 0029 RBX: c9b8ff58 RCX: 
 82868e38
 [  198.594663] RDX: 0001 RSI: 0001 RDI: 
 0001
 [  198.594664] RBP: 880078623980 R08: 0dfa R09: 
 063b
 [  198.594664] R10:  R11: 063b R12: 
 
 [  198.594665] R13:  R14:  R15: 
 
 [  198.594672] FS:  7fa252372b40() GS:88007d04() 
 knlGS:
 [  198.594673] CS:  e033 DS:  ES:  CR0: 80050033
 [  198.594674] CR2: f7f303e4 CR3: 02824000 CR4: 
 0660
 [  198.594676] Call Trace:
 [  198.594683]  entry_INT80_compat+0x7f/0x90
 [  198.594685]  ? vunmap_page_range+0x2a0/0x340
 [  198.594686] Code: 03 7f 48 8b 75 00 f7 c6 0e 38 00 00 75 2e 83 65 08 f9 
 5b 5d c3 e8 0c fb ff ff e9 53 ff ff ff 48 c7 c7 58 35 57 82 e8 ab 3e 0c 00 
 <0f> 0b bf 09 00 00 00 48 89 ee e8 8c 00 0d 00 eb b8 48 89 df e8 
 [  198.594706] ---[ end trace 90bcd2147bc825ef ]---

 After reverting commit f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1 the issue 
 is gone.
>>> :(
>>>
>>> This will be the issue which OSSTest is probably bisecting to as well. 
>>> It is quite odd to see a 64bit process using int80 as opposed to syscall.
>>>
>>> I'll see about double checking my assembly code, and will also try to
>>> identify why my unit tests haven't noticed an issue.
>> As a progress report, this is proving to be terrible bug to debug.
>>

Re: [Xen-devel] [RFC PATCH 01/12] libacpi: new DSDT ACPI table for Q35

[Alexey G]

On Mon, 12 Mar 2018 15:38:03 -0400
Konrad Rzeszutek Wilk  wrote:

>On Tue, Mar 13, 2018 at 04:33:46AM +1000, Alexey Gerasimenko wrote:
>> This patch adds the DSDT table for Q35 (new
>> tools/libacpi/dsdt_q35.asl file). There are not many differences
>> with dsdt.asl (for i440) at the moment, namely:
>> 
>> - BDF location of LPC Controller
>> - Minor changes related to FDC detection
>> - Addition of _OSC method to inform OSPM about PCIe features
>> supported
>> 
>> As we are still using 4 PCI router links and their corresponding
>> device/register addresses are same (offset 0x60), no need to change
>> PCI routing descriptions.
>> 
>> Also, ACPI hotplug is still used to control passed through device hot
>> (un)plug (as it was for i440).
>> 
>> Signed-off-by: Alexey Gerasimenko 
>> ---
>>  tools/libacpi/dsdt_q35.asl | 551
>> + 1 file changed, 551
>> insertions(+) create mode 100644 tools/libacpi/dsdt_q35.asl
>> 
>> diff --git a/tools/libacpi/dsdt_q35.asl b/tools/libacpi/dsdt_q35.asl
>> new file mode 100644
>> index 00..cd02946a07
>> --- /dev/null
>> +++ b/tools/libacpi/dsdt_q35.asl
>> @@ -0,0 +1,551 @@
>> +/**
>> + * DSDT for Xen with Qemu device model (for Q35 machine)
>> + *
>> + * Copyright (c) 2004, Intel Corporation.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify
>> + * it under the terms of the GNU Lesser General Public License as
>> published
>> + * by the Free Software Foundation; version 2.1 only. with the
>> special
>> + * exception on linking described in file LICENSE.  
>
>I don't see the 'LICENSE' file in Xen's directory?
>
>Also, your email does not seem to be coming from Intel, so I have to
>ask, where did this file originally come from?

It's basically Xen's dsdt.asl with some modifications related to Q35.
Currently only few modifications needed, but in the future dsdt.asl and
dsdt_q35.asl will diverge more from each other -- that's the reason why
a separate file was forked instead applying these changes to dsdt.asl
directly, for example, as #ifdef-parts.

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

Re: [Xen-devel] Regression with commit "x86/pv: Drop int80_bounce from struct pv_vcpu" f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1

[Boris Ostrovsky]

On 03/12/2018 03:05 PM, Andrew Cooper wrote:
> On 10/03/18 16:27, Andrew Cooper wrote:
>> On 10/03/2018 16:14, Sander Eikelenboom wrote:
>>> Hi Andrew,
>>>
>>> It seems commit "x86/pv: Drop int80_bounce from struct pv_vcpu" 
>>> (f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1) causes an issue on my machine, 
>>> an AMD phenom X6.
>>>
>>> When trying to installing a new kernel package which runs the Debian
>>> update-initramfs tools with xen-unstable which happened to be at commit 
>>> c9bd8a73656d7435b1055ee8825823aee995993e as last commit the tool stalls
>>> and i get this kernel splat:
>>>
>>> [  284.910674] BUG: unable to handle kernel NULL pointer dereference at 
>>> 
>>> [  284.919696] IP:   (null)
>>> [  284.928315] PGD 0 P4D 0 
>>> [  284.943343] Oops: 0010 [#1] SMP NOPTI
>>> [  284.957008] Modules linked in:
>>> [  284.965521] CPU: 5 PID: 24729 Comm: ld-linux.so.2 Not tainted 
>>> 4.16.0-rc4-20180305-linus-pvhpatches-doflr+ #1
>>> [  284.974154] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS 
>>> V1.8B1 09/13/2010
>>> [  284.983198] RIP: e030:  (null)
>>> [  284.992006] RSP: e02b:c90001497ed8 EFLAGS: 00010286
>>> [  285.000612] RAX:  RBX: 880074c64500 RCX: 
>>> 82f8d1c0
>>> [  285.009122] RDX: 82f8d1c0 RSI: 20020002 RDI: 
>>> 82f8d1c0
>>> [  285.017598] RBP: 880074c64b7c R08:  R09: 
>>> 
>>> [  285.025999] R10:  R11:  R12: 
>>> 82f8d1c0
>>> [  285.034400] R13:  R14:  R15: 
>>> 880074c64b50
>>> [  285.042718] FS:  7f919fe2eb40() GS:88007d14() 
>>> knlGS:
>>> [  285.051001] CS:  e033 DS: 002b ES: 002b CR0: 80050033
>>> [  285.059458] CR2:  CR3: 02824000 CR4: 
>>> 0660
>>> [  285.067813] Call Trace:
>>> [  285.075947]  ? task_work_run+0x85/0xa0
>>> [  285.084025]  ? exit_to_usermode_loop+0x72/0x80
>>> [  285.091980]  ? do_int80_syscall_32+0xfe/0x120
>>> [  285.099896]  ? entry_INT80_compat+0x7f/0x90
>>> [  285.107688]  ? fpu__drop+0x23/0x40
>>> [  285.115362] Code:  Bad RIP value.
>>> [  285.123072] RIP:   (null) RSP: c90001497ed8
>>> [  285.130714] CR2: 
>>> [  285.138219] ---[ end trace 4d3317497f4ba022 ]---
>>> [  285.145671] Fixing recursive fault but reboot is needed!
>>>
>>> After updating xen-unstable to the latest available commit 
>>> 185413355fe331cbc926d48568838227234c9a20,
>>> the tool doesn't stall anymore but i still get a kernel splat:
>>>
>>> [  198.594638] [ cut here ]
>>> [  198.594641] Invalid address limit on user-mode return
>>> [  198.594651] WARNING: CPU: 1 PID: 75 at ./include/linux/syscalls.h:236 
>>> do_int80_syscall_32+0xe5/0x120
>>> [  198.594652] Modules linked in:
>>> [  198.594655] CPU: 1 PID: 75 Comm: kworker/1:1 Not tainted 
>>> 4.16.0-rc4-20180305-linus-pvhpatches-doflr+ #1
>>> [  198.594656] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS 
>>> V1.8B1 09/13/2010
>>> [  198.594658] Workqueue: events free_work
>>> [  198.594660] RIP: e030:do_int80_syscall_32+0xe5/0x120
>>> [  198.594661] RSP: e02b:c9b8ff40 EFLAGS: 00010086
>>> [  198.594662] RAX: 0029 RBX: c9b8ff58 RCX: 
>>> 82868e38
>>> [  198.594663] RDX: 0001 RSI: 0001 RDI: 
>>> 0001
>>> [  198.594664] RBP: 880078623980 R08: 0dfa R09: 
>>> 063b
>>> [  198.594664] R10:  R11: 063b R12: 
>>> 
>>> [  198.594665] R13:  R14:  R15: 
>>> 
>>> [  198.594672] FS:  7fa252372b40() GS:88007d04() 
>>> knlGS:
>>> [  198.594673] CS:  e033 DS:  ES:  CR0: 80050033
>>> [  198.594674] CR2: f7f303e4 CR3: 02824000 CR4: 
>>> 0660
>>> [  198.594676] Call Trace:
>>> [  198.594683]  entry_INT80_compat+0x7f/0x90
>>> [  198.594685]  ? vunmap_page_range+0x2a0/0x340
>>> [  198.594686] Code: 03 7f 48 8b 75 00 f7 c6 0e 38 00 00 75 2e 83 65 08 f9 
>>> 5b 5d c3 e8 0c fb ff ff e9 53 ff ff ff 48 c7 c7 58 35 57 82 e8 ab 3e 0c 00 
>>> <0f> 0b bf 09 00 00 00 48 89 ee e8 8c 00 0d 00 eb b8 48 89 df e8 
>>> [  198.594706] ---[ end trace 90bcd2147bc825ef ]---
>>>
>>> After reverting commit f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1 the issue 
>>> is gone.
>> :(
>>
>> This will be the issue which OSSTest is probably bisecting to as well. 
>> It is quite odd to see a 64bit process using int80 as opposed to syscall.
>>
>> I'll see about double checking my assembly code, and will also try to
>> identify why my unit tests haven't noticed an issue.
> As a progress report, this is proving to be terrible bug to debug.
>
> I've confirmed your findings.  However, my repro takes 10 minutes, and
> I've failed to make it any faster.  It is more complicated than just
> 

Re: [Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

[Boris Ostrovsky]

On 03/12/2018 03:26 PM, Sander Eikelenboom wrote:
> On 19/02/18 22:13, Sander Eikelenboom wrote:
>> On 19/02/18 11:16, Juergen Gross wrote:
>>> On 19/02/18 10:47, Sander Eikelenboom wrote:
 On 24/01/18 16:26, George Dunlap wrote:
> On Wed, Jan 24, 2018 at 3:20 PM, Juergen Gross  wrote:
>> On 24/01/18 16:07, George Dunlap wrote:
>>> On Wed, Jan 24, 2018 at 2:10 PM, Boris Ostrovsky
>>>  wrote:
 On 01/24/2018 07:06 AM, Juergen Gross wrote:
> On 24/01/18 11:54, Roger Pau Monné wrote:
>> On Wed, Jan 24, 2018 at 10:42:39AM +, George Dunlap wrote:
>>> On Wed, Jan 24, 2018 at 2:41 AM, Boris Ostrovsky
>>>  wrote:
 On 01/18/2018 05:33 AM, Wei Liu wrote:
> On Thu, Jan 18, 2018 at 11:31:32AM +0100, Juergen Gross wrote:
>> Wei,
>>
>> On 01/12/17 15:14, Juergen Gross wrote:
>>> Instead of locating the RSDP table below 1MB put it just below 
>>> 4GB
>>> like the rest of the ACPI tables in case of PVH guests. This 
>>> will
>>> avoid punching more holes than necessary into the memory map.
>>>
>>> Signed-off-by: Juergen Gross 
>>> Acked-by: Wei Liu 
>> Mind applying this one?
> Don't worry, it is in my queue.
>
> Will come to this and other patches I accumulated soon.
>
> Wei.
 This requires kernel changes, doesn't it?

 https://lists.xenproject.org/archives/html/xen-devel/2017-12/msg00714.html

 And this series apparently never made it to the tree.

 PVH guests are broken now on staging.
>>> And the Linux side of PVH is officially supported now, right?

 AFAIK PVH is still considered a tech preview --- Linux or Xen.
>>> From SUPPORT.md:
>>>
>>> ### x86/PVH guest
>>>
>>> Status: Supported
>>>
>>> I was under the impression that PVH guest in Linux was complete and
>>> stable as of Linux 4.11.  If that's not true it should have been
>>> brought up during the 4.10 development cycle, where we declared PVH
>>> domUs as "supported".
>> So what is the problem here?
>>
>> - current Linux can't be booted as PVH guest with xen-unstable due to
>>   a bug in Linux, patches for Linux are being worked on
>> - booting Linux as PVH guest with xen 4.10 is working
> I was responding to Boris's claim that PVH is considered tech preview.
> I can't say anything one way or the other about PVH in Linux, but PVH
> in Xen is definitely now considered supported.
>
> My subsequent response to Roger ("FWIW I can buy this argument") was
> meant to indicate I didn't have any more objection to the approach you
> guys were planning on taking.
>
>  -George
 L.S.,

 Seems I lost track, is there any progress on this issue ?
 (doesn't seem a fix has landed in 4.16-rc2 yet).
>>> Just sent a new patch series.
>> Just tested and it works fine here.
> Hi Juergen,
>
> I don't know by which tree those patches should arrive at Linus,
> so i can't check if they fell through the cracks somewhere, but 4.16-rc5
> hasn't got them yet.
>


I was just about to send this exact question. Last I saw a note from
Ingo that he put it in tip:x86/boot
(https://lkml.org/lkml/2017/12/11/358) but I don't see it there. (And
I'd think it would have been pulled by Linus by now anyway)

-boris

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

Re: [Xen-devel] [RFC PATCH 16/30] q35/xen: Add Xen platform device support for Q35

[Eduardo Habkost]

On Tue, Mar 13, 2018 at 04:34:01AM +1000, Alexey Gerasimenko wrote:
> Current Xen/QEMU method to control Xen Platform device on i440 is a bit
> odd -- enabling/disabling Xen platform device actually modifies the QEMU
> emulated machine type, namely xenfv <--> pc.
> 
> In order to avoid multiplying machine types, use a new way to control Xen
> Platform device for QEMU -- "xen-platform-dev" machine property (bool).
> To maintain backward compatibility with existing Xen/QEMU setups, this
> is only applicable to q35 machine currently. i440 emulation still uses the
> old method (i.e. xenfv/pc machine selection) to control Xen Platform
> device, this may be changed later to xen-platform-dev property as well.
> 
> This way we can use a single machine type (q35) and change just
> xen-platform-dev value to on/off to control Xen platform device.
> 
> Signed-off-by: Alexey Gerasimenko 
> ---
[...]
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 6585058c6c..cee0b92028 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -38,6 +38,7 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
>  "dump-guest-core=on|off include guest memory in a core 
> dump (default=on)\n"
>  "mem-merge=on|off controls memory merge support 
> (default: on)\n"
>  "igd-passthru=on|off controls IGD GFX passthrough 
> support (default=off)\n"
> +"xen-platform-dev=on|off controls Xen Platform device 
> (default=off)\n"
>  "aes-key-wrap=on|off controls support for AES key 
> wrapping (default=on)\n"
>  "dea-key-wrap=on|off controls support for DEA key 
> wrapping (default=on)\n"
>  "suppress-vmdesc=on|off disables self-describing 
> migration (default=off)\n"

What are the obstacles preventing "-device xen-platform" from
working?  It would be better than adding a new boolean option to
-machine.

-- 
Eduardo

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

Re: [Xen-devel] [RFC PATCH 01/12] libacpi: new DSDT ACPI table for Q35

[Konrad Rzeszutek Wilk]

On Tue, Mar 13, 2018 at 04:33:46AM +1000, Alexey Gerasimenko wrote:
> This patch adds the DSDT table for Q35 (new tools/libacpi/dsdt_q35.asl
> file). There are not many differences with dsdt.asl (for i440) at the
> moment, namely:
> 
> - BDF location of LPC Controller
> - Minor changes related to FDC detection
> - Addition of _OSC method to inform OSPM about PCIe features supported
> 
> As we are still using 4 PCI router links and their corresponding
> device/register addresses are same (offset 0x60), no need to change PCI
> routing descriptions.
> 
> Also, ACPI hotplug is still used to control passed through device hot
> (un)plug (as it was for i440).
> 
> Signed-off-by: Alexey Gerasimenko 
> ---
>  tools/libacpi/dsdt_q35.asl | 551 
> +
>  1 file changed, 551 insertions(+)
>  create mode 100644 tools/libacpi/dsdt_q35.asl
> 
> diff --git a/tools/libacpi/dsdt_q35.asl b/tools/libacpi/dsdt_q35.asl
> new file mode 100644
> index 00..cd02946a07
> --- /dev/null
> +++ b/tools/libacpi/dsdt_q35.asl
> @@ -0,0 +1,551 @@
> +/**
> + * DSDT for Xen with Qemu device model (for Q35 machine)
> + *
> + * Copyright (c) 2004, Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.

I don't see the 'LICENSE' file in Xen's directory?

Also, your email does not seem to be coming from Intel, so I have to ask,
where did this file originally come from?

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

Re: [Xen-devel] [PATCH 1/2] make xen ocaml safe-strings compliant

[Michael Young]

On Mon, 12 Mar 2018, Christian Lindig wrote:


 The problem with the old patch is illustrated by the following section
 from the old patch for tools/ocaml/xenstored/utils.ml
 @@ -85,7 +85,7 @@ let create_unix_socket name =
  let read_file_single_integer filename =
     let fd = Unix.openfile filename [ Unix.O_RDONLY ] 0o640 in
     let buf = String.make 20 (char_of_int 0) in
 -   let sz = Unix.read fd buf 0 20 in
 +   let sz = Unix.read fd (Bytes.of_string buf) 0 20 in
     Unix.close fd;
     int_of_string (String.sub buf 0 sz)

 where the patch makes Unix.read write to a Bytes copy of buf and buf
 itself is unchanged, so int_of_string sees a string of null characters
 rather than a string to convert into a number.


Good analysis. (Bytes.of_string buf) created a buffer for the result from 
read() for which we have no handle.


Reviewing the new patch I believe it is sound. The (new) signature of 
read_mmap is



 val read_mmap : backend_mmap -> 'a -> bytes -> int -> int


The new implementation is below - argument s used to be a string value and is 
now a bytes value. I would suggest to reflect this in the names (using b 
instead of s) as this is about conversion between strings and bytes.

   let read_mmap back con s len =
 -  let rd = Xs_ring.read back.mmap s len in
 +  let stmp = String.make len (char_of_int 0) in
 +  let rd = Xs_ring.read back.mmap stmp len in
 +  Bytes.blit_string stmp 0 s 0 rd;
back.work_again <- (rd > 0);
if rd > 0 then
 back.eventchn_notify ();


Below are the functions that changed their type and where this also should be 
considered:

 -val read_fd : backend_fd -> 'a -> string -> int -> int
 -val read_mmap : backend_mmap -> 'a -> string -> int -> int
 -val read : t -> string -> int -> int
 -val write_fd : backend_fd -> 'a -> string -> int -> int
 +val read_fd : backend_fd -> 'a -> bytes -> int -> int
 +val read_mmap : backend_mmap -> 'a -> bytes -> int -> int
 +val read : t -> bytes -> int -> int
 +val write_fd : backend_fd -> 'a -> bytes -> int -> int


-- Christian


Here is version 4 of the patch where I have replaced the uses of s with b 
where the patch changes it from string to bytes. I have also removed the 
two trailing spaces and changed stmp back to s.


Michael YoungFrom da088e4eef2bbea4be262e12db4c36960ff5145a Mon Sep 17 00:00:00 2001
From: Michael Young 
Date: Mon, 12 Mar 2018 18:49:29 +
Subject: [PATCH v4] make xen ocaml safe-strings compliant

Xen built with ocaml 4.06 gives errors such as
Error: This expression has type bytes but an expression was
expected of type string
as Byte and safe-strings which were introduced in 4.02 are the
default in 4.06.
This patch which is partly by Richard W.M. Jones of Red Hat
from https://bugzilla.redhat.com/show_bug.cgi?id=1526703
fixes these issues.

v4: Where string s is now bytes, rename it to b.

Signed-off-by: Michael Young 
---
 tools/ocaml/libs/xb/xb.ml| 34 ++
 tools/ocaml/libs/xb/xb.mli   | 10 +-
 tools/ocaml/xenstored/logging.ml | 22 +++---
 tools/ocaml/xenstored/stdext.ml  |  2 +-
 tools/ocaml/xenstored/utils.ml   | 20 ++--
 5 files changed, 45 insertions(+), 43 deletions(-)

diff --git a/tools/ocaml/libs/xb/xb.ml b/tools/ocaml/libs/xb/xb.ml
index 50944b5fd6..519842723b 100644
--- a/tools/ocaml/libs/xb/xb.ml
+++ b/tools/ocaml/libs/xb/xb.ml
@@ -40,7 +40,7 @@ type backend_fd =
 
 type backend = Fd of backend_fd | Xenmmap of backend_mmap
 
-type partial_buf = HaveHdr of Partial.pkt | NoHdr of int * string
+type partial_buf = HaveHdr of Partial.pkt | NoHdr of int * bytes
 
 type t =
 {
@@ -52,7 +52,7 @@ type t =
 }
 
 let init_partial_in () = NoHdr
-   (Partial.header_size (), String.make (Partial.header_size()) '\000')
+   (Partial.header_size (), Bytes.make (Partial.header_size()) '\000')
 
 let reconnect t = match t.backend with
| Fd _ ->
@@ -69,26 +69,28 @@ let reconnect t = match t.backend with
 
 let queue con pkt = Queue.push pkt con.pkt_out
 
-let read_fd back con s len =
-   let rd = Unix.read back.fd s 0 len in
+let read_fd back con b len =
+   let rd = Unix.read back.fd b 0 len in
if rd = 0 then
raise End_of_file;
rd
 
-let read_mmap back con s len =
+let read_mmap back con b len =
+   let s = String.make len (char_of_int 0) in
let rd = Xs_ring.read back.mmap s len in
+   Bytes.blit_string s 0 b 0 rd;
back.work_again <- (rd > 0);
if rd > 0 then
back.eventchn_notify ();
rd
 
-let read con s len =
+let read con b len =
match con.backend with
-   | Fd backfd -> read_fd backfd con s len
-   | Xenmmap backmmap -> read_mmap backmmap con s len
+   | Fd backfd -> read_fd backfd con b len
+   | Xenmmap backmmap -> read_mmap backmmap con b len
 
-let write_fd back con s len =
-  

Re: [Xen-devel] Regression with commit "x86/pv: Drop int80_bounce from struct pv_vcpu" f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1

[Sander Eikelenboom]

On 12/03/18 20:05, Andrew Cooper wrote:
> On 10/03/18 16:27, Andrew Cooper wrote:
>> On 10/03/2018 16:14, Sander Eikelenboom wrote:
>>> Hi Andrew,
>>>
>>> It seems commit "x86/pv: Drop int80_bounce from struct pv_vcpu" 
>>> (f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1) causes an issue on my machine, 
>>> an AMD phenom X6.
>>>
>>> When trying to installing a new kernel package which runs the Debian
>>> update-initramfs tools with xen-unstable which happened to be at commit 
>>> c9bd8a73656d7435b1055ee8825823aee995993e as last commit the tool stalls
>>> and i get this kernel splat:
>>>
>>> [  284.910674] BUG: unable to handle kernel NULL pointer dereference at 
>>> 
>>> [  284.919696] IP:   (null)
>>> [  284.928315] PGD 0 P4D 0 
>>> [  284.943343] Oops: 0010 [#1] SMP NOPTI
>>> [  284.957008] Modules linked in:
>>> [  284.965521] CPU: 5 PID: 24729 Comm: ld-linux.so.2 Not tainted 
>>> 4.16.0-rc4-20180305-linus-pvhpatches-doflr+ #1
>>> [  284.974154] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS 
>>> V1.8B1 09/13/2010
>>> [  284.983198] RIP: e030:  (null)
>>> [  284.992006] RSP: e02b:c90001497ed8 EFLAGS: 00010286
>>> [  285.000612] RAX:  RBX: 880074c64500 RCX: 
>>> 82f8d1c0
>>> [  285.009122] RDX: 82f8d1c0 RSI: 20020002 RDI: 
>>> 82f8d1c0
>>> [  285.017598] RBP: 880074c64b7c R08:  R09: 
>>> 
>>> [  285.025999] R10:  R11:  R12: 
>>> 82f8d1c0
>>> [  285.034400] R13:  R14:  R15: 
>>> 880074c64b50
>>> [  285.042718] FS:  7f919fe2eb40() GS:88007d14() 
>>> knlGS:
>>> [  285.051001] CS:  e033 DS: 002b ES: 002b CR0: 80050033
>>> [  285.059458] CR2:  CR3: 02824000 CR4: 
>>> 0660
>>> [  285.067813] Call Trace:
>>> [  285.075947]  ? task_work_run+0x85/0xa0
>>> [  285.084025]  ? exit_to_usermode_loop+0x72/0x80
>>> [  285.091980]  ? do_int80_syscall_32+0xfe/0x120
>>> [  285.099896]  ? entry_INT80_compat+0x7f/0x90
>>> [  285.107688]  ? fpu__drop+0x23/0x40
>>> [  285.115362] Code:  Bad RIP value.
>>> [  285.123072] RIP:   (null) RSP: c90001497ed8
>>> [  285.130714] CR2: 
>>> [  285.138219] ---[ end trace 4d3317497f4ba022 ]---
>>> [  285.145671] Fixing recursive fault but reboot is needed!
>>>
>>> After updating xen-unstable to the latest available commit 
>>> 185413355fe331cbc926d48568838227234c9a20,
>>> the tool doesn't stall anymore but i still get a kernel splat:
>>>
>>> [  198.594638] [ cut here ]
>>> [  198.594641] Invalid address limit on user-mode return
>>> [  198.594651] WARNING: CPU: 1 PID: 75 at ./include/linux/syscalls.h:236 
>>> do_int80_syscall_32+0xe5/0x120
>>> [  198.594652] Modules linked in:
>>> [  198.594655] CPU: 1 PID: 75 Comm: kworker/1:1 Not tainted 
>>> 4.16.0-rc4-20180305-linus-pvhpatches-doflr+ #1
>>> [  198.594656] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS 
>>> V1.8B1 09/13/2010
>>> [  198.594658] Workqueue: events free_work
>>> [  198.594660] RIP: e030:do_int80_syscall_32+0xe5/0x120
>>> [  198.594661] RSP: e02b:c9b8ff40 EFLAGS: 00010086
>>> [  198.594662] RAX: 0029 RBX: c9b8ff58 RCX: 
>>> 82868e38
>>> [  198.594663] RDX: 0001 RSI: 0001 RDI: 
>>> 0001
>>> [  198.594664] RBP: 880078623980 R08: 0dfa R09: 
>>> 063b
>>> [  198.594664] R10:  R11: 063b R12: 
>>> 
>>> [  198.594665] R13:  R14:  R15: 
>>> 
>>> [  198.594672] FS:  7fa252372b40() GS:88007d04() 
>>> knlGS:
>>> [  198.594673] CS:  e033 DS:  ES:  CR0: 80050033
>>> [  198.594674] CR2: f7f303e4 CR3: 02824000 CR4: 
>>> 0660
>>> [  198.594676] Call Trace:
>>> [  198.594683]  entry_INT80_compat+0x7f/0x90
>>> [  198.594685]  ? vunmap_page_range+0x2a0/0x340
>>> [  198.594686] Code: 03 7f 48 8b 75 00 f7 c6 0e 38 00 00 75 2e 83 65 08 f9 
>>> 5b 5d c3 e8 0c fb ff ff e9 53 ff ff ff 48 c7 c7 58 35 57 82 e8 ab 3e 0c 00 
>>> <0f> 0b bf 09 00 00 00 48 89 ee e8 8c 00 0d 00 eb b8 48 89 df e8 
>>> [  198.594706] ---[ end trace 90bcd2147bc825ef ]---
>>>
>>> After reverting commit f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1 the issue 
>>> is gone.
>> :(
>>
>> This will be the issue which OSSTest is probably bisecting to as well. 
>> It is quite odd to see a 64bit process using int80 as opposed to syscall.
>>
>> I'll see about double checking my assembly code, and will also try to
>> identify why my unit tests haven't noticed an issue.
> 
> As a progress report, this is proving to be terrible bug to debug.
> 
> I've confirmed your findings.  However, my repro takes 10 minutes, and
> I've failed to make it any faster.  It is more complicated than just
> 

Re: [Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

[Sander Eikelenboom]

On 19/02/18 22:13, Sander Eikelenboom wrote:
> On 19/02/18 11:16, Juergen Gross wrote:
>> On 19/02/18 10:47, Sander Eikelenboom wrote:
>>> On 24/01/18 16:26, George Dunlap wrote:
 On Wed, Jan 24, 2018 at 3:20 PM, Juergen Gross  wrote:
> On 24/01/18 16:07, George Dunlap wrote:
>> On Wed, Jan 24, 2018 at 2:10 PM, Boris Ostrovsky
>>  wrote:
>>> On 01/24/2018 07:06 AM, Juergen Gross wrote:
 On 24/01/18 11:54, Roger Pau Monné wrote:
> On Wed, Jan 24, 2018 at 10:42:39AM +, George Dunlap wrote:
>> On Wed, Jan 24, 2018 at 2:41 AM, Boris Ostrovsky
>>  wrote:
>>> On 01/18/2018 05:33 AM, Wei Liu wrote:
 On Thu, Jan 18, 2018 at 11:31:32AM +0100, Juergen Gross wrote:
> Wei,
>
> On 01/12/17 15:14, Juergen Gross wrote:
>> Instead of locating the RSDP table below 1MB put it just below 
>> 4GB
>> like the rest of the ACPI tables in case of PVH guests. This will
>> avoid punching more holes than necessary into the memory map.
>>
>> Signed-off-by: Juergen Gross 
>> Acked-by: Wei Liu 
> Mind applying this one?
 Don't worry, it is in my queue.

 Will come to this and other patches I accumulated soon.

 Wei.
>>> This requires kernel changes, doesn't it?
>>>
>>> https://lists.xenproject.org/archives/html/xen-devel/2017-12/msg00714.html
>>>
>>> And this series apparently never made it to the tree.
>>>
>>> PVH guests are broken now on staging.
>> And the Linux side of PVH is officially supported now, right?
>>>
>>>
>>> AFAIK PVH is still considered a tech preview --- Linux or Xen.
>>
>> From SUPPORT.md:
>>
>> ### x86/PVH guest
>>
>> Status: Supported
>>
>> I was under the impression that PVH guest in Linux was complete and
>> stable as of Linux 4.11.  If that's not true it should have been
>> brought up during the 4.10 development cycle, where we declared PVH
>> domUs as "supported".
>
> So what is the problem here?
>
> - current Linux can't be booted as PVH guest with xen-unstable due to
>   a bug in Linux, patches for Linux are being worked on
> - booting Linux as PVH guest with xen 4.10 is working

 I was responding to Boris's claim that PVH is considered tech preview.
 I can't say anything one way or the other about PVH in Linux, but PVH
 in Xen is definitely now considered supported.

 My subsequent response to Roger ("FWIW I can buy this argument") was
 meant to indicate I didn't have any more objection to the approach you
 guys were planning on taking.

  -George
>>>
>>> L.S.,
>>>
>>> Seems I lost track, is there any progress on this issue ?
>>> (doesn't seem a fix has landed in 4.16-rc2 yet).
>>
>> Just sent a new patch series.
> 
> Just tested and it works fine here.

Hi Juergen,

I don't know by which tree those patches should arrive at Linus,
so i can't check if they fell through the cracks somewhere, but 4.16-rc5
hasn't got them yet.

--
Sander


> 
> --
> Sander
> 
>>
>> Juergen
>>
> 


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

Re: [Xen-devel] Regression with commit "x86/pv: Drop int80_bounce from struct pv_vcpu" f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1

[Andrew Cooper]

On 10/03/18 16:27, Andrew Cooper wrote:
> On 10/03/2018 16:14, Sander Eikelenboom wrote:
>> Hi Andrew,
>>
>> It seems commit "x86/pv: Drop int80_bounce from struct pv_vcpu" 
>> (f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1) causes an issue on my machine, 
>> an AMD phenom X6.
>>
>> When trying to installing a new kernel package which runs the Debian
>> update-initramfs tools with xen-unstable which happened to be at commit 
>> c9bd8a73656d7435b1055ee8825823aee995993e as last commit the tool stalls
>> and i get this kernel splat:
>>
>> [  284.910674] BUG: unable to handle kernel NULL pointer dereference at 
>> 
>> [  284.919696] IP:   (null)
>> [  284.928315] PGD 0 P4D 0 
>> [  284.943343] Oops: 0010 [#1] SMP NOPTI
>> [  284.957008] Modules linked in:
>> [  284.965521] CPU: 5 PID: 24729 Comm: ld-linux.so.2 Not tainted 
>> 4.16.0-rc4-20180305-linus-pvhpatches-doflr+ #1
>> [  284.974154] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS 
>> V1.8B1 09/13/2010
>> [  284.983198] RIP: e030:  (null)
>> [  284.992006] RSP: e02b:c90001497ed8 EFLAGS: 00010286
>> [  285.000612] RAX:  RBX: 880074c64500 RCX: 
>> 82f8d1c0
>> [  285.009122] RDX: 82f8d1c0 RSI: 20020002 RDI: 
>> 82f8d1c0
>> [  285.017598] RBP: 880074c64b7c R08:  R09: 
>> 
>> [  285.025999] R10:  R11:  R12: 
>> 82f8d1c0
>> [  285.034400] R13:  R14:  R15: 
>> 880074c64b50
>> [  285.042718] FS:  7f919fe2eb40() GS:88007d14() 
>> knlGS:
>> [  285.051001] CS:  e033 DS: 002b ES: 002b CR0: 80050033
>> [  285.059458] CR2:  CR3: 02824000 CR4: 
>> 0660
>> [  285.067813] Call Trace:
>> [  285.075947]  ? task_work_run+0x85/0xa0
>> [  285.084025]  ? exit_to_usermode_loop+0x72/0x80
>> [  285.091980]  ? do_int80_syscall_32+0xfe/0x120
>> [  285.099896]  ? entry_INT80_compat+0x7f/0x90
>> [  285.107688]  ? fpu__drop+0x23/0x40
>> [  285.115362] Code:  Bad RIP value.
>> [  285.123072] RIP:   (null) RSP: c90001497ed8
>> [  285.130714] CR2: 
>> [  285.138219] ---[ end trace 4d3317497f4ba022 ]---
>> [  285.145671] Fixing recursive fault but reboot is needed!
>>
>> After updating xen-unstable to the latest available commit 
>> 185413355fe331cbc926d48568838227234c9a20,
>> the tool doesn't stall anymore but i still get a kernel splat:
>>
>> [  198.594638] [ cut here ]
>> [  198.594641] Invalid address limit on user-mode return
>> [  198.594651] WARNING: CPU: 1 PID: 75 at ./include/linux/syscalls.h:236 
>> do_int80_syscall_32+0xe5/0x120
>> [  198.594652] Modules linked in:
>> [  198.594655] CPU: 1 PID: 75 Comm: kworker/1:1 Not tainted 
>> 4.16.0-rc4-20180305-linus-pvhpatches-doflr+ #1
>> [  198.594656] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS 
>> V1.8B1 09/13/2010
>> [  198.594658] Workqueue: events free_work
>> [  198.594660] RIP: e030:do_int80_syscall_32+0xe5/0x120
>> [  198.594661] RSP: e02b:c9b8ff40 EFLAGS: 00010086
>> [  198.594662] RAX: 0029 RBX: c9b8ff58 RCX: 
>> 82868e38
>> [  198.594663] RDX: 0001 RSI: 0001 RDI: 
>> 0001
>> [  198.594664] RBP: 880078623980 R08: 0dfa R09: 
>> 063b
>> [  198.594664] R10:  R11: 063b R12: 
>> 
>> [  198.594665] R13:  R14:  R15: 
>> 
>> [  198.594672] FS:  7fa252372b40() GS:88007d04() 
>> knlGS:
>> [  198.594673] CS:  e033 DS:  ES:  CR0: 80050033
>> [  198.594674] CR2: f7f303e4 CR3: 02824000 CR4: 
>> 0660
>> [  198.594676] Call Trace:
>> [  198.594683]  entry_INT80_compat+0x7f/0x90
>> [  198.594685]  ? vunmap_page_range+0x2a0/0x340
>> [  198.594686] Code: 03 7f 48 8b 75 00 f7 c6 0e 38 00 00 75 2e 83 65 08 f9 
>> 5b 5d c3 e8 0c fb ff ff e9 53 ff ff ff 48 c7 c7 58 35 57 82 e8 ab 3e 0c 00 
>> <0f> 0b bf 09 00 00 00 48 89 ee e8 8c 00 0d 00 eb b8 48 89 df e8 
>> [  198.594706] ---[ end trace 90bcd2147bc825ef ]---
>>
>> After reverting commit f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1 the issue is 
>> gone.
> :(
>
> This will be the issue which OSSTest is probably bisecting to as well. 
> It is quite odd to see a 64bit process using int80 as opposed to syscall.
>
> I'll see about double checking my assembly code, and will also try to
> identify why my unit tests haven't noticed an issue.

As a progress report, this is proving to be terrible bug to debug.

I've confirmed your findings.  However, my repro takes 10 minutes, and
I've failed to make it any faster.  It is more complicated than just
using 32bit userspace in a 64bit VM, and putting debugging in the
hypervisor makes the problem go away.

~Andrew

[Xen-devel] [RFC PATCH 29/30] xen/pt: add Resizable BAR PCIe Extended Capability descriptor and sizing

[Alexey Gerasimenko]

Unlike other PCIe Extended Capabilities, we currently cannot allow attempts
to use Resizable BAR Capability. Without specifically handling BAR resizing
we're likely end up with corrupted MMIO hole layout if guest OS will
attempt to use this feature. Actually, recent Windows versions started
to understand and use the Resizable BAR Capability (see [1]).

For now, we need to hide the Resizable BAR Capability from guest OS until
BAR resizing emulation support will be implemented in Xen. This support
is a pretty much mandatory todo-feature as the effect of writing
to Resizable BAR control registers can be considered similar
to reprogramming normal BAR registers -- i.e. this needs to be handled
explicitly, resulting in corresponding MMIO BAR range(s) remapping.
Until then, we mark the Resizable BAR Capability as
XEN_PT_GRP_TYPE_HARDWIRED.

[1]: 
https://docs.microsoft.com/en-us/windows-hardware/drivers/display/resizable-bar-support

Signed-off-by: Alexey Gerasimenko 
---
 hw/xen/xen_pt_config_init.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 326f5671ff..b03b071b22 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -2156,6 +2156,26 @@ static int 
xen_pt_ext_cap_pmux_size_init(XenPCIPassthroughState *s,
 return ret;
 }
 
+/* get Resizable BAR Extended Capability register group size */
+static int xen_pt_ext_cap_rebar_size_init(XenPCIPassthroughState *s,
+  const XenPTRegGroupInfo *grp_reg,
+  uint32_t base_offset,
+  uint32_t *size)
+{
+uint32_t rebar_ctl = 0;
+uint32_t num_entries;
+
+int ret = xen_host_pci_get_long(>real_device,
+base_offset + PCI_REBAR_CTRL,
+_ctl);
+num_entries =
+(rebar_ctl & PCI_REBAR_CTRL_NBAR_MASK) >> PCI_REBAR_CTRL_NBAR_SHIFT;
+
+*size = num_entries*8 + 4;
+
+log_pcie_extended_cap(s, "Resizable BAR", base_offset, *size);
+return ret;
+}
 
 static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
 /* Header Type0 reg group */
@@ -2488,6 +2508,13 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
 .size_init  = xen_pt_ext_cap_dpc_size_init,
 .emu_regs   = xen_pt_ext_cap_emu_reg_dummy,
 },
+/* Resizable BAR Extended Capability reg group */
+{
+.grp_id = PCIE_EXT_CAP_ID(PCI_EXT_CAP_ID_REBAR),
+.grp_type   = XEN_PT_GRP_TYPE_HARDWIRED,
+.grp_size   = 0xFF,
+.size_init  = xen_pt_ext_cap_rebar_size_init,
+},
 {
 .grp_size = 0,
 },
-- 
2.11.0


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

[Xen-devel] [RFC PATCH 30/30] xen/pt: add VC/VC9/MFVC PCIe Extended Capabilities descriptors and sizing

[Alexey Gerasimenko]

Virtual Channel/MFVC capabilities are relatively useless for emulation
(passing through accesses to them should be enough in most cases) yet they
have hardest format of all PCIe Extended Capabilities, mostly because
VC capability format allows the sparse config space layout with gaps
between the parts which make up the VC capability.

We have the main capability body followed by variable number of entries
where each entry may additionally reference the arbitration table outside
main capability body. There are no constrains on these arbitration table
offsets -- in theory, they may reside outside the VC capability range
anywhere in PCIe extended config space. Also, every arbitration table size
is not fixed - it depends on current VC/Port Arbitration Select field
value.

To simplify things, this patch assume that changing VC/Port Arbitration
Select value (i.e. resizing arbitration tables) do not cause arbitration
table offsets to change. Normally the device must place arbitration tables
considering their maximum size, not current one. Maximum arbitration table
size depends on VC/Port Arbitration Capability bitmask -- this is what
actually used to calculate the arbitration table size.

Signed-off-by: Alexey Gerasimenko 
---
 hw/xen/xen_pt_config_init.c | 192 
 1 file changed, 192 insertions(+)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index b03b071b22..ab9c233d84 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -2177,6 +2177,174 @@ static int 
xen_pt_ext_cap_rebar_size_init(XenPCIPassthroughState *s,
 return ret;
 }
 
+/* get VC/VC9/MFVC Extended Capability register group size */
+static uint32_t get_arb_table_len_max(XenPCIPassthroughState *s,
+  uint32_t max_bit_supported,
+  uint32_t arb_cap)
+{
+int n_bit;
+uint32_t table_max_size = 0;
+
+if (!arb_cap) {
+return 0;
+}
+
+for (n_bit = 7; n_bit >= 0 && !(arb_cap & (1 << n_bit)); n_bit--);
+
+if (n_bit > max_bit_supported) {
+XEN_PT_ERR(>dev, "Warning: encountered unknown VC arbitration "
+   "capability supported: 0x%02x\n", (uint8_t) arb_cap);
+}
+
+switch (n_bit) {
+case 0: break;
+case 1: return 32;
+case 2: return 64;
+case 3: /*128 too*/
+case 4: return 128;
+default:
+table_max_size = 8 << n_bit;
+}
+
+return table_max_size;
+}
+
+#define GET_ARB_TABLE_OFFSET(x)   (((x) >> 24) * 0x10)
+#define GET_VC_ARB_CAPABILITY(x)  ((x) & 0xFF)
+#define ARB_TABLE_ENTRY_SIZE_BITS(x)  (1 << (((x) & PCI_VC_CAP1_ARB_SIZE)\
+  >> 10))
+static int xen_pt_ext_cap_vchan_size_init(XenPCIPassthroughState *s,
+  const XenPTRegGroupInfo *grp_reg,
+  uint32_t base_offset,
+  uint32_t *size)
+{
+uint32_t header;
+uint32_t vc_cap_max_size = PCIE_CONFIG_SPACE_SIZE - base_offset;
+uint32_t next_ptr;
+uint32_t arb_table_start_max = 0, arb_table_end_max = 0;
+uint32_t port_vc_cap1, port_vc_cap2, vc_rsrc_cap;
+uint32_t ext_vc_count = 0;
+uint32_t arb_table_entry_size;  /* in bits */
+const char *cap_name;
+int ret;
+int i;
+
+ret = xen_host_pci_get_long(>real_device, base_offset, );
+if (ret) {
+goto err_read;
+}
+
+next_ptr = PCI_EXT_CAP_NEXT(header);
+
+switch (PCI_EXT_CAP_ID(header)) {
+case PCI_EXT_CAP_ID_VC:
+case PCI_EXT_CAP_ID_VC9:
+cap_name = "Virtual Channel";
+break;
+case PCI_EXT_CAP_ID_MFVC:
+cap_name = "Multi-Function VC";
+break;
+default:
+XEN_PT_ERR(>dev, "Unknown VC Extended Capability ID "
+   "encountered: 0x%04x\n", PCI_EXT_CAP_ID(header));
+return -1;
+}
+
+if (next_ptr && next_ptr > base_offset) {
+vc_cap_max_size = next_ptr - base_offset;
+}
+
+ret = xen_host_pci_get_long(>real_device,
+base_offset + PCI_VC_PORT_CAP1,
+_vc_cap1);
+if (ret) {
+goto err_read;
+}
+
+ret = xen_host_pci_get_long(>real_device,
+base_offset + PCI_VC_PORT_CAP2,
+_vc_cap2);
+if (ret) {
+goto err_read;
+}
+
+ext_vc_count = port_vc_cap1 & PCI_VC_CAP1_EVCC;
+
+arb_table_start_max = GET_ARB_TABLE_OFFSET(port_vc_cap2);
+
+/* check arbitration table offset for validity */
+if (arb_table_start_max >= vc_cap_max_size) {
+XEN_PT_ERR(>dev, "Warning: VC arbitration table offset points "
+   "outside the expected range: %#04x\n",
+   (uint16_t) arb_table_start_max);
+/* skip this arbitration table */
+arb_table_start_max = 0;

[Xen-devel] [RFC PATCH 16/30] q35/xen: Add Xen platform device support for Q35

[Alexey Gerasimenko]

Current Xen/QEMU method to control Xen Platform device on i440 is a bit
odd -- enabling/disabling Xen platform device actually modifies the QEMU
emulated machine type, namely xenfv <--> pc.

In order to avoid multiplying machine types, use a new way to control Xen
Platform device for QEMU -- "xen-platform-dev" machine property (bool).
To maintain backward compatibility with existing Xen/QEMU setups, this
is only applicable to q35 machine currently. i440 emulation still uses the
old method (i.e. xenfv/pc machine selection) to control Xen Platform
device, this may be changed later to xen-platform-dev property as well.

This way we can use a single machine type (q35) and change just
xen-platform-dev value to on/off to control Xen platform device.

Signed-off-by: Alexey Gerasimenko 
---
 hw/core/machine.c   | 21 +
 hw/i386/pc_q35.c| 14 ++
 include/hw/boards.h |  1 +
 qemu-options.hx |  1 +
 4 files changed, 37 insertions(+)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index 5e2bbcdace..205e7da3ce 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -290,6 +290,20 @@ static void machine_set_igd_gfx_passthru(Object *obj, bool 
value, Error **errp)
 ms->igd_gfx_passthru = value;
 }
 
+static bool machine_get_xen_platform_dev(Object *obj, Error **errp)
+{
+MachineState *ms = MACHINE(obj);
+
+return ms->xen_platform_dev;
+}
+
+static void machine_set_xen_platform_dev(Object *obj, bool value, Error **errp)
+{
+MachineState *ms = MACHINE(obj);
+
+ms->xen_platform_dev = value;
+}
+
 static char *machine_get_firmware(Object *obj, Error **errp)
 {
 MachineState *ms = MACHINE(obj);
@@ -595,6 +609,13 @@ static void machine_class_init(ObjectClass *oc, void *data)
 object_class_property_set_description(oc, "igd-passthru",
 "Set on/off to enable/disable igd passthrou", _abort);
 
+object_class_property_add_bool(oc, "xen-platform-dev",
+machine_get_xen_platform_dev,
+machine_set_xen_platform_dev, _abort);
+object_class_property_set_description(oc, "xen-platform-dev",
+"Set on/off to enable/disable Xen Platform device",
+_abort);
+
 object_class_property_add_str(oc, "firmware",
 machine_get_firmware, machine_set_firmware,
 _abort);
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 0db670f6d7..62caf924cf 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -56,6 +56,18 @@
 /* ICH9 AHCI has 6 ports */
 #define MAX_SATA_PORTS 6
 
+static void q35_xen_hvm_init(MachineState *machine)
+{
+PCMachineState *pcms = PC_MACHINE(machine);
+
+if (xen_enabled()) {
+/* check if Xen Platform device is enabled */
+if (machine->xen_platform_dev) {
+pci_create_simple(pcms->bus, -1, "xen-platform");
+}
+}
+}
+
 /* PC hardware initialisation */
 static void pc_q35_init(MachineState *machine)
 {
@@ -207,6 +219,8 @@ static void pc_q35_init(MachineState *machine)
 if (xen_enabled()) {
 pci_bus_irqs(host_bus, xen_cmn_set_irq, xen_cmn_pci_slot_get_pirq,
  ich9_lpc, ICH9_XEN_NUM_IRQ_SOURCES);
+
+q35_xen_hvm_init(machine);
 } else {
 pci_bus_irqs(host_bus, ich9_lpc_set_irq, ich9_lpc_map_irq, ich9_lpc,
  ICH9_LPC_NB_PIRQS);
diff --git a/include/hw/boards.h b/include/hw/boards.h
index efb0a9edfd..f35fc1cc03 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -238,6 +238,7 @@ struct MachineState {
 bool usb;
 bool usb_disabled;
 bool igd_gfx_passthru;
+bool xen_platform_dev;
 char *firmware;
 bool iommu;
 bool suppress_vmdesc;
diff --git a/qemu-options.hx b/qemu-options.hx
index 6585058c6c..cee0b92028 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -38,6 +38,7 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
 "dump-guest-core=on|off include guest memory in a core 
dump (default=on)\n"
 "mem-merge=on|off controls memory merge support (default: 
on)\n"
 "igd-passthru=on|off controls IGD GFX passthrough support 
(default=off)\n"
+"xen-platform-dev=on|off controls Xen Platform device 
(default=off)\n"
 "aes-key-wrap=on|off controls support for AES key wrapping 
(default=on)\n"
 "dea-key-wrap=on|off controls support for DEA key wrapping 
(default=on)\n"
 "suppress-vmdesc=on|off disables self-describing migration 
(default=off)\n"
-- 
2.11.0


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

[Xen-devel] [RFC PATCH 25/30] xen/pt: add Vendor-specific PCIe Extended Capability descriptor and sizing

[Alexey Gerasimenko]

The patch provides Vendor-specific PCIe Extended Capability description
structure and corresponding sizing function. In this particular case the
size of the Vendor capability is available in the VSEC Length field.

Signed-off-by: Alexey Gerasimenko 
---
 hw/xen/xen_pt_config_init.c | 77 +++--
 1 file changed, 75 insertions(+), 2 deletions(-)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 10f3b67d35..6e99b9ebd7 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -129,6 +129,18 @@ static uint32_t get_throughable_mask(const 
XenPCIPassthroughState *s,
 return throughable_mask & valid_mask;
 }
 
+static void log_pcie_extended_cap(XenPCIPassthroughState *s,
+  const char *cap_name,
+  uint32_t base_offset, uint32_t size)
+{
+if (size) {
+XEN_PT_LOG(>dev, "Found PCIe Extended Capability: %s at 0x%04x, "
+"size 0x%x bytes\n", cap_name,
+(uint16_t) base_offset, size);
+}
+}
+
+
 /
  * general register functions
  */
@@ -1684,6 +1696,44 @@ static int 
xen_pt_ext_cap_capid_reg_init(XenPCIPassthroughState *s,
 }
 
 
+/* Vendor-specific Ext Capability Structure reg static information table */
+static XenPTRegInfo xen_pt_ext_cap_emu_reg_vendor[] = {
+{
+.offset = XEN_PCIE_CAP_ID,
+.size   = 2,
+.init_val   = 0x,
+.ro_mask= 0x,
+.emu_mask   = 0x,
+.init   = xen_pt_ext_cap_capid_reg_init,
+.u.w.read   = xen_pt_word_reg_read,
+.u.w.write  = xen_pt_word_reg_write,
+},
+{
+.offset = XEN_PCIE_CAP_LIST_NEXT,
+.size   = 2,
+.init_val   = 0x,
+.ro_mask= 0x,
+.emu_mask   = 0x,
+.init   = xen_pt_ext_cap_ptr_reg_init,
+.u.w.read   = xen_pt_word_reg_read,
+.u.w.write  = xen_pt_word_reg_write,
+},
+{
+.offset = PCI_VNDR_HEADER,
+.size   = 4,
+.init_val   = 0x,
+.ro_mask= 0x,
+.emu_mask   = 0x,
+.init   = xen_pt_common_reg_init,
+.u.dw.read  = xen_pt_long_reg_read,
+.u.dw.write = xen_pt_long_reg_write,
+},
+{
+.size = 0,
+},
+};
+
+
 /
  * Capabilities
  */
@@ -1708,6 +1758,23 @@ static int 
xen_pt_vendor_size_init(XenPCIPassthroughState *s,
 *size = sz;
 return ret;
 }
+
+static int xen_pt_ext_cap_vendor_size_init(XenPCIPassthroughState *s,
+   const XenPTRegGroupInfo *grp_reg,
+   uint32_t base_offset,
+   uint32_t *size)
+{
+uint32_t vsec_hdr = 0;
+int ret = xen_host_pci_get_long(>real_device,
+base_offset + PCI_VNDR_HEADER,
+_hdr);
+
+*size = PCI_VNDR_HEADER_LEN(vsec_hdr);
+
+log_pcie_extended_cap(s, "Vendor-specific", base_offset, *size);
+
+return ret;
+}
 /* get PCI Express Capability Structure register group size */
 static int xen_pt_pcie_size_init(XenPCIPassthroughState *s,
  const XenPTRegGroupInfo *grp_reg,
@@ -1934,6 +2001,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
 .size_init   = xen_pt_reg_grp_size_init,
 .emu_regs= xen_pt_emu_reg_igd_opregion,
 },
+/* Vendor-specific Extended Capability reg group */
+{
+.grp_id  = PCIE_EXT_CAP_ID(PCI_EXT_CAP_ID_VNDR),
+.grp_type= XEN_PT_GRP_TYPE_EMU,
+.grp_size= 0xFF,
+.size_init   = xen_pt_ext_cap_vendor_size_init,
+.emu_regs= xen_pt_ext_cap_emu_reg_vendor,
+},
 {
 .grp_size = 0,
 },
@@ -2054,8 +2129,6 @@ out:
 return 0;
 }
 
-
-
 /*
  * Main
  */
-- 
2.11.0


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

[Xen-devel] [RFC PATCH 23/30] xen/pt: handle PCIe Extended Capabilities Next register

[Alexey Gerasimenko]

The patch adds new xen_pt_ext_cap_ptr_reg_init function which is used
to initialize the emulated next pcie extended capability pointer.

Primary mission of this function is to have a method to selectively hide
some extended capabilities from the capability linked list, skipping them
by altering the Next capability pointer value.

Signed-off-by: Alexey Gerasimenko 
---
 hw/xen/xen_pt_config_init.c | 73 +++--
 1 file changed, 71 insertions(+), 2 deletions(-)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 9c041fa288..0ce2a033f9 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -23,11 +23,14 @@
 
 #define XEN_PT_INVALID_REG  0x  /* invalid register value 
*/
 
-/* prototype */
+/* prototypes */
 
 static int xen_pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
uint32_t real_offset, uint32_t *data);
-
+static int xen_pt_ext_cap_ptr_reg_init(XenPCIPassthroughState *s,
+   XenPTRegInfo *reg,
+   uint32_t real_offset,
+   uint32_t *data);
 
 /* helper */
 
@@ -1932,6 +1935,72 @@ out:
 return 0;
 }
 
+#define PCIE_EXT_CAP_NEXT_SHIFT 4
+#define PCIE_EXT_CAP_VER_MASK   0xF
+
+static int xen_pt_ext_cap_ptr_reg_init(XenPCIPassthroughState *s,
+   XenPTRegInfo *reg,
+   uint32_t real_offset,
+   uint32_t *data)
+{
+int i, rc;
+XenHostPCIDevice *d = >real_device;
+uint16_t reg_field;
+uint16_t cur_offset, version, cap_id;
+uint32_t header;
+
+if (real_offset < PCI_CONFIG_SPACE_SIZE) {
+XEN_PT_ERR(>dev, "Incorrect PCIe extended capability offset"
+   "encountered: 0x%04x\n", real_offset);
+return -EINVAL;
+}
+
+rc = xen_host_pci_get_word(d, real_offset, _field);
+if (rc)
+return rc;
+
+/* preserve version field */
+version= reg_field & PCIE_EXT_CAP_VER_MASK;
+cur_offset = reg_field >> PCIE_EXT_CAP_NEXT_SHIFT;
+
+while (cur_offset && cur_offset != 0xFFF) {
+rc = xen_host_pci_get_long(d, cur_offset, );
+if (rc) {
+XEN_PT_ERR(>dev, "Failed to read PCIe extended capability "
+   "@0x%x (rc:%d)\n", cur_offset, rc);
+return rc;
+}
+
+cap_id = PCI_EXT_CAP_ID(header);
+
+for (i = 0; xen_pt_emu_reg_grps[i].grp_size != 0; i++) {
+uint32_t cur_grp_id = xen_pt_emu_reg_grps[i].grp_id;
+
+if (!IS_PCIE_EXT_CAP_ID(cur_grp_id))
+continue;
+
+if (xen_pt_hide_dev_cap(d, cur_grp_id))
+continue;
+
+if (GET_PCIE_EXT_CAP_ID(cur_grp_id) == cap_id) {
+if (xen_pt_emu_reg_grps[i].grp_type == XEN_PT_GRP_TYPE_EMU)
+goto out;
+
+/* skip TYPE_HARDWIRED capability, move the ptr to next one */
+break;
+}
+}
+
+/* next capability */
+cur_offset = PCI_EXT_CAP_NEXT(header);
+}
+
+out:
+*data = (cur_offset << PCIE_EXT_CAP_NEXT_SHIFT) | version;
+return 0;
+}
+
+
 
 /*
  * Main
-- 
2.11.0


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

[Xen-devel] [RFC PATCH 27/30] xen/pt: add AER PCIe Extended Capability descriptor and sizing

[Alexey Gerasimenko]

The patch provides Advanced Error Reporting PCIe Extended Capability
description structure and corresponding capability sizing function.

Signed-off-by: Alexey Gerasimenko 
---
 hw/xen/xen_pt_config_init.c | 72 +
 1 file changed, 72 insertions(+)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 42296c08cc..98aae3daca 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -1924,6 +1924,70 @@ static int xen_pt_msix_size_init(XenPCIPassthroughState 
*s,
 return 0;
 }
 
+/* get Advanced Error Reporting Extended Capability register group size */
+#define PCI_ERR_CAP_TLP_PREFIX_LOG  (1U << 11)
+#define PCI_DEVCAP2_END_END_TLP_PREFIX  (1U << 21)
+static int xen_pt_ext_cap_aer_size_init(XenPCIPassthroughState *s,
+const XenPTRegGroupInfo *grp_reg,
+uint32_t base_offset,
+uint32_t *size)
+{
+uint8_t dev_type = get_pcie_device_type(s);
+uint32_t aer_caps = 0;
+uint32_t sz = 0;
+int pcie_cap_pos;
+uint32_t devcaps2;
+int ret = 0;
+
+pcie_cap_pos = xen_host_pci_find_next_cap(>real_device, 0,
+  PCI_CAP_ID_EXP);
+if (!pcie_cap_pos) {
+XEN_PT_ERR(>dev,
+   "Cannot find a required PCI Express Capability\n");
+return -1;
+}
+
+if (get_pcie_capability_version(s) > 1) {
+ret = xen_host_pci_get_long(>real_device,
+pcie_cap_pos + PCI_EXP_DEVCAP2,
+);
+if (ret) {
+XEN_PT_ERR(>dev, "Error while reading Device "
+   "Capabilities 2 Register \n");
+return -1;
+}
+}
+
+if (devcaps2 & PCI_DEVCAP2_END_END_TLP_PREFIX) {
+ret = xen_host_pci_get_long(>real_device,
+base_offset + PCI_ERR_CAP,
+_caps);
+if (ret) {
+XEN_PT_ERR(>dev,
+   "Error while reading AER Extended Capability\n");
+return -1;
+}
+
+if (aer_caps & PCI_ERR_CAP_TLP_PREFIX_LOG) {
+sz = 0x48;
+}
+}
+
+if (!sz) {
+if (dev_type == PCI_EXP_TYPE_ROOT_PORT ||
+dev_type == PCI_EXP_TYPE_RC_EC) {
+sz = 0x38;
+} else {
+sz = 0x2C;
+}
+}
+
+*size = sz;
+
+log_pcie_extended_cap(s, "AER", base_offset, *size);
+return ret;
+}
+
 
 static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
 /* Header Type0 reg group */
@@ -2192,6 +2256,14 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
 .size_init  = xen_pt_reg_grp_size_init,
 .emu_regs   = xen_pt_ext_cap_emu_reg_dummy,
 },
+/* Advanced Error Reporting Extended Capability reg group */
+{
+.grp_id = PCIE_EXT_CAP_ID(PCI_EXT_CAP_ID_ERR),
+.grp_type   = XEN_PT_GRP_TYPE_EMU,
+.grp_size   = 0xFF,
+.size_init  = xen_pt_ext_cap_aer_size_init,
+.emu_regs   = xen_pt_ext_cap_emu_reg_dummy,
+},
 {
 .grp_size = 0,
 },
-- 
2.11.0


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

[Xen-devel] [RFC PATCH 14/30] pc/q35: Apply PCI bus BSEL property for Xen PCI device hotplug

[Alexey Gerasimenko]

On Q35 we still need to assign BSEL property to bus(es) for PCI device
add/hotplug to work.
Extend acpi_set_pci_info() function to support Q35 as well. Previously
it was limited to find_i440fx() call, this patch adds new (trivial)
function find_q35() which returns root PCIBus object on Q35, in a way
similar to what find_i440fx does.

Signed-off-by: Alexey Gerasimenko 
---
 hw/acpi/pcihp.c  | 6 +-
 hw/pci-host/q35.c| 8 
 include/hw/i386/pc.h | 3 +++
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
index 91c82fdc7a..f70d8620d7 100644
--- a/hw/acpi/pcihp.c
+++ b/hw/acpi/pcihp.c
@@ -105,7 +105,11 @@ static void acpi_set_pci_info(void)
 }
 bsel_is_set = true;
 
-bus = find_i440fx(); /* TODO: Q35 support */
+bus = find_i440fx();
+if (!bus) {
+bus = find_q35();
+}
+
 if (bus) {
 /* Scan all PCI buses. Set property to enable acpi based hotplug. */
 pci_for_each_bus_depth_first(bus, acpi_set_bsel, NULL, _alloc);
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index a36a1195e4..8c1603fce9 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -258,6 +258,14 @@ static void q35_host_initfn(Object *obj)
 IO_APIC_DEFAULT_ADDRESS - 1);
 }
 
+PCIBus *find_q35(void)
+{
+PCIHostState *s = OBJECT_CHECK(PCIHostState,
+   object_resolve_path("/machine/q35", NULL),
+   TYPE_PCI_HOST_BRIDGE);
+return s ? s->bus : NULL;
+}
+
 static const TypeInfo q35_host_info = {
 .name   = TYPE_Q35_HOST_DEVICE,
 .parent = TYPE_PCIE_HOST_BRIDGE,
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index bb49165fe0..96d74b35bd 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -302,6 +302,9 @@ PCIBus *find_i440fx(void);
 extern PCIDevice *piix4_dev;
 int piix4_init(PCIBus *bus, ISABus **isa_bus, int devfn);
 
+/* q35.c */
+PCIBus *find_q35(void);
+
 /* pc_sysfw.c */
 void pc_system_firmware_init(MemoryRegion *rom_memory,
  bool isapc_ram_fw);
-- 
2.11.0


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

[Xen-devel] [RFC PATCH 28/30] xen/pt: add descriptors and size calculation for RCLD/ACS/PMUX/DPA/MCAST/TPH/DPC PCIe Extended Capabilities

[Alexey Gerasimenko]

Add few more PCIe Extended Capabilities entries to the
xen_pt_emu_reg_grps[] array along with their corresponding *_size_init()
functions.

All these capabilities have non-fixed size but their size calculation
is very simple, hence adding them in a single batch.

For every capability register group, only 2 registers are emulated
currently: Capability ID (16 bit) and Next Capability Offset/Version (16
bit). Both needed to implement the selective capability hiding. All other
registers are passed through at the moment (unless they belong to
a capability marked as "hardwired" which is hidden)

Signed-off-by: Alexey Gerasimenko 
---
 hw/xen/xen_pt_config_init.c | 224 
 1 file changed, 224 insertions(+)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 98aae3daca..326f5671ff 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -1988,6 +1988,174 @@ static int 
xen_pt_ext_cap_aer_size_init(XenPCIPassthroughState *s,
 return ret;
 }
 
+/* get Root Complex Link Declaration Extended Capability register group size */
+#define RCLD_GET_NUM_ENTRIES(x) (((x) >> 8) & 0xFF)
+static int xen_pt_ext_cap_rcld_size_init(XenPCIPassthroughState *s,
+ const XenPTRegGroupInfo *grp_reg,
+ uint32_t base_offset,
+ uint32_t *size)
+{
+uint32_t elem_self_descr = 0;
+
+int ret = xen_host_pci_get_long(>real_device,
+base_offset + 4,
+_self_descr);
+
+*size = 0x10 + RCLD_GET_NUM_ENTRIES(elem_self_descr) * 0x10;
+
+log_pcie_extended_cap(s, "Root Complex Link Declaration",
+  base_offset, *size);
+return ret;
+}
+
+/* get Access Control Services Extended Capability register group size */
+#define ACS_VECTOR_SIZE_BITS(x)x) >> 8) & 0xFF) ?: 256)
+static int xen_pt_ext_cap_acs_size_init(XenPCIPassthroughState *s,
+const XenPTRegGroupInfo *grp_reg,
+uint32_t base_offset,
+uint32_t *size)
+{
+uint16_t acs_caps = 0;
+
+int ret = xen_host_pci_get_word(>real_device,
+base_offset + PCI_ACS_CAP,
+_caps);
+
+if (acs_caps & PCI_ACS_EC) {
+uint32_t vector_sz = ACS_VECTOR_SIZE_BITS(acs_caps);
+
+*size = PCI_ACS_EGRESS_CTL_V + ((vector_sz + 7) & ~7) / 8;
+} else {
+*size = PCI_ACS_EGRESS_CTL_V;
+}
+
+log_pcie_extended_cap(s, "ACS", base_offset, *size);
+return ret;
+}
+
+/* get Multicast Extended Capability register group size */
+static int xen_pt_ext_cap_multicast_size_init(XenPCIPassthroughState *s,
+  const XenPTRegGroupInfo *grp_reg,
+  uint32_t base_offset,
+  uint32_t *size)
+{
+uint8_t dev_type = get_pcie_device_type(s);
+
+switch (dev_type) {
+case PCI_EXP_TYPE_ENDPOINT:
+case PCI_EXP_TYPE_LEG_END:
+case PCI_EXP_TYPE_RC_END:
+case PCI_EXP_TYPE_RC_EC:
+default:
+*size = PCI_EXT_CAP_MCAST_ENDPOINT_SIZEOF;
+break;
+
+case PCI_EXP_TYPE_ROOT_PORT:
+case PCI_EXP_TYPE_UPSTREAM:
+case PCI_EXP_TYPE_DOWNSTREAM:
+*size = 0x30;
+break;
+}
+
+log_pcie_extended_cap(s, "Multicast", base_offset, *size);
+return 0;
+}
+
+/* get Dynamic Power Allocation Extended Capability register group size */
+static int xen_pt_ext_cap_dpa_size_init(XenPCIPassthroughState *s,
+const XenPTRegGroupInfo *grp_reg,
+uint32_t base_offset,
+uint32_t *size)
+{
+uint32_t dpa_caps = 0;
+uint32_t num_entries;
+
+int ret = xen_host_pci_get_long(>real_device,
+base_offset + PCI_DPA_CAP,
+_caps);
+
+num_entries = (dpa_caps & PCI_DPA_CAP_SUBSTATE_MASK) + 1;
+
+*size = PCI_DPA_BASE_SIZEOF + num_entries /*byte-size registers*/;
+
+log_pcie_extended_cap(s, "Dynamic Power Allocation", base_offset, *size);
+return ret;
+}
+
+/* get TPH Requester Extended Capability register group size */
+static int xen_pt_ext_cap_tph_size_init(XenPCIPassthroughState *s,
+const XenPTRegGroupInfo *grp_reg,
+uint32_t base_offset,
+uint32_t *size)
+{
+uint32_t tph_caps = 0;
+uint32_t num_entries;
+
+int ret = xen_host_pci_get_long(>real_device,
+base_offset + PCI_TPH_CAP,
+_caps);
+
+

[Xen-devel] [RFC PATCH 26/30] xen/pt: add fixed-size PCIe Extended Capabilities descriptors

[Alexey Gerasimenko]

This adds description structures for all fixed-size PCIe Extended
Capabilities.

For every capability register group, only 2 registers are emulated
currently: Capability ID (16 bit) and Next Capability Offset/Version (16
bit). Both needed to implement selective capability hiding. All other
registers are passed through at the moment (unless they belong to
a "hardwired" capability which is hidden)

Signed-off-by: Alexey Gerasimenko 
---
 hw/xen/xen_pt_config_init.c | 183 
 1 file changed, 183 insertions(+)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 6e99b9ebd7..42296c08cc 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -1734,6 +1734,37 @@ static XenPTRegInfo xen_pt_ext_cap_emu_reg_vendor[] = {
 };
 
 
+/* Common reg static information table for all passthru-type
+ * PCIe Extended Capabilities. Only Extended Cap ID and
+ * Next pointer are handled (to support capability hiding).
+ */
+static XenPTRegInfo xen_pt_ext_cap_emu_reg_dummy[] = {
+{
+.offset = XEN_PCIE_CAP_ID,
+.size   = 2,
+.init_val   = 0x,
+.ro_mask= 0x,
+.emu_mask   = 0x,
+.init   = xen_pt_ext_cap_capid_reg_init,
+.u.w.read   = xen_pt_word_reg_read,
+.u.w.write  = xen_pt_word_reg_write,
+},
+{
+.offset = XEN_PCIE_CAP_LIST_NEXT,
+.size   = 2,
+.init_val   = 0x,
+.ro_mask= 0x,
+.emu_mask   = 0x,
+.init   = xen_pt_ext_cap_ptr_reg_init,
+.u.w.read   = xen_pt_word_reg_read,
+.u.w.write  = xen_pt_word_reg_write,
+},
+{
+.size = 0,
+},
+};
+
+
 /
  * Capabilities
  */
@@ -2009,6 +2040,158 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
 .size_init   = xen_pt_ext_cap_vendor_size_init,
 .emu_regs= xen_pt_ext_cap_emu_reg_vendor,
 },
+/* Device Serial Number Extended Capability reg group */
+{
+.grp_id = PCIE_EXT_CAP_ID(PCI_EXT_CAP_ID_DSN),
+.grp_type   = XEN_PT_GRP_TYPE_EMU,
+.grp_size   = PCI_EXT_CAP_DSN_SIZEOF,   /*0x0C*/
+.size_init  = xen_pt_reg_grp_size_init,
+.emu_regs   = xen_pt_ext_cap_emu_reg_dummy,
+},
+/* Power Budgeting Extended Capability reg group */
+{
+.grp_id = PCIE_EXT_CAP_ID(PCI_EXT_CAP_ID_PWR),
+.grp_type   = XEN_PT_GRP_TYPE_EMU,
+.grp_size   = PCI_EXT_CAP_PWR_SIZEOF,   /*0x10*/
+.size_init  = xen_pt_reg_grp_size_init,
+.emu_regs   = xen_pt_ext_cap_emu_reg_dummy,
+},
+/* Root Complex Internal Link Control Extended Capability reg group */
+{
+.grp_id = PCIE_EXT_CAP_ID(PCI_EXT_CAP_ID_RCILC),
+.grp_type   = XEN_PT_GRP_TYPE_EMU,
+.grp_size   = 0x0C,
+.size_init  = xen_pt_reg_grp_size_init,
+.emu_regs   = xen_pt_ext_cap_emu_reg_dummy,
+},
+/* Root Complex Event Collector Extended Capability reg group */
+{
+.grp_id = PCIE_EXT_CAP_ID(PCI_EXT_CAP_ID_RCEC),
+.grp_type   = XEN_PT_GRP_TYPE_EMU,
+.grp_size   = 0x08,
+.size_init  = xen_pt_reg_grp_size_init,
+.emu_regs   = xen_pt_ext_cap_emu_reg_dummy,
+},
+/* Root Complex Register Block Extended Capability reg group */
+{
+.grp_id = PCIE_EXT_CAP_ID(PCI_EXT_CAP_ID_RCRB),
+.grp_type   = XEN_PT_GRP_TYPE_EMU,
+.grp_size   = 0x14,
+.size_init  = xen_pt_reg_grp_size_init,
+.emu_regs   = xen_pt_ext_cap_emu_reg_dummy,
+},
+/* Configuration Access Correlation Extended Capability reg group */
+{
+.grp_id = PCIE_EXT_CAP_ID(PCI_EXT_CAP_ID_CAC),
+.grp_type   = XEN_PT_GRP_TYPE_EMU,
+.grp_size   = 0x08,
+.size_init  = xen_pt_reg_grp_size_init,
+.emu_regs   = xen_pt_ext_cap_emu_reg_dummy,
+},
+/* Alternate Routing ID Extended Capability reg group */
+{
+.grp_id = PCIE_EXT_CAP_ID(PCI_EXT_CAP_ID_ARI),
+.grp_type   = XEN_PT_GRP_TYPE_EMU,
+.grp_size   = PCI_EXT_CAP_ARI_SIZEOF,
+.size_init  = xen_pt_reg_grp_size_init,
+.emu_regs   = xen_pt_ext_cap_emu_reg_dummy,
+},
+/* Address Translation Services Extended Capability reg group */
+{
+.grp_id = PCIE_EXT_CAP_ID(PCI_EXT_CAP_ID_ATS),
+.grp_type   = XEN_PT_GRP_TYPE_EMU,
+.grp_size   = PCI_EXT_CAP_ATS_SIZEOF,
+.size_init  = xen_pt_reg_grp_size_init,
+.emu_regs   = xen_pt_ext_cap_emu_reg_dummy,
+},
+/* Single Root I/O Virtualization Extended Capability reg group */
+{
+.grp_id = PCIE_EXT_CAP_ID(PCI_EXT_CAP_ID_SRIOV),
+.grp_type   = XEN_PT_GRP_TYPE_EMU,
+.grp_size   = PCI_EXT_CAP_SRIOV_SIZEOF,
+.size_init  = xen_pt_reg_grp_size_init,
+.emu_regs   = xen_pt_ext_cap_emu_reg_dummy,

[Xen-devel] [RFC PATCH 24/30] xen/pt: allow to hide PCIe Extended Capabilities

[Alexey Gerasimenko]

We need to hide some unwanted PCI/PCIe capabilities for passed through
devices.
Normally we do this by marking the capability register group
as XEN_PT_GRP_TYPE_HARDWIRED which exclude this capability from the
capability list and returns zeroes on attempts to read capability body.
Skipping the capability in the linked list of capabilities can be done
by changing Next Capability register to skip one or many unwanted
capabilities.

One difference between PCI and PCIe Extended capabilities is that we don't
have the list head field anymore. PCIe Extended capabilities always start
at offset 0x100 if they're present. Unfortunately, there are typically
only few PCIe extended capabilities present which means there is a chance
that some capability we want to hide will reside at offset 0x100 in PCIe
config space.

The simplest way to hide such capabilities from guest OS or drivers
is faking their capability ID value.

This patch adds the Capability ID register handler which checks
- if the capability to which this register belong starts at offset 0x100
  in PCIe config space
- if this capability is marked as XEN_PT_GRP_TYPE_HARDWIRED

If it is the case, then a fake Capability ID value is returned.

Signed-off-by: Alexey Gerasimenko 
---
 hw/xen/xen_pt.c | 11 +++-
 hw/xen/xen_pt.h |  5 
 hw/xen/xen_pt_config_init.c | 62 -
 3 files changed, 76 insertions(+), 2 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index bf098c26b3..e6a18afa83 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -154,7 +154,16 @@ static uint32_t xen_pt_pci_read_config(PCIDevice *d, 
uint32_t addr, int len)
 reg_grp_entry = xen_pt_find_reg_grp(s, addr);
 if (reg_grp_entry) {
 /* check 0-Hardwired register group */
-if (reg_grp_entry->reg_grp->grp_type == XEN_PT_GRP_TYPE_HARDWIRED) {
+if (reg_grp_entry->reg_grp->grp_type == XEN_PT_GRP_TYPE_HARDWIRED &&
+/*
+ * For PCIe Extended Capabilities we need to emulate
+ * CapabilityID and NextCapability/Version registers for a
+ * hardwired reg group located at the offset 0x100 in PCIe
+ * config space. This allows us to hide the first extended
+ * capability as well.
+ */
+!(reg_grp_entry->base_offset == PCI_CONFIG_SPACE_SIZE &&
+ranges_overlap(addr, len, 0x100, 4))) {
 /* no need to emulate, just return 0 */
 val = 0;
 goto exit;
diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 5531347ab2..ac45261679 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -78,6 +78,11 @@ typedef int (*xen_pt_conf_byte_read)
 
 #define XEN_PCI_INTEL_OPREGION 0xfc
 
+#define XEN_PCIE_CAP_ID 0
+#define XEN_PCIE_CAP_LIST_NEXT  2
+
+#define XEN_PCIE_FAKE_CAP_ID_BASE   0xFE00
+
 typedef enum {
 XEN_PT_GRP_TYPE_HARDWIRED = 0,  /* 0 Hardwired reg group */
 XEN_PT_GRP_TYPE_EMU,/* emul reg group */
diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 0ce2a033f9..10f3b67d35 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -31,6 +31,10 @@ static int 
xen_pt_ext_cap_ptr_reg_init(XenPCIPassthroughState *s,
XenPTRegInfo *reg,
uint32_t real_offset,
uint32_t *data);
+static int xen_pt_ext_cap_capid_reg_init(XenPCIPassthroughState *s,
+ XenPTRegInfo *reg,
+ uint32_t real_offset,
+ uint32_t *data);
 
 /* helper */
 
@@ -1630,6 +1634,56 @@ static XenPTRegInfo xen_pt_emu_reg_igd_opregion[] = {
 },
 };
 
+
+/
+ * Emulated registers for
+ * PCIe Extended Capabilities
+ */
+
+static uint16_t fake_cap_id = XEN_PCIE_FAKE_CAP_ID_BASE;
+
+/* PCIe Extended Capability ID reg */
+static int xen_pt_ext_cap_capid_reg_init(XenPCIPassthroughState *s,
+ XenPTRegInfo *reg,
+ uint32_t real_offset,
+ uint32_t *data)
+{
+uint16_t reg_field;
+int rc;
+XenPTRegGroup *reg_grp_entry = NULL;
+
+/* use real device register's value as initial value */
+rc = xen_host_pci_get_word(>real_device, real_offset, _field);
+if (rc) {
+return rc;
+}
+
+reg_grp_entry = xen_pt_find_reg_grp(s, real_offset);
+
+if (reg_grp_entry) {
+if (reg_grp_entry->reg_grp->grp_type == XEN_PT_GRP_TYPE_HARDWIRED &&
+reg_grp_entry->base_offset == PCI_CONFIG_SPACE_SIZE) {
+/*
+ * This is the situation when we were asked to hide (aka
+ * "hardwire to 0") some PCIe ext capability, but it was located
+ * at offset 0x100 in PCIe config 

[Xen-devel] [RFC PATCH 22/30] xen/pt: add support for PCIe Extended Capabilities and larger config space

[Alexey Gerasimenko]

This patch provides basic facilities for PCIe Extended Capabilities and
support for controlled (via s->pcie_enabled_dev flag) access to PCIe
config space (>256).

PCIe Extended Capabilities make use of 16-bit capability ID. Also,
a capability size might exceed 8-bit width. So as the very first step
we need to increase type size for grp_id, grp_size, etc -- they were
limited to 8-bit.

The only troublesome issue with PCIe Extended Capability IDs is that their
value range is actually same as for basic PCI capabilities.
Eg. capability ID 3 means VPD Capability for PCI and at the same time
Device Serial Number Capability for PCIe Extended caps. This adds a bit of
inconvenience.

In order to distinguish between two sets of same capability IDs, the patch
introduces a set of macros to mark a capability ID as PCIe Extended one
(or check if it is basic/extended + get a raw ID value):
- PCIE_EXT_CAP_ID(cap_id)
- IS_PCIE_EXT_CAP_ID(grp_id)
- GET_PCIE_EXT_CAP_ID(grp_id)

Here is how it's used:
/* Intel IGD Opregion group */
{
.grp_id  = XEN_PCI_INTEL_OPREGION,  /* no change */
.grp_type= XEN_PT_GRP_TYPE_EMU,
.grp_size= 0x4,
.size_init   = xen_pt_reg_grp_size_init,
.emu_regs= xen_pt_emu_reg_igd_opregion,
},
/* Vendor-specific Extended Capability reg group */
{
.grp_id  = PCIE_EXT_CAP_ID(PCI_EXT_CAP_ID_VNDR),
.grp_type= XEN_PT_GRP_TYPE_EMU,
.grp_size= 0xFF,
.size_init   = xen_pt_ext_cap_vendor_size_init,
.emu_regs= xen_pt_ext_cap_emu_reg_vendor,
},
By using the PCIE_EXT_CAP_ID() macro it is possible to reuse existing
header files with already defined PCIe Extended Capability ID values.

find_cap_offset() receive capabily ID and checks if it's an Extended one
by using IS_PCIE_EXT_CAP_ID(cap) macro, passing the real capabiliy
ID value to either xen_host_pci_find_next_ext_cap
or xen_host_pci_find_next_cap.

Signed-off-by: Alexey Gerasimenko 
---
 hw/xen/xen_pt.c |  14 +-
 hw/xen/xen_pt.h |  13 +++--
 hw/xen/xen_pt_config_init.c | 113 +---
 3 files changed, 74 insertions(+), 66 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index a902a9b685..bf098c26b3 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -82,10 +82,20 @@ void xen_pt_log(const PCIDevice *d, const char *f, ...)
 
 /* Config Space */
 
-static int xen_pt_pci_config_access_check(PCIDevice *d, uint32_t addr, int len)
+static int xen_pt_pci_config_access_check(PCIDevice *d,
+  uint32_t addr, int len)
 {
+XenPCIPassthroughState *s = XEN_PT_DEVICE(d);
+
 /* check offset range */
-if (addr > 0xFF) {
+if (s->pcie_enabled_dev) {
+if (addr >= PCIE_CONFIG_SPACE_SIZE) {
+XEN_PT_ERR(d, "Failed to access register with offset "
+  "exceeding 0xFFF. (addr: 0x%02x, len: %d)\n",
+  addr, len);
+return -1;
+}
+} else if (addr >= PCI_CONFIG_SPACE_SIZE) {
 XEN_PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
"(addr: 0x%02x, len: %d)\n", addr, len);
 return -1;
diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 1204acbdce..5531347ab2 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -31,6 +31,11 @@ void xen_pt_log(const PCIDevice *d, const char *f, ...) 
GCC_FMT_ATTR(2, 3);
 /* Helper */
 #define XEN_PFN(x) ((x) >> XC_PAGE_SHIFT)
 
+/* Macro's for PCIe Extended Capabilities */
+#define PCIE_EXT_CAP_ID(cap_id) ((cap_id) | (1U << 16))
+#define IS_PCIE_EXT_CAP_ID(grp_id)  ((grp_id) & (1U << 16))
+#define GET_PCIE_EXT_CAP_ID(grp_id) ((grp_id) & 0x)
+
 typedef const struct XenPTRegInfo XenPTRegInfo;
 typedef struct XenPTReg XenPTReg;
 
@@ -152,13 +157,13 @@ typedef const struct XenPTRegGroupInfo XenPTRegGroupInfo;
 /* emul reg group size initialize method */
 typedef int (*xen_pt_reg_size_init_fn)
 (XenPCIPassthroughState *, XenPTRegGroupInfo *,
- uint32_t base_offset, uint8_t *size);
+ uint32_t base_offset, uint32_t *size);
 
 /* emulated register group information */
 struct XenPTRegGroupInfo {
-uint8_t grp_id;
+uint32_t grp_id;
 XenPTRegisterGroupType grp_type;
-uint8_t grp_size;
+uint32_t grp_size;
 xen_pt_reg_size_init_fn size_init;
 XenPTRegInfo *emu_regs;
 };
@@ -168,7 +173,7 @@ typedef struct XenPTRegGroup {
 QLIST_ENTRY(XenPTRegGroup) entries;
 XenPTRegGroupInfo *reg_grp;
 uint32_t base_offset;
-uint8_t size;
+uint32_t size;
 QLIST_HEAD(, XenPTReg) reg_tbl_list;
 } XenPTRegGroup;
 
diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 91de215407..9c041fa288 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -32,29 +32,42 @@ static int xen_pt_ptr_reg_init(XenPCIPassthroughState *s, 
XenPTRegInfo *reg,
 /* helper */
 
 /* 

[Xen-devel] [RFC PATCH 21/30] xen/pt: Xen PCIe passthrough support for Q35: bypass PCIe topology check

[Alexey Gerasimenko]

Compared to legacy i440 system, there are certain difficulties while
passing through PCIe devices to guest OSes like Windows 7 and above
on platforms with native support of PCIe bus (in our case Q35). This
problem is not applicable to older OSes like Windows XP -- PCIe
passthrough on such OSes can be used normally as these OSes have
no support for PCIe-specific features and treat all PCIe devices as legacy
PCI ones.

The problem manifests itself as "Code 10" error for a passed thru PCIe
device in Windows Device Manager (along with exclamation mark on it). The
device with such error do not function no matter the fact that Windows
successfully booted while actually using this device, ex. as a primary VGA
card with VBE features, LFB, etc. working properly during boot time.
It doesn't matter which PCI class the device have -- the problem is common
to GPUs, NIC cards, USB controllers, etc. In the same time, all these
devices can be passed thru successfully using i440 emulation on same
Windows 7+ OSes.

The actual root cause of the problem lies in the fact that Windows kernel
(PnP manager particularly) while processing StartDevice IRP refuses
to continue to start the device and control flow actually doesn't even
reach the IRP handler in the device driver at all. The real reason for
this typically does not appear at the time PnP manager tries to start the
device, but happens much earlier -- during the Windows boot stage, while
enumerating devices on a PCI/PCIe bus in the Windows pci.sys driver. There
is a set of checks for every discovered device on the PCIe bus. Failing
some of them leads to marking the discovered PCIe device as 'invalid'
by setting the flag. Later on, StartDevice attempt will fail due to this
flag, finally resulting in Code 10 error.

The actual check in pci.sys which results in the PCIe device being marked
as 'invalid' in our case is a validation of upstream PCIe bus hierarchy
to which passed through device belongs. Basically, pci.sys checks if the
PCIe device has parent devices, such as PCIe Root Port or upstream PCIe
switch. In our case the PCIe device has no parents and resides on bus
0 without eg. corresponding Root Port.

Therefore, in order to resolve this problem in a architecturally correct
way, we need to introduce to Xen some support of at least trivial non-flat
PCI bus hierarchy. In very simplest case - just one virtual Root Port,
on secondary bus of which all physical functions of the real passed thru
device will reside, eg. GPU and its HDAudio function.

This solution is not hard to implement technically, but there are multiple
affecting limitations present in Xen (many related to each other)
currently:

- in many places the code is limited to use bus 0 only. This applicable
  to both hypervisor and supplemental modules like hvmloader. This
  limitation is enforced on API level -- many functions and interfaces
  allow to specify only devfn argument while bus 0 being implied.

- lot of code assumes Type0 PCI config space layout only, while we need
  to handle Type1 PCI devices as well

- currently there no way to assign to a guest domain even a simplest
  linked hierarchy of passed thru PCI devices. In some cases we might need
  to passthrough a real PCIe Switch/Root Port with his downstream child
  devices.

- in a similar way Xen/hvmloader lacks the concept of IO/MMIO space
  nesting. Both code which does MMIO hole sizing and code which allocates
  BARs to MMIO hole have no idea of MMIO ranges nesting and their relations.
  In case of virtual Root Port we have basically an emulated PCI-PCI bridge
  with some parts of its MMIO range used for real MMIO ranges of passed
  through device(s).

So, adding to Xen multiple PCI buses support will require a bit of effort
and discussions regarding the actual design of the feature.  Nevertheless,
this task is crucial for PCI/GPU passthrough features of Xen to work
properly.

To summarize, we need to implement following things in the future:
1) Get rid of PCI bus 0 limitation everywhere. This could've been
  a simplest of subtasks but in reality this will require to change
  interfaces as well - AFAIR even adding a PCI device via QMP only allows
  to specify a device slot while we need to have some way to place the
  device on an arbitrary bus.

2) Fully or partially emulated PCI-PCI bridge which will provide
  a secondary bus for PCIe device placement - there might be a possibility
  to reuse some existing emulation QEMU provides. This also includes Type1
  devices support.
  The task will become more complicated if there arise necessity, for
  example, to control the PCIe link for a passed through PCIe device. As PT
  device reset is mandatory in most cases, there might be a chance
  to encounter a situation when we need to retrain the PCIe link to restore
  PCIe link speed after the reset. In this case there will be a need
  to selectively translate accesses to certain registers of emulated PCIe
  Switch/Root Port to the corresponding 

[Xen-devel] [RFC PATCH 18/30] xen/pt: XenHostPCIDevice: provide functions for PCI Capabilities and PCIe Extended Capabilities enumeration

[Alexey Gerasimenko]

This patch introduces 2 new functions,
- xen_host_pci_find_next_ext_cap (actually a reworked
  xen_host_pci_find_ext_cap_offset function which is unused)
- xen_host_pci_find_next_cap

These functions allow to search for PCI/PCIe capabilities in a uniform
way. Both functions allow to search either a specific capability or any
encountered next (by specifying CAP_ID_ANY as a capability ID) -- this may
be useful when we merely need to traverse the capability list one-by-one.
In both functions the 'pos' argument allows to continue searching from
last position (0 means to start from beginning).

In order not to probe PCIe Extended Capabilities existence every time,
xen_host_pci_find_next_ext_cap makes use of the new 'has_pcie_ext_caps'
field in XenHostPCIDevice structure which is filled only once (in
xen_host_pci_device_get).

Signed-off-by: Alexey Gerasimenko 
---
 hw/xen/xen-host-pci-device.c | 95 +---
 hw/xen/xen-host-pci-device.h |  5 ++-
 2 files changed, 85 insertions(+), 15 deletions(-)

diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
index eed8cc88e3..9d76b199af 100644
--- a/hw/xen/xen-host-pci-device.c
+++ b/hw/xen/xen-host-pci-device.c
@@ -14,6 +14,7 @@
 
 #define XEN_HOST_PCI_MAX_EXT_CAP \
 ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+#define XEN_HOST_PCI_CAP_MAX 48
 
 #ifdef XEN_HOST_PCI_DEVICE_DEBUG
 #  define XEN_HOST_PCI_LOG(f, a...) fprintf(stderr, "%s: " f, __func__, ##a)
@@ -199,6 +200,19 @@ static bool xen_host_pci_dev_is_virtfn(XenHostPCIDevice *d)
 return !stat(path, );
 }
 
+static bool xen_host_pci_dev_has_pcie_ext_caps(XenHostPCIDevice *d)
+{
+uint32_t header;
+
+if (xen_host_pci_get_long(d, PCI_CONFIG_SPACE_SIZE, ))
+return false;
+
+if (header == 0 || header == ~0U)
+return false;
+
+return true;
+}
+
 static void xen_host_pci_config_open(XenHostPCIDevice *d, Error **errp)
 {
 char path[PATH_MAX];
@@ -297,37 +311,89 @@ int xen_host_pci_set_block(XenHostPCIDevice *d, int pos, 
uint8_t *buf, int len)
 return xen_host_pci_config_write(d, pos, buf, len);
 }
 
-int xen_host_pci_find_ext_cap_offset(XenHostPCIDevice *d, uint32_t cap)
+int xen_host_pci_find_next_ext_cap(XenHostPCIDevice *d, int pos, uint32_t cap)
 {
 uint32_t header = 0;
 int max_cap = XEN_HOST_PCI_MAX_EXT_CAP;
-int pos = PCI_CONFIG_SPACE_SIZE;
+
+if (!d->has_pcie_ext_caps)
+return 0;
+
+if (!pos) {
+pos = PCI_CONFIG_SPACE_SIZE;
+} else {
+if (xen_host_pci_get_long(d, pos, ))
+return 0;
+
+pos = PCI_EXT_CAP_NEXT(header);
+}
 
 do {
-if (xen_host_pci_get_long(d, pos, )) {
+if (!pos || pos < PCI_CONFIG_SPACE_SIZE)
+break;
+
+if (xen_host_pci_get_long(d, pos, ))
 break;
-}
 /*
  * If we have no capabilities, this is indicated by cap ID,
  * cap version and next pointer all being 0.
+ * Also check for all F's returned (which means PCIe ext conf space
+ * is unreadable for some reason)
  */
-if (header == 0) {
+if (header == 0 || header == ~0U)
 break;
-}
 
-if (PCI_EXT_CAP_ID(header) == cap) {
+if (cap == CAP_ID_ANY)
+return pos;
+else if (PCI_EXT_CAP_ID(header) == cap)
 return pos;
-}
 
 pos = PCI_EXT_CAP_NEXT(header);
-if (pos < PCI_CONFIG_SPACE_SIZE) {
+} while (--max_cap);
+
+return 0;
+}
+
+int xen_host_pci_find_next_cap(XenHostPCIDevice *d, int pos, uint32_t cap)
+{
+uint8_t id;
+unsigned max_cap = XEN_HOST_PCI_CAP_MAX;
+uint8_t status = 0;
+uint8_t curpos;
+
+if (xen_host_pci_get_byte(d, PCI_STATUS, ))
+return 0;
+
+if ((status & PCI_STATUS_CAP_LIST) == 0)
+return 0;
+
+if (pos < PCI_CAPABILITY_LIST) {
+curpos = PCI_CAPABILITY_LIST;
+} else {
+curpos = (uint8_t) pos;
+}
+
+while (max_cap--) {
+if (xen_host_pci_get_byte(d, curpos, ))
+break;
+if (!curpos)
 break;
-}
 
-max_cap--;
-} while (max_cap > 0);
+if (cap == CAP_ID_ANY)
+return curpos;
 
-return -1;
+if (xen_host_pci_get_byte(d, curpos + PCI_CAP_LIST_ID, ))
+break;
+
+if (id == 0xff)
+break;
+else if (id == cap)
+return curpos;
+
+curpos += PCI_CAP_LIST_NEXT;
+}
+
+return 0;
 }
 
 void xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t domain,
@@ -377,7 +443,8 @@ void xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t 
domain,
 }
 d->class_code = v;
 
-d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
+d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
+d->has_pcie_ext_caps = xen_host_pci_dev_has_pcie_ext_caps(d);
 
 return;
 
diff --git 

[Xen-devel] [RFC PATCH 17/30] q35: Fix incorrect values for PCIEXBAR masks

[Alexey Gerasimenko]

There are two small issues in PCIEXBAR address mask handling:
- wrong bit positions for address mask bits (see PCIEXBAR description
  in Q35 datasheet)
- incorrect usage of 64ADR_MASK

Due to this, attempting to write a valid PCIEXBAR address may cause it to
shift to another address, causing memory layout corruption where emulated
MMIO regions may overlap real (passed through) MMIO ranges. Fix this
by providing correct values.

Signed-off-by: Alexey Gerasimenko 
---
 hw/pci-host/q35.c | 6 +++---
 include/hw/pci-host/q35.h | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 8c1603fce9..b9a49721e2 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -322,12 +322,12 @@ static void mch_update_pciexbar(MCHPCIState *mch)
 break;
 case MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_128M:
 length = 128 * 1024 * 1024;
-addr_mask |= MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK |
-MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK;
+addr_mask |= MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK;
 break;
 case MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_64M:
 length = 64 * 1024 * 1024;
-addr_mask |= MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK;
+addr_mask |= MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK |
+MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK;
 break;
 case MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_RVD:
 default:
diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
index 8f4ddde393..ec8d77fa8b 100644
--- a/include/hw/pci-host/q35.h
+++ b/include/hw/pci-host/q35.h
@@ -103,8 +103,8 @@ typedef struct Q35PCIHost {
 #define MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT   0xb000
 #define MCH_HOST_BRIDGE_PCIEXBAR_MAX   (0x1000) /* 256M */
 #define MCH_HOST_BRIDGE_PCIEXBAR_ADMSK Q35_MASK(64, 35, 28)
-#define MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK  ((uint64_t)(1 << 26))
-#define MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK   ((uint64_t)(1 << 25))
+#define MCH_HOST_BRIDGE_PCIEXBAR_128ADMSK  ((uint64_t)(1 << 27))
+#define MCH_HOST_BRIDGE_PCIEXBAR_64ADMSK   ((uint64_t)(1 << 26))
 #define MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_MASK   ((uint64_t)(0x3 << 1))
 #define MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_256M   ((uint64_t)(0x0 << 1))
 #define MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_128M   ((uint64_t)(0x1 << 1))
-- 
2.11.0


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

[Xen-devel] [RFC PATCH 15/30] q35/acpi/xen: Provide ACPI PCI hotplug interface for Xen on Q35

[Alexey Gerasimenko]

This patch allows to use ACPI PCI hotplug functionality for Xen on Q35.
All added code depends on xen_enabled(), so no functionality change for
non-Xen usage.

We need to call the acpi_set_pci_info function from ich9_pm_init as well,
so it was made globally visible again (as it was before).

Signed-off-by: Alexey Gerasimenko 
---
 hw/acpi/ich9.c  | 24 
 hw/acpi/pcihp.c |  2 +-
 include/hw/acpi/ich9.h  |  2 ++
 include/hw/acpi/pcihp.h |  2 ++
 4 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index c5d8646abc..62e2582e1a 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -37,6 +37,7 @@
 
 #include "hw/i386/ich9.h"
 #include "hw/mem/pc-dimm.h"
+#include "hw/xen/xen.h"
 
 //#define DEBUG
 
@@ -258,6 +259,10 @@ static void pm_reset(void *opaque)
 pm->smi_en_wmask = ~0;
 
 acpi_update_sci(>acpi_regs, pm->irq);
+
+if (xen_enabled()) {
+acpi_pcihp_reset(>acpi_pci_hotplug);
+}
 }
 
 static void pm_powerdown_req(Notifier *n, void *opaque)
@@ -300,6 +305,17 @@ void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm,
 pm->powerdown_notifier.notify = pm_powerdown_req;
 qemu_register_powerdown_notifier(>powerdown_notifier);
 
+if (xen_enabled()) {
+PCIBus *bus = pci_get_bus(lpc_pci);
+
+qbus_set_hotplug_handler(BUS(bus), DEVICE(lpc_pci), _abort);
+
+acpi_pcihp_init(OBJECT(lpc_pci), >acpi_pci_hotplug, bus,
+pci_address_space_io(lpc_pci), false);
+
+acpi_set_pci_info();
+}
+
 legacy_acpi_cpu_hotplug_init(pci_address_space_io(lpc_pci),
 OBJECT(lpc_pci), >gpe_cpu, ICH9_CPU_HOTPLUG_IO_BASE);
 
@@ -496,6 +512,10 @@ void ich9_pm_device_plug_cb(HotplugHandler *hotplug_dev, 
DeviceState *dev,
 acpi_memory_plug_cb(hotplug_dev, >pm.acpi_memory_hotplug,
 dev, errp);
 }
+} else if (xen_enabled() &&
+   object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
+acpi_pcihp_device_plug_cb(hotplug_dev, >pm.acpi_pci_hotplug,
+  dev, errp);
 } else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
 if (lpc->pm.cpu_hotplug_legacy) {
 legacy_acpi_cpu_plug_cb(hotplug_dev, >pm.gpe_cpu, dev, errp);
@@ -522,6 +542,10 @@ void ich9_pm_device_unplug_request_cb(HotplugHandler 
*hotplug_dev,
!lpc->pm.cpu_hotplug_legacy) {
 acpi_cpu_unplug_request_cb(hotplug_dev, >pm.cpuhp_state,
dev, errp);
+} else if (xen_enabled() &&
+   object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
+acpi_pcihp_device_unplug_cb(hotplug_dev, >pm.acpi_pci_hotplug,
+dev, errp);
 } else {
 error_setg(errp, "acpi: device unplug request for not supported device"
" type: %s", object_get_typename(OBJECT(dev)));
diff --git a/hw/acpi/pcihp.c b/hw/acpi/pcihp.c
index f70d8620d7..d822f93293 100644
--- a/hw/acpi/pcihp.c
+++ b/hw/acpi/pcihp.c
@@ -94,7 +94,7 @@ static void *acpi_set_bsel(PCIBus *bus, void *opaque)
 return bsel_alloc;
 }
 
-static void acpi_set_pci_info(void)
+void acpi_set_pci_info(void)
 {
 static bool bsel_is_set;
 PCIBus *bus;
diff --git a/include/hw/acpi/ich9.h b/include/hw/acpi/ich9.h
index 59aeb06393..4a47d93745 100644
--- a/include/hw/acpi/ich9.h
+++ b/include/hw/acpi/ich9.h
@@ -26,6 +26,7 @@
 #include "hw/acpi/cpu.h"
 #include "hw/acpi/memory_hotplug.h"
 #include "hw/acpi/acpi_dev_interface.h"
+#include "hw/acpi/pcihp.h"
 #include "hw/acpi/tco.h"
 
 typedef struct ICH9LPCPMRegs {
@@ -52,6 +53,7 @@ typedef struct ICH9LPCPMRegs {
 bool cpu_hotplug_legacy;
 AcpiCpuHotplug gpe_cpu;
 CPUHotplugState cpuhp_state;
+AcpiPciHpState acpi_pci_hotplug;
 
 MemHotplugState acpi_memory_hotplug;
 
diff --git a/include/hw/acpi/pcihp.h b/include/hw/acpi/pcihp.h
index 8a65f99fc8..0a685dd228 100644
--- a/include/hw/acpi/pcihp.h
+++ b/include/hw/acpi/pcihp.h
@@ -64,6 +64,8 @@ void acpi_pcihp_device_unplug_cb(HotplugHandler *hotplug_dev, 
AcpiPciHpState *s,
 /* Called on reset */
 void acpi_pcihp_reset(AcpiPciHpState *s);
 
+void acpi_set_pci_info(void);
+
 extern const VMStateDescription vmstate_acpi_pcihp_pci_status;
 
 #define VMSTATE_PCI_HOTPLUG(pcihp, state, test_pcihp) \
-- 
2.11.0


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

[Xen-devel] [RFC PATCH 13/30] pc/xen: Xen Q35 support: provide IRQ handling for PCI devices

[Alexey Gerasimenko]

The primary difference in PCI device IRQ management between Xen HVM and
QEMU is that Xen PCI IRQs are "device-centric" while QEMU PCI IRQs are
"chipset-centric". Namely, Xen uses PCI device BDF and INTx as coordinates
to assert IRQ while QEMU finds out to which chipset PIRQ the IRQ is routed
through the hierarchy of PCI buses and manages IRQ assertion on chipset
side (as PIRQ inputs).

Two callback functions are used for this purpose: .map_irq and .set_irq
(named after corresponding structure fields). Corresponding Xen-specific
callback functions are piix3_set_irq() and pci_slot_get_pirq(). In Xen
case these functions do not operate on pirq pin numbers. Instead, they use
a specific value to pass BDF/INTx information between .map_irq and
.set_irq -- PCI device devfn and INTx pin number are combined into
pseudo-PIRQ in pci_slot_get_pirq, which piix3_set_irq later decodes back
into devfn and INTx number for passing to *set_pci_intx_level() call.

For Xen on Q35 this scheme is still applicable, with the exception that
function names are non-descriptive now and need to be renamed to show
their common i440/Q35 nature. Proposed new names are:

xen_pci_slot_get_pirq --> xen_cmn_pci_slot_get_pirq
xen_piix3_set_irq --> xen_cmn_set_irq

Another IRQ-related difference between i440 and Q35 is the number of PIRQ
inputs and PIRQ routers (PCI IRQ links in terms of ACPI) available. i440
has 4 PCI interrupt links, while Q35 has 8 (PIRQA...PIRQH).
Currently Xen have support for only 4 PCI links, so we describe only 4 of
8 PCI links in ACPI tables. Also, hvmloader disables PIRQ routing for
PIRQE..PIRQH by writing 80h into corresponding PIRQ[n]_ROUT registers.

All this PCI interrupt routing stuff is largely an ancient legacy from PIC
era. It's hardly worth to extend number of PCI links supported as we
normally deal with APIC mode and/or MSI interrupts.

The only useful thing to do with PIRQE..PIRQH routing currently is to
check if guest actually attempts to use it for some reason (despite ACPI
PCI routing information provided). In this case, a warning is logged.

Signed-off-by: Alexey Gerasimenko 
---
 hw/i386/pc_q35.c   | 13 ++---
 hw/i386/xen/xen-hvm.c  | 32 +---
 hw/isa/lpc_ich9.c  |  4 
 hw/pci-host/piix.c |  2 +-
 include/hw/i386/ich9.h |  1 +
 include/hw/xen/xen.h   |  5 +++--
 stubs/xen-hvm.c|  8 ++--
 7 files changed, 54 insertions(+), 11 deletions(-)

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 0c0bc48137..0db670f6d7 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -203,9 +203,16 @@ static void pc_q35_init(MachineState *machine)
 for (i = 0; i < GSI_NUM_PINS; i++) {
 qdev_connect_gpio_out_named(lpc_dev, ICH9_GPIO_GSI, i, pcms->gsi[i]);
 }
-pci_bus_irqs(host_bus, ich9_lpc_set_irq, ich9_lpc_map_irq, ich9_lpc,
- ICH9_LPC_NB_PIRQS);
-pci_bus_set_route_irq_fn(host_bus, ich9_route_intx_pin_to_irq);
+
+if (xen_enabled()) {
+pci_bus_irqs(host_bus, xen_cmn_set_irq, xen_cmn_pci_slot_get_pirq,
+ ich9_lpc, ICH9_XEN_NUM_IRQ_SOURCES);
+} else {
+pci_bus_irqs(host_bus, ich9_lpc_set_irq, ich9_lpc_map_irq, ich9_lpc,
+ ICH9_LPC_NB_PIRQS);
+pci_bus_set_route_irq_fn(host_bus, ich9_route_intx_pin_to_irq);
+}
+
 isa_bus = ich9_lpc->isa_bus;
 
 if (kvm_pic_in_kernel()) {
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index f24b7d4923..40a5c13fa6 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -13,6 +13,7 @@
 #include "cpu.h"
 #include "hw/pci/pci.h"
 #include "hw/i386/pc.h"
+#include "hw/i386/ich9.h"
 #include "hw/i386/apic-msidef.h"
 #include "hw/xen/xen_common.h"
 #include "hw/xen/xen_backend.h"
@@ -115,14 +116,14 @@ typedef struct XenIOState {
 Notifier wakeup;
 } XenIOState;
 
-/* Xen specific function for piix pci */
+/* Xen-specific functions for pci dev IRQ handling */
 
-int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
+int xen_cmn_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
 {
 return irq_num + ((pci_dev->devfn >> 3) << 2);
 }
 
-void xen_piix3_set_irq(void *opaque, int irq_num, int level)
+void xen_cmn_set_irq(void *opaque, int irq_num, int level)
 {
 xen_set_pci_intx_level(xen_domid, 0, 0, irq_num >> 2,
irq_num & 3, level);
@@ -145,6 +146,31 @@ void xen_piix_pci_write_config_client(uint32_t address, 
uint32_t val, int len)
 }
 }
 
+void xen_ich9_pci_write_config_client(uint32_t address, uint32_t val, int len)
+{
+static bool pirqe_f_warned = false;
+
+if (ranges_overlap(address, len, ICH9_LPC_PIRQA_ROUT, 4)) {
+/* handle PIRQA..PIRQD routing */
+xen_piix_pci_write_config_client(address, val, len);
+} else if (ranges_overlap(address, len, ICH9_LPC_PIRQE_ROUT, 4)) {
+while (len--) {
+if (range_covers_byte(ICH9_LPC_PIRQE_ROUT, 4, address) &&
+(val & 0x80) 

[Xen-devel] [RFC PATCH 20/30] xen/pt: determine the legacy/PCIe mode for a passed through device

[Alexey Gerasimenko]

Even if we have some real PCIe device being passed through to a guest,
there are situations when we cannot use its PCIe features, primarily
allowing to access extended (>256) config space.

Basically, we can allow reading PCIe extended config space only if both
the device and emulated system are PCIe-capable. So it's a combination
of checks:
- PCI Express capability presence
- pci_is_express(device)
- pci_bus_is_express(device bus)

The AND-product of these checks is stored to pcie_enabled_dev flag
in XenPCIPassthroughState for later use in functions like
xen_pt_pci_config_access_check.

This way we get consistent behavior when the same PCIe device being passed
through to either i440 domain or Q35 one.

Signed-off-by: Alexey Gerasimenko 
---
 hw/xen/xen_pt.c | 28 ++--
 hw/xen/xen_pt.h |  1 +
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 9b7a960de1..a902a9b685 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -687,6 +687,21 @@ static const MemoryListener xen_pt_io_listener = {
 .priority = 10,
 };
 
+static inline bool xen_pt_dev_is_pcie_mode(PCIDevice *d)
+{
+XenPCIPassthroughState *s = XEN_PT_DEVICE(d);
+PCIBus *bus = pci_get_bus(d);
+
+if (bus != NULL) {
+if (pci_is_express(d) && pci_bus_is_express(bus) &&
+xen_host_pci_find_next_cap(>real_device, 0, PCI_CAP_ID_EXP)) {
+return true;
+}
+}
+
+return false;
+}
+
 static void
 xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
   XenHostPCIDevice *dev)
@@ -794,8 +809,17 @@ static void xen_pt_realize(PCIDevice *d, Error **errp)
s->real_device.dev, s->real_device.func);
 }
 
-/* Initialize virtualized PCI configuration (Extended 256 Bytes) */
-memset(d->config, 0, PCI_CONFIG_SPACE_SIZE);
+s->pcie_enabled_dev = xen_pt_dev_is_pcie_mode(d);
+if (s->pcie_enabled_dev) {
+XEN_PT_LOG(d, "Host device %04x:%02x:%02x.%d passed thru "
+   "in PCIe mode\n", s->real_device.domain,
+s->real_device.bus, s->real_device.dev,
+s->real_device.func);
+}
+
+/* Initialize virtualized PCI configuration space (256/4K bytes) */
+memset(d->config, 0, pci_is_express(d) ? PCIE_CONFIG_SPACE_SIZE
+   : PCI_CONFIG_SPACE_SIZE);
 
 s->memory_listener = xen_pt_memory_listener;
 s->io_listener = xen_pt_io_listener;
diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index aa39a9aa5f..1204acbdce 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -212,6 +212,7 @@ struct XenPCIPassthroughState {
 
 PCIHostDeviceAddress hostaddr;
 bool is_virtfn;
+bool pcie_enabled_dev;
 bool permissive;
 bool permissive_warned;
 XenHostPCIDevice real_device;
-- 
2.11.0


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

[Xen-devel] [RFC PATCH 19/30] xen/pt: avoid reading PCIe device type and cap version multiple times

[Alexey Gerasimenko]

xen_pt_config_init.c reads Device/Port Type and Capability version fields
in many places. Two functions are used for this purpose:
get_capability_version and get_device_type. These functions perform PCI
conf space reading every time they're called. Another bad thing is that
these functions know nothing about where PCI Expess Capability is located,
so its offset must be provided explicitly in function arguments. Their
typical usage is like this:
uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
uint8_t dev_type = get_device_type(s, real_offset - reg->offset);

To avoid this, the PCI Express Capability register now being read only
once and stored in  XenHostPCIDevice structure (pcie_flags field). The
capabiliy offset parameter is no longer needed, simplifying functions
usage. Also, get_device_type and get_capability_version were renamed
to more descriptive get_pcie_device_type and get_pcie_capability_version.

Signed-off-by: Alexey Gerasimenko 
---
 hw/xen/xen-host-pci-device.c | 15 +++
 hw/xen/xen-host-pci-device.h |  1 +
 hw/xen/xen_pt_config_init.c  | 34 ++
 3 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
index 9d76b199af..11e9e26d31 100644
--- a/hw/xen/xen-host-pci-device.c
+++ b/hw/xen/xen-host-pci-device.c
@@ -402,6 +402,7 @@ void xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t 
domain,
 {
 unsigned int v;
 Error *err = NULL;
+int pcie_cap_pos;
 
 d->config_fd = -1;
 d->domain = domain;
@@ -446,6 +447,20 @@ void xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t 
domain,
 d->is_virtfn = xen_host_pci_dev_is_virtfn(d);
 d->has_pcie_ext_caps = xen_host_pci_dev_has_pcie_ext_caps(d);
 
+/* read and store PCIe Capabilities field for later use */
+pcie_cap_pos = xen_host_pci_find_next_cap(d, 0, PCI_CAP_ID_EXP);
+
+if (pcie_cap_pos) {
+if (xen_host_pci_get_word(d, pcie_cap_pos + PCI_EXP_FLAGS,
+  >pcie_flags)) {
+error_setg(, "Unable to read from PCI Express capability "
+   "structure at 0x%x", pcie_cap_pos);
+goto error;
+}
+} else {
+d->pcie_flags = 0x;
+}
+
 return;
 
 error:
diff --git a/hw/xen/xen-host-pci-device.h b/hw/xen/xen-host-pci-device.h
index 37c5614a24..2884c4b4b9 100644
--- a/hw/xen/xen-host-pci-device.h
+++ b/hw/xen/xen-host-pci-device.h
@@ -27,6 +27,7 @@ typedef struct XenHostPCIDevice {
 uint16_t device_id;
 uint32_t class_code;
 int irq;
+uint16_t pcie_flags;
 
 XenHostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
 XenHostPCIIORegion rom;
diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index a3ce33e78b..02e8c97f3c 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -828,24 +828,18 @@ static XenPTRegInfo xen_pt_emu_reg_vendor[] = {
  * PCI Express Capability
  */
 
-static inline uint8_t get_capability_version(XenPCIPassthroughState *s,
- uint32_t offset)
+static inline uint8_t get_pcie_capability_version(XenPCIPassthroughState *s)
 {
-uint8_t flag;
-if (xen_host_pci_get_byte(>real_device, offset + PCI_EXP_FLAGS, )) 
{
-return 0;
-}
-return flag & PCI_EXP_FLAGS_VERS;
+assert(s->real_device.pcie_flags != 0x);
+
+return (uint8_t) (s->real_device.pcie_flags & PCI_EXP_FLAGS_VERS);
 }
 
-static inline uint8_t get_device_type(XenPCIPassthroughState *s,
-  uint32_t offset)
+static inline uint8_t get_pcie_device_type(XenPCIPassthroughState *s)
 {
-uint8_t flag;
-if (xen_host_pci_get_byte(>real_device, offset + PCI_EXP_FLAGS, )) 
{
-return 0;
-}
-return (flag & PCI_EXP_FLAGS_TYPE) >> 4;
+assert(s->real_device.pcie_flags != 0x);
+
+return (uint8_t) ((s->real_device.pcie_flags & PCI_EXP_FLAGS_TYPE) >> 4);
 }
 
 /* initialize Link Control register */
@@ -853,8 +847,8 @@ static int xen_pt_linkctrl_reg_init(XenPCIPassthroughState 
*s,
 XenPTRegInfo *reg, uint32_t real_offset,
 uint32_t *data)
 {
-uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
-uint8_t dev_type = get_device_type(s, real_offset - reg->offset);
+uint8_t cap_ver  = get_pcie_capability_version(s);
+uint8_t dev_type = get_pcie_device_type(s);
 
 /* no need to initialize in case of Root Complex Integrated Endpoint
  * with cap_ver 1.x
@@ -871,7 +865,7 @@ static int xen_pt_devctrl2_reg_init(XenPCIPassthroughState 
*s,
 XenPTRegInfo *reg, uint32_t real_offset,
 uint32_t *data)
 {
-uint8_t cap_ver = get_capability_version(s, real_offset - reg->offset);
+uint8_t cap_ver = 

[Xen-devel] [RFC PATCH 12/12] docs: provide description for device_model_machine option

[Alexey Gerasimenko]

This patch adds description for 'device_model_machine' option which allows
to control which chipset will be emulated by device model.

Signed-off-by: Alexey Gerasimenko 
---
 docs/man/xl.cfg.pod.5.in | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index a699367779..7b8991ab7d 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -2484,6 +2484,33 @@ you have existing guests then, depending on the nature 
of the guest
 Operating System, you may wish to force them to use the device
 model which they were installed with.
 
+=item 

[Xen-devel] [RFC PATCH 08/12] libxl: Q35 support (new option device_model_machine)

[Alexey Gerasimenko]

Provide a new domain config option to select the emulated machine type,
device_model_machine. It has following possible values:
- "i440" - i440 emulation (default)
- "q35" - emulate a Q35 machine. By default, the storage interface is AHCI.

Note that omitting device_model_machine parameter means i440 system
by default, so the default behavior doesn't change for existing domain
config files.

Setting device_model_machine to "q35" sends '-machine q35,accel=xen'
argument to QEMU. Unlike i440, there no separate machine type
to enable/disable Xen platform device, it is controlled via a machine
property only. See 'libxl: Xen Platform device support for Q35' patch for
a detailed description.

Signed-off-by: Alexey Gerasimenko 
---
 tools/libxl/libxl_dm.c  | 16 ++--
 tools/libxl/libxl_types.idl |  7 +++
 tools/xl/xl_parse.c | 14 ++
 3 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index a3cddce8b7..7b531050c7 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1443,13 +1443,17 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
 flexarray_append(dm_args, b_info->extra_pv[i]);
 break;
 case LIBXL_DOMAIN_TYPE_HVM:
-if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
-/* Switching here to the machine "pc" which does not add
- * the xen-platform device instead of the default "xenfv" machine.
- */
-machinearg = libxl__strdup(gc, "pc,accel=xen");
+if (b_info->device_model_machine == LIBXL_DEVICE_MODEL_MACHINE_Q35) {
+machinearg = libxl__sprintf(gc, "q35,accel=xen");
 } else {
-machinearg = libxl__strdup(gc, "xenfv");
+if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
+/* Switching here to the machine "pc" which does not add
+ * the xen-platform device instead of the default "xenfv" 
machine.
+ */
+machinearg = libxl__strdup(gc, "pc,accel=xen");
+} else {
+machinearg = libxl__strdup(gc, "xenfv");
+}
 }
 if (b_info->u.hvm.mmio_hole_memkb) {
 uint64_t max_ram_below_4g = (1ULL << 32) -
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 35038120ca..f3ef3cbdde 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -101,6 +101,12 @@ libxl_device_model_version = 
Enumeration("device_model_version", [
 (2, "QEMU_XEN"), # Upstream based qemu-xen device model
 ])
 
+libxl_device_model_machine = Enumeration("device_model_machine", [
+(0, "UNKNOWN"),
+(1, "I440"),
+(2, "Q35"),
+])
+
 libxl_console_type = Enumeration("console_type", [
 (0, "UNKNOWN"),
 (1, "SERIAL"),
@@ -491,6 +497,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
 ("device_model_ssid_label", string),
 # device_model_user is not ready for use yet
 ("device_model_user", string),
+("device_model_machine", libxl_device_model_machine),
 
 # extra parameters pass directly to qemu, NULL terminated
 ("extra",libxl_string_list),
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index f6842540ca..a7506a426b 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2110,6 +2110,20 @@ skip_usbdev:
 xlu_cfg_replace_string(config, "device_model_user",
_info->device_model_user, 0);
 
+if (!xlu_cfg_get_string (config, "device_model_machine", , 0)) {
+if (!strcmp(buf, "i440")) {
+b_info->device_model_machine = LIBXL_DEVICE_MODEL_MACHINE_I440;
+} else if (!strcmp(buf, "q35")) {
+b_info->device_model_machine = LIBXL_DEVICE_MODEL_MACHINE_Q35;
+} else {
+fprintf(stderr,
+"Unknown device_model_machine \"%s\" specified\n", buf);
+exit(1);
+}
+} else {
+b_info->device_model_machine = LIBXL_DEVICE_MODEL_MACHINE_UNKNOWN;
+}
+
 #define parse_extra_args(type)\
 e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
 _info->extra##type, 0);\
-- 
2.11.0


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

[Xen-devel] [RFC PATCH 01/12] libacpi: new DSDT ACPI table for Q35

[Alexey Gerasimenko]

This patch adds the DSDT table for Q35 (new tools/libacpi/dsdt_q35.asl
file). There are not many differences with dsdt.asl (for i440) at the
moment, namely:

- BDF location of LPC Controller
- Minor changes related to FDC detection
- Addition of _OSC method to inform OSPM about PCIe features supported

As we are still using 4 PCI router links and their corresponding
device/register addresses are same (offset 0x60), no need to change PCI
routing descriptions.

Also, ACPI hotplug is still used to control passed through device hot
(un)plug (as it was for i440).

Signed-off-by: Alexey Gerasimenko 
---
 tools/libacpi/dsdt_q35.asl | 551 +
 1 file changed, 551 insertions(+)
 create mode 100644 tools/libacpi/dsdt_q35.asl

diff --git a/tools/libacpi/dsdt_q35.asl b/tools/libacpi/dsdt_q35.asl
new file mode 100644
index 00..cd02946a07
--- /dev/null
+++ b/tools/libacpi/dsdt_q35.asl
@@ -0,0 +1,551 @@
+/**
+ * DSDT for Xen with Qemu device model (for Q35 machine)
+ *
+ * Copyright (c) 2004, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
+{
+Name (\PMBS, 0x0C00)
+Name (\PMLN, 0x08)
+Name (\IOB1, 0x00)
+Name (\IOL1, 0x00)
+Name (\APCB, 0xFEC0)
+Name (\APCL, 0x0001)
+Name (\PUID, 0x00)
+
+
+Scope (\_SB)
+{
+
+/* Fix HCT test for 0x400 pci memory:
+ * - need to report low 640 MB mem as motherboard resource
+ */
+   Device(MEM0)
+   {
+   Name(_HID, EISAID("PNP0C02"))
+   Name(_CRS, ResourceTemplate() {
+   QWordMemory(
+ResourceConsumer, PosDecode, MinFixed,
+MaxFixed, Cacheable, ReadWrite,
+0x,
+0x,
+0x0009,
+0x,
+0x000a)
+   })
+   }
+
+   Device (PCI0)
+   {
+   Name (_HID, EisaId ("PNP0A03"))
+   Name (_UID, 0x00)
+   Name (_ADR, 0x00)
+   Name (_BBN, 0x00)
+
+   /* _OSC, modified from ASL sample in ACPI spec */
+   Name(SUPP, 0) /* PCI _OSC Support Field value */
+   Name(CTRL, 0) /* PCI _OSC Control Field value */
+   Method(_OSC, 4) {
+   /* Create DWORD-addressable fields from the Capabilities Buffer 
*/
+   CreateDWordField(Arg3, 0, CDW1)
+
+   /* Switch by UUID.
+* Only PCI Host Bridge Device capabilities UUID used for now
+*/
+   If (LEqual(Arg0, 
ToUUID("33DB4D5B-1FF7-401C-9657-7441C03DD766"))) {
+   /* Create DWORD-addressable fields from the Capabilities 
Buffer */
+   CreateDWordField(Arg3, 4, CDW2)
+   CreateDWordField(Arg3, 8, CDW3)
+
+   /* Save Capabilities DWORD2 & 3 */
+   Store(CDW2, SUPP)
+   Store(CDW3, CTRL)
+
+   /* Validate Revision DWORD */
+   If (LNotEqual(Arg1, One)) {
+   /* Unknown revision */
+   /* Support and Control DWORDs will be returned anyway */
+   Or(CDW1, 0x08, CDW1)
+   }
+
+   /* Control field bits are:
+* bit 0PCI Express Native Hot Plug control
+* bit 1SHPC Native Hot Plug control
+* bit 2PCI Express Native Power Management Events 
control
+* bit 3PCI Express Advanced Error Reporting control
+* bit 4PCI Express Capability Structure control
+*/
+
+   /* Always allow native PME, AER (no dependencies)
+* Never allow SHPC (no SHPC controller in this system)
+* Do not allow PCIe Capability Structure control for now
+* Also, ACPI hotplug is used for now instead of PCIe
+* Native Hot Plug
+*/
+   And(CTRL, 0x0C, CTRL)
+
+   If (LNotEqual(CDW3, CTRL)) {
+   /* Some of Capabilities bits were masked */
+   Or(CDW1, 0x10, CDW1)
+   }
+   /* Update DWORD3 in the buffer */
+

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

[Alexey Gerasimenko]

This patch extends hvmloader_acpi_build_tables() with code which detects
if MMCONFIG is available -- i.e. initialized and enabled (+we're running
on Q35), obtains its base address and size and asks libacpi to build MCFG
table for it via setting the flag ACPI_HAS_MCFG in a manner similar
to other optional ACPI tables building.

Signed-off-by: Alexey Gerasimenko 
---
 tools/firmware/hvmloader/util.c | 70 +
 1 file changed, 70 insertions(+)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index d8db9e3c8e..c6fc81d52a 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -782,6 +782,69 @@ int get_pc_machine_type(void)
 return machine_type;
 }
 
+#define PCIEXBAR_ADDR_MASK_64MB (~((1ULL << 26) - 1))
+#define PCIEXBAR_ADDR_MASK_128MB(~((1ULL << 27) - 1))
+#define PCIEXBAR_ADDR_MASK_256MB(~((1ULL << 28) - 1))
+#define PCIEXBAR_LENGTH_BITS(reg)   (((reg) >> 1) & 3)
+#define PCIEXBAREN  1
+
+static uint64_t mmconfig_get_base(void)
+{
+uint64_t base;
+uint32_t reg = pci_readl(PCI_MCH_DEVFN, PCI_MCH_PCIEXBAR);
+
+base = reg | (uint64_t) pci_readl(PCI_MCH_DEVFN, PCI_MCH_PCIEXBAR+4) << 32;
+
+switch (PCIEXBAR_LENGTH_BITS(reg))
+{
+case 0:
+base &= PCIEXBAR_ADDR_MASK_256MB;
+break;
+case 1:
+base &= PCIEXBAR_ADDR_MASK_128MB;
+break;
+case 2:
+base &= PCIEXBAR_ADDR_MASK_64MB;
+break;
+case 3:
+BUG();  /* a reserved value encountered */
+}
+
+return base;
+}
+
+static uint32_t mmconfig_get_size(void)
+{
+uint32_t reg = pci_readl(PCI_MCH_DEVFN, PCI_MCH_PCIEXBAR);
+
+switch (PCIEXBAR_LENGTH_BITS(reg))
+{
+case 0: return MB(256);
+case 1: return MB(128);
+case 2: return MB(64);
+case 3:
+BUG();  /* a reserved value encountered */
+}
+
+return 0;
+}
+
+static uint32_t mmconfig_is_enabled(void)
+{
+return pci_readl(PCI_MCH_DEVFN, PCI_MCH_PCIEXBAR) & PCIEXBAREN;
+}
+
+static int is_mmconfig_used(void)
+{
+if (get_pc_machine_type() == MACHINE_TYPE_Q35)
+{
+if (mmconfig_is_enabled() && mmconfig_get_base())
+return 1;
+}
+
+return 0;
+}
+
 static void validate_hvm_info(struct hvm_info_table *t)
 {
 uint8_t *ptr = (uint8_t *)t;
@@ -993,6 +1056,13 @@ void hvmloader_acpi_build_tables(struct acpi_config 
*config,
 config->pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
 }
 
+if ( is_mmconfig_used() )
+{
+config->table_flags |= ACPI_HAS_MCFG;
+config->mmconfig_addr = mmconfig_get_base();
+config->mmconfig_len  = mmconfig_get_size();
+}
+
 s = xenstore_read("platform/generation-id", "0:0");
 if ( s )
 {
-- 
2.11.0


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

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

[Alexey Gerasimenko]

Much like normal PCI BARs or other chipset-specific memory-mapped
resources, MMCONFIG area needs space in MMIO hole, so we must allocate
it manually.

The actual MMCONFIG size depends on a number of PCI buses available which
should be covered by ECAM. Possible options are 64MB, 128MB and 256MB.
As we are limited to the bus 0 currently, thus using lowest possible
setting (64MB), #defined via PCI_MAX_MCFG_BUSES in hvmloader/config.h.
When multiple PCI buses support for Xen will be implemented,
PCI_MAX_MCFG_BUSES may be changed to calculation of the number of buses
according to results of the PCI devices enumeration.

The way to allocate MMCONFIG range in MMIO hole is similar to how other
PCI BARs are allocated. The patch extends 'bars' structure to make
it universal for any arbitrary BAR type -- either IO, MMIO, ROM or
a chipset-specific resource.

One important new field is addr_mask, which tells which bits of the base
address can (should) be written. Different address types (ROM, MMIO BAR,
PCIEXBAR) will have different addr_mask values.

For every assignable BAR range we store its size, PCI device BDF (devfn
actually) to which it belongs, BAR type (mem/io/mem64) and corresponding
register offset in device PCI conf space. This way we can insert MMCONFIG
entry into bars array in the same manner like for any other BARs. In this
case, the devfn field will point to MCH PCI device and bar_reg will
contain PCIEXBAR register offset. It will be assigned a slot in MMIO hole
later in a very same way like for plain PCI BARs, with respect to its size
alignment.

Also, to reduce code complexity, all long mem/mem64 BAR flags checks are
replaced by simple bars[i] field probing, eg.:
-if ( (bar_reg == PCI_ROM_ADDRESS) ||
- ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
-  PCI_BASE_ADDRESS_SPACE_MEMORY) )
+if ( bars[i].is_mem )

Signed-off-by: Alexey Gerasimenko 
---
 tools/firmware/hvmloader/config.h   |   4 ++
 tools/firmware/hvmloader/pci.c  | 127 
 tools/firmware/hvmloader/pci_regs.h |   2 +
 3 files changed, 106 insertions(+), 27 deletions(-)

diff --git a/tools/firmware/hvmloader/config.h 
b/tools/firmware/hvmloader/config.h
index 6fde6b7b60..5443ecd804 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -53,10 +53,14 @@ extern uint8_t ioapic_version;
 #define PCI_ISA_DEVFN   0x08/* dev 1, fn 0 */
 #define PCI_ISA_IRQ_MASK0x0c20U /* ISA IRQs 5,10,11 are PCI connected */
 #define PCI_ICH9_LPC_DEVFN  0xf8/* dev 31, fn 0 */
+#define PCI_MCH_DEVFN   0   /* bus 0, dev 0, func 0 */
 
 /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
 #define PCI_MEM_END 0xfc00
 
+/* possible values are: 64, 128, 256 */
+#define PCI_MAX_MCFG_BUSES  64
+
 #define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
 
 extern unsigned long pci_mem_start, pci_mem_end;
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 033bd20992..6de124bbd5 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -158,9 +158,10 @@ static void class_specific_pci_device_setup(uint16_t 
vendor_id,
 
 void pci_setup(void)
 {
-uint8_t is_64bar, using_64bar, bar64_relocate = 0;
+uint8_t is_64bar, using_64bar, bar64_relocate = 0, is_mem;
 uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
 uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
+uint64_t addr_mask;
 uint16_t vendor_id, device_id;
 unsigned int bar, pin, link, isa_irq;
 int is_running_on_q35 = 0;
@@ -172,10 +173,14 @@ void pci_setup(void)
 
 /* Create a list of device BARs in descending order of size. */
 struct bars {
-uint32_t is_64bar;
 uint32_t devfn;
 uint32_t bar_reg;
 uint64_t bar_sz;
+uint64_t addr_mask; /* which bits of the base address can be written */
+uint32_t bar_data;  /* initial value - BAR flags here */
+uint8_t  is_64bar;
+uint8_t  is_mem;
+uint8_t  padding[2];
 } *bars = (struct bars *)scratch_start;
 unsigned int i, nr_bars = 0;
 uint64_t mmio_hole_size = 0;
@@ -259,13 +264,21 @@ void pci_setup(void)
 bar_reg = PCI_ROM_ADDRESS;
 
 bar_data = pci_readl(devfn, bar_reg);
+
+is_mem = !!(((bar_data & PCI_BASE_ADDRESS_SPACE) ==
+   PCI_BASE_ADDRESS_SPACE_MEMORY) ||
+   (bar_reg == PCI_ROM_ADDRESS));
+
 if ( bar_reg != PCI_ROM_ADDRESS )
 {
-is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
- PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
- (PCI_BASE_ADDRESS_SPACE_MEMORY |
+is_64bar = !!(is_mem &&
+ ((bar_data & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
  PCI_BASE_ADDRESS_MEM_TYPE_64));
+
 

[Xen-devel] [RFC PATCH 04/12] hvmloader: add ACPI enabling for Q35

[Alexey Gerasimenko]

In order to turn on ACPI for OS, we need to write a chipset-specific value
to SMI_CMD register (sort of imitation of the APM->ACPI switch on real
systems). Modify acpi_enable_sci() function to support both i440 and Q35
emulation.

Signed-off-by: Alexey Gerasimenko 
---
 tools/firmware/hvmloader/hvmloader.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index f603f68ded..070698440e 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -257,9 +257,16 @@ static const struct bios_config *detect_bios(void)
 static void acpi_enable_sci(void)
 {
 uint8_t pm1a_cnt_val;
+uint8_t acpi_enable_val;
 
-#define PIIX4_SMI_CMD_IOPORT 0xb2
+#define SMI_CMD_IOPORT   0xb2
 #define PIIX4_ACPI_ENABLE0xf1
+#define ICH9_ACPI_ENABLE 0x02
+
+if (get_pc_machine_type() == MACHINE_TYPE_Q35)
+acpi_enable_val = ICH9_ACPI_ENABLE;
+else
+acpi_enable_val = PIIX4_ACPI_ENABLE;
 
 /*
  * PIIX4 emulation in QEMU has SCI_EN=0 by default. We have no legacy
@@ -267,7 +274,7 @@ static void acpi_enable_sci(void)
  */
 pm1a_cnt_val = inb(ACPI_PM1A_CNT_BLK_ADDRESS_V1);
 if ( !(pm1a_cnt_val & ACPI_PM1C_SCI_EN) )
-outb(PIIX4_SMI_CMD_IOPORT, PIIX4_ACPI_ENABLE);
+outb(SMI_CMD_IOPORT, acpi_enable_val);
 
 pm1a_cnt_val = inb(ACPI_PM1A_CNT_BLK_ADDRESS_V1);
 BUG_ON(!(pm1a_cnt_val & ACPI_PM1C_SCI_EN));
-- 
2.11.0


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

[Xen-devel] [RFC PATCH 03/12] hvmloader: add function to query an emulated machine type (i440/Q35)

[Alexey Gerasimenko]

This adds a new function get_pc_machine_type() which allows to determine
the emulated chipset type. Supported return values:

- MACHINE_TYPE_I440
- MACHINE_TYPE_Q35
- MACHINE_TYPE_UNKNOWN, results in the error message being printed
  followed by calling BUG() in hvmloader.

Signed-off-by: Alexey Gerasimenko 
---
 tools/firmware/hvmloader/pci_regs.h |  5 
 tools/firmware/hvmloader/util.c | 47 +
 tools/firmware/hvmloader/util.h |  8 +++
 3 files changed, 60 insertions(+)

diff --git a/tools/firmware/hvmloader/pci_regs.h 
b/tools/firmware/hvmloader/pci_regs.h
index 7bf2d873ab..ba498b840e 100644
--- a/tools/firmware/hvmloader/pci_regs.h
+++ b/tools/firmware/hvmloader/pci_regs.h
@@ -107,6 +107,11 @@
 
 #define PCI_INTEL_OPREGION 0xfc /* 4 bits */
 
+#define PCI_VENDOR_ID_INTEL  0x8086
+#define PCI_DEVICE_ID_INTEL_824410x1237
+#define PCI_DEVICE_ID_INTEL_Q35_MCH  0x29c0
+
+
 #endif /* __HVMLOADER_PCI_REGS_H__ */
 
 /*
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 0c3f2d24cd..5739a87628 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -22,6 +22,7 @@
 #include "hypercall.h"
 #include "ctype.h"
 #include "vnuma.h"
+#include "pci_regs.h"
 #include 
 #include 
 #include 
@@ -735,6 +736,52 @@ void __bug(char *file, int line)
 crash();
 }
 
+
+static int machine_type = MACHINE_TYPE_UNDEFINED;
+
+int get_pc_machine_type(void)
+{
+uint16_t vendor_id;
+uint16_t device_id;
+
+if (machine_type != MACHINE_TYPE_UNDEFINED)
+return machine_type;
+
+machine_type = MACHINE_TYPE_UNKNOWN;
+
+vendor_id = pci_readw(0, PCI_VENDOR_ID);
+device_id = pci_readw(0, PCI_DEVICE_ID);
+
+/* only Intel platforms are emulated currently */
+if (vendor_id == PCI_VENDOR_ID_INTEL)
+{
+switch (device_id)
+{
+case PCI_DEVICE_ID_INTEL_82441:
+machine_type = MACHINE_TYPE_I440;
+printf("Detected i440 chipset\n");
+break;
+
+case PCI_DEVICE_ID_INTEL_Q35_MCH:
+machine_type = MACHINE_TYPE_Q35;
+printf("Detected Q35 chipset\n");
+break;
+
+default:
+break;
+}
+}
+
+if (machine_type == MACHINE_TYPE_UNKNOWN)
+{
+printf("Unknown emulated chipset encountered, VID=%04Xh, DID=%04Xh\n",
+   vendor_id, device_id);
+BUG();
+}
+
+return machine_type;
+}
+
 static void validate_hvm_info(struct hvm_info_table *t)
 {
 uint8_t *ptr = (uint8_t *)t;
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 7bca6418d2..7c77bedb00 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -100,6 +100,14 @@ void pci_write(uint32_t devfn, uint32_t reg, uint32_t len, 
uint32_t val);
 #define pci_writew(devfn, reg, val) pci_write(devfn, reg, 2, (uint16_t)(val))
 #define pci_writel(devfn, reg, val) pci_write(devfn, reg, 4, (uint32_t)(val))
 
+/* Emulated machine types */
+#define MACHINE_TYPE_UNDEFINED  0
+#define MACHINE_TYPE_I440   1
+#define MACHINE_TYPE_Q352
+#define MACHINE_TYPE_UNKNOWN(-1)
+
+int get_pc_machine_type(void);
+
 /* Get a pointer to the shared-info page */
 struct shared_info *get_shared_info(void) __attribute__ ((const));
 
-- 
2.11.0


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

[Xen-devel] [RFC PATCH 05/12] hvmloader: add Q35 DSDT table loading

[Alexey Gerasimenko]

Allows to select Q35 DSDT table in hvmloader_acpi_build_tables(). Function
get_pc_machine_type() is used to select a proper table (i440/q35).

As we are bound to the qemu-xen device model for Q35, no need
to initialize config->dsdt_15cpu/config->dsdt_15cpu_len fields.

Signed-off-by: Alexey Gerasimenko 
---
 tools/firmware/hvmloader/util.c | 13 +++--
 tools/firmware/hvmloader/util.h |  2 ++
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 5739a87628..d8db9e3c8e 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -955,8 +955,17 @@ void hvmloader_acpi_build_tables(struct acpi_config 
*config,
 }
 else if ( !strncmp(s, "qemu_xen", 9) )
 {
-config->dsdt_anycpu = dsdt_anycpu_qemu_xen;
-config->dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len;
+if (get_pc_machine_type() == MACHINE_TYPE_Q35)
+{
+config->dsdt_anycpu = dsdt_q35_anycpu_qemu_xen;
+config->dsdt_anycpu_len = dsdt_q35_anycpu_qemu_xen_len;
+}
+else
+{
+config->dsdt_anycpu = dsdt_anycpu_qemu_xen;
+config->dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len;
+}
+
 config->dsdt_15cpu = NULL;
 config->dsdt_15cpu_len = 0;
 }
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 7c77bedb00..fd2d885c96 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -288,7 +288,9 @@ bool check_overlap(uint64_t start, uint64_t size,
uint64_t reserved_start, uint64_t reserved_size);
 
 extern const unsigned char dsdt_anycpu_qemu_xen[], dsdt_anycpu[], dsdt_15cpu[];
+extern const unsigned char dsdt_q35_anycpu_qemu_xen[];
 extern const int dsdt_anycpu_qemu_xen_len, dsdt_anycpu_len, dsdt_15cpu_len;
+extern const int dsdt_q35_anycpu_qemu_xen_len;
 
 struct acpi_config;
 void hvmloader_acpi_build_tables(struct acpi_config *config,
-- 
2.11.0


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

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

[Alexey Gerasimenko]

This adds construct_mcfg() function to libacpi which allows to build MCFG
table for a given mmconfig_addr/mmconfig_len pair if the ACPI_HAS_MCFG
flag was specified in acpi_config struct.

The maximum bus number is calculated from mmconfig_len using
MCFG_SIZE_TO_NUM_BUSES macro (1MByte of MMIO space per bus).

Signed-off-by: Alexey Gerasimenko 
---
 tools/libacpi/acpi2_0.h | 21 +
 tools/libacpi/build.c   | 42 ++
 tools/libacpi/libacpi.h |  4 
 3 files changed, 67 insertions(+)

diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
index 2619ba32db..209ad1acd3 100644
--- a/tools/libacpi/acpi2_0.h
+++ b/tools/libacpi/acpi2_0.h
@@ -422,6 +422,25 @@ struct acpi_20_slit {
 };
 
 /*
+ * PCI Express Memory Mapped Configuration Description Table
+ */
+struct mcfg_range_entry {
+uint64_t base_address;
+uint16_t pci_segment;
+uint8_t  start_pci_bus_num;
+uint8_t  end_pci_bus_num;
+uint32_t reserved;
+};
+
+struct acpi_mcfg {
+struct acpi_header header;
+uint8_t reserved[8];
+struct mcfg_range_entry entries[1];
+};
+
+#define MCFG_SIZE_TO_NUM_BUSES(size)  ((size) >> 20)
+
+/*
  * Table Signatures.
  */
 #define ACPI_2_0_RSDP_SIGNATURE ASCII64('R','S','D',' ','P','T','R',' ')
@@ -435,6 +454,7 @@ struct acpi_20_slit {
 #define ACPI_2_0_WAET_SIGNATURE ASCII32('W','A','E','T')
 #define ACPI_2_0_SRAT_SIGNATURE ASCII32('S','R','A','T')
 #define ACPI_2_0_SLIT_SIGNATURE ASCII32('S','L','I','T')
+#define ACPI_MCFG_SIGNATURE ASCII32('M','C','F','G')
 
 /*
  * Table revision numbers.
@@ -449,6 +469,7 @@ struct acpi_20_slit {
 #define ACPI_1_0_FADT_REVISION 0x01
 #define ACPI_2_0_SRAT_REVISION 0x01
 #define ACPI_2_0_SLIT_REVISION 0x01
+#define ACPI_1_0_MCFG_REVISION 0x01
 
 #pragma pack ()
 
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index f9881c9604..5daf1fc5b8 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -303,6 +303,37 @@ static struct acpi_20_slit *construct_slit(struct 
acpi_ctxt *ctxt,
 return slit;
 }
 
+static struct acpi_mcfg *construct_mcfg(struct acpi_ctxt *ctxt,
+const struct acpi_config *config)
+{
+struct acpi_mcfg *mcfg;
+
+/* Warning: this code expects that we have only one PCI segment */
+mcfg = ctxt->mem_ops.alloc(ctxt, sizeof(*mcfg), 16);
+if (!mcfg)
+return NULL;
+
+memset(mcfg, 0, sizeof(*mcfg));
+mcfg->header.signature= ACPI_MCFG_SIGNATURE;
+mcfg->header.revision = ACPI_1_0_MCFG_REVISION;
+fixed_strcpy(mcfg->header.oem_id, ACPI_OEM_ID);
+fixed_strcpy(mcfg->header.oem_table_id, ACPI_OEM_TABLE_ID);
+mcfg->header.oem_revision = ACPI_OEM_REVISION;
+mcfg->header.creator_id   = ACPI_CREATOR_ID;
+mcfg->header.creator_revision = ACPI_CREATOR_REVISION;
+mcfg->header.length = sizeof(*mcfg);
+
+mcfg->entries[0].base_address = config->mmconfig_addr;
+mcfg->entries[0].pci_segment = 0;
+mcfg->entries[0].start_pci_bus_num = 0;
+mcfg->entries[0].end_pci_bus_num =
+MCFG_SIZE_TO_NUM_BUSES(config->mmconfig_len) - 1;
+
+set_checksum(mcfg, offsetof(struct acpi_header, checksum), sizeof(*mcfg));
+
+return mcfg;;
+}
+
 static int construct_passthrough_tables(struct acpi_ctxt *ctxt,
 unsigned long *table_ptrs,
 int nr_tables,
@@ -350,6 +381,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 struct acpi_20_hpet *hpet;
 struct acpi_20_waet *waet;
 struct acpi_20_tcpa *tcpa;
+struct acpi_mcfg *mcfg;
 unsigned char *ssdt;
 static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
 void *lasa;
@@ -417,6 +449,16 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 printf("CONV disabled\n");
 }
 
+/* MCFG */
+if ( config->table_flags & ACPI_HAS_MCFG )
+{
+mcfg = construct_mcfg(ctxt, config);
+if (!mcfg)
+return -1;
+
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, mcfg);
+}
+
 /* TPM TCPA and SSDT. */
 if ( (config->table_flags & ACPI_HAS_TCPA) &&
  (config->tis_hdr[0] == tis_signature[0]) &&
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index a2efd23b0b..dd85b928e9 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -36,6 +36,7 @@
 #define ACPI_HAS_8042  (1<<13)
 #define ACPI_HAS_CMOS_RTC  (1<<14)
 #define ACPI_HAS_SSDT_LAPTOP_SLATE (1<<15)
+#define ACPI_HAS_MCFG  (1<<16)
 
 struct xen_vmemrange;
 struct acpi_numa {
@@ -96,6 +97,9 @@ struct acpi_config {
 uint32_t ioapic_base_address;
 uint16_t pci_isa_irq_mask;
 uint8_t ioapic_id;
+
+uint64_t mmconfig_addr;
+uint32_t mmconfig_len;
 };
 
 int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
-- 
2.11.0


___

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

[Alexey Gerasimenko]

This patch does following:

1. Move PCI-device specific initialization out of pci_setup function
to the newly created class_specific_pci_device_setup function to simplify
code.

2. PCI-device specific initialization extended with LPC controller
initialization

3. Initialize PIRQA...{PIRQD, PIRQH} routing accordingly to the emulated
south bridge (either located on PCI_ISA_DEVFN or PCI_ICH9_LPC_DEVFN).

Signed-off-by: Alexey Gerasimenko 
---
 tools/firmware/hvmloader/config.h |   1 +
 tools/firmware/hvmloader/pci.c| 162 --
 2 files changed, 104 insertions(+), 59 deletions(-)

diff --git a/tools/firmware/hvmloader/config.h 
b/tools/firmware/hvmloader/config.h
index 6e00413f2e..6fde6b7b60 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -52,6 +52,7 @@ extern uint8_t ioapic_version;
 
 #define PCI_ISA_DEVFN   0x08/* dev 1, fn 0 */
 #define PCI_ISA_IRQ_MASK0x0c20U /* ISA IRQs 5,10,11 are PCI connected */
+#define PCI_ICH9_LPC_DEVFN  0xf8/* dev 31, fn 0 */
 
 /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
 #define PCI_MEM_END 0xfc00
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 0b708bf578..033bd20992 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -35,6 +35,7 @@ unsigned long pci_mem_end = PCI_MEM_END;
 uint64_t pci_hi_mem_start = 0, pci_hi_mem_end = 0;
 
 enum virtual_vga virtual_vga = VGA_none;
+uint32_t vga_devfn = 256;
 unsigned long igd_opregion_pgbase = 0;
 
 /* Check if the specified range conflicts with any reserved device memory. */
@@ -76,14 +77,93 @@ static int find_next_rmrr(uint32_t base)
 return next_rmrr;
 }
 
+#define SCI_EN_IOPORT  (ACPI_PM1A_EVT_BLK_ADDRESS_V1 + 0x30)
+#define GBL_SMI_EN  (1 << 0)
+#define APMC_EN (1 << 5)
+
+static void class_specific_pci_device_setup(uint16_t vendor_id,
+uint16_t device_id,
+uint8_t bus, uint8_t devfn)
+{
+uint16_t class;
+
+class = pci_readw(devfn, PCI_CLASS_DEVICE);
+
+switch ( class )
+{
+case 0x0300:
+/* If emulated VGA is found, preserve it as primary VGA. */
+if ( (vendor_id == 0x1234) && (device_id == 0x) )
+{
+vga_devfn = devfn;
+virtual_vga = VGA_std;
+}
+else if ( (vendor_id == 0x1013) && (device_id == 0xb8) )
+{
+vga_devfn = devfn;
+virtual_vga = VGA_cirrus;
+}
+else if ( virtual_vga == VGA_none )
+{
+vga_devfn = devfn;
+virtual_vga = VGA_pt;
+if ( vendor_id == 0x8086 )
+{
+igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES);
+/*
+ * Write the the OpRegion offset to give the opregion
+ * address to the device model. The device model will trap
+ * and map the OpRegion at the give address.
+ */
+pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+   igd_opregion_pgbase << PAGE_SHIFT);
+}
+}
+break;
+
+case 0x0680:
+/* PIIX4 ACPI PM. Special device with special PCI config space. */
+ASSERT((vendor_id == 0x8086) && (device_id == 0x7113));
+pci_writew(devfn, 0x20, 0x); /* No smb bus IO enable */
+pci_writew(devfn, 0xd2, 0x); /* No smb bus IO enable */
+pci_writew(devfn, 0x22, 0x);
+pci_writew(devfn, 0x3c, 0x0009); /* Hardcoded IRQ9 */
+pci_writew(devfn, 0x3d, 0x0001);
+pci_writel(devfn, 0x40, ACPI_PM1A_EVT_BLK_ADDRESS_V1 | 1);
+pci_writeb(devfn, 0x80, 0x01); /* enable PM io space */
+break;
+
+case 0x0601:
+/* LPC bridge */
+if (vendor_id == 0x8086 && device_id == 0x2918)
+{
+pci_writeb(devfn, 0x3c, 0x09); /* Hardcoded IRQ9 */
+pci_writeb(devfn, 0x3d, 0x01);
+pci_writel(devfn, 0x40, ACPI_PM1A_EVT_BLK_ADDRESS_V1 | 1);
+pci_writeb(devfn, 0x44, 0x80); /* enable PM io space */
+outl(SCI_EN_IOPORT, inl(SCI_EN_IOPORT) | GBL_SMI_EN | APMC_EN);
+}
+break;
+
+case 0x0101:
+if ( vendor_id == 0x8086 )
+{
+/* Intel ICHs since PIIX3: enable IDE legacy mode. */
+pci_writew(devfn, 0x40, 0x8000); /* enable IDE0 */
+pci_writew(devfn, 0x42, 0x8000); /* enable IDE1 */
+}
+break;
+}
+}
+
 void pci_setup(void)
 {
 uint8_t is_64bar, using_64bar, bar64_relocate = 0;
 uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
 uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
-uint32_t vga_devfn = 256;
-uint16_t class, vendor_id, device_id;
+uint16_t vendor_id, device_id;
 unsigned int bar, pin, link, isa_irq;

[Xen-devel] [RFC PATCH 09/12] libxl: Xen Platform device support for Q35

[Alexey Gerasimenko]

Current Xen/QEMU method to control Xen Platform device is a bit odd --
changing 'xen_platform_device' option value actually modifies QEMU
emulated machine type, namely xenfv <--> pc.

In order to avoid multiplying machine types, use the new way to control
Xen Platform device for QEMU -- xen-platform-dev property. To maintain
backward compatibility with existing Xen/QEMU setups, this is only
applicable to q35 machine currently. i440 emulation uses the old method
(xenfv/pc machine) to control Xen Platform device, this may be changed
later to xen-platform-dev property as well.

Signed-off-by: Alexey Gerasimenko 
---
 tools/libxl/libxl_dm.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 7b531050c7..586035aa73 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1444,7 +1444,11 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
 break;
 case LIBXL_DOMAIN_TYPE_HVM:
 if (b_info->device_model_machine == LIBXL_DEVICE_MODEL_MACHINE_Q35) {
-machinearg = libxl__sprintf(gc, "q35,accel=xen");
+if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
+machinearg = libxl__sprintf(gc, "q35,accel=xen");
+} else {
+machinearg = libxl__sprintf(gc, 
"q35,accel=xen,xen-platform-dev=on");
+}
 } else {
 if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
 /* Switching here to the machine "pc" which does not add
-- 
2.11.0


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

[Xen-devel] [RFC PATCH 02/12] Makefile: build and use new DSDT table for Q35

[Alexey Gerasimenko]

Provide building for newly added dsdt_q35.asl file, in a way similar
to dsdt.asl.

Note that '15cpu' ACPI tables are only applicable to qemu-traditional
(which have no support for Q35), so we need to use 'anycpu' version only.

Signed-off-by: Alexey Gerasimenko 
---
 tools/firmware/hvmloader/Makefile | 2 +-
 tools/libacpi/Makefile| 9 -
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index a5b4c32c1a..b8b94bddda 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -75,7 +75,7 @@ rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
 ACPI_PATH = ../../libacpi
-DSDT_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
+DSDT_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c 
dsdt_q35_anycpu_qemu_xen.c
 ACPI_OBJS = $(patsubst %.c,%.o,$(DSDT_FILES)) build.o static_tables.o
 $(ACPI_OBJS): CFLAGS += -I. -DLIBACPI_STDUTILS=\"$(CURDIR)/util.h\"
 CFLAGS += -I$(ACPI_PATH)
diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index a47a658a25..7946284118 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -21,7 +21,7 @@ endif
 
 MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
 
-C_SRC-$(CONFIG_X86) = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c 
dsdt_pvh.c
+C_SRC-$(CONFIG_X86) = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c 
dsdt_q35_anycpu_qemu_xen.c dsdt_pvh.c
 C_SRC-$(CONFIG_ARM_64) = dsdt_anycpu_arm.c
 DSDT_FILES ?= $(C_SRC-y)
 C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, $(DSDT_FILES))
@@ -56,6 +56,13 @@ $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl 
dsdt_acpi_info.asl $(MK_DSD
$(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
mv -f $@.$(TMP_SUFFIX) $@
 
+$(ACPI_BUILD_DIR)/dsdt_q35_anycpu_qemu_xen.asl: dsdt_q35.asl 
dsdt_acpi_info.asl $(MK_DSDT)
+   # Remove last bracket
+   awk 'NR > 1 {print s} {s=$$0}' $< > $@.$(TMP_SUFFIX)
+   cat dsdt_acpi_info.asl >> $@.$(TMP_SUFFIX)
+   $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@.$(TMP_SUFFIX)
+   mv -f $@.$(TMP_SUFFIX) $@
+
 # NB. awk invocation is a portable alternative to 'head -n -1'
 $(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl  $(MK_DSDT)
# Remove last bracket
-- 
2.11.0


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

[Xen-devel] [RFC PATCH 00/30] Xen Q35 Bringup patches + support for PCIe Extended Capabilities for passed through devices

[Alexey Gerasimenko]

This patch series introduces support of Q35 emulation for Xen HVM guests
(via QEMU). This feature is present in other virtualization products and
Xen can greatly benefit from this feature as well.

The main goal for implementing Q35 emulation for Xen was extending PCI/GPU
passthrough capabilities. It's the main advantage of Q35 emulation
- availability of extra features for PCIe device passthrough. The most
important PCIe-specific passthrough feature Q35 provides is a support for
PCIe config space ECAM (aka MMCONFIG) to allow accesses to extended PCIe
config space (>256), which is MMIO-based.  Lots of PCIe devices and their
drivers make use of PCIe Extended Capabilities, whose can be accessed only
using ECAM and offsets above 0x100 in PCI config space. Supporting ECAM
is a mandatory feature for PCIe passthrough. Not only this allows
passthrough PCIe devices to function properly, but opens a road to extend
Xen PCIe passthrough features further -- eg. providing support for AER. One
of possible directions is providing support for PCIe Resizable BARs --
a feature which likely to become common for modern GPUs as video memory
sizes increase.

Q35 emulation may also be useful for other purposes. In fact, the emulation
of a more recent chipset partially closes a huge gap between a set of
required platform features and the actual emulated platform capabilities
- lot of required functionality is actually missing in a real i440 chipset.
One can look at IGD passthru support patches from Intel for example:
according to code comments, they had to create a dummy PCI-ISA bridge
at BDF 0:1F.0 in order to make the old i440 system look more modern, just
to make it compatible with IGD driver. Using Q35 emulation with its own
emulated LPC bridge allows to avoid workarounds like this. i440 on its own
is a fairly outdated system and doesn't really support lot of things, like
MMIO hole above 4Gb (although it is actually emulated). Also, due to the
i440 chipset's age the only fact of its usage may be used as a reliable
method to detect a virtualized environment by some malicious software
especially considering the fact that i440 emulation is shared among
multiple virtualization products.

On top of this series I've also implemented a solution which solves
existing Xen puzzle with HVM memory layout -- handling of VRAM, RMRRs and
MMIO hole in general. This "puzzle" (memory layout inconsistency between
libxl/libxc, hvmloader and QEMU) is a sort of fundamental problem which
plagues Xen for years and among few other issues prevents Xen to become a
decent GPU/PCIe passthrough platform (which it should be). This solution
also allows to later resolve current PCI passthrough incompatibility
issues, eg. with Populate-on-Demand. In fact, i440 support has been added
as well, but it's a bit hacky as it uses NB registers which are not present
in a real i440 (well, one more non-existing i440 feature won't harm anyway
as there are plenty of them already). I'm planning to send RFC patches of
this solution right after current patches will be reviewed and related code
settle, to rebase patches on top of it. Also, a good description is
required as the change is rather radical.

The good thing is that providing Q35 support for Xen at this stage neither
break any existing functionality nor affect the legacy i440 emulation
in any way - Q35 emulation can be enabled on demand only, using a new
domain config option. Also, only existing interfaces are used, no new
hypecalls were introduced, no API changes, etc. Although in the future
we'll have to change some hypercall/QMP/etc interfaces to remove
limitations and extend the Q35/PCIe passthru support further.

Current features and limitations:
- All basic functionality works normally - MP, networking, storage (AHCI),
  powering down VMs via ACPI soft off, etc
- Xen Platform Device and PV devices are supported -- PV drivers for vbd,
  vif, etc may be installed and used
- PCIe ECAM fully supported, with allocating space for PCIEXBAR in MMIO
  hole, ACPI MCFG generation, etc.
- Xen is limited to max 4 PIRQs in multiple places, while Q35 have support
  of 8 PIRQs / PCI router links. This was workarounded by describing only
  4 usable IRQ link entries in ACPI tables and disabling PIRQE..PIRQH -- like
  we're on a real system which has only some of 8 available PIRQs physically
  connected on the chipset. Extending the number of PCI links supported
  is trivial, but this step will change the save/migration stream format
  a bit... although as it seems there was actually some place for this
  extension being left -- eg. field uint8_t route[4] followed by uint8_t
  pad0[4] in hvm_hw_pci_link structure. Anyway, there is no problem actually
  as we normally deal with APIC mode (or MSIs) for IRQ delivery, while PIC
  mode with PCI routing needed only for legacy compatibility
- PCI hotplug currently implemented via ACPI hotplug, in a way similar
  to i440. In future, this might be changed to native PCIe hotplug 

Re: [Xen-devel] xen 4.10.0: stubdomain for HVM guest fails to start unless qdisk backend is used?

[Chris Brannon]

George Dunlap  writes:

> Can you attach the following?
>
> * the output of `xl dmesg`
> * the output of `dmesg`
> * the config file for the guest

Attached.

> I just tested stubdoms with staging-4.10 and everything works
> correctly *as long as dom0 is assigned all memory*.  If I limit the
> amount of dom0 memory to 1GiB, then stubdomains *doesn't* work with
> qdisk; only works with the defautl ("phy") backend.

Oh now that is interesting.
For what it's worth, I have seen this on both xen-4.10.0 and
stable-4.10.  I have not tried staging-4.10.

-- Chris

 Xen 4.10.0-1_prgmr.el6
(XEN) Xen version 4.10.0-1_prgmr.el6 (c...@centos.org) (gcc (GCC) 4.4.7 
20120313 (Red Hat 4.4.7-18)) debug=n  Wed Mar  7 17:18:35 PST 2018
(XEN) Latest ChangeSet: Wed Sep 13 17:16:31 2017 +0100 git:62bd6f0-dirty
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: cpuinfo loglvl=all guest_loglvl=error 
dom0_mem=2560M,max:2560M com1=115200,8n1 console=com1 dom0_max_vcpus=2 
dom0_vcpus_pin=true dom0_nodes=0 pv-linear-pt=true
(XEN) Xen image load base address: 0
(XEN) Video information:
(XEN)  No VGA detected
(XEN) Disc information:
(XEN)  Found 4 MBR signatures
(XEN)  Found 4 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 0009e000 (usable)
(XEN)  0009e000 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - f000 (usable)
(XEN)  fc00 - 0001 (reserved)
(XEN)  0001 - 00021000 (usable)
(XEN) New Xen image base address: 0xefa0
(XEN) ACPI: RSDP 000EA020, 0024 (r2Xen)
(XEN) ACPI: XSDT FC00C750, 0054 (r1Xen  HVM0 HVML0)
(XEN) ACPI: FACP FC00C440, 00F4 (r4Xen  HVM0 HVML0)
(XEN) ACPI: DSDT FC003940, 8A7E (r2Xen  HVM0 INTL 20090123)
(XEN) ACPI: FACS FC003900, 0040
(XEN) ACPI: APIC FC00C540, 00A0 (r2Xen  HVM0 HVML0)
(XEN) ACPI: HPET FC00C660, 0038 (r1Xen  HVM0 HVML0)
(XEN) ACPI: WAET FC00C6A0, 0028 (r1Xen  HVM0 HVML0)
(XEN) ACPI: SSDT FC00C6D0, 0031 (r2Xen  HVM0 INTL 20090123)
(XEN) ACPI: SSDT FC00C710, 0031 (r2Xen  HVM0 INTL 20090123)
(XEN) System RAM: 8191MB (8388216kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at -00021000
(XEN) Domain heap initialised
(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 62 (0x3e), Stepping 4 (raw 
000306e4)
(XEN) found SMP MP-table at 000fb710
(XEN) DMI 2.4 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0xb008 (32 bits)
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:b004,1:0], pm1x_evt[1:b000,1:0]
(XEN) ACPI: wakeup_vec[fc00390c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee0
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] enabled)
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 17, address 0xfec0, GSI 0-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ5 used by override.
(XEN) ACPI: IRQ10 used by override.
(XEN) ACPI: IRQ11 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a201 base: 0xfed0
(XEN) ERST table was not found
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 8 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 48 GSI, 1504 MSI/MSI-X
(XEN) Not enabling x2APIC: depends on iommu_supports_eim.
(XEN) Levelling caps: 0x1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 256K
(XEN) CPU: L3 cache: 25600K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 0
(XEN) xstate: size: 0x340 and states: 0x7
(XEN) CPU0: Intel machine check reporting enabled
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Initializing CPU#0
(XEN) Platform timer is 62.500MHz HPET
(XEN) Detected 2200.058 MHz processor.
(XEN) Initing memory sharing.
(XEN) alt table 82d080410558 -> 82d080411c8c
(XEN) I/O virtualisation disabled
(XEN) CPU0: Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz stepping 04
(XEN) nr_sockets: 1
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=0 pin2=0
(XEN) TSC deadline timer enabled
(XEN) 

Re: [Xen-devel] [RFC PATCH] xen/arm: Add MVEBU UART driver for Armada 3700 SoC

[Amit Tomer]

Hi,

> This is quite useful to get output without any serial driver. I am quite
> impressed you managed to debug your serial driver without it :).

Actually,  we have earlycon=xenboot(suggested by Andre) enabled in
Dom0 bootargs and it allowed us to
debug XEN boot further.

I am wondering if ealycon interface can be used in absence of
earlyprintk doing same work?

Thanks
Amit.

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

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

[osstest service owner]

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

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  966f154c58bacf07690135d7da3f1d5281d84ab0
baseline version:
 xen  185413355fe331cbc926d48568838227234c9a20

Last test of basis   120372  2018-03-09 17:06:57 Z2 days
Testing same since   120582  2018-03-12 13:30:52 Z0 days1 attempts


People who touched revisions under test:
  Andre Przywara 
  Julien Grall 
  Julien Grall 

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-i386 pass
 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
   185413355f..966f154c58  966f154c58bacf07690135d7da3f1d5281d84ab0 -> smoke

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

Re: [Xen-devel] [PATCH 3/7] RFC arm/domain: Reject invalid combinations of domain creation flags

[Wei Liu]

On Sun, Mar 11, 2018 at 07:59:16PM +, Julien Grall wrote:
> Hi Andrew,
> 
> On 03/09/2018 01:18 PM, Andrew Cooper wrote:
> > ARM guests are HVM and have hardware assisted paging.  There are no PV 
> > guests
> > or shadow paging, and all other creation flags are x86 specific.
> > 
> > Signed-off-by: Andrew Cooper 
> > ---
> > CC: Stefano Stabellini 
> > CC: Julien Grall 
> > CC: Ian Jackson 
> > CC: Wei Liu 
> > 
> > RFC.  This is untested, but I noticed it when putting together the 
> > preceeding
> > patch.  There is a moderate chance that this will cause things to explode
> > because of how libxl handles ARM guest construction, but something along 
> > these
> > lines is the right thing to do.
> 
> Tools and hypervisor are considering ARM guests as PV. So this patch is
> going to break boot. There are an action (XEN-102) to move ARM guests to
> behave more like PVH from the tools POV. I am not sure when I will have time
> to look at it thought.
> 
> For the time being, I am wondering if we could override the flags for Arm in
> the toolstack?
> 

Is that necessary? I don't think the rest of this series will break ARM
at first glance.

Wei.

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

Re: [Xen-devel] [PATCH v3] tools: detect appropriate debug optimization level

[Wei Liu]

On Sat, Mar 10, 2018 at 11:08:21PM -0600, Doug Goldstein wrote:
> On 3/2/18 6:46 AM, Wei Liu wrote:
> > On Fri, Feb 23, 2018 at 11:26:17PM -0600, Doug Goldstein wrote:
> >> On 4/28/16 12:40 PM, Wei Liu wrote:
> >>> On Tue, Apr 26, 2016 at 09:38:45AM -0500, Doug Goldstein wrote:
>  When building debug use -Og as the optimization level if its available,
>  otherwise retain the use of -O0. -Og has been added by GCC to enable all
>  optimizations that to not affect debugging while retaining full
>  debugability.
> 
>  Signed-off-by: Doug Goldstein 
>  ---
>  change since v2:
>  - switch back to cc-option-add to not call cc-option on every invocation
>  change since v1:
>  - switch to cc-option to only specify -O0 if -Og isn't supported
>  ---
>   tools/Rules.mk | 1 +
>   1 file changed, 1 insertion(+)
> 
>  diff --git a/tools/Rules.mk b/tools/Rules.mk
>  index 9ef0b47..1b79a6e 100644
>  --- a/tools/Rules.mk
>  +++ b/tools/Rules.mk
>  @@ -138,6 +138,7 @@ SHLIB_libxenvchan  = $(SHDEPS_libxenvchan) 
>  -Wl,-rpath-link=$(XEN_LIBVCHAN)
>   ifeq ($(debug),y)
>   # Disable optimizations and enable debugging information for macros
>   CFLAGS += -O0 -g3
>  +$(call cc-option-add,CFLAGS,CC,-Og)
> > 
> > Though -Og will supersede -O0 because it comes later, I would rather you
> > use cc-option to selectively add one of the two, like:
> > 
> > CFLAGS += $(cc-option,CC,-Og,-O0)
> > 
> > Wei.
> > 
> 
> Wei,
> 
> It was like that in v2 but I changed it per Ian's request to this
> version. See:
> https://lists.xenproject.org/archives/html/xen-devel/2016-04/msg02822.html
> for reference.

That's a good point. We certainly want to avoid expanding the same thing
over and over again.

I think you can do with

ifneq ($(call cc-option,$(CC),-Og,n),n)
CFLAGS += -Og
else
CFLAGS += -O0
endif

Wei.

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

[Xen-devel] [xen-4.7-testing test] 120425: regressions - FAIL

[osstest service owner]

flight 120425 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120425/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install   fail REGR. vs. 119780

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 120309 pass 
in 120425
 test-arm64-arm64-xl-xsm   7 xen-boot fail in 120309 pass in 120425
 test-xtf-amd64-amd64-2   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 120309

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-4  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119780
 test-xtf-amd64-amd64-1  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119780
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 119780
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 119780
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 119780
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 119780
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 119780
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 119780
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 119780
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 119780
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 119780
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 119780
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 119780
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  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  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-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-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-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-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 

[Xen-devel] [PATCH v1] Rename DEBUG_DIR to XEN_DEBUG_DIR

[Olaf Hering]

The usage of DEBUG_DIR breaks OVMF build. Rename it to XEN_DEBUG_DIR.

The default DEBUG_DIR=/usr/lib/debug can not be used for rpm builds
because that directory is "owned" by rpm-packaging itself to store the
autogenerated ${pkg}-debuginfo.rpm data. Thats why I set it to /boot.
This worked fine until recently, only /boot/xen-syms was affected by
that change, and in fact only the "xen" build needed DEBUG_DIR as make
cmdline option.

Now tools/firmware/Makefile also uses DEBUG_DIR. To set DEBUG_DIR the
tools build must be done like "make DEBUG_DIR=/my/dir". But this breaks
build with --enable-ovmf because ovmf.git makes use of the very same
variable. For some reason it can not deal with a custom value, some
autogenerated file will not be found:

[  126s] make[8]: *** No rule to make target '/boot/AutoGen.h', needed by 
'/home/abuild/rpmbuild/BUILD/xen-4.11.20180228T150620.cb671efbf1/non-dbg/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.bin'.

Fixes commit b38c4e1763 ("build: remove shim related targets")

Signed-off-by: Olaf Hering 
---

In case this patch gets applied, it is also required to fix the 
build regression introduced by cee8bb62ff in 4.10.


 INSTALL |  4 ++--
 config/StdGNU.mk|  2 +-
 config/SunOS.mk |  2 +-
 tools/firmware/Makefile |  2 +-
 xen/Makefile| 14 +++---
 xen/test/livepatch/Makefile |  2 +-
 6 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/INSTALL b/INSTALL
index 9aa9ebdddc..3c05a7a35c 100644
--- a/INSTALL
+++ b/INSTALL
@@ -196,10 +196,10 @@ OCAMLFIND_DESTDIR= and OCAMLFIND_METADIR= will have the 
same effect.
 OCAMLDESTDIR=
 
 The xen subsystem will install the hypervisor into fixed locations.
-BOOT_DIR defaults to /boot, DEBUG_DIR defaults to /usr/lib/debug and
+BOOT_DIR defaults to /boot, XEN_DEBUG_DIR defaults to /usr/lib/debug and
 EFI_DIR to /usr/lib64/efi.
 BOOT_DIR=
-DEBUG_DIR=
+XEN_DEBUG_DIR=
 EFI_DIR=
 
 The make target 'rpmball' will build a xen.rpm. This variable can be
diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 039274ea61..f75e39782c 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -27,7 +27,7 @@ INSTALL_DATA = $(INSTALL) -m0644 -p
 INSTALL_PROG = $(INSTALL) -m0755 -p
 
 BOOT_DIR ?= /boot
-DEBUG_DIR ?= /usr/lib/debug
+XEN_DEBUG_DIR ?= /usr/lib/debug
 
 SOCKET_LIBS =
 UTIL_LIBS = -lutil
diff --git a/config/SunOS.mk b/config/SunOS.mk
index 0fe5f45590..f36120c4a1 100644
--- a/config/SunOS.mk
+++ b/config/SunOS.mk
@@ -19,7 +19,7 @@ INSTALL_DATA = $(INSTALL) -m0644 -p
 INSTALL_PROG = $(INSTALL) -m0755 -p
 
 BOOT_DIR ?= /boot
-DEBUG_DIR ?= /usr/lib/debug
+XEN_DEBUG_DIR ?= /usr/lib/debug
 
 SunOS_LIBDIR = /usr/sfw/lib
 SunOS_LIBDIR_x86_64 = /usr/sfw/lib/amd64
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 5a7cf7766d..13cefb5ce9 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -8,7 +8,7 @@ endif
 # hvmloader is a 32-bit protected mode binary.
 TARGET  := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
-DEBG_DIR := $(DESTDIR)$(DEBUG_DIR)$(XENFIRMWAREDIR)
+DEBG_DIR := $(DESTDIR)$(XEN_DEBUG_DIR)$(XENFIRMWAREDIR)
 
 SUBDIRS-y :=
 SUBDIRS-$(CONFIG_OVMF) += ovmf-dir
diff --git a/xen/Makefile b/xen/Makefile
index 62d479c799..79f3a95ec1 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -60,15 +60,15 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
ln -f -s $(T)-$(XEN_FULLVERSION)$(Z) 
$(D)$(BOOT_DIR)/$(T)-$(XEN_VERSION).$(XEN_SUBVERSION)$(Z)
ln -f -s $(T)-$(XEN_FULLVERSION)$(Z) 
$(D)$(BOOT_DIR)/$(T)-$(XEN_VERSION)$(Z)
ln -f -s $(T)-$(XEN_FULLVERSION)$(Z) $(D)$(BOOT_DIR)/$(T)$(Z)
-   [ -d "$(D)$(DEBUG_DIR)" ] || $(INSTALL_DIR) $(D)$(DEBUG_DIR)
-   $(INSTALL_DATA) $(TARGET)-syms 
$(D)$(DEBUG_DIR)/$(T)-syms-$(XEN_FULLVERSION)
-   $(INSTALL_DATA) $(TARGET)-syms.map 
$(D)$(DEBUG_DIR)/$(T)-syms-$(XEN_FULLVERSION).map
+   [ -d "$(D)$(XEN_DEBUG_DIR)" ] || $(INSTALL_DIR) $(D)$(XEN_DEBUG_DIR)
+   $(INSTALL_DATA) $(TARGET)-syms 
$(D)$(XEN_DEBUG_DIR)/$(T)-syms-$(XEN_FULLVERSION)
+   $(INSTALL_DATA) $(TARGET)-syms.map 
$(D)$(XEN_DEBUG_DIR)/$(T)-syms-$(XEN_FULLVERSION).map
$(INSTALL_DATA) $(KCONFIG_CONFIG) 
$(D)$(BOOT_DIR)/$(T)-$(XEN_FULLVERSION).config
if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
[ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
$(INSTALL_DATA) $(TARGET).efi 
$(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
if [ -e $(TARGET).efi.map ]; then \
-   $(INSTALL_DATA) $(TARGET).efi.map 
$(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
+   $(INSTALL_DATA) $(TARGET).efi.map 
$(D)$(XEN_DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
fi; \
ln -sf $(T)-$(XEN_FULLVERSION).efi 
$(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).$(XEN_SUBVERSION).efi; \
ln -sf 

[Xen-devel] [PATCH v2] xen/arm: p2m: Prevent deadlock when using memaccess

[julien . grall]

From: Julien Grall 

Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt"
assumed the read-write lock can be taken recursively. However, this
assumption is wrong and will lead to deadlock when the lock is
contended.

The read lock is taken recursively in the following case:
1) get_page_from_gva
=> Take the read lock (first read lock)
=> Call p2m_mem_access_check_and_get_page on failure when
memaccess is enabled
2) p2m_mem_access_check_and_get_page
=> If hardware translation failed fallback to software lookup
=> Call guest_walk_tables
3) guest_walk_tables
=> Will use access_guest_memory_ipa to access stage-1 page-table
4) access_guest_memory_ipa
=> Because Arm does not have hardware instruction to only do
stage-2 page-table, this is done in software.
=> Take the read lock (second read lock)

To avoid the nested lock, rework the locking in get_page_from_gva and
p2m_mem_access_check_and_get_page. The latter will now be called without
the p2m lock. The new locking in p2m_mem_accces_check_and_get_page will
not cover the translation of the VA to an IPA.

This is fine because we can't promise that the stage-1 page-table have
changed behind our back (they are under guest control). Modification in
the stage-2 page-table can now happen, but I can't issue any potential
issue here except with the break-before-make sequence used when updating
page-table. gva_to_ipa may fail if the sequence is executed at the same
on another CPU. In that case we would fallback in the software lookup
path.

Signed-off-by: Julien Grall 

---
This patch should be backported to Xen 4.10. There are other
potential optimization that I am working on. Although, I don't think
they are backport material.

Changes in v2:
- Update the commit message to explain where the lock is taken
recursively.
---
 xen/arch/arm/mem_access.c | 8 ++--
 xen/arch/arm/p2m.c| 4 ++--
 xen/include/asm-arm/p2m.h | 4 
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
index 0f2cbb81d3..11c2b03b7b 100644
--- a/xen/arch/arm/mem_access.c
+++ b/xen/arch/arm/mem_access.c
@@ -126,7 +126,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag,
  * is not mapped.
  */
 if ( guest_walk_tables(v, gva, , ) < 0 )
-goto err;
+return NULL;
 
 /*
  * Check permissions that are assumed by the caller. For instance in
@@ -139,11 +139,13 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag,
  * test for execute permissions this check can be left out.
  */
 if ( (flag & GV2M_WRITE) && !(perms & GV2M_WRITE) )
-goto err;
+return NULL;
 }
 
 gfn = gaddr_to_gfn(ipa);
 
+p2m_read_lock(p2m);
+
 /*
  * We do this first as this is faster in the default case when no
  * permission is set on the page.
@@ -216,6 +218,8 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag,
 page = NULL;
 
 err:
+p2m_read_unlock(p2m);
+
 return page;
 }
 
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 65e8b9c6ea..5de82aafe1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1449,11 +1449,11 @@ struct page_info *get_page_from_gva(struct vcpu *v, 
vaddr_t va,
 }
 
 err:
+p2m_read_unlock(p2m);
+
 if ( !page && p2m->mem_access_enabled )
 page = p2m_mem_access_check_and_get_page(va, flags, v);
 
-p2m_read_unlock(p2m);
-
 return page;
 }
 
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index a0abc84ed8..45ef2cd58b 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -23,10 +23,6 @@ extern void memory_type_changed(struct domain *);
 struct p2m_domain {
 /*
  * Lock that protects updates to the p2m.
- *
- * Please note that we use this lock in a nested way by calling
- * access_guest_memory_by_ipa in guest_walk_(sd|ld). This must be
- * considered in the future implementation.
  */
 rwlock_t lock;
 
-- 
2.11.0


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

Re: [Xen-devel] [PATCHv3] xen: Add EFI_LOAD_OPTION support

[Tamas K Lengyel]

Patch ping. Jan, I would like to touch base once more to see if we can
get this patch included in 4.11. The patch as-is correctly tells the
difference between buffers provided by both an EFI shell or by the
firmware as an EFI_LOAD_OPTION.

Thanks,
Tamas

On Wed, Feb 7, 2018 at 9:00 AM, Tamas K Lengyel  wrote:
> On Mon, Jan 29, 2018 at 2:18 AM, Jan Beulich  wrote:
> On 26.01.18 at 18:35,  wrote:
>>> On Fri, Jan 26, 2018 at 5:46 AM, Jan Beulich  wrote:
>>> On 23.01.18 at 01:21,  wrote:
> @@ -375,12 +385,39 @@ static void __init PrintErrMesg(const CHAR16 *mesg, 
> EFI_STATUS ErrCode)
>
>  static unsigned int __init get_argv(unsigned int argc, CHAR16 **argv,
>  CHAR16 *cmdline, UINTN cmdsize,
> -CHAR16 **options)
> +CHAR16 **options, bool *elo_active)
>  {
>  CHAR16 *ptr = (CHAR16 *)(argv + argc + 1), *prev = NULL;
>  bool prev_sep = true;
>
> -for ( ; cmdsize > sizeof(*cmdline) && *cmdline;
> +if ( cmdsize > sizeof(EFI_LOAD_OPTION) &&
> + *(CHAR16 *)((void *)cmdline + cmdsize - sizeof(*cmdline)) != 
> L'\0' )

 This is too lax - you should check whether the nul at that position
 indeed is the _first_ one.
>>>
>>> IMHO that check you suggest has nothing to do with EFI_LOAD_OPTION
>>> support. That's sanity checking a command line buffer. It could
>>> certainly be done, but I would say that belongs in a separate patch.
>>> This check currently as is distinguishes an EFI_LOAD_OPTION from a
>>> well-formed command line buffer. If the command line buffer has
>>> multiple '\0' in it, that's a separate problem.
>>
>> You could view it as a separate problem if there was a non-heuristic
>> way of distinguishing the formats.
>>
> +{
> +const EFI_LOAD_OPTION *elo = (const EFI_LOAD_OPTION *)cmdline;
> +
> +/* The absolute minimum the size of the buffer it needs to be */
> +size_t size_check = offsetof(EFI_LOAD_OPTION, Description[1]) +
> +elo->FilePathListLength;
> +
> +if ( (elo->Attributes & LOAD_OPTION_ACTIVE) && size_check < 
> cmdsize )
> +{
> +const CHAR16 *desc = elo->Description;
> +size_t desc_length = 0;
> +
> +/* Find Description string length in its possible space */
> +while ( desc_length < cmdsize - size_check && *desc++ != 
> L'\0')
> +desc_length += sizeof(*desc);
> +
> +if ( size_check + desc_length < cmdsize )
> +{
> +*elo_active = true;
> +cmdline = (void *)cmdline + size_check + desc_length;
> +cmdsize = cmdsize - size_check - desc_length;
> +}
> +}

 I can't help thinking that this is broken: What if you have a structure
 with the LOAD_OPTION_ACTIVE bit clear (leaving aside the fact that
 I'm not sure the meaning of the flag is what you use it for here)?
 That's still not to be taken as a plain command line then.
>>>
>>> Keep in mind that currently everything is being parsed as a plain
>>> command line. So that's the default behavior. All I'm doing in this
>>> patch is falling back on the default behavior if is determined that we
>>> are not dealing with a well-formed EFI_LOAD_OPTION. Doing sanity
>>> checking on arbitrary buffers that may end up being passed here by
>>> buggy shells or buggy firmware or whatnot is beyond the scope of what
>>> I'm looking to accomplish.
>>
>> As per above - this isn't sanity checking. It is a heuristic to tell apart
>> the two possible formats. Without knowing what other formats there
>> might be, there's no way the checking you do is going to be
>> meaningfully more safe than the alternative I'm suggesting. Being
>> given a binary blob, just simply have no way of telling its format
>> without sideband information.
>>
>
> This patch as-is correctly tells the two possible formats apart. I
> tested and Xen boots correctly both from the Shell and from the
> firmware boot menu. I would not like to start addressing hypothetical
> scenarios that I have no reasonable way to test against. If you are
> inclined to do that, that's your call but I'll just leave this patch
> here for now and I hope you would consider merging it.
>
> Tamas

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

Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC

[Lars Kurth]

Hi all,

this is my first go at the agenda. 
See 
https://docs.google.com/document/d/1n7HAu5IbuRt5aJbQKt5X470kv2Ubvk5P2mG0vp6rKfU/edit?usp=sharing
 and attached PDF

Text without tables below

As I didn't get a priority order, nor design stuff, but a few series to discuss 
I sorted by what looked sensible to me
If you feel strongly about the order, please let me know ASAP

A) What looks feasible for 4.11 => 2 series
B) Longer term: non-RFC series with more than one revision => 2 series
C) Longer term: RFC series - v > 1 first, then sorted by size => 8 series
D) AOB
We should allocate 5 minutes at the end to
* Reflect on meeting format/improvements
* Should we use a different mechanism for the call (e.g. a video facility)

Regards
Lars

== For 4.11

=== [PATCH v4 00/10] x86: emulator enhancements
Sent in for meeting agenda by George
https://marc.info/?l=xen-devel=151982229407799 
https://xen.markmail.org/thread/roukz6r3gcuhxinn 

Notes: v4 posted by Jan Beulich on 28 Feb 2018.  Most patches seem to have acks 
or r-bs, but I know this one has been around a long time, so it might be worth 
making sure we can get it in before the feature freeze. 

[Table in PDF] - shows that apart from 1 design approach disagreement and 16/20 
not having had review this series looks pretty close

=== [PATCH v17 00/11] x86: guest resource mapping
Sent in for meeting agenda by George
https://xen.markmail.org/thread/ge2hlgljac3uqepe 

v17 posted by Paul Durrant on 3 January 2018

Notes: All but 6/11 have a fair amount of A-b's or R-b’s
Is this a patch we can get into 4.11?

[Table in PDF] - Looks pretty close also

== Longer Term - non-RFCs

=== [PATCH v4 00/28] add vIOMMU support with irq remapping function of virtual 
VT-d
Sent in for meeting agenda by George
v3 posted by Lan Tianyu on 22 September 2017: 
marc.info/?l=xen-devel=150607140722407 
v4 posted by Chao Gao: https://xen.markmail.org/thread/wfyorbn3nzsio6s7 

Seems to have had review by Roger Pau Monne (not counted acks).
RB for [PATCH v4 06/28] vtd: clean-up and preparation for vvtd

=== [RFC Patch v4 0/8] Extend resources to support more vcpus in single VM
Sent in by George
RFC v3 by Lan Tianyu: https://marc.info/?l=xen-devel=150530044827940 (Sep 17)
RFC v4 re-posted by Chao Gao: https://xen.markmail.org/thread/tlto7b3fadp7kkw6 
(Dec 17) 

Quite a bit of feedback on v4 from a few people up to Feb 28th

== Longer Term: RFCs or v1 (v > 1 first, then smaller first)

=== [RFC XEN PATCH v4 00/41] Add vNVDIMM support to HVM domains
Sent in for meeting agenda by George
https://marc.info/?l=xen-devel=151264150712808 
https://xen.markmail.org/thread/6uzmarrlws73mq5d 

RFC posted by Haozhong Zhang on 7 December 2017.  A few messages about the 
overall architecture; some more detailed comments by Anthony on the integration 
with the toolstack. Otherwise feedback by Roger & Jan.

=== [PATCH 0/7] paravirtual IOMMU interface
Sent in for meeting agenda by George
https://marc.info/?l=xen-devel=151843249327749 
https://xen.markmail.org/thread/kmxk4hoj2ao65qsa 

v1 posted by Paul Durrant on 12 Feb 2018.  
Seems to have had a lot of feedback from Kevin Tian.

=== [PATCH RESEND v1 0/7] Intel Processor Trace virtulization enabling
Sent in for meeting agenda by George
https://marc.info/?l=xen-devel=151608947805423 
https://xen.markmail.org/thread/rbaf7cxh2a7wwchf 

v1.1 Posted by Lan Tianyu on 15 January 2018.  
No feedback.

=== [RFC PATCH 0/8] Add guest CPU topology support
Sent in for meeting agenda by George
https://marc.info/?l=xen-devel=151538433419631 
https://xen.markmail.org/thread/od46uc5nwhshnluz 

Some feedback from Andrew Cooper and Daniel De Graaf

Blocked on CPUID? 
As far as I understand, this series seems to be building on an area of code, 
which has underlying issues, which may be a problem.

=== [PATCH RFC 00/10] x86 passthrough code cleanup
Sent in for meeting agenda by Wei
https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01939.html

Does not know how to approach

=== [PATCH RFC 00/14] EPT-Based Sub-page Write Protection Support
Sent in for meeting agenda by George
https://marc.info/?l=xen-devel=150840502417156 
https://xen.markmail.org/thread/m75h6b2aiwk5h7fx 

RFC posted by Zhang Yi Oct 19, 2017
No acks, reviews only by memaccess maintainers / developers





x86 Community Call March 2018.pdf
Description: x86 Community Call March 2018.pdf
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC PATCH] xen/arm: Add MVEBU UART driver for Armada 3700 SoC

[Julien Grall]

On 12/03/18 14:36, Amit Tomer wrote:

Hi


Hi Amit,



Thanks for the comments.


OOI, do you have any plan for adding earlyprintk support for that platform?


I didn't think about it but I would look into it.


This is quite useful to get output without any serial driver. I am quite 
impressed you managed to debug your serial driver without it :).





Please give a link to the Linux driver. This would help me for reviewing and
also for future reference.


Ok.


This is part of xen/drivers/char/* so even if the driver if only for ARM
hardware, you likely want to CC "THE REST" maintainers as this is under
drivers/char. scripts/get_maintainers.pl can help you to find relevant
maintainers to CC on each patch.


Ok.

   include should be first, then .

Ok, I was under the impression that it should be sorted in alphabetical order.


They should be sorted alphabetical, but all  should be after 
 so common headers gets included first, then the arch specific ones.

+
+#define TX_FIFO_SIZE32
+#define RX_FIFO_SIZE64
+
+static struct mvebu3700_uart {
+unsigned int baud, data_bits, parity, stop_bits;



Are all those fields necessary? For instance, you always set baud but never
read it.


Not sure about this as I don't know if these fields are used by XEN
serial infrastructure later on.


This is an internal structure. I can't see how the serial code would 
know the layout and access the fields.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH] xen/arm: Add MVEBU UART driver for Armada 3700 SoC

[Amit Tomer]

Hi

Thanks for the comments.

> OOI, do you have any plan for adding earlyprintk support for that platform?

I didn't think about it but I would look into it.

> Please give a link to the Linux driver. This would help me for reviewing and
> also for future reference.

Ok.

> This is part of xen/drivers/char/* so even if the driver if only for ARM
> hardware, you likely want to CC "THE REST" maintainers as this is under
> drivers/char. scripts/get_maintainers.pl can help you to find relevant
> maintainers to CC on each patch.

Ok.

  include should be first, then .

Ok, I was under the impression that it should be sorted in alphabetical order.

>
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>
>
> xen/serial.h is mentioned twice.
Ok.

>
>> +#include 
>> +
>> +#define UART_RX_REG 0x00
>> +#define RBR_BRK_DET BIT(15)
>> +#define RBR_FRM_ERR_DET BIT(14)
>> +#define RBR_PAR_ERR_DET BIT(13)
>> +#define RBR_OVR_ERR_DET BIT(12)
>> +
>> +#define UART_TX_REG 0x04
>> +
>> +#define UART_CTRL_REG   0x08
>> +#define CTRL_SOFT_RST   BIT(31)
>> +#define CTRL_TXFIFO_RST BIT(15)
>> +#define CTRL_RXFIFO_RST BIT(14)
>> +#define CTRL_ST_MIRR_EN BIT(13)
>> +#define CTRL_LPBK_ENBIT(12)
>> +#define CTRL_SND_BRK_SEQBIT(11)
>> +#define CTRL_PAR_EN BIT(10)
>> +#define CTRL_TWO_STOP   BIT(9)
>> +#define CTRL_TX_HFL_INT BIT(8)
>> +#define CTRL_RX_HFL_INT BIT(7)
>> +#define CTRL_TX_EMP_INT BIT(6)
>> +#define CTRL_TX_RDY_INT BIT(5)
>> +#define CTRL_RX_RDY_INT BIT(4)
>> +#define CTRL_BRK_DET_INTBIT(3)
>> +#define CTRL_FRM_ERR_INTBIT(2)
>> +#define CTRL_PAR_ERR_INTBIT(1)
>> +#define CTRL_OVR_ERR_INTBIT(0)
>> +#define CTRL_RX_INT (CTRL_BRK_DET_INT | CTRL_FRM_ERR_INT | \
>> + CTRL_PAR_ERR_INT | CTRL_OVR_ERR_INT)
>> +
>> +#define UART_STATUS_REG 0x0c
>> +#define STATUS_TXFIFO_EMP   BIT(13)
>> +#define STATUS_RXFIFO_EMP   BIT(12)
>> +#define STATUS_TXFIFO_FUL   BIT(11)
>> +#define STATUS_TXFIFO_HFL   BIT(10)
>> +#define STATUS_RX_TOGL  BIT(9)
>> +#define STATUS_RXFIFO_FUL   BIT(8)
>> +#define STATUS_RXFIFO_HFL   BIT(7)
>> +#define STATUS_TX_EMP   BIT(6)
>> +#define STATUS_TX_RDY   BIT(5)
>> +#define STATUS_RX_RDY   BIT(4)
>> +#define STATUS_BRK_DET  BIT(3)
>> +#define STATUS_FRM_ERR  BIT(2)
>> +#define STATUS_PAR_ERR  BIT(1)
>> +#define STATUS_OVR_ERR  BIT(0)
>> +#define STATUS_BRK_ERR  (STATUS_BRK_DET | STATUS_FRM_ERR | \
>> +STATUS_PAR_ERR | STATUS_OVR_ERR)
>> +
>> +#define UART_BAUD_REG   0x10
>> +#define UART_POSSR_REG  0x14
>
>
> Can you please only define only registers/bits used in the code?

Ok.

>> +
>> +#define TX_FIFO_SIZE32
>> +#define RX_FIFO_SIZE64
>> +
>> +static struct mvebu3700_uart {
>> +unsigned int baud, data_bits, parity, stop_bits;
>
>
> Are all those fields necessary? For instance, you always set baud but never
> read it.

Not sure about this as I don't know if these fields are used by XEN
serial infrastructure later on.

>> +unsigned int irq;
>> +void __iomem *regs;
>> +struct irqaction irqaction;
>> +struct vuart_info vuart;
>> +} mvebu3700_com = {0};
>> +
>> +#define PARITY_NONE  (0)
>> +
>> +#define mvebu3700_read(uart, off)   readl((uart)->regs + off)
>> +#define mvebu3700_write(uart, off, val) writel(val, (uart->regs) +
>> off)
>> +
>> +static void mvebu3700_uart_interrupt(int irq, void *data, struct
>> +cpu_user_regs *regs)
>
>
> The indentation looks wrong here.
>
>> +{
>> +struct serial_port *port = data;
>> +struct mvebu3700_uart *uart = port->uart;
>> +unsigned int st = mvebu3700_read(uart, UART_STATUS_REG);
>> +
>> +if ( st & STATUS_TX_RDY )
>> +serial_tx_interrupt(port, regs);
>> +
>> +if ( st & (STATUS_RX_RDY | STATUS_OVR_ERR | STATUS_FRM_ERR |
>> STATUS_BRK_DET) )
>> +serial_rx_interrupt(port, regs);
>> +}
>> +
>> +static void __init mvebu3700_uart_init_preirq(struct serial_port *port)
>> +{
>> +struct mvebu3700_uart *uart = port->uart;
>> +unsigned ret;
>
>
> 'ret' is a bit confusion. I would expect to be the return value of the
> function but it is used a temporary variable for reading/write reg. You
> might want to rename to 'reg' for more clarity.
Ok.

> But as this is a register value (i.e specific size), please use uint32_t.
>
>> +
>> +ret = mvebu3700_read(uart, UART_CTRL_REG);
>> +ret |= (CTRL_TXFIFO_RST | CTRL_RXFIFO_RST);
>> +mvebu3700_write(uart, UART_CTRL_REG, ret);
>> +
>> +/* Before we make IRQ request, Clear the error bits of state register
>> */
>
>
> s/Clear/clear/ and missing full stop.

Ok.
>
>
>> +ret = 

Re: [Xen-devel] xen 4.10.0: stubdomain for HVM guest fails to start unless qdisk backend is used?

[George Dunlap]

On Fri, Mar 9, 2018 at 3:24 PM, Chris Brannon  wrote:
> I recently made a build of xen 4.10.0 and installed it.
> I have a pre-existing HVM guest that uses the following configuration:
> 1 hard drive using the phy disk backend.  The guest also uses a device
> model stubdomain.  After upgrading, it refuses to start, due to a
> stubdomain timeout:
>
> Parsing config from somedomain
> libxl: error: libxl_dm.c:2203:stubdom_xswait_cb: Domain 32:Stubdom 33 for 32 
> startup: startup timed out
> libxl: error: libxl_create.c:1538:domcreate_devmodel_started: Domain 
> 32:device model did not start: -9
> libxl: error: libxl_domain.c:1000:libxl__destroy_domid: Domain 
> 32:Non-existant domain
> libxl: error: libxl_domain.c:959:domain_destroy_callback: Domain 32:Unable to 
> destroy guest
> libxl: error: libxl_domain.c:886:domain_destroy_cb: Domain 32:Destruction of 
> domain failed
>
> There is nothing in the logs.
>
> I noticed that a similar guest was booting with no issue.  The
> difference was that the booting guest also had a CD-ROM attached.  That
> CD-ROM used the qdisk backend, because it is backed by an ISO9660 image file.
> I changed the disk parameter in the first non-booting guest so that it
> used the qdisk backend rather than phy, and it booted with no trouble.
>
> Has anyone else had an issue like this after upgrading to 4.10?  I did
> some searching, and I didn't find anything.  I'm a bit surprised by
> that.  Since this is so easy for me to reproduce, and no one else has
> mentioned it, I wonder if my build could be subtly broken somehow.

Can you attach the following?

* the output of `xl dmesg`
* the output of `dmesg`
* the config file for the guest

I just tested stubdoms with staging-4.10 and everything works
correctly *as long as dom0 is assigned all memory*.  If I limit the
amount of dom0 memory to 1GiB, then stubdomains *doesn't* work with
qdisk; only works with the defautl ("phy") backend.

/me investigates a bit further...

 -George

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

Re: [Xen-devel] [RFC PATCH] xen/arm64: Add Support for Marvell ARMADA 3700 SoC

[Amit Tomer]

Hi,

Thanks for looking into.

> Would you mind creating a page on Xen wiki to explain how to boot Xen on
> that board? See [1].

Sure, I would do it and it was on my TODO list as well.

Thanks
Amit.

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

[Xen-devel] [PATCH] xen/arm: Relax ARM_SMCCC_ARCH_WORKAROUND_1 discovery

[julien . grall]

From: Julien Grall 

A recent update to the ARM SMCCC_ARCH_WORKAROUND_1 specification (see [1])
allows firmware to return a non zero, positive value, to describe that
although the mitigation is implemented at the higher exception level,
the CPU on which the call is made is not affected.

Relax the check on the return value from ARM_WORKAROUND_1 so that we
only error out if the returned value is negative.

[1] https://developer.arm.com/support/security-update/downloads
"Firmware interfaces for mitigating CVE-2017-5715 System Software on Arm
Systems"

Signed-off-by: Julien Grall 

---
This patch should be backported as part of XSA-254.

There are potential more optimization to do as part of this
relaxation. For instance, we dropping the CPU ID recognition and
only look ad the SMCCC.
---
 xen/arch/arm/cpuerrata.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 4eb1567589..1baa20654b 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -168,7 +168,8 @@ static int enable_smccc_arch_workaround_1(void *data)
 
 arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
   ARM_SMCCC_ARCH_WORKAROUND_1_FID, );
-if ( res.a0 != ARM_SMCCC_SUCCESS )
+/* The return value is in the lower 32-bits. */
+if ( (int)res.a0 < 0 )
 goto warn;
 
 return !install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
-- 
2.11.0


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

[Xen-devel] Last posting date for Xen 4.11 is March 16th, 2018

[Juergen Gross]

Hi all,

The last posting date for Xen 4.11 is March 16th, 2018. If you want your
features to be included for the release, please make sure they are
posted for the first time before March 16th, 2018.


Juergen Gross

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

Re: [Xen-devel] [PATCH 2/2] x86: use invpcid to do global flushing

[Juergen Gross]

On 12/03/18 14:13, Jan Beulich wrote:
 Juergen Gross  03/12/18 2:10 PM >>>
>> BTW: are you already working on rebasing your XPTI speed up series to
>> current staging? I'd like my series to use your series as a base unless
>> you are telling me you won't be able to resend your series soon.
> 
> I hope to be able to get to this later this week.

Okay, thanks.


Juergen


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

Re: [Xen-devel] [PATCH 2/2] x86: use invpcid to do global flushing

[Jan Beulich]

>>> Juergen Gross  03/12/18 2:10 PM >>>
>BTW: are you already working on rebasing your XPTI speed up series to
>current staging? I'd like my series to use your series as a base unless
>you are telling me you won't be able to resend your series soon.

I hope to be able to get to this later this week.

Jan


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

Re: [Xen-devel] [PATCH 2/2] x86: use invpcid to do global flushing

[Juergen Gross]

On 12/03/18 13:59, Jan Beulich wrote:
 Juergen Gross  03/09/18 7:05 PM >>>
>> On 09/03/18 16:29, Jan Beulich wrote:
>> On 05.03.18 at 10:50,  wrote:
 @@ -120,11 +121,24 @@ unsigned int flush_area_local(const void *va, 
 unsigned int flags)
  else
  {
  u32 t = pre_flush();
 -unsigned long cr4 = read_cr4();
  
 -write_cr4(cr4 & ~X86_CR4_PGE);
 -barrier();
 -write_cr4(cr4);
 +if ( !cpu_has_invpcid )
 +{
 +unsigned long cr4 = read_cr4();
 +
 +write_cr4(cr4 & ~X86_CR4_PGE);
 +barrier();
 +write_cr4(cr4);
 +}
 +else
 +{
 +/*
 + * Using invpcid to flush all mappings works
 + * regardless of whether PCID is enabled or not.
 + * It is faster than read-modify-write CR4.
 + */
 +invpcid_flush_all();
 +}
>>>
>>> As just validly indicated by Jürgen, this is where my comment I
>>> gave to one of his patches actually belongs: This is correct for
>>> FLUSH_TLB_GLOBAL, but goes too far for FLUSH_TLB.
>>
>> And again it was so even before this patch.
> 
> Not exactly - "before this patch" should include the state things were in 
> before
> 32-bit code got removed. And that's where we had a proper separation between
> flushes including and excluding global entries. And now that we regain that
> ability, we should leverage it.

Already working on it in my XPTI speed-up series.

BTW: are you already working on rebasing your XPTI speed up series to
current staging? I'd like my series to use your series as a base unless
you are telling me you won't be able to resend your series soon.


Juergen

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

Re: [Xen-devel] [PATCH 2/2] x86: use invpcid to do global flushing

[Jan Beulich]

>>> Juergen Gross  03/09/18 7:05 PM >>>
>On 09/03/18 16:29, Jan Beulich wrote:
> On 05.03.18 at 10:50,  wrote:
>>> @@ -120,11 +121,24 @@ unsigned int flush_area_local(const void *va, 
>>> unsigned int flags)
>>>  else
>>>  {
>>>  u32 t = pre_flush();
>>> -unsigned long cr4 = read_cr4();
>>>  
>>> -write_cr4(cr4 & ~X86_CR4_PGE);
>>> -barrier();
>>> -write_cr4(cr4);
>>> +if ( !cpu_has_invpcid )
>>> +{
>>> +unsigned long cr4 = read_cr4();
>>> +
>>> +write_cr4(cr4 & ~X86_CR4_PGE);
>>> +barrier();
>>> +write_cr4(cr4);
>>> +}
>>> +else
>>> +{
>>> +/*
>>> + * Using invpcid to flush all mappings works
>>> + * regardless of whether PCID is enabled or not.
>>> + * It is faster than read-modify-write CR4.
>>> + */
>>> +invpcid_flush_all();
>>> +}
>> 
>> As just validly indicated by Jürgen, this is where my comment I
>> gave to one of his patches actually belongs: This is correct for
>> FLUSH_TLB_GLOBAL, but goes too far for FLUSH_TLB.
>
>And again it was so even before this patch.

Not exactly - "before this patch" should include the state things were in before
32-bit code got removed. And that's where we had a proper separation between
flushes including and excluding global entries. And now that we regain that
ability, we should leverage it.

Jan


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

Re: [Xen-devel] [PATCH 6/7] xen/domain: Pass the full domctl_createdomain struct to create_domain()

[Jan Beulich]

>>> Andrew Cooper  03/09/18 6:06 PM >>>
>On 09/03/18 17:00, Jan Beulich wrote:
> On 09.03.18 at 14:18,  wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -426,8 +426,8 @@ static bool emulation_flags_ok(const struct domain *d, 
>>> uint32_t emflags)
>>>  return true;
>>>  }
>>>  
>>> -int arch_domain_create(struct domain *d, unsigned int domcr_flags,
>>> -   struct xen_arch_domainconfig *config)
>>> +int arch_domain_create(struct domain *d,
>>> +   struct xen_domctl_createdomain *config)
>> Is there any reason for this to not be const? There's no write now
>> afaics, and I can't imagine you wanting to add one later on.
>
>I originally planned to make them const, but the ARM side passes data
>back to the toolstack, and the prototype is (rightfully) common.

Oh, I see - certainly a little odd, but that's the way it is then.

Jan


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

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

[Marc Zyngier]

Manish,

On 12/03/18 12:42, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi 
> 
> This patchset is a Xen port of Marc's patchset.
> arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1]
> 
> The current RFC patchset is a subset of [1], as it handleing only Group1 traps
> as a PoC. Most of the trap code is added in vsysreg.c. Trap handler function 
> is kept
> independent of the usual guest trap handling code. 
> Looking for feedback on this approach.  
Why Group-1 only? AFAIK, Group-0 is affected as well, and results in a
DoS on the secure side. Only handling Group-1 makes it hard to compare
to the reference implementation (which handles booth groups), and will
introduce pointless churn once you start adding Group-0 handling.

As it stands, this series is a bit pointless. Please consider posting a
complete fix.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

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

Re: [Xen-devel] osstest planned outage consultation

[Lars Kurth]

> On 12 Mar 2018, at 11:12, Lars Kurth  wrote:
> 
> 
> 
>> On 9 Mar 2018, at 17:02, Ian Jackson  wrote:
>> 
>> Ian Jackson writes ("Re: osstest planned outage consultation"):
>>> It turns out that another key member of staff is away then.  We will
>>> have to do this some time in late April.  Some time the [week] of the
>>> 16th-20th I think.
>> 
>> Lars, can you check this is OK with Credativ and then report back here
>> with a confirmation we're doing it then ?

OK. Felix from Credativ - whom we need - is OO from 16th-18th. 
However he as well as others we need are available from the 19th.

Thus, anytime Apr 19 - 27 works.
Does this work for everyone?

Lars

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

[Xen-devel] [PATCH 12/12] arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler

[mjaggi]

From: Manish Jaggi 

This patch is ported from linux to xen
commit: 2724c11a1df4b22ee966c04809ea0e808f66b04e
(KVM: arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler)

Add a handler for reading the guest's view of the ICV_HPPIR1_EL1
register. This is a simple parsing of the available LRs, extracting the
highest available interrupt.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/arm64/vsysreg_errata.c | 24 
 xen/include/asm-arm/arm64/sysregs.h |  1 +
 2 files changed, 25 insertions(+)

diff --git a/xen/arch/arm/arm64/vsysreg_errata.c 
b/xen/arch/arm/arm64/vsysreg_errata.c
index 869d67640f..088d39613d 100644
--- a/xen/arch/arm/arm64/vsysreg_errata.c
+++ b/xen/arch/arm/arm64/vsysreg_errata.c
@@ -594,6 +594,26 @@ void handle_eoi(struct cpu_user_regs *regs, int regidx, 
const union hsr hsr)
 __vgic_v3_write_eoir(regs, regidx, hsr);
 }
 
+void handle_hppir1(struct cpu_user_regs *regs, int regidx, const union hsr hsr)
+{
+u64 lr_val;
+int lr, lr_grp, grp;
+u32 vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+grp = __vgic_v3_get_group(hsr);
+lr = __vgic_v3_highest_priority_lr(regs, vmcr, _val);
+
+if ( lr == -1 )
+goto spurious;
+
+lr_grp = !!(lr_val & ICH_LR_GROUP);
+if ( lr_grp != grp )
+lr_val = ICC_IAR1_EL1_SPURIOUS;
+
+spurious:
+set_user_reg(regs, regidx, lr_val & ICH_LR_VIRTUAL_ID_MASK);
+}
+
 bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const union hsr 
hsr)
 {
 bool ret = 0;
@@ -624,6 +644,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs, const union hsr hsr
 handle_eoi(regs, regidx, hsr);
 break;
 
+case HSR_SYSREG_ICC_HPPIR1_EL1:
+handle_hppir1(regs, regidx, hsr);
+break;
+
 default:
 ret = 1;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index f9110ebf9c..c23c4a33b2 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -93,6 +93,7 @@
 #define HSR_SYSREG_ICC_IGRPEN1_EL1 HSR_SYSREG(3,0,c12,c12,7)
 #define HSR_SYSREG_ICC_IAR1_EL1   HSR_SYSREG(3,0,c12,c12,0)
 #define HSR_SYSREG_ICC_EOIR1_EL1  HSR_SYSREG(3,0,c12,c12,1)
+#define HSR_SYSREG_ICC_HPPIR1_EL1 HSR_SYSREG(3,0,c12,c12,2)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
-- 
2.14.1


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

[Xen-devel] [PATCH 10/12] arm64: Add ICV_IAR1_EL1 handler

[mjaggi]

From: Manish Jaggi 

This patch is ported to xen from linux commit
132a324ab62fe4fb8d6dcc2ab4eddb0e93b69afe.

Add a handler for reading the guest's view of the ICC_IAR1_EL1
register. This involves finding the highest priority Group-1
interrupt, checking against both PMR and the active group
priority, activating the interrupt and setting the group
priority as active.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/arm64/vsysreg_errata.c | 196 
 xen/include/asm-arm/arm64/sysregs.h |   1 +
 xen/include/asm-arm/gic_v3_defs.h   |  17 
 3 files changed, 214 insertions(+)

diff --git a/xen/arch/arm/arm64/vsysreg_errata.c 
b/xen/arch/arm/arm64/vsysreg_errata.c
index d7bf9d6ce3..9bc1d7b58a 100644
--- a/xen/arch/arm/arm64/vsysreg_errata.c
+++ b/xen/arch/arm/arm64/vsysreg_errata.c
@@ -3,8 +3,18 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
 
 #define vtr_to_nr_pre_bits(v) u32)(v) >> 26) & 7) + 1)
+#define vtr_to_nr_apr_regs(v) (1 << (vtr_to_nr_pre_bits(v) - 5))
+
+#define ESR_ELx_SYS64_ISS_CRM_SHIFT 1
+#define ESR_ELx_SYS64_ISS_CRM_MASK (0xf << ESR_ELx_SYS64_ISS_CRM_SHIFT)
+
+#define ICC_IAR1_EL1_SPURIOUS0x3ff
+#define VGIC_MAX_SPI 1019
 
 static int  __vgic_v3_bpr_min(void)
 {
@@ -272,6 +282,188 @@ static void gicv3_ich_write_lr(int lr, uint64_t val)
 isb();
 }
 
+static int  __vgic_v3_get_group(const union hsr hsr)
+{
+u8 crm = (hsr.bits & ESR_ELx_SYS64_ISS_CRM_MASK) >>
+  ESR_ELx_SYS64_ISS_CRM_SHIFT;
+
+return crm != 8;
+}
+
+unsigned int gic_get_num_lrs(void)
+{
+uint32_t vtr;
+
+vtr = READ_SYSREG32(ICH_VTR_EL2);
+return (vtr & GICH_VTR_NRLRGS) + 1;
+}
+
+static int __vgic_v3_highest_priority_lr(struct cpu_user_regs *regs,
+ u32 vmcr, u64 *lr_val)
+{
+int i, lr = -1;
+unsigned int used_lrs =  gic_get_num_lrs();
+u8 priority = GICV3_IDLE_PRIORITY;
+
+for ( i = 0; i < used_lrs; i++ )
+{
+u64 val =  gicv3_ich_read_lr(i);
+u8 lr_prio = (val & ICH_LR_PRIORITY_MASK) >> ICH_LR_PRIORITY_SHIFT;
+
+/* Not pending in the state? */
+if ( (val & ICH_LR_STATE) != ICH_LR_PENDING_BIT )
+continue;
+
+/* Group-0 interrupt, but Group-0 disabled? */
+if ( !(val & ICH_LR_GROUP) && !(vmcr & ICH_VMCR_ENG0_MASK) )
+continue;
+
+/* Group-1 interrupt, but Group-1 disabled? */
+if ( (val & ICH_LR_GROUP) && !(vmcr & ICH_VMCR_ENG1_MASK) )
+continue;
+
+/* Not the highest priority? */
+if ( lr_prio >= priority )
+continue;
+
+/* This is a candidate */
+priority = lr_prio;
+*lr_val = val;
+lr = i;
+}
+
+if ( lr == -1 )
+*lr_val = ICC_IAR1_EL1_SPURIOUS;
+
+return lr;
+}
+
+static int  __vgic_v3_get_highest_active_priority(void)
+{
+int i;
+u32 hap = 0;
+u8 nr_apr_regs = vtr_to_nr_apr_regs(READ_SYSREG32(ICH_VTR_EL2));
+
+for ( i = 0; i < nr_apr_regs; i++ )
+{
+u32 val;
+
+/*
+ * The ICH_AP0Rn_EL2 and ICH_AP1Rn_EL2 registers
+ * contain the active priority levels for this VCPU
+ * for the maximum number of supported priority
+ * levels, and we return the full priority level only
+ * if the BPR is programmed to its minimum, otherwise
+ * we return a combination of the priority level and
+ * subpriority, as determined by the setting of the
+ * BPR, but without the full subpriority.
+ */
+val  = __vgic_v3_read_ap0rn(i);
+val |= __vgic_v3_read_ap1rn(i);
+if ( !val )
+{
+hap += 32;
+continue;
+}
+
+return (hap + __ffs(val)) << __vgic_v3_bpr_min();
+}
+
+return GICV3_IDLE_PRIORITY;
+}
+
+/*
+ * Convert a priority to a preemption level, taking the relevant BPR
+ * into account by zeroing the sub-priority bits.
+ */
+static u8  __vgic_v3_pri_to_pre(u8 pri, u32 vmcr, int grp)
+{
+unsigned int bpr;
+
+if ( !grp )
+bpr = __vgic_v3_get_bpr0(vmcr) + 1;
+else
+bpr = __vgic_v3_get_bpr1(vmcr);
+
+return pri & (GENMASK(7, 0) << bpr);
+}
+
+/*
+ * The priority value is independent of any of the BPR values, so we
+ * normalize it using the minumal BPR value. This guarantees that no
+ * matter what the guest does with its BPR, we can always set/get the
+ * same value of a priority.
+ */
+static void  __vgic_v3_set_active_priority(u8 pri, u32 vmcr, int grp)
+{
+u8 pre, ap;
+u32 val;
+int apr;
+
+pre = __vgic_v3_pri_to_pre(pri, vmcr, grp);
+ap = pre >> __vgic_v3_bpr_min();
+apr = ap / 32;
+
+if ( !grp )
+{
+val = __vgic_v3_read_ap0rn(apr);
+__vgic_v3_write_ap0rn(val | BIT(ap % 32), apr);
+}
+else
+{
+val = __vgic_v3_read_ap1rn(apr);
+__vgic_v3_write_ap1rn(val | BIT(ap % 32), 

[Xen-devel] [PATCH 11/12] arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

[mjaggi]

From: Manish Jaggi 

This patch is ported to xen from linux commit
b6f49035b4bf6e2709f2a5fed3107f5438c1fd02

Add a handler for writing the guest's view of the ICC_EOIR1_EL1
register. This involves dropping the priority of the interrupt,
and deactivating it if required (EOImode == 0).

Signed-off-by : Manish Jaggi 
---
 xen/arch/arm/arm64/vsysreg_errata.c | 134 
 xen/include/asm-arm/arm64/sysregs.h |   1 +
 xen/include/asm-arm/gic_v3_defs.h   |   4 ++
 3 files changed, 139 insertions(+)

diff --git a/xen/arch/arm/arm64/vsysreg_errata.c 
b/xen/arch/arm/arm64/vsysreg_errata.c
index 9bc1d7b58a..869d67640f 100644
--- a/xen/arch/arm/arm64/vsysreg_errata.c
+++ b/xen/arch/arm/arm64/vsysreg_errata.c
@@ -15,6 +15,7 @@
 
 #define ICC_IAR1_EL1_SPURIOUS0x3ff
 #define VGIC_MAX_SPI 1019
+#define VGIC_MIN_LPI 8192
 
 static int  __vgic_v3_bpr_min(void)
 {
@@ -462,7 +463,136 @@ void handle_iar(struct cpu_user_regs *regs, int regidx, 
const union hsr hsr)
 __vgic_v3_read_iar(regs, regidx, hsr);
 }
 
+static int  __vgic_v3_find_active_lr(int intid, u64 *lr_val)
+{
+int i;
+unsigned int used_lrs =  gic_get_num_lrs();
+
+for ( i = 0; i < used_lrs; i++ )
+{
+u64 val = gicv3_ich_read_lr(i);
+
+if ( (val & ICH_LR_VIRTUAL_ID_MASK) == intid &&
+(val & ICH_LR_ACTIVE_BIT) )
+{
+*lr_val = val;
+return i;
+}
+}
+
+*lr_val = ICC_IAR1_EL1_SPURIOUS;
+return -1;
+}
+
+static int  __vgic_v3_clear_highest_active_priority(void)
+{
+u32 hap = 0;
+int i;
+u8 nr_apr_regs = vtr_to_nr_apr_regs(READ_SYSREG32(ICH_VTR_EL2));
+
+for ( i = 0; i < nr_apr_regs; i++ )
+{
+u32 ap0, ap1;
+int c0, c1;
+
+ap0 = __vgic_v3_read_ap0rn(i);
+ap1 = __vgic_v3_read_ap1rn(i);
+if ( !ap0 && !ap1 )
+{
+hap += 32;
+continue;
+}
+
+c0 = ap0 ? __ffs(ap0) : 32;
+c1 = ap1 ? __ffs(ap1) : 32;
+
+/* Always clear the LSB, which is the highest priority */
+if ( c0 < c1 )
+{
+ap0 &= ~BIT(c0);
+__vgic_v3_write_ap0rn(ap0, i);
+hap += c0;
+}
+else
+{
+ap1 &= ~BIT(c1);
+__vgic_v3_write_ap1rn(ap1, i);
+hap += c1;
+}
+
+/* Rescale to 8 bits of priority */
+return hap << __vgic_v3_bpr_min();
+}
+
+return GICV3_IDLE_PRIORITY;
+}
+
+static void  __vgic_v3_clear_active_lr(int lr, u64 lr_val)
+{
+lr_val &= ~ICH_LR_ACTIVE_BIT;
+if ( lr_val & ICH_LR_HW )
+{
+u32 pid;
+
+pid = (lr_val & ICH_LR_PHYS_ID_MASK) >> ICH_LR_PHYS_ID_SHIFT;
+WRITE_SYSREG32(pid, ICC_DIR_EL1);
+}
+gicv3_ich_write_lr(lr, lr_val);
+}
+
+static void  __vgic_v3_bump_eoicount(void)
+{
+u32 hcr;
+
+hcr = READ_SYSREG32(ICH_HCR_EL2);
+hcr += 1 << ICH_HCR_EOIcount_SHIFT;
+WRITE_SYSREG32(hcr, ICH_HCR_EL2);
+}
 
+static void  __vgic_v3_write_eoir(struct cpu_user_regs *regs, int regidx,
+  const union hsr hsr)
+{
+u32 vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+u32 vid = get_user_reg(regs, regidx);
+u64 lr_val;
+u8 lr_prio, act_prio;
+int lr, grp;
+
+grp = __vgic_v3_get_group(hsr);
+
+/* Drop priority in any case */
+act_prio = __vgic_v3_clear_highest_active_priority();
+
+/* If EOIing an LPI, no deactivate to be performed */
+if ( vid >= VGIC_MIN_LPI )
+return;
+
+/* EOImode == 1, nothing to be done here */
+if ( vmcr & ICH_VMCR_EOIM_MASK )
+return;
+
+lr = __vgic_v3_find_active_lr(vid, _val);
+if ( lr == -1 )
+{
+__vgic_v3_bump_eoicount();
+return;
+}
+
+lr_prio = (lr_val & ICH_LR_PRIORITY_MASK) >> ICH_LR_PRIORITY_SHIFT;
+
+/* If priorities or group do not match, the guest has fscked-up. */
+if ( grp != !!(lr_val & ICH_LR_GROUP) ||
+ __vgic_v3_pri_to_pre(lr_prio, vmcr, grp) != act_prio )
+return;
+
+/* Let's now perform the deactivation */
+__vgic_v3_clear_active_lr(lr, lr_val);
+}
+
+void handle_eoi(struct cpu_user_regs *regs, int regidx, const union hsr hsr)
+{
+__vgic_v3_write_eoir(regs, regidx, hsr);
+}
 
 bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const union hsr 
hsr)
 {
@@ -490,6 +620,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs, const union hsr hsr
 handle_iar(regs, regidx, hsr);
 break;
 
+case HSR_SYSREG_ICC_EOIR1_EL1:
+handle_eoi(regs, regidx, hsr);
+break;
+
 default:
 ret = 1;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 53d2251840..f9110ebf9c 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -92,6 +92,7 @@
 #define 

[Xen-devel] [PATCH 08/12] arm64: Add accessors for the ICH_APxRn_EL2 registers

[mjaggi]

From: Manish Jaggi 

This patch is ported to xen from linux commit
63000dd8006dc987db31ba670edc23142ea91e01

As we're about to access the Active Priority registers a lot more,
let's define accessors that take the register number as a parameter.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/arm64/vsysreg_errata.c | 92 +
 1 file changed, 92 insertions(+)

diff --git a/xen/arch/arm/arm64/vsysreg_errata.c 
b/xen/arch/arm/arm64/vsysreg_errata.c
index 93e9143a0d..b2a95a69dc 100644
--- a/xen/arch/arm/arm64/vsysreg_errata.c
+++ b/xen/arch/arm/arm64/vsysreg_errata.c
@@ -97,6 +97,98 @@ void handle_igrpen1(struct cpu_user_regs *regs, int regidx, 
bool read,
 __vgic_v3_write_igrpen1(regs, regidx);
 }
 
+void  __vgic_v3_write_ap0rn(u32 val, int n)
+{
+switch (n)
+{
+case 0:
+WRITE_SYSREG32(val, ICH_AP0R0_EL2);
+break;
+case 1:
+WRITE_SYSREG32(val, ICH_AP0R1_EL2);
+break;
+case 2:
+WRITE_SYSREG32(val, ICH_AP0R2_EL2);
+break;
+case 3:
+WRITE_SYSREG32(val, ICH_AP0R3_EL2);
+break;
+default:
+unreachable();
+}
+}
+
+void __vgic_v3_write_ap1rn(u32 val, int n)
+{
+switch (n)
+{
+case 0:
+WRITE_SYSREG32(val, ICH_AP1R0_EL2);
+break;
+case 1:
+WRITE_SYSREG32(val, ICH_AP1R1_EL2);
+break;
+case 2:
+WRITE_SYSREG32(val, ICH_AP1R2_EL2);
+break;
+case 3:
+WRITE_SYSREG32(val, ICH_AP1R3_EL2);
+break;
+default:
+unreachable();
+}
+}
+
+u32  __vgic_v3_read_ap0rn(int n)
+{
+u32 val;
+
+switch (n)
+{
+case 0:
+val = READ_SYSREG32(ICH_AP0R0_EL2);
+break;
+case 1:
+val = READ_SYSREG32(ICH_AP0R1_EL2);
+break;
+case 2:
+val = READ_SYSREG32(ICH_AP0R2_EL2);
+break;
+case 3:
+val = READ_SYSREG32(ICH_AP0R3_EL2);
+break;
+default:
+unreachable();
+}
+
+return val;
+}
+
+u32  __vgic_v3_read_ap1rn(int n)
+{
+u32 val;
+
+switch (n)
+{
+case 0:
+val = READ_SYSREG32(ICH_AP1R0_EL2);
+break;
+case 1:
+val = READ_SYSREG32(ICH_AP1R1_EL2);
+break;
+case 2:
+val = READ_SYSREG32(ICH_AP1R2_EL2);
+break;
+case 3:
+val = READ_SYSREG32(ICH_AP1R3_EL2);
+break;
+default:
+unreachable();
+}
+
+return val;
+}
+
 bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const union hsr 
hsr)
 {
 bool ret = 0;
-- 
2.14.1


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

[Xen-devel] [PATCH 07/12] arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler

[mjaggi]

From: Manish Jaggi 

This patch is ported to xen from linux commit:
f8b630bc542e0368886ae193d3519c832b270359

Add a handler for reading/writing the guest's view of the ICC_IGRPEN1_EL1
register, which is located in the ICH_VMCR_EL2.VENG1 field.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/arm64/vsysreg_errata.c | 32 
 xen/include/asm-arm/arm64/sysregs.h |  1 +
 xen/include/asm-arm/gic_v3_defs.h   |  2 ++
 3 files changed, 35 insertions(+)

diff --git a/xen/arch/arm/arm64/vsysreg_errata.c 
b/xen/arch/arm/arm64/vsysreg_errata.c
index eb2b7ad74a..93e9143a0d 100644
--- a/xen/arch/arm/arm64/vsysreg_errata.c
+++ b/xen/arch/arm/arm64/vsysreg_errata.c
@@ -69,6 +69,34 @@ void handle_bpr1(struct cpu_user_regs *regs, int regidx, 
bool read,
 __vgic_v3_write_bpr1(regs, regidx);
 }
 
+static void  __vgic_v3_read_igrpen1(struct cpu_user_regs *regs, int regidx)
+{
+u32 vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+set_user_reg(regs, regidx, !!(vmcr & ICH_VMCR_ENG1_MASK));
+}
+
+static void  __vgic_v3_write_igrpen1(struct cpu_user_regs *regs, int regidx)
+{
+u64 val = get_user_reg(regs, regidx);
+u32 vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( val & 1 )
+vmcr |= ICH_VMCR_ENG1_MASK;
+else
+vmcr &= ~ICH_VMCR_ENG1_MASK;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+void handle_igrpen1(struct cpu_user_regs *regs, int regidx, bool read,
+ const union hsr hsr)
+{
+if ( read )
+__vgic_v3_read_igrpen1(regs, regidx);
+else
+__vgic_v3_write_igrpen1(regs, regidx);
+}
+
 bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const union hsr 
hsr)
 {
 bool ret = 0;
@@ -87,6 +115,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs, const union hsr hsr
  handle_bpr1(regs, regidx, hsr.sysreg.read, hsr);
  break;
 
+case HSR_SYSREG_ICC_IGRPEN1_EL1:
+handle_igrpen1(regs, regidx, hsr.sysreg.read, hsr);
+break;
+
 default:
 ret = 1;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 025a27b0b4..731cabc74a 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -90,6 +90,7 @@
 #define HSR_SYSREG_ICC_SGI0R_EL1  HSR_SYSREG(3,2,c12,c11,7)
 #define HSR_SYSREG_ICC_SRE_EL1HSR_SYSREG(3,0,c12,c12,5)
 #define HSR_SYSREG_ICC_BPR1_EL1   HSR_SYSREG(3,0,c12,c12,3)
+#define HSR_SYSREG_ICC_IGRPEN1_EL1 HSR_SYSREG(3,0,c12,c12,7)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h
index 68a34cc353..ff8bda37d1 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -163,6 +163,8 @@
 #define ICH_VMCR_BPR0_MASK   (7 << ICH_VMCR_BPR0_SHIFT)
 #define ICH_VMCR_BPR1_SHIFT  18
 #define ICH_VMCR_BPR1_MASK   (7 << ICH_VMCR_BPR1_SHIFT)
+#define ICH_VMCR_ENG1_SHIFT  1
+#define ICH_VMCR_ENG1_MASK   (1 << ICH_VMCR_ENG1_SHIFT)
 
 #define GICH_LR_VIRTUAL_MASK 0x
 #define GICH_LR_VIRTUAL_SHIFT0
-- 
2.14.1


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

[Xen-devel] [PATCH 03/12] arm64: Add config for Cavium Thunder erratum 30115

[mjaggi]

From: Manish Jaggi 

Some Cavium Thunder CPUs suffer a problem where a KVM guest may
inadvertently cause the host kernel to quit receiving interrupts.
This patch adds CONFIG_CAVIUM_ERRATUM_30115. Subsequent patches will
provide workaround.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/Kconfig |  4 
 xen/arch/arm/cpuerrata.c | 21 +
 xen/include/asm-arm/cpuerrata.h  |  1 +
 xen/include/asm-arm/cpufeature.h |  3 ++-
 4 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 10a6d1a956..71976ed07b 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -169,6 +169,10 @@ config ARM64_ERRATUM_834220
 
  If unsure, say Y.
 
+config CAVIUM_ERRATUM_30115
+ bool "Cavium vgic errata"
+ depends on HAS_GICV3
+
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index fe9e9facbe..d49698f785 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -56,6 +56,27 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 MIDR_RANGE(MIDR_CORTEX_A57, 0x00,
(1 << MIDR_VARIANT_SHIFT) | 2),
 },
+#endif
+#ifdef CONFIG_CAVIUM_ERRATUM_30115
+{
+/* Cavium ThunderX, T88 pass 1.x - 2.2 */
+.desc = "Cavium erratum 30115",
+.capability = ARM64_WORKAROUND_CAVIUM_30115,
+MIDR_RANGE(MIDR_THUNDERX, 0x00,
+   (1 << MIDR_VARIANT_SHIFT) | 2),
+},
+{
+/* Cavium ThunderX, T81 pass 1.0 - 1.2 */
+.desc = "Cavium erratum 30115",
+.capability = ARM64_WORKAROUND_CAVIUM_30115,
+MIDR_RANGE(MIDR_THUNDERX_81XX, 0x00, 0x02),
+},
+{
+/* Cavium ThunderX, T83 pass 1.0 */
+.desc = "Cavium erratum 30115",
+.capability = ARM64_WORKAROUND_CAVIUM_30115,
+MIDR_RANGE(MIDR_THUNDERX_83XX, 0x00, 0x00),
+},
 #endif
 {},
 };
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 8b158429c7..521f03521b 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -41,6 +41,7 @@ static inline bool check_workaround_##erratum(void)   
  \
 
 CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
 CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
+CHECK_WORKAROUND_HELPER(30115, ARM64_WORKAROUND_CAVIUM_30115, CONFIG_ARM_64)
 
 #undef CHECK_WORKAROUND_HELPER
 
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index f00b6dbd39..d409636bf0 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -42,8 +42,9 @@
 #define LIVEPATCH_FEATURE   4
 #define SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT 5
 #define SKIP_CTXT_SWITCH_SERROR_SYNC 6
+#define ARM64_WORKAROUND_CAVIUM_30115 7
 
-#define ARM_NCAPS   7
+#define ARM_NCAPS   8
 
 #ifndef __ASSEMBLY__
 
-- 
2.14.1


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

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

[mjaggi]

From: Manish Jaggi 

This patchset is a Xen port of Marc's patchset.
arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1]

The current RFC patchset is a subset of [1], as it handleing only Group1 traps
as a PoC. Most of the trap code is added in vsysreg.c. Trap handler function is 
kept
independent of the usual guest trap handling code. 
Looking for feedback on this approach.  

The errata has been validated on Cavium ThunderX platform.

Steps to reporduce the errata
- Boot Xen with 2 cores.
- Disable group1 interrupts in domU kernel
- start domU, the kill and start again.
One of the Xen core would hang.

Code in this patchset fixes this issue.

[1] https://lists.cs.columbia.edu/pipermail/kvmarm/2017-June/026029.html

Changes from RFC
- Added commit information on ported patches from linux
- Added skip_hyp_tail to control calling leave_hypervisor_tail 
- Added CAVIUM_CONFIG_ERRATUM_30115 which will auto enable workaround

Manish Jaggi (12):
  arm:Kconfig Rename menu text
  arm64: cputype: Add MIDR values for Cavium ThunderX1 CPUs
  arm64: Add config for Cavium Thunder erratum 30115
  Enable Group1 Traps by default for Cavium ThunderX
  Placeholder for handling Group1 register traps
  arm64: vgic-v3: Add ICV_BPR1_EL1 handler
  arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler
  arm64: Add accessors for the ICH_APxRn_EL2 registers
  Expose ich_read/write_lr in vsysreg_errata.c
  arm64: Add ICV_IAR1_EL1 handler
  arm64: vgic-v3: Add ICV_EOIR1_EL1 handler
  arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler

 xen/arch/arm/Kconfig|   6 +-
 xen/arch/arm/arm64/Makefile |   1 +
 xen/arch/arm/arm64/vsysreg_errata.c | 660 
 xen/arch/arm/cpuerrata.c|  21 ++
 xen/arch/arm/gic-v3.c   |  16 +-
 xen/arch/arm/traps.c|  20 ++
 xen/include/asm-arm/arm64/sysregs.h |   5 +
 xen/include/asm-arm/arm64/traps.h   |   3 +-
 xen/include/asm-arm/cpuerrata.h |   1 +
 xen/include/asm-arm/cpufeature.h|   3 +-
 xen/include/asm-arm/current.h   |   1 +
 xen/include/asm-arm/gic.h   |   1 +
 xen/include/asm-arm/gic_v3_defs.h   |  29 ++
 xen/include/asm-arm/processor.h |   9 +
 14 files changed, 771 insertions(+), 5 deletions(-)
 create mode 100644 xen/arch/arm/arm64/vsysreg_errata.c

-- 
2.14.1


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

[Xen-devel] [PATCH 02/12] arm64: cputype: Add MIDR values for Cavium ThunderX1 CPUs

[mjaggi]

From: Manish Jaggi 

Add MIDR values for Cavium ThunderX1 SoC's (88xx, 81xx, 83xx).

Signed-off-by: Manish Jaggi 
---
 xen/include/asm-arm/processor.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 65eb1071e1..649a3ae3ca 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -43,15 +43,24 @@
 })
 
 #define ARM_CPU_IMP_ARM 0x41
+#define ARM_CPU_IMP_CAVIUM  0x43
 
 #define ARM_CPU_PART_CORTEX_A15 0xC0F
 #define ARM_CPU_PART_CORTEX_A53 0xD03
 #define ARM_CPU_PART_CORTEX_A57 0xD07
 
+#define CAVIUM_CPU_PART_THUNDERX0x0A1
+#define CAVIUM_CPU_PART_THUNDERX_81XX 0x0A2
+#define CAVIUM_CPU_PART_THUNDERX_83XX 0x0A3
+
 #define MIDR_CORTEX_A15 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A15)
 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A53)
 #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A57)
 
+#define MIDR_THUNDERX   MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX)
+#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_81XX)
+#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_83XX)
+
 /* MPIDR Multiprocessor Affinity Register */
 #define _MPIDR_UP   (30)
 #define MPIDR_UP(_AC(1,U) << _MPIDR_UP)
-- 
2.14.1


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

[Xen-devel] [PATCH 04/12] Enable Group1 Traps by default for Cavium ThunderX1

[mjaggi]

From: Manish Jaggi 

Enable trapping for Group1 register access when
CONFIG_CAVIUM_ERRATUM_30115 is enabled.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/gic-v3.c | 16 ++--
 xen/include/asm-arm/gic.h |  1 +
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 473e26111f..53a772a313 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* Global state */
@@ -825,7 +826,7 @@ static void gicv3_cpu_disable(void)
 
 static void gicv3_hyp_init(void)
 {
-uint32_t vtr;
+uint32_t vtr, reg32 = GICH_HCR_EN;
 
 vtr = READ_SYSREG32(ICH_VTR_EL2);
 gicv3_info.nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
@@ -836,7 +837,18 @@ static void gicv3_hyp_init(void)
 panic("GICv3: Invalid number of priority bits\n");
 
 WRITE_SYSREG32(GICH_VMCR_EOI | GICH_VMCR_VENG1, ICH_VMCR_EL2);
-WRITE_SYSREG32(GICH_HCR_EN, ICH_HCR_EL2);
+
+#ifdef CONFIG_CAVIUM_ERRATUM_30115
+if ( cpus_have_cap(ARM64_WORKAROUND_CAVIUM_30115) )
+{
+reg32 |= GICH_HCR_TALL1;
+printk("%s: 30115 Workaround enabled \r\n", __func__);
+}
+else
+printk("%s: 30115 Workaround not enabled \r\n", __func__);
+#endif
+
+ WRITE_SYSREG32(reg32, ICH_HCR_EL2);
 }
 
 /* Set up the per-CPU parts of the GIC for a secondary CPU */
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index d3d7bda50d..e4c77fefd6 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -117,6 +117,7 @@
 #define GICH_HCR_VGRP0DIE (1 << 5)
 #define GICH_HCR_VGRP1EIE (1 << 6)
 #define GICH_HCR_VGRP1DIE (1 << 7)
+#define GICH_HCR_TALL1(1 << 12)
 
 #define GICH_MISR_EOI (1 << 0)
 #define GICH_MISR_U   (1 << 1)
-- 
2.14.1


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

[Xen-devel] [PATCH 09/12] Expose ich_read/write_lr in vsysreg_errata.c

[mjaggi]

From: Manish Jaggi 

gicv3_ich_read/write_lr functions are duplicated in vsysreg_errata.c

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/arm64/vsysreg_errata.c | 83 +
 1 file changed, 83 insertions(+)

diff --git a/xen/arch/arm/arm64/vsysreg_errata.c 
b/xen/arch/arm/arm64/vsysreg_errata.c
index b2a95a69dc..d7bf9d6ce3 100644
--- a/xen/arch/arm/arm64/vsysreg_errata.c
+++ b/xen/arch/arm/arm64/vsysreg_errata.c
@@ -189,6 +189,89 @@ u32  __vgic_v3_read_ap1rn(int n)
 return val;
 }
 
+static uint64_t gicv3_ich_read_lr(int lr)
+{
+switch ( lr )
+{
+case 0: return READ_SYSREG(ICH_LR0_EL2);
+case 1: return READ_SYSREG(ICH_LR1_EL2);
+case 2: return READ_SYSREG(ICH_LR2_EL2);
+case 3: return READ_SYSREG(ICH_LR3_EL2);
+case 4: return READ_SYSREG(ICH_LR4_EL2);
+case 5: return READ_SYSREG(ICH_LR5_EL2);
+case 6: return READ_SYSREG(ICH_LR6_EL2);
+case 7: return READ_SYSREG(ICH_LR7_EL2);
+case 8: return READ_SYSREG(ICH_LR8_EL2);
+case 9: return READ_SYSREG(ICH_LR9_EL2);
+case 10: return READ_SYSREG(ICH_LR10_EL2);
+case 11: return READ_SYSREG(ICH_LR11_EL2);
+case 12: return READ_SYSREG(ICH_LR12_EL2);
+case 13: return READ_SYSREG(ICH_LR13_EL2);
+case 14: return READ_SYSREG(ICH_LR14_EL2);
+case 15: return READ_SYSREG(ICH_LR15_EL2);
+default:
+BUG();
+}
+}
+
+static void gicv3_ich_write_lr(int lr, uint64_t val)
+{
+switch ( lr )
+{
+case 0:
+WRITE_SYSREG(val, ICH_LR0_EL2);
+break;
+case 1:
+WRITE_SYSREG(val, ICH_LR1_EL2);
+break;
+case 2:
+WRITE_SYSREG(val, ICH_LR2_EL2);
+break;
+case 3:
+WRITE_SYSREG(val, ICH_LR3_EL2);
+break;
+case 4:
+WRITE_SYSREG(val, ICH_LR4_EL2);
+break;
+case 5:
+WRITE_SYSREG(val, ICH_LR5_EL2);
+break;
+case 6:
+WRITE_SYSREG(val, ICH_LR6_EL2);
+break;
+case 7:
+WRITE_SYSREG(val, ICH_LR7_EL2);
+break;
+case 8:
+WRITE_SYSREG(val, ICH_LR8_EL2);
+break;
+case 9:
+WRITE_SYSREG(val, ICH_LR9_EL2);
+break;
+case 10:
+WRITE_SYSREG(val, ICH_LR10_EL2);
+break;
+case 11:
+WRITE_SYSREG(val, ICH_LR11_EL2);
+break;
+case 12:
+WRITE_SYSREG(val, ICH_LR12_EL2);
+break;
+case 13:
+WRITE_SYSREG(val, ICH_LR13_EL2);
+break;
+case 14:
+WRITE_SYSREG(val, ICH_LR14_EL2);
+break;
+case 15:
+WRITE_SYSREG(val, ICH_LR15_EL2);
+break;
+default:
+return;
+}
+isb();
+}
+
 bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const union hsr 
hsr)
 {
 bool ret = 0;
-- 
2.14.1


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

[Xen-devel] [PATCH 06/12] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

[mjaggi]

From: Manish Jaggi 

This patch is ported to xen from linux commit
d70c7b31a60f2458f35c226131f2a01a7a98b6cf

Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/arm64/vsysreg_errata.c | 71 +
 xen/include/asm-arm/arm64/sysregs.h |  1 +
 xen/include/asm-arm/gic_v3_defs.h   |  6 
 3 files changed, 78 insertions(+)

diff --git a/xen/arch/arm/arm64/vsysreg_errata.c 
b/xen/arch/arm/arm64/vsysreg_errata.c
index 6af162bdf7..eb2b7ad74a 100644
--- a/xen/arch/arm/arm64/vsysreg_errata.c
+++ b/xen/arch/arm/arm64/vsysreg_errata.c
@@ -2,10 +2,77 @@
 #include 
 #include 
 #include 
+#include 
+
+#define vtr_to_nr_pre_bits(v) u32)(v) >> 26) & 7) + 1)
+
+static int  __vgic_v3_bpr_min(void)
+{
+/* See Pseudocode for VPriorityGroup */
+return 8 - vtr_to_nr_pre_bits(READ_SYSREG32(ICH_VTR_EL2));
+}
+
+static unsigned int __vgic_v3_get_bpr0(u32 vmcr)
+{
+return (vmcr & ICH_VMCR_BPR0_MASK) >> ICH_VMCR_BPR0_SHIFT;
+}
+
+static unsigned int __vgic_v3_get_bpr1(u32 vmcr)
+{
+unsigned int bpr;
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+{
+bpr = __vgic_v3_get_bpr0(vmcr);
+if ( bpr < 7 )
+bpr++;
+}
+else
+bpr = (vmcr & ICH_VMCR_BPR1_MASK) >> ICH_VMCR_BPR1_SHIFT;
+
+return bpr;
+}
+
+static void  __vgic_v3_read_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+u32 vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+set_user_reg(regs, regidx, __vgic_v3_get_bpr1(vmcr));
+}
+
+static void  __vgic_v3_write_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+u64 val = get_user_reg(regs, regidx);
+u8 bpr_min = __vgic_v3_bpr_min();
+u32 vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+return;
+
+/* Enforce BPR limiting */
+if ( val < bpr_min )
+val = bpr_min;
+
+val <<= ICH_VMCR_BPR1_SHIFT;
+val &= ICH_VMCR_BPR1_MASK;
+vmcr &= ~ICH_VMCR_BPR1_MASK;
+vmcr |= val;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+void handle_bpr1(struct cpu_user_regs *regs, int regidx, bool read,
+ const union hsr hsr)
+{
+if ( read )
+__vgic_v3_read_bpr1(regs, regidx);
+else
+__vgic_v3_write_bpr1(regs, regidx);
+}
 
 bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const union hsr 
hsr)
 {
 bool ret = 0;
+int regidx = hsr.sysreg.reg;
 
 local_irq_disable();
 if ( hsr.ec != HSR_EC_SYSREG )
@@ -16,6 +83,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, 
const union hsr hsr
 
 switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
 {
+case HSR_SYSREG_ICC_BPR1_EL1:
+ handle_bpr1(regs, regidx, hsr.sysreg.read, hsr);
+ break;
+
 default:
 ret = 1;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 084d2a1e5d..025a27b0b4 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -89,6 +89,7 @@
 #define HSR_SYSREG_ICC_ASGI1R_EL1 HSR_SYSREG(3,1,c12,c11,6)
 #define HSR_SYSREG_ICC_SGI0R_EL1  HSR_SYSREG(3,2,c12,c11,7)
 #define HSR_SYSREG_ICC_SRE_EL1HSR_SYSREG(3,0,c12,c12,5)
+#define HSR_SYSREG_ICC_BPR1_EL1   HSR_SYSREG(3,0,c12,c12,3)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h
index 65c9dc47cf..68a34cc353 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -157,6 +157,12 @@
 
 #define GICH_VMCR_EOI(1 << 9)
 #define GICH_VMCR_VENG1  (1 << 1)
+#define ICH_VMCR_CBPR_SHIFT  4
+#define ICH_VMCR_CBPR_MASK   (1 << ICH_VMCR_CBPR_SHIFT)
+#define ICH_VMCR_BPR0_SHIFT  21
+#define ICH_VMCR_BPR0_MASK   (7 << ICH_VMCR_BPR0_SHIFT)
+#define ICH_VMCR_BPR1_SHIFT  18
+#define ICH_VMCR_BPR1_MASK   (7 << ICH_VMCR_BPR1_SHIFT)
 
 #define GICH_LR_VIRTUAL_MASK 0x
 #define GICH_LR_VIRTUAL_SHIFT0
-- 
2.14.1


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

[Xen-devel] [PATCH 05/12] Placeholder for handling Group1 register traps

[mjaggi]

From: Manish Jaggi 

Since this is a SoC errata and trapping of certain group1 registers
should not affect the normal flow. A new file vsysreg_errata.c is added.

Function vgic_v3_handle_cpuif_access is called from do_trap_guest_sync
if ARM64_WORKAROUND_CAVIUM_30115 capability is found.

A flag skip_hyp_tail is introduced in struct cpu_info. This flag specifies
that leave_hypervisor_tail not to be called when handling group1 traps
under this errata.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/arm64/Makefile |  1 +
 xen/arch/arm/arm64/vsysreg_errata.c | 28 
 xen/arch/arm/traps.c| 20 
 xen/include/asm-arm/arm64/traps.h   |  3 ++-
 xen/include/asm-arm/current.h   |  1 +
 5 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 718fe44455..19440c3d8c 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -11,3 +11,4 @@ obj-y += smpboot.o
 obj-y += traps.o
 obj-y += vfp.o
 obj-y += vsysreg.o
+obj-$(CONFIG_CAVIUM_ERRATUM_30115) += vsysreg_errata.o
diff --git a/xen/arch/arm/arm64/vsysreg_errata.c 
b/xen/arch/arm/arm64/vsysreg_errata.c
new file mode 100644
index 00..6af162bdf7
--- /dev/null
+++ b/xen/arch/arm/arm64/vsysreg_errata.c
@@ -0,0 +1,28 @@
+#include 
+#include 
+#include 
+#include 
+
+bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const union hsr 
hsr)
+{
+bool ret = 0;
+
+local_irq_disable();
+if ( hsr.ec != HSR_EC_SYSREG )
+{
+ret = 1;
+goto end;
+}
+
+switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
+{
+default:
+ret = 1;
+break;
+}
+end:
+local_irq_enable();
+
+return ret;
+}
+
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f6f6de3691..9d08cd6ad3 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2103,6 +2104,21 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
 {
 const union hsr hsr = { .bits = regs->hsr };
 
+#ifdef CONFIG_CAVIUM_ERRATUM_30115
+if ( cpus_have_cap(ARM64_WORKAROUND_CAVIUM_30115) )
+{
+int ret;
+get_cpu_info()->skip_hyp_tail = 0;
+ret  = vgic_v3_handle_cpuif_access(regs, hsr);
+if ( !ret )
+{
+advance_pc(regs, hsr);
+get_cpu_info()->skip_hyp_tail = 1;
+return;
+}
+}
+#endif
+
 enter_hypervisor_head(regs);
 
 switch (hsr.ec) {
@@ -2295,6 +2311,10 @@ void do_trap_fiq(struct cpu_user_regs *regs)
 
 void leave_hypervisor_tail(void)
 {
+#ifdef CONFIG_CAVIUM_ERRATUM_30115
+if ( get_cpu_info()->skip_hyp_tail )
+return;
+#endif
 while (1)
 {
 local_irq_disable();
diff --git a/xen/include/asm-arm/arm64/traps.h 
b/xen/include/asm-arm/arm64/traps.h
index 2379b578cb..a5ae93ec11 100644
--- a/xen/include/asm-arm/arm64/traps.h
+++ b/xen/include/asm-arm/arm64/traps.h
@@ -2,7 +2,8 @@
 #define __ASM_ARM64_TRAPS__
 
 void inject_undef64_exception(struct cpu_user_regs *regs, int instr_len);
-
+bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs,
+const union hsr hsr);
 void do_sysreg(struct cpu_user_regs *regs,
const union hsr hsr);
 
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index 7a0971fdea..dacf3adc85 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -22,6 +22,7 @@ struct cpu_info {
 struct cpu_user_regs guest_cpu_user_regs;
 unsigned long elr;
 unsigned int pad;
+bool skip_hyp_tail;
 };
 
 static inline struct cpu_info *get_cpu_info(void)
-- 
2.14.1


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

[Xen-devel] [PATCH 01/12] arm:Kconfig Rename menu text

[mjaggi]

From: Manish Jaggi 

Rename the menu text to Errata Workarounds. Subsequent patches will
add config options for SoC specific erratas.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index f58019d6ed..10a6d1a956 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -59,7 +59,7 @@ config SBSA_VUART_CONSOLE
 
 endmenu
 
-menu "ARM errata workaround via the alternative framework"
+menu "Errata workarounds"
depends on HAS_ALTERNATIVE
 
 config ARM64_ERRATUM_827319
-- 
2.14.1


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

[Xen-devel] [rumprun test] 120451: regressions - FAIL

[osstest service owner]

flight 120451 rumprun real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120451/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumprun   6 rumprun-buildfail REGR. vs. 106754
 build-i386-rumprun6 rumprun-buildfail REGR. vs. 106754

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a

version targeted for testing:
 rumprun  94bdf32ac57b84c1b42150d21f0ad79b3b5dd99c
baseline version:
 rumprun  c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74

Last test of basis   106754  2017-03-18 04:21:25 Z  359 days
Testing same since   120360  2018-03-09 04:19:20 Z3 days3 attempts


People who touched revisions under test:
  Kent McLeod 
  Kent McLeod 
  Naja Melan 
  Sebastian Wicki 
  Wei Liu 

jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  fail
 build-i386-rumprun   fail
 test-amd64-amd64-rumprun-amd64   blocked 
 test-amd64-i386-rumprun-i386 blocked 



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


Not pushing.


commit 94bdf32ac57b84c1b42150d21f0ad79b3b5dd99c
Merge: 8fe40c8 b3c1033
Author: Kent McLeod 
Date:   Fri Feb 16 09:15:45 2018 +1100

Merge pull request #118 from kent-mcleod/stretch-linking-defaultpie

Fix linking on Debian Stretch (gcc-6)

commit b3c1033b090b65e8e86999ddd063c174502aa3f0
Author: Kent McLeod 
Date:   Wed Feb 14 16:43:16 2018 +1100

Add further -no-pie checks to Rumprun build tools

This builds upon the previous commit to add -no-pie anywhere the
relocatable flag (-Wl,-r) is used to handle compilers that enable -pie
by default (Such as Debian Stretch).

commit 8fe40c84edddfbf472b4a7cce960df749701174c
Merge: c7f2f01 685f4ab
Author: Sebastian Wicki 
Date:   Fri Jan 5 15:04:18 2018 +0100

Merge pull request #112 from najamelan/bugfix/gcc7-fallthrough

Add the -Wimplicit-fallthrough=0 flag to allow compiling with GCC7

commit 685f4ab3b74b6f1e1b40bdd3d2c42efa44bf385d
Author: Naja Melan 
Date:   Thu Jan 4 16:07:46 2018 +

Make the disabling of the fallthrough warning dependent on GCC version

This should prevent older gcc versions from choking on unknown argument.

I have not tested this, just wrote the code directly on github. Use with 
caution.

commit 34056451174e8722b972229fefc1bf9e0b89a7da
Author: Naja Melan 
Date:   Wed Jan 3 18:57:50 2018 +

Add the -Wimplicit-fallthrough=0 flag to allow compiling with GCC7

GCC7 comes with a new warning "implicit-fallthrough" which will prevent 
building the netbsd-src.

For more information: 
https://dzone.com/articles/implicit-fallthrough-in-gcc-7

commit 35d81194b7feb75d20af3ba4fdb45ea76230852f
Author: Wei Liu 
Date:   Wed Jun 7 16:30:00 2017 +0100

Fix linking on Debian Stretch

Provide cc-option. Use that to check if -no-pie is available and
append it when necessary.

Signed-off-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 3/3] docs: Remove redundant qemu-xen-security document

[George Dunlap]

On 03/11/2018 08:29 PM, Stefano Stabellini wrote:
> On Fri, 9 Mar 2018, George Dunlap wrote:
>> All this information is now covered in SUPPORT.md.
>>
>> Most of the emulated hardware is obvious a couple of the items are
>> worth pointing out specifically.
>>
>> "xen_disk" is listed under "Blkback"
>>
>> "...the PCI host bridge and the PIIX3 chipset...": This statement is
>> redundant -- the PCI host bridge is a part of the piix3 chipset, which
>> is listed as supported.
>>
>> xenfb: The "graphics" side of "xenfb" is listed under "PV Framebuffer
>> (backend)", and the "input" side of "xenfb" (including both keyboard
>> and mouse) is listed under "PV Keyboard (backend)".
>>
>> Backing storage image format is listed in the "Blkback" section.
>>
>> Signed-off-by: George Dunlap 
> 
> One thing: stdvga is still mispelled in SUPPORT.md.
> Anything else is fine.

So it is.  What about the attached?

 -George
>From 6b41d5c33b95f55fd16b259f58a3852a6cce13f9 Mon Sep 17 00:00:00 2001
From: George Dunlap 
Date: Fri, 9 Mar 2018 11:04:18 +
Subject: [PATCH] docs: Remove redundant qemu-xen-security document

All this information is now covered in SUPPORT.md.

Most of the emulated hardware is obvious a couple of the items are
worth pointing out specifically.

"xen_disk" is listed under "Blkback"

"...the PCI host bridge and the PIIX3 chipset...": This statement is
redundant -- the PCI host bridge is a part of the piix3 chipset, which
is listed as supported.

xenfb: The "graphics" side of "xenfb" is listed under "PV Framebuffer
(backend)", and the "input" side of "xenfb" (including both keyboard
and mouse) is listed under "PV Keyboard (backend)".

Backing storage image format is listed in the "Blkback" section.

Fix 'stdvga' spelling while we're here.

Signed-off-by: George Dunlap 
---
v2:
- Fix stdvgga spelling.

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Tim Deegan 
CC: Konrad Wilk 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Anthony Perard 
CC: Lars Kurth 
---
 SUPPORT.md  |  2 +-
 docs/misc/qemu-xen-security | 21 -
 2 files changed, 1 insertion(+), 22 deletions(-)
 delete mode 100644 docs/misc/qemu-xen-security

diff --git a/SUPPORT.md b/SUPPORT.md
index ee65d45b24..9ac1a40036 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -645,7 +645,7 @@ See the section **Blkback** for image formats supported by QEMU.
 ### x86/Emulated graphics (QEMU):
 
 Status, cirrus-vga: Supported
-Status, stgvga: Supported
+Status, stdvga: Supported
 
 ### x86/Emulated audio (QEMU):
 
diff --git a/docs/misc/qemu-xen-security b/docs/misc/qemu-xen-security
deleted file mode 100644
index 496f7eee7a..00
--- a/docs/misc/qemu-xen-security
+++ /dev/null
@@ -1,21 +0,0 @@
-qemu-xen (git://xenbits.xen.org/qemu-xen.git) is only supported for
-security fixes when used together with the Xen hypervisor and only with
-a subset of all the possible QEMU emulators. Specifically:
-
-- network: e1000, rtl8139, virtio-net
-- storage: piix3 ide, ahci, xen_disk
-- backing storage image format: raw, qcow, qcow2, vhd
-- graphics: cirris-vga, stdvga and xenfb
-- audio: sb16, es1370, ac97
-- input: Xen PV keyboard and mouse (part of xenfb), USB and PS/2
- keyboard and mouse
-- serial cards: UART 16550A
-
-Core components, such as the PCI host bridge and the PIIX3 chipset, are
-supported. All devices of one the above classes, which are not explicitly
-mentioned, are not supported. For example the ne2000 network card is not
-supported. 
-
-If you think that a specific emulated device should be supported, please
-contact the QEMU UPSTREAM maintainer and the Xen Security Team
-(secur...@xenproject.org).
-- 
2.16.2

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