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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf  broken  in 113293
 build-armhf4 host-install(4) broken in 113293 REGR. vs. 113031
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
113031
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 113031
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 113031
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 113031
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 113031
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 113031
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 113031
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 113031
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
113031
 test-amd64-i386-examine   7 reboot   fail REGR. vs. 113031
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
113031

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 113293 pass in 
113323
 test-amd64-amd64-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail pass in 
113293

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu  1 build-check(1)  blocked in 113293 n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked in 113293 n/a
 build-armhf-libvirt   1 build-check(1)   blocked in 113293 n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked in 113293 n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked in 113293 n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked in 113293 n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked in 113293 n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked in 113293 n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1) blocked in 113293 n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked in 113293 n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked in 113293 n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked in 113293 n/a
 test-amd64-i386-libvirt-qcow2  7 xen-boot   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
113031
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113031
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113031
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113031
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113031
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-am

Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md

[Juergen Gross]

On 11/09/17 19:01, George Dunlap wrote:
> Add a machine-readable file to describe what features are in what
> state of being 'supported', as well as information about how long this
> release will be supported, and so on.
> 
> The document should be formatted using "semantic newlines" [1], to make
> changes easier.
> 
> Signed-off-by: Ian Jackson 
> Signed-off-by: George Dunlap 
> 
> [1] http://rhodesmill.org/brandon/2012/one-sentence-per-line/
> ---
> 
> Sorry, I wrote a 'changes since v1' but managed to lose it.  I'll
> reply to this mail tomorrow with a list of changes.
> 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Andrew Cooper 
> CC: Jan Beulich 
> CC: Tim Deegan 
> CC: Dario Faggioli 
> CC: Tamas K Lengyel 
> CC: Roger Pau Monne 
> CC: Stefano Stabellini 
> CC: Anthony Perard 
> CC: Paul Durrant 
> CC: Konrad Wilk 
> CC: Julien Grall 
> ---
>  SUPPORT.md | 821 
> +
>  1 file changed, 821 insertions(+)
>  create mode 100644 SUPPORT.md
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> new file mode 100644
> index 00..e30664feca
> --- /dev/null
> +++ b/SUPPORT.md
> @@ -0,0 +1,821 @@
> +# Support statement for this release
> +
> +This document describes the support status and in particular the
> +security support status of the Xen branch within which you find it.
> +
> +See the bottom of the file for the definitions of the support status
> +levels etc.
> +
> +# Release Support
> +
> +Xen-Version: 4.10-unstable
> +Initial-Release: n/a
> +Supported-Until: TBD
> +Security-Support-Until: Unreleased - not yet security-supported
> +
> +# Feature Support
> +

> +### Virtual RAM
> +
> +Limit, x86 PV: >1TB

2047GB PV guests have been tested to work, including live migration.
Tests with larger guests are just ongoing (needed my live migration
patch which is upstream now).


Juergen

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

Re: [Xen-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest

[Haozhong Zhang]

On 09/11/17 11:52 -0700, Stefano Stabellini wrote:
> CC'ing xen-devel, and the Xen tools and x86 maintainers.
> 
> On Mon, 11 Sep 2017, Igor Mammedov wrote:
> > On Mon, 11 Sep 2017 12:41:47 +0800
> > Haozhong Zhang  wrote:
> > 
> > > This is the QEMU part patches that works with the associated Xen
> > > patches to enable vNVDIMM support for Xen HVM domains. Xen relies on
> > > QEMU to build guest NFIT and NVDIMM namespace devices, and allocate
> > > guest address space for vNVDIMM devices.
> > > 
> > > All patches can be found at
> > >   Xen:  https://github.com/hzzhan9/xen.git nvdimm-rfc-v3
> > >   QEMU: https://github.com/hzzhan9/qemu.git xen-nvdimm-rfc-v3
> > > 
> > > Patch 1 is to avoid dereferencing the NULL pointer to non-existing
> > > label data, as the Xen side support for labels is not implemented yet.
> > > 
> > > Patch 2 & 3 add a memory backend dedicated for Xen usage and a hotplug
> > > memory region for Xen guest, in order to make the existing nvdimm
> > > device plugging path work on Xen.
> > > 
> > > Patch 4 - 10 build and cooy NFIT from QEMU to Xen guest, when QEMU is
> > > used as the Xen device model.
> > 
> > I've skimmed over patch-set and can't say that I'm happy with
> > number of xen_enabled() invariants it introduced as well as
> > with partial blobs it creates.
> 
> I have not read the series (Haozhong, please CC me, Anthony and
> xen-devel to the whole series next time), but yes, indeed. Let's not add
> more xen_enabled() if possible.
> 
> Haozhong, was there a design document thread on xen-devel about this? If
> so, did it reach a conclusion? Was the design accepted? If so, please
> add a link to the design doc in the introductory email, so that
> everybody can read it and be on the same page.

Yes, there is a design [1] discussed and reviewed. Section 4.3 discussed
the guest ACPI.

[1] https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg01921.html

> 
> 
> > I'd like to reduce above and a way to do this might be making xen 
> >  1. use fw_cfg
> >  2. fetch QEMU build acpi tables from fw_cfg
> >  3. extract nvdim tables (which is trivial) and use them
> > 
> > looking at xen_load_linux(), it seems possible to use fw_cfg.
> > 
> > So what's stopping xen from using it elsewhere?,
> > instead of adding more xen specific code to do 'the same'
> > job and not reusing/sharing common code with tcg/kvm.
> 
> So far, ACPI tables have not been generated by QEMU. Xen HVM machines
> rely on a firmware-like application called "hvmloader" that runs in
> guest context and generates the ACPI tables. I have no opinions on
> hvmloader and I'll let the Xen maintainers talk about it. However, keep
> in mind that with an HVM guest some devices are emulated by Xen and/or
> by other device emulators that can run alongside QEMU. QEMU doesn't have
> a full few of the system.
> 
> Here the question is: does it have to be QEMU the one to generate the
> ACPI blobs for the nvdimm? It would be nicer if it was up to hvmloader
> like the rest, instead of introducing this split-brain design about
> ACPI. We need to see a design doc to fully understand this.
>

hvmloader runs in the guest and is responsible to build/load guest
ACPI. However, it's not capable to build AML at runtime (for the lack
of AML builder). If any guest ACPI object is needed (e.g. by guest
DSDT), it has to be generated from ASL by iasl at Xen compile time and
then be loaded by hvmloader at runtime.

Xen includes an OperationRegion "BIOS" in the static generated guest
DSDT, whose address is hardcoded and which contains a list of values
filled by hvmloader at runtime. Other ACPI objects can refer to those
values (e.g., the number of vCPUs). But it's not enough for generating
guest NVDIMM ACPI objects at compile time and then being customized
and loaded by hvmload, because its structure (i.e., the number of
namespace devices) cannot be decided util the guest config is known.

Alternatively, we may introduce an AML builder in hvmloader and build
all guest ACPI completely in hvmloader. Looking at the similar
implementation in QEMU, it would not be small, compared to the current
size of hvmloader. Besides, I'm still going to let QEMU handle guest
NVDIMM _DSM and _FIT calls, which is another reason I use QEMU to
build NVDIMM ACPI.

> If the design doc thread led into thinking that it has to be QEMU to
> generate them, then would it make the code nicer if we used fw_cfg to
> get the (full or partial) tables from QEMU, as Igor suggested?

I'll have a look at the code (which I didn't notice) pointed by Igor.

One possible issue to use fw_cfg is how to avoid the conflict between
ACPI built by QEMU and ACPI built by hvmloader (e.g., both may use the
same table signature / device names / ...). In my current design, QEMU
will pass the table signatures and device names used in its ACPI to
Xen, and Xen can check the conflict with its own ACPI. Perhaps we can
add necessary functions in fw_cfg as well. Anyway, let me first look
at the code.

Tha

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

[osstest service owner]

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

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
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:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  d719518d9ce9132bad8a06e8029aeead328f66a3
  Bug not present: cb8c65ccff7f77d0285f1b126c72d37b2572c865
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/113347/


  (Revision log too long, omitted.)


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-qemuu-rhel6hvm-intel.xen-boot
 --summary-out=tmp/113347.bisection-summary --basis-template=113031 
--blessings=real,real-bisect linux-linus test-amd64-i386-qemuu-rhel6hvm-intel 
xen-boot
Searching for failure / basis pass:
 113262 fail [host=italia0] / 112277 [host=elbling1] 112271 [host=italia1] 
112235 [host=fiano1] 112182 [host=baroque1] 112083 [host=baroque0] 112049 
[host=fiano0] 112019 [host=nobling1] 111995 [host=elbling0] 111972 ok.
Failure / basis pass flights: 113262 / 111972
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest d719518d9ce9132bad8a06e8029aeead328f66a3 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
c349189772cec43498b0bec8a84146f10b8937af 
70892c317fd56064b09a4b0fcaa0781735e64efc
Basis pass cb8c65ccff7f77d0285f1b126c72d37b2572c865 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
2b8a8a03f56e21381c7dd560b081002d357639e2
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#cb8c65ccff7f77d0285f1b126c72d37b2572c865-d719518d9ce9132bad8a06e8029aeead328f66a3
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#414d069b38ab114b89085e44989bf57604ea86d7-c349189772cec43498b0bec8a84146f10b8937af
 
git://xenbits.xen.org/xen.git#2b8a8a03f56e21381c7dd560b081002d357639e2-70892c317fd56064b09a4b0fcaa0781735e64efc
adhoc-revtuple-generator: tree discontiguous: linux-2.6
adhoc-revtuple-generator: tree discontiguous: qemu-xen
Loaded 1004 nodes in revision graph
Searching for test results:
 111831 [host=nobling0]
 111866 [host=elbling1]
 111939 [host=huxelrebe1]
 111972 pass cb8c65ccff7f77d0285f1b126c72d37b2572c865 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
2b8a8a03f56e21381c7dd560b081002d357639e2
 112019 [host=nobling1]
 111995 [host=elbling0]
 112049 [host=fiano0]
 112083 [host=baroque0]
 112182 [host=baroque1]
 112271 [host=italia1]
 112235 [host=fiano1]
 112277 [host=elbling1]
 113150 fail irrelevant
 113166 fail irrelevant
 113189 fail irrelevant
 113341 fail d719518d9ce9132bad8a06e8029aeead328f66a3 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
c349189772cec43498b0bec8a84146f10b8937af 
70892c317fd56064b09a4b0fcaa0781735e64efc
 113287 fail d719518d9ce9132bad8a06e8029aeead328f66a3 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
c349189772cec43498b0bec8a84146f10b8937af 
70892c317fd56064b09a4b0fcaa0781735e64efc
 113290 pass cb8c65ccff7f77d0285f1b126c72d37b2572c865 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
09ed69f66d5799cd70f38e458b56a6a65dbead1f
 113306 pass cb8c65ccff7f77d0285f1b126c72d37b2572c865 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
12257de3cfff9b4ffa0b7379ef82c9ad7c8dbec9
 113292 pass cb8c65ccff7f77d0285f1b126c72d37b2572c865 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
0913366a9117241ea960d240f7fbcc659227e39b
 113

Re: [Xen-devel] CONFIG_SCRUB_DEBUG=y + arm64 + livepatch = Xen BUG at page_alloc.c:738

[Boris Ostrovsky]

On 09/11/2017 07:55 PM, Konrad Rzeszutek Wilk wrote:

Hey,

I've only been able to reproduce this on ARM64 (trying right now ARM32
as well), and not on x86.

If I compile Xen without CONFIG_SCRUB_DEBUG it works great. But if
enable it and try to load a livepatch it blows up in page_alloc.c:738

This is with origin/staging (d0291f3391)


Can you still reproduce this if you revert 307c3be?


-boris

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

[Xen-devel] [PATCH v3 10/17] livepatch: Declare live patching as a supported feature

[Konrad Rzeszutek Wilk]

From: Ross Lagerwall 

See docs/features/livepatch.pandoc for the details.

Reviewed-by: Jan Beulich 
Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 

--
v2:
 - Moved it into a feature document.
 - Clarified a few bits and pieces based on feedback.
v3:
 - default X86
 - added Jan's Reviewed-by
 - Added tech preview for ARM.
 - Cut down the 3) paragraph per George's input
---
 docs/features/livepatch.pandoc | 106 +
 xen/common/Kconfig |   4 +-
 2 files changed, 108 insertions(+), 2 deletions(-)
 create mode 100644 docs/features/livepatch.pandoc

diff --git a/docs/features/livepatch.pandoc b/docs/features/livepatch.pandoc
new file mode 100644
index 00..17f1cd0d05
--- /dev/null
+++ b/docs/features/livepatch.pandoc
@@ -0,0 +1,106 @@
+% Live Patching
+% Revision 1
+
+\clearpage
+
+# Basics
+
+ 
+ Status: **Supported**
+
+   Architecture: x86
+
+ Status: **Tech Preview/Experimental**
+
+   Architecture: ARM
+
+  Component: Hypervisor, toolstack
+ 
+
+
+# Details
+
+Xen Live Patching has been available as tech preview feature since Xen
+4.7 and has now had a couple of releases to stabilize. Xen Live patching
+has been used by multiple vendors to fix several real-world security
+issues without any severe bugs encountered. Additionally, there are now
+tests in OSSTest that test live patching to ensure that no regressions
+are introduced.
+
+Based on the amount of testing and usage it has had, we are ready to
+declare live patching as a 'Supported' feature on x86.
+
+Live patching is slightly peculiar when it comes to support because it
+allows the host administrator to break their system rather easily
+depending on the content of the live patch. Because of this, it is
+worth detailing the scope of security support:
+
+1) Unprivileged access to live patching operations:
+   Live patching operations should only be accessible to privileged
+   guests and it shall be treated as a security issue if this is not
+   the case.
+
+2) Bugs in the patch-application code such that vulnerabilities exist
+   after application:
+   If a correct live patch is loaded but it is not applied correctly
+   such that it might result in an insecure system (e.g. not all
+   functions are patched), it shall be treated as a security issue.
+
+3) Bugs in livepatch-build-tools creating an incorrect live patch that
+   results in an insecure host:
+   If livepatch-build-tools creates an incorrect live patch that
+   results in an insecure host, this shall not be considered a security
+   issue. A live patch should be checked to verify that it is valid
+   before loading.
+
+4) Loading an incorrect live patch that results in an insecure host or
+   host crash:
+   If a live patch (whether created using livepatch-build-tools or some
+   alternative) is loaded and it results in an insecure host or host
+   crash due to the content of the live patch being incorrect or the
+   issue being inappropriate to live patch, this is not considered as a
+   security issue.
+
+5) Bugs in the live patch parsing code (the ELF loader):
+   Bugs in the live patch parsing code such as out-of-bounds reads
+   caused by invalid ELF files are not considered to be security issues
+   because the it can only be triggered by a privileged domain.
+
+6) Bugs which allow a guest to prevent the application of a livepatch:
+   A guest should not be able to prevent the application of a live
+   patch. If an unprivileged guest can somehow prevent the application
+   of a live patch despite pausing it (xl pause ...), it shall be
+   treated as a security issue.
+
+Note: It is expected that live patches are tested in a test environment
+before being used in production to avoid unexpected issues. In
+particular, to avoid the issues described by (3), (4), & (5).
+
+There are also some generic security questions which are worth asking:
+
+1) Is guest->host privilege escalation possible?
+
+The new live patching sysctl subops are only accessible to privileged
+domains and this is tested by OSSTest with an XTF test.
+There is a caveat -- an incorrect live patch can introduce a guest->host
+privilege escalation.
+
+2) Is guest user->guest kernel escalation possible?
+
+No, although an incorrect live patch can introduce a guest user->guest
+kernel privilege escalation.
+
+3) Is there any information leakage?
+
+The new live patching sysctl subops are only accessible to privileged
+domains so it is not possible for an unprivileged guest to access the
+list of loaded live patches. This is tested by OSSTest with an XTF test.
+There is a caveat -- an incorrect live patch can introduce an
+information leakage.
+
+4) Can a Denial-of-Service be triggered?
+
+There are no known ways that an unprivileged guest can prevent a live
+patch from being loaded.
+Once 

[Xen-devel] [PATCH v3 17/17] livepatch: Add xen_local_symbols test-case

[Konrad Rzeszutek Wilk]

To exercise the local/global visibility.

With "livepatch: Add local and global symbol resolution."
we can load both xen_hello_world and xen_local_symbols
without having to worry about:

-bash-4.1# xen-livepatch load xen_hello_world.livepatch
Uploading xen_hello_world.livepatch... completed
Applying xen_hello_world... completed
-bash-4.1# xen-livepatch list
 ID | status
+
xen_hello_world | APPLIED
-bash-4.1# xen-livepatch upload xen_local_symbols xen_local_symbols.livepatch
Uploading xen_local_symbols.livepatch... failed
(XEN) livepatch.c:819: livepatch: xen_local_symbols: duplicate new symbol: 
revert_hook

In fact you will see:

livepatch: xen_hello_world: new local symbol revert_hook
livepatch: xen_hello_world: new local symbol apply_hook
livepatch: xen_hello_world: new local symbol check_fnc
livepatch: xen_hello_world: new local symbol hello_world_patch_this_fnc

...
livepatch: xen_local_symbols: new local symbol revert_hook
livepatch: xen_local_symbols: new local symbol apply_hook
livepatch: xen_local_symbols: new local symbol hello_world_patch_this_fnc
..

Signed-off-by: Konrad Rzeszutek Wilk 
---
v1: First edition
v2: Build with mkhex version of build-id from hypervisor.
---
 xen/test/livepatch/Makefile| 12 +++-
 xen/test/livepatch/xen_local_symbols.c | 53 ++
 2 files changed, 64 insertions(+), 1 deletion(-)
 create mode 100644 xen/test/livepatch/xen_local_symbols.c

diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 6e5b9a3a75..f88c8f9c80 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -11,11 +11,13 @@ LIVEPATCH := xen_hello_world.livepatch
 LIVEPATCH_BYE := xen_bye_world.livepatch
 LIVEPATCH_REPLACE := xen_replace_world.livepatch
 LIVEPATCH_NOP := xen_nop.livepatch
+LIVEPATCH_LOCAL := xen_local_symbols.livepatch
 
 LIVEPATCHES += $(LIVEPATCH)
 LIVEPATCHES += $(LIVEPATCH_BYE)
 LIVEPATCHES += $(LIVEPATCH_REPLACE)
 LIVEPATCHES += $(LIVEPATCH_NOP)
+LIVEPATCHES += $(LIVEPATCH_LOCAL)
 
 LIVEPATCH_DEBUG_DIR ?= $(DEBUG_DIR)/xen-livepatch
 
@@ -109,5 +111,13 @@ $(LIVEPATCH_NOP): xen_nop.o
$(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@
$(OBJCOPY) --set-section-flags .livepatch.funcs=alloc,readonly $@
 
+xen_local_symbols.o: config.h livepatch_depends.h
+
+.PHONY: $(LIVEPATCH_LOCAL)
+$(LIVEPATCH_LOCAL): xen_hello_world_func.o xen_local_symbols.o
+   $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_LOCAL) $^
+   $(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@
+   $(OBJCOPY) --set-section-flags .livepatch.funcs=alloc,readonly $@
+
 .PHONY: livepatch
-livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE) $(LIVEPATCH_NOP)
+livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE) $(LIVEPATCH_NOP) 
$(LIVEPATCH_LOCAL)
diff --git a/xen/test/livepatch/xen_local_symbols.c 
b/xen/test/livepatch/xen_local_symbols.c
new file mode 100644
index 00..448c489818
--- /dev/null
+++ b/xen/test/livepatch/xen_local_symbols.c
@@ -0,0 +1,53 @@
+/*
+ * Copyright (c) 2017 Oracle and/or its affiliates. All rights reserved.
+ */
+
+#include "config.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include "livepatch_depends.h"
+
+/* Same name as in xen_hello_world */
+static const char hello_world_patch_this_fnc[] = "xen_extra_version";
+extern const char *xen_hello_world(void);
+
+/*
+ * The hooks are static here (LOCAL) and also in xen_hello_world.c
+ * and their name is exactly the same.
+ */
+static void apply_hook(void)
+{
+printk(KERN_DEBUG "local_symbols: Hook executing.\n");
+}
+
+static void revert_hook(void)
+{
+printk(KERN_DEBUG "local_symbols: Hook unloaded.\n");
+}
+
+LIVEPATCH_LOAD_HOOK(apply_hook);
+LIVEPATCH_UNLOAD_HOOK(revert_hook);
+
+struct livepatch_func __section(".livepatch.funcs") 
livepatch_xen_local_symbols = {
+.version = LIVEPATCH_PAYLOAD_VERSION,
+.name = hello_world_patch_this_fnc,
+.new_addr = xen_hello_world,
+.old_addr = xen_extra_version,
+.new_size = NEW_CODE_SZ,
+.old_size = OLD_CODE_SZ,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.13.3


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

[Xen-devel] [PATCH v3 02/17] livepatch: Tighten alignment checks.

[Konrad Rzeszutek Wilk]

The ELF specification mentions nothing about the sh_size being
modulo the sh_addralign. Only that sh_addr MUST be aligned on
sh_addralign if sh_addralign is not zero or one.

We on loading did not take this in-to account so this patch adds
a check on the ELF file as it is being parsed.

Signed-off-by: Konrad Rzeszutek Wilk 
---
v1: Initial patch
v2: Drop the check when loading it in memory
Add check for alignment being anything but power of two (ignoring 0, and 1)
Change dprintk to include hex values and print addr not size.
v3: Change the two checks to be per Jan's recommendations.
---
 xen/common/livepatch_elf.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
index b69e2718dd..7839913ff5 100644
--- a/xen/common/livepatch_elf.c
+++ b/xen/common/livepatch_elf.c
@@ -86,6 +86,19 @@ static int elf_resolve_sections(struct livepatch_elf *elf, 
const void *data)
 delta < sizeof(Elf_Ehdr) ? "at ELF header" : "is past 
end");
 return -EINVAL;
 }
+else if ( sec[i].sec->sh_addralign &&
+  sec[i].sec->sh_addr % sec[i].sec->sh_addralign )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Section [%u] addr 
(%#"PRIxElfAddr") is not aligned properly (%#"PRIxElfAddr")\n",
+elf->name, i, sec[i].sec->sh_addr, 
sec[i].sec->sh_addralign);
+return -EINVAL;
+}
+else if ( sec[i].sec->sh_addralign & (sec[i].sec->sh_addralign - 1) )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Section [%u] alignment 
(%#"PRIxElfAddr") is not supported\n",
+elf->name, i, sec[i].sec->sh_addralign);
+return -EOPNOTSUPP;
+}
 else if ( (sec[i].sec->sh_flags & (SHF_WRITE | SHF_ALLOC)) &&
   sec[i].sec->sh_type == SHT_NOBITS &&
   sec[i].sec->sh_size > LIVEPATCH_MAX_SIZE )
-- 
2.13.3


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

[Xen-devel] [PATCH v3 07/17] livepatch/arm/x86: Strip note_depends symbol from test-cases.

[Konrad Rzeszutek Wilk]

This surfaced due to "xen/livepatch/x86/arm32: Force
.livepatch.depends section to be uint32_t aligned." which switched
to a different way of including the build-id.

Each livepatch ends with a global:

30:  1 OBJECT  GLOBAL HIDDEN 7 note_depends

which will cause collision when loading.

One attempted solution was to add in the Makefile stanza:
 @sed -i '/unsigned/static unsinged/' $@

But that resulted in the note_depends being omitted from the livepatch
(as it was static and not used) which meant we would not have an
.livepatch_depends section which we require.

The solution to this is to remove the symbol via the --strip-symbols
after generating the livepatch.

However that fails as note_depends is in use by .rel.debug_info:
Relocation section '.rel.debug_info' at offset 0x151c contains 113 entries:
 Offset InfoTypeSym.Value  Sym. Name
..
0625  1e02 R_ARM_ABS32      note_depends

And the solution to that is to also slap on --strip-debug which removes
various .debug* sections (which livepatch ignores anyhow):
.debug_aranges, .debug_info, .debug_abbrev, .debug_line, .debug_frame,
.debug_str, and their .rel.* sections. And that will remove that.

Alternatively we could also use --localize-symbol so that note_depends
is not globally visible. But that won't help as hypervisor treats
both local and global symbols as global when resolving them.
(This is fixed in "livepatch: Add local and global symbol resolution."
but that patch is stuck in limbo).

Signed-off-by: Konrad Rzeszutek Wilk 
---
v3: First version
---
 xen/test/livepatch/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 89ad89dfd5..9e73861732 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -53,6 +53,7 @@ xen_hello_world.o: config.h livepatch_depends.h
 .PHONY: $(LIVEPATCH)
 $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH) $^
+   $(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@
 
 #
 # This target is only accessible if CONFIG_LIVEPATCH is defined, which
@@ -88,18 +89,21 @@ xen_bye_world.o: config.h hello_world_livepatch_depends.h
 .PHONY: $(LIVEPATCH_BYE)
 $(LIVEPATCH_BYE): xen_bye_world_func.o xen_bye_world.o
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_BYE) $^
+   $(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@
 
 xen_replace_world.o: config.h livepatch_depends.h
 
 .PHONY: $(LIVEPATCH_REPLACE)
 $(LIVEPATCH_REPLACE): xen_replace_world_func.o xen_replace_world.o
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_REPLACE) $^
+   $(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@
 
 xen_nop.o: config.h livepatch_depends.h
 
 .PHONY: $(LIVEPATCH_NOP)
 $(LIVEPATCH_NOP): xen_nop.o
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_NOP) $^
+   $(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@
 
 .PHONY: livepatch
 livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE) $(LIVEPATCH_NOP)
-- 
2.13.3


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

[Xen-devel] [PATCH v3] Livepatching patch set for 4.10

[Konrad Rzeszutek Wilk]

Hey,

As I was trying to port livepatch-build-tools.git to work under ARM32 and ARM64
(still ongoing, if somebody wants to help/take over would appreciate it)
I found some inconsistencies compared to the x86 and test-cases:
 - The .livepatch.funcs in the test-cases are in RW section but the 
livepatch-build-tools
   puts them in the RO sections. That works on x86 as arch_livepatch_quiesce
   turns of WP globally during the livepatching.
   But not on ARM.. and to make it work there I ended up using the vmap 
functionality.
   Which then I made common on x86 as well (so no more CR4 mucking).
   This meant however meant mucking with x86 code page walker to
   have a do_page_walk functionality.

 - Cross compiling ARM32 introduces subtle alignment issues. Mainly
   both .altinstructions and .livepatch.depends end up with the
   wrong alingment and the hypervisor blows up. Both fixes are
   in the patchset.

I am also including in this patchset:

 - Declare the livepatch supported on x86 (but not ARM). It has latest
   feedback from Andrew and George (I hope!)

 - Post the local/global symbol patchset functionality. Only Jan had
   commented and I would appreciate other folks feedback - perhaps
   folks have better ideas on this?

Lastly, I tested this on ARM32 (Cubietruck), ARM64 (HiKey960) and
on x86. All looked good until I enabled CONFIG_DEBUG_SCRUB - which
is reported in:
https://lists.xen.org/archives/html/xen-devel/2017-09/msg01147.html

Patches are in 

  git://xenbits.xen.org/people/konradwilk/xen.git staging-for-4.10.v3

 docs/features/livepatch.pandoc | 106 
 docs/misc/livepatch.markdown   |   4 +
 xen/arch/arm/arm32/livepatch.c |  33 -
 xen/arch/arm/arm64/livepatch.c |  17 ++-
 xen/arch/arm/livepatch.c   |  49 +---
 xen/arch/arm/xen.lds.S |   2 -
 xen/arch/x86/livepatch.c   |  36 --
 xen/arch/x86/x86_64/mm.c   |  33 +++--
 xen/arch/x86/xen.lds.S |   1 -
 xen/common/Kconfig |   4 +-
 xen/common/livepatch.c | 219 +
 xen/common/livepatch_elf.c |  13 ++
 xen/include/asm-arm/alternative.h  |   4 +
 xen/include/asm-arm/livepatch.h|   6 -
 xen/include/asm-x86/alternative.h  |   1 +
 xen/include/asm-x86/mm.h   |   1 +
 xen/include/xen/elfstructs.h   |   2 +
 xen/include/xen/livepatch.h|  23 +++-
 xen/include/xen/livepatch_elf.h|   7 ++
 xen/test/livepatch/Makefile|  76 +++-
 xen/test/livepatch/xen_bye_world.c |   1 +
 xen/test/livepatch/xen_hello_world.c   |   1 +
 xen/test/livepatch/xen_local_symbols.c |  53 
 xen/test/livepatch/xen_nop.c   |   1 +
 xen/test/livepatch/xen_replace_world.c |   1 +
 25 files changed, 521 insertions(+), 173 deletions(-)

Konrad Rzeszutek Wilk (16):
  livepatch: Expand check for safe_for_reapply if livepatch has only 
.rodata.
  livepatch: Tighten alignment checks.
  livepatch: Include sizes when an mismatch occurs
  xen/livepatch/ARM32: Don't load and crash on livepatches loaded with 
wrong text alignment.
  alternative/x86/arm32: Align altinstructions (and altinstr_replacement) 
sections.
  xen/livepatch/x86/arm32: Force .livepatch.depends section to be uint32_t 
aligned.
  livepatch/arm/x86: Strip note_depends symbol from test-cases.
  livepatch/tests: Make sure all .livepatch.funcs sections are read-only
  livepatch/arm[32,64]: Modify livepatch_funcs
  livepatch/x86/arm[32,64]: Use common vmap code for applying.
  livepatch/x86/arm[32,64]: Unify arch_livepatch_revert
  livepatch: Expand spin_debug_disable in [apply|revert]_payload
  livepatch/x86/arm: arch/x86/mm: generalize do_page_walk() and implement 
arch_livepatch_lookup_mfn
  livepatch/x86/arm: Utilize the arch_livepatch_lookup_mfn
  livepatch: Add local and global symbol resolution.
  livepatch: Add xen_local_symbols test-case

Ross Lagerwall (1):
  livepatch: Declare live patching as a supported feature


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

[Xen-devel] [PATCH v3 03/17] livepatch: Include sizes when an mismatch occurs

[Konrad Rzeszutek Wilk]

If the .bug.frames.X or .livepatch.funcs sizes are different
than what the hypervisor expects - we fail the payload. To help
in diagnosing this include the expected and the payload
sizes.

Also make it more natural by having "Multiples" in the warning.

Also fix one case where we would fail if the size of the .ex_table
was being zero - but that is OK.

Signed-off-by: Konrad Rzeszutek Wilk 
---
v1: Initial version
v2: - Changed to 'Multiple' per Jan's recommendation.
- Folded the checks in 'check_size' function and removed all the other
  parts of code that checked for this.
v3: - Drop bool zero_ok
- Return bool instead of int (and invert the return condition)
- Change name of the function to be more clear
---
 xen/common/livepatch.c   | 46 +---
 xen/include/xen/elfstructs.h |  2 ++
 2 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index a1f54c42d3..c6ee95fbcf 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -460,6 +460,22 @@ static int secure_payload(struct payload *payload, struct 
livepatch_elf *elf)
 return rc;
 }
 
+static bool section_ok(const struct livepatch_elf *elf,
+   const struct livepatch_elf_sec *sec, size_t sz)
+{
+if ( !elf || !sec )
+return false;
+
+if ( sec->sec->sh_size % sz )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size %"PRIuElfWord" of %s 
(must be multiple of %zu)\n",
+elf->name, sec->sec->sh_size, sec->name, sz);
+return false;
+}
+
+return true;
+}
+
 static int check_special_sections(const struct livepatch_elf *elf)
 {
 unsigned int i;
@@ -509,12 +525,8 @@ static int prepare_payload(struct payload *payload,
 
 sec = livepatch_elf_sec_by_name(elf, ELF_LIVEPATCH_FUNC);
 ASSERT(sec);
-if ( sec->sec->sh_size % sizeof(*payload->funcs) )
-{
-dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size of 
"ELF_LIVEPATCH_FUNC"!\n",
-elf->name);
+if ( !section_ok(elf, sec, sizeof(*payload->funcs)) )
 return -EINVAL;
-}
 
 payload->funcs = sec->load_addr;
 payload->nfuncs = sec->sec->sh_size / sizeof(*payload->funcs);
@@ -556,7 +568,7 @@ static int prepare_payload(struct payload *payload,
 sec = livepatch_elf_sec_by_name(elf, ".livepatch.hooks.load");
 if ( sec )
 {
-if ( sec->sec->sh_size % sizeof(*payload->load_funcs) )
+if ( !section_ok(elf, sec, sizeof(*payload->load_funcs)) )
 return -EINVAL;
 
 payload->load_funcs = sec->load_addr;
@@ -566,7 +578,7 @@ static int prepare_payload(struct payload *payload,
 sec = livepatch_elf_sec_by_name(elf, ".livepatch.hooks.unload");
 if ( sec )
 {
-if ( sec->sec->sh_size % sizeof(*payload->unload_funcs) )
+if ( !section_ok(elf, sec, sizeof(*payload->unload_funcs)) )
 return -EINVAL;
 
 payload->unload_funcs = sec->load_addr;
@@ -637,12 +649,8 @@ static int prepare_payload(struct payload *payload,
 if ( !sec )
 continue;
 
-if ( sec->sec->sh_size % sizeof(*region->frame[i].bugs) )
-{
-dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size of 
.bug_frames.%u!\n",
-elf->name, i);
+if ( !section_ok(elf, sec, sizeof(*region->frame[i].bugs)) )
 return -EINVAL;
-}
 
 region->frame[i].bugs = sec->load_addr;
 region->frame[i].n_bugs = sec->sec->sh_size /
@@ -655,12 +663,8 @@ static int prepare_payload(struct payload *payload,
 #ifdef CONFIG_HAS_ALTERNATIVE
 struct alt_instr *a, *start, *end;
 
-if ( sec->sec->sh_size % sizeof(*a) )
-{
-dprintk(XENLOG_ERR, LIVEPATCH "%s: Size of .alt_instr is not 
multiple of %zu!\n",
-elf->name, sizeof(*a));
+if ( !section_ok(elf, sec, sizeof(*a)) )
 return -EINVAL;
-}
 
 start = sec->load_addr;
 end = sec->load_addr + sec->sec->sh_size;
@@ -692,14 +696,8 @@ static int prepare_payload(struct payload *payload,
 #ifdef CONFIG_HAS_EX_TABLE
 struct exception_table_entry *s, *e;
 
-if ( !sec->sec->sh_size ||
- (sec->sec->sh_size % sizeof(*region->ex)) )
-{
-dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size of .ex_table 
(exp:%lu vs %lu)!\n",
-elf->name, sizeof(*region->ex),
-sec->sec->sh_size);
+if ( !section_ok(elf, sec, sizeof(*region->ex)) )
 return -EINVAL;
-}
 
 s = sec->load_addr;
 e = sec->load_addr + sec->sec->sh_size;
diff --git a/xen/include/xen/elfstructs.h b/xen/include/xen/elfstructs.h
index 950e1492e5..726ca8f60d 100644
--- a/xen/include/xen/elfstructs.h
+++ b/xen/include/xen/elfstructs.h
@@ -555,6 +555,7 @@ typedef struct {
 
 #if defined(ELFSIZE) && (ELFSIZE == 32)
 #define PRIxElfAddr"08x"
+#define PRIuElfWord

[Xen-devel] [PATCH v3 09/17] livepatch/arm[32, 64]: Modify livepatch_funcs

[Konrad Rzeszutek Wilk]

This was found when porting livepatch-build-tools to ARM64/32.

When livepatch-build-tools are built (and test-case thanks to:
livepatch/tests: Make sure all .livepatch.funcs sections are read-only)
the .livepatch.funcs are in read-only section.

However the hypervisor uses the 'opaque' for its own purpose, that
is stashing the original code. But the .livepatch_funcs section is
in the RO vmap area so on ARM[32,64] we get a fault.

On x86 the same protection is in place. In 'arch_livepatch_quiesce'
we disable WP to allow changes to read-only pages (and in arch_live_resume
we enable the WP protection).

On ARM[32,64] we do not have the luxury of a global register that can
be changed after boot. In lieu of that we use the vmap to create
a temporary virtual address in which we can use instead.

To do this we need to stash during livepatch: vmap of the hypervisor
code, vmap of the .livepatch_funcs (vmap comes in page aligned virtual
addresses), offset in the vmap (in case it is not nicely aligned), and
the original first livepatch_funcs to figure out the index.

Equipped with that we can patch livepatch functions which have
 .livepatch_funcs in rodata section.

An alternative is to add the 'W' flag during loading of the
.livepatch_funcs which would result the section being in writeable
region from the gecko.

Note that this vmap solution could be extended to x86 as well.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/arch/arm/arm32/livepatch.c  | 11 ++---
 xen/arch/arm/arm64/livepatch.c  | 11 ++---
 xen/arch/arm/livepatch.c| 52 -
 xen/arch/x86/livepatch.c|  2 +-
 xen/common/livepatch.c  |  5 ++--
 xen/include/asm-arm/livepatch.h | 13 ---
 xen/include/xen/livepatch.h |  2 +-
 7 files changed, 71 insertions(+), 25 deletions(-)

diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 10887ace81..d793ebcaad 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -16,18 +16,23 @@ void arch_livepatch_apply(struct livepatch_func *func)
 uint32_t insn;
 uint32_t *new_ptr;
 unsigned int i, len;
+struct livepatch_func *f;
 
 BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE > sizeof(func->opaque));
 BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE != sizeof(insn));
 
-ASSERT(vmap_of_xen_text);
+ASSERT(livepatch_vmap.text);
 
 len = livepatch_insn_len(func);
 if ( !len )
 return;
 
+/* Index in the vmap region. */
+i = livepatch_vmap.va - func;
+f = (struct livepatch_func *)(livepatch_vmap.funcs + 
livepatch_vmap.offset) + i;
+
 /* Save old ones. */
-memcpy(func->opaque, func->old_addr, len);
+memcpy(f->opaque, func->old_addr, len);
 
 if ( func->new_addr )
 {
@@ -56,7 +61,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
 else
 insn = 0xe1a0; /* mov r0, r0 */
 
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+new_ptr = func->old_addr - (void *)_start + livepatch_vmap.text;
 len = len / sizeof(uint32_t);
 
 /* PATCH! */
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index 2728e2a125..662bedabc3 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -20,18 +20,23 @@ void arch_livepatch_apply(struct livepatch_func *func)
 uint32_t insn;
 uint32_t *new_ptr;
 unsigned int i, len;
+struct livepatch_func *f;
 
 BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE > sizeof(func->opaque));
 BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE != sizeof(insn));
 
-ASSERT(vmap_of_xen_text);
+ASSERT(livepatch_vmap.text);
 
 len = livepatch_insn_len(func);
 if ( !len )
 return;
 
+/* Index in the vmap region. */
+i = livepatch_vmap.va - func;
+f = (struct livepatch_func *)(livepatch_vmap.funcs + 
livepatch_vmap.offset) + i;
+
 /* Save old ones. */
-memcpy(func->opaque, func->old_addr, len);
+memcpy(f->opaque, func->old_addr, len);
 
 if ( func->new_addr )
 insn = aarch64_insn_gen_branch_imm((unsigned long)func->old_addr,
@@ -43,7 +48,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
 /* Verified in livepatch_verify_distance. */
 ASSERT(insn != AARCH64_BREAK_FAULT);
 
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+new_ptr = func->old_addr - (void *)_start + livepatch_vmap.text;
 len = len / sizeof(uint32_t);
 
 /* PATCH! */
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 3e53524365..2f9ae8e61e 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -16,14 +17,18 @@
 #undef virt_to_mfn
 #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
 
-void *vmap_of_xen_text;
+struct livepatch_vmap_stash livepatch_vmap;
 
-int arch_livepatch_quiesce(void)
+int arch_livepatch_quiesce(struct livepatch_func *funcs, unsigned int nfuncs)
 {

[Xen-devel] [PATCH v3 13/17] livepatch: Expand spin_debug_disable in [apply|revert]_payload

[Konrad Rzeszutek Wilk]

Under ARM64 the vmap calls were all done with IRQs disabled which
didn't trip the spinlock debug check (as seen on x86):

livepatch.c:1330: livepatch: xen_hello_world: timeout is 3000ns
livepatch.c:1437: livepatch: xen_hello_world: CPU3 - IPIing the other 3 CPUs
Applying xen_hello_world... (XEN) livepatch: xen_hello_world: Applying 1 
functions
Xen BUG at spinlock.c:47
..snip..
[] spinlock.c#check_lock+0x3e/0x44
[] _spin_lock+0x11/0x4a
[] __vmap+0x78/0x381
[] livepatch.c#livepatch_quiesce+0xc4/0x1bf
[] livepatch.c#apply_payload+0x3a/0x102
[] check_for_livepatch_work+0x1f3/0x390
[] domain.c#continue_idle_domain+0x1b/0x22

But are definitly the case on x86 - so we expand the scope
of the spin_debug_disable.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/common/livepatch.c | 30 --
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 93083cda1a..2f5ee1ae75 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1154,22 +1154,22 @@ static int apply_payload(struct payload *data)
 printk(XENLOG_INFO LIVEPATCH "%s: Applying %u functions\n",
 data->name, data->nfuncs);
 
+/*
+ * Since we are running with IRQs disabled and the hooks may call common
+ * code - which expects certain spinlocks to run with IRQs enabled - we
+ * temporarily disable the spin locks IRQ state checks.
+ */
+spin_debug_disable();
 rc = livepatch_quiesce(data->funcs, data->nfuncs);
 if ( rc )
 {
+spin_debug_enable();
 printk(XENLOG_ERR LIVEPATCH "%s: unable to quiesce!\n", data->name);
 return rc;
 }
 
-/*
- * Since we are running with IRQs disabled and the hooks may call common
- * code - which expects certain spinlocks to run with IRQs enabled - we
- * temporarily disable the spin locks IRQ state checks.
- */
-spin_debug_disable();
 for ( i = 0; i < data->n_load_funcs; i++ )
 data->load_funcs[i]();
-spin_debug_enable();
 
 ASSERT(!local_irq_is_enabled());
 
@@ -1177,6 +1177,7 @@ static int apply_payload(struct payload *data)
 arch_livepatch_apply(&data->funcs[i]);
 
 livepatch_revive();
+spin_debug_enable();
 
 /*
  * We need RCU variant (which has barriers) in case we crash here.
@@ -1195,9 +1196,16 @@ static int revert_payload(struct payload *data)
 
 printk(XENLOG_INFO LIVEPATCH "%s: Reverting\n", data->name);
 
+/*
+ * Since we are running with IRQs disabled and the hooks may call common
+ * code - which expects certain spinlocks to run with IRQs enabled - we
+ * temporarily disable the spin locks IRQ state checks.
+ */
+spin_debug_disable();
 rc = livepatch_quiesce(data->funcs, data->nfuncs);
 if ( rc )
 {
+spin_debug_enable();
 printk(XENLOG_ERR LIVEPATCH "%s: unable to quiesce!\n", data->name);
 return rc;
 }
@@ -1205,19 +1213,13 @@ static int revert_payload(struct payload *data)
 for ( i = 0; i < data->nfuncs; i++ )
 livepatch_revert(&data->funcs[i]);
 
-/*
- * Since we are running with IRQs disabled and the hooks may call common
- * code - which expects certain spinlocks to run with IRQs enabled - we
- * temporarily disable the spin locks IRQ state checks.
- */
-spin_debug_disable();
 for ( i = 0; i < data->n_unload_funcs; i++ )
 data->unload_funcs[i]();
-spin_debug_enable();
 
 ASSERT(!local_irq_is_enabled());
 
 livepatch_revive();
+spin_debug_enable();
 
 /*
  * We need RCU variant (which has barriers) in case we crash here.
-- 
2.13.3


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

[Xen-devel] [PATCH v3 11/17] livepatch/x86/arm[32, 64]: Use common vmap code for applying.

[Konrad Rzeszutek Wilk]

Patch titled "livepatch/arm[32,64]: Modify livepatch_funcs" added
the infrastructure on ARM [32,64] to use vmap as way to
map read-only regions. On x86 we use a global register.

But there is nothing wrong with using on x86 the same method
as on ARM[32,64] - which is exactly what this patch does.

As result the common code for setting up vmap is now
done in livepatch_quiesce and there is no arch specific
arch_livepatch_quiesce anymore.

The same treatment is applied to arch_livepatch_revive albeit
we still need arch specific code for ARM (to clear the i-cache).

Interestingly the arch_livepatch_revert looks almost the same
on x86 and ARM. See 'livepatch/x86/arm[32,64]: Unify arch_livepatch_revert'

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/arch/arm/livepatch.c| 64 
 xen/arch/x86/livepatch.c| 32 +---
 xen/common/livepatch.c  | 81 +++--
 xen/include/asm-arm/livepatch.h | 13 ---
 xen/include/xen/livepatch.h | 13 +++
 5 files changed, 108 insertions(+), 95 deletions(-)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 2f9ae8e61e..2debb5368c 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -17,57 +17,6 @@
 #undef virt_to_mfn
 #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
 
-struct livepatch_vmap_stash livepatch_vmap;
-
-int arch_livepatch_quiesce(struct livepatch_func *funcs, unsigned int nfuncs)
-{
-mfn_t text_mfn, rodata_mfn;
-void *vmap_addr;
-unsigned int text_order;
-unsigned long va = (unsigned long)(funcs);
-unsigned int offs = va & (PAGE_SIZE - 1);
-unsigned int size = PFN_UP(offs + nfuncs * sizeof(*funcs));
-
-if ( livepatch_vmap.text || livepatch_vmap.funcs )
-return -EINVAL;
-
-text_mfn = virt_to_mfn(_start);
-text_order = get_order_from_bytes(_end - _start);
-
-/*
- * The text section is read-only. So re-map Xen to be able to patch
- * the code.
- */
-vmap_addr = __vmap(&text_mfn, 1U << text_order, 1, 1, PAGE_HYPERVISOR,
-   VMAP_DEFAULT);
-
-if ( !vmap_addr )
-{
-printk(XENLOG_ERR LIVEPATCH "Failed to setup vmap of hypervisor! 
(order=%u)\n",
-   text_order);
-return -ENOMEM;
-}
-
-livepatch_vmap.text = vmap_addr;
-livepatch_vmap.offset = offs;
-
-rodata_mfn = virt_to_mfn(va & PAGE_MASK);
-vmap_addr  = __vmap(&rodata_mfn, size, 1, 1, PAGE_HYPERVISOR, 
VMAP_DEFAULT);
-if ( !vmap_addr )
-{
-printk(XENLOG_ERR LIVEPATCH "Failed to setup vmap of livepatch_funcs! 
(mfn=%"PRI_mfn", size=%u)\n",
-   mfn_x(rodata_mfn), size);
-vunmap(livepatch_vmap.text);
-livepatch_vmap.text = NULL;
-return -ENOMEM;
-}
-
-livepatch_vmap.funcs = vmap_addr;
-livepatch_vmap.va = funcs;
-
-return 0;
-}
-
 void arch_livepatch_revive(void)
 {
 /*
@@ -75,19 +24,6 @@ void arch_livepatch_revive(void)
  * arch_livepatch_[apply|revert].
  */
 invalidate_icache();
-
-if ( livepatch_vmap.text )
-vunmap(livepatch_vmap.text);
-
-livepatch_vmap.text = NULL;
-
-if ( livepatch_vmap.funcs )
-vunmap(livepatch_vmap.funcs);
-
-livepatch_vmap.funcs = NULL;
-
-livepatch_vmap.va = NULL;
-livepatch_vmap.offset = 0;
 }
 
 int arch_livepatch_verify_func(const struct livepatch_func *func)
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 8522fcbd36..5273f5a176 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -14,18 +14,9 @@
 #include 
 #include 
 
-int arch_livepatch_quiesce(struct livepatch_func *func, unsigned int nfuncs)
-{
-/* Disable WP to allow changes to read-only pages. */
-write_cr0(read_cr0() & ~X86_CR0_WP);
-
-return 0;
-}
-
 void arch_livepatch_revive(void)
 {
-/* Reinstate WP. */
-write_cr0(read_cr0() | X86_CR0_WP);
+/* Nothing to do. */
 }
 
 int arch_livepatch_verify_func(const struct livepatch_func *func)
@@ -54,14 +45,21 @@ void noinline arch_livepatch_apply(struct livepatch_func 
*func)
 {
 uint8_t *old_ptr;
 uint8_t insn[sizeof(func->opaque)];
-unsigned int len;
+unsigned int i, len;
+struct livepatch_func *f;
 
-old_ptr = func->old_addr;
+/* Recompute using the vmap. */
+old_ptr = func->old_addr - (void *)_start + livepatch_vmap.text;
 len = livepatch_insn_len(func);
 if ( !len )
 return;
 
-memcpy(func->opaque, old_ptr, len);
+/* Index in the vmap region. */
+i = livepatch_vmap.va - func;
+f = (struct livepatch_func *)(livepatch_vmap.funcs + 
livepatch_vmap.offset) + i;
+
+memcpy(f->opaque, old_ptr, len);
+
 if ( func->new_addr )
 {
 int32_t val;
@@ -85,7 +83,13 @@ void noinline arch_livepatch_apply(struct livepatch_func 
*func)
  */
 void noinline arch_livepatch_revert(const struct livepatch_func *func)
 {
-memcpy(func->old_addr, func->opaque, livepatch

[Xen-devel] [PATCH v3 12/17] livepatch/x86/arm[32, 64]: Unify arch_livepatch_revert

[Konrad Rzeszutek Wilk]

The arch_livepatch_revert is very similar between the platforms.
Lets unify it as much as possible.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/arch/arm/livepatch.c| 10 +-
 xen/arch/x86/livepatch.c| 10 ++
 xen/common/livepatch.c  | 14 +-
 xen/include/xen/livepatch.h |  3 +--
 4 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 2debb5368c..e1d5d58f97 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -39,16 +39,8 @@ int arch_livepatch_verify_func(const struct livepatch_func 
*func)
 return 0;
 }
 
-void arch_livepatch_revert(const struct livepatch_func *func)
+void arch_livepatch_revert(uint32_t *new_ptr, unsigned int len)
 {
-uint32_t *new_ptr;
-unsigned int len;
-
-new_ptr = func->old_addr - (void *)_start + livepatch_vmap.text;
-
-len = livepatch_insn_len(func);
-memcpy(new_ptr, func->opaque, len);
-
 clean_and_invalidate_dcache_va_range(new_ptr, len);
 }
 
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 5273f5a176..12287d445f 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -81,15 +81,9 @@ void noinline arch_livepatch_apply(struct livepatch_func 
*func)
  * "noinline" to cause control flow change and thus invalidate I$ and
  * cause refetch after modification.
  */
-void noinline arch_livepatch_revert(const struct livepatch_func *func)
+void noinline arch_livepatch_revert(uint32_t *new_ptr, unsigned int len)
 {
-uint32_t *new_ptr;
-unsigned int len;
-
-new_ptr = func->old_addr - (void *)_start + livepatch_vmap.text;
-
-len = livepatch_insn_len(func);
-memcpy(new_ptr, func->opaque, len);
+/* Nothing to do. */
 }
 
 /*
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index eb7d4098fd..93083cda1a 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1128,6 +1128,18 @@ static void livepatch_revive(void)
 livepatch_vmap.offset = 0;
 }
 
+static void livepatch_revert(const struct livepatch_func *func)
+{
+uint32_t *new_ptr;
+unsigned int len;
+
+new_ptr = func->old_addr - (void *)_start + livepatch_vmap.text;
+
+len = livepatch_insn_len(func);
+memcpy(new_ptr, func->opaque, len);
+
+arch_livepatch_revert(new_ptr, len);
+}
 /*
  * The following functions get the CPUs into an appropriate state and
  * apply (or revert) each of the payload's functions. This is needed
@@ -1191,7 +1203,7 @@ static int revert_payload(struct payload *data)
 }
 
 for ( i = 0; i < data->nfuncs; i++ )
-arch_livepatch_revert(&data->funcs[i]);
+livepatch_revert(&data->funcs[i]);
 
 /*
  * Since we are running with IRQs disabled and the hooks may call common
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 1659ffcdf0..065c1a323a 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -117,11 +117,10 @@ extern struct livepatch_vmap_stash livepatch_vmap;
  * These functions are called around the critical region patching live code,
  * for an architecture to take make appropratie global state adjustments.
  */
-int arch_livepatch_quiesce(struct livepatch_func *func, unsigned int nfuncs);
 void arch_livepatch_revive(void);
 
 void arch_livepatch_apply(struct livepatch_func *func);
-void arch_livepatch_revert(const struct livepatch_func *func);
+void arch_livepatch_revert(uint32_t *new_ptr, unsigned int len);
 void arch_livepatch_post_action(void);
 
 void arch_livepatch_mask(void);
-- 
2.13.3


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

[Xen-devel] [PATCH v3 01/17] livepatch: Expand check for safe_for_reapply if livepatch has only .rodata.

[Konrad Rzeszutek Wilk]

If the livepatch has only .rodata sections then it is OK to also
apply/revert/apply the livepatch without having to worry about the
unforseen consequences.

See commit 98b728a7b235c67e210f67f789db5d9eb38ca00c
"livepatch: Disallow applying after an revert" for details.

Signed-off-by: Konrad Rzeszutek Wilk 
---
v3: New patch
---
 xen/common/livepatch.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 66d532db14..a1f54c42d3 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -417,9 +417,12 @@ static int move_payload(struct payload *payload, struct 
livepatch_elf *elf)
 }
 }
 
-/* Only one RW section with non-zero size: .livepatch.funcs */
-if ( rw_buf_cnt == 1 &&
- !strcmp(elf->sec[rw_buf_sec].name, ELF_LIVEPATCH_FUNC) )
+/*
+ * Only one RW section with non-zero size: .livepatch.funcs,
+ * or only RO sections.
+ */
+if ( !rw_buf_cnt || (rw_buf_cnt == 1 &&
+ !strcmp(elf->sec[rw_buf_sec].name, ELF_LIVEPATCH_FUNC)) )
 payload->safe_to_reapply = true;
  out:
 xfree(offset);
-- 
2.13.3


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

[Xen-devel] [PATCH v3 04/17] xen/livepatch/ARM32: Don't load and crash on livepatches loaded with wrong text alignment.

[Konrad Rzeszutek Wilk]

The ARM 32&64 ELF specification says "sections containing ARM
code must be at least 32-bit aligned." This patch adds the
check for that. We also make sure that this check is done
when doing relocations for the types that are considered
ARM code. However we don't have to check for all as we only
implement a small subset of them - as such we only check for
data types that are implemented - and if the type is anything else
and not aligned to 32-bit, then we error out.

Signed-off-by: Konrad Rzeszutek Wilk 
---
v1: Initial patch
v2: Redo the commit to include the commits which fix the alignment issues.
Also mention the need in the docs
v3: Change the docs to explicitly mention text code section alignment 
requirements.
Invert arch_livepatch_verify_alignment return value (true for alignment is 
ok).
Drop the alignment check in check_special_sections.
Make the alignment check in check_section only for executable sections.
Rewrote the commit message as it is not applicable to v2 of the patch 
anymore.
---
 docs/misc/livepatch.markdown   |  2 ++
 xen/arch/arm/arm32/livepatch.c | 22 --
 xen/arch/arm/arm64/livepatch.c |  6 ++
 xen/arch/x86/livepatch.c   |  6 ++
 xen/common/livepatch.c |  7 +++
 xen/include/xen/livepatch.h|  1 +
 6 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 54a6b850cb..505dc37cda 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -279,6 +279,8 @@ It may also have some architecture-specific sections. For 
example:
  * Exception tables.
  * Relocations for each of these sections.
 
+Note that on ARM 32 the sections containing code MUST be four byte aligned.
+
 The Xen Live Patch core code loads the payload as a standard ELF binary, 
relocates it
 and handles the architecture-specifc sections as needed. This process is much
 like what the Linux kernel module loader does.
diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 41378a54ae..10887ace81 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -112,6 +112,15 @@ bool arch_livepatch_symbol_deny(const struct livepatch_elf 
*elf,
 return false;
 }
 
+bool arch_livepatch_verify_alignment(const struct livepatch_elf_sec *sec)
+{
+if ( sec->sec->sh_flags & SHF_EXECINSTR &&
+ ((uint32_t)sec->load_addr % sizeof(uint32_t)) )
+return false;
+
+return true;
+};
+
 static s32 get_addend(unsigned char type, void *dest)
 {
 s32 addend = 0;
@@ -233,7 +242,7 @@ int arch_livepatch_perform(struct livepatch_elf *elf,
 uint32_t val;
 void *dest;
 unsigned char type;
-s32 addend;
+s32 addend = 0;
 
 if ( use_rela )
 {
@@ -251,7 +260,6 @@ int arch_livepatch_perform(struct livepatch_elf *elf,
 symndx = ELF32_R_SYM(r->r_info);
 type = ELF32_R_TYPE(r->r_info);
 dest = base->load_addr + r->r_offset; /* P */
-addend = get_addend(type, dest);
 }
 
 if ( symndx == STN_UNDEF )
@@ -272,6 +280,16 @@ int arch_livepatch_perform(struct livepatch_elf *elf,
 elf->name, symndx);
 return -EINVAL;
 }
+else if ( (type != R_ARM_ABS32 && type != R_ARM_REL32) /* Only check 
code. */ &&
+  ((uint32_t)dest % sizeof(uint32_t)) )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: dest=%p (%s) is not aligned 
properly!\n",
+elf->name, dest, base->name);
+return -EINVAL;
+}
+
+if ( !use_rela )
+addend = get_addend(type, dest);
 
 val = elf->sym[symndx].sym->st_value; /* S */
 
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index 2247b925a0..2728e2a125 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -86,6 +86,12 @@ bool arch_livepatch_symbol_deny(const struct livepatch_elf 
*elf,
 return false;
 }
 
+bool arch_livepatch_verify_alignment(const struct livepatch_elf_sec *sec)
+{
+/* Unaligned access on ARM 64 is OK. */
+return true;
+}
+
 enum aarch64_reloc_op {
 RELOC_OP_NONE,
 RELOC_OP_ABS,
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 406eb910cc..48d20fdacd 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -148,6 +148,12 @@ bool arch_livepatch_symbol_deny(const struct livepatch_elf 
*elf,
 return false;
 }
 
+bool arch_livepatch_verify_alignment(const struct livepatch_elf_sec *sec)
+{
+/* Unaligned access on x86 is fine. */
+return true;
+}
+
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index c6ee95fbcf..dbab8a3f6f 100644
-

[Xen-devel] [PATCH v3 08/17] livepatch/tests: Make sure all .livepatch.funcs sections are read-only

[Konrad Rzeszutek Wilk]

Instead of being writable (.data). This mimics the behavior of what
livepatch-build-tools do.

Other approaches such as 'struct const livepatch_funcs' still result
in the WA section attributes.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/test/livepatch/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 9e73861732..6e5b9a3a75 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -54,6 +54,7 @@ xen_hello_world.o: config.h livepatch_depends.h
 $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH) $^
$(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@
+   $(OBJCOPY) --set-section-flags .livepatch.funcs=alloc,readonly $@
 
 #
 # This target is only accessible if CONFIG_LIVEPATCH is defined, which
@@ -90,6 +91,7 @@ xen_bye_world.o: config.h hello_world_livepatch_depends.h
 $(LIVEPATCH_BYE): xen_bye_world_func.o xen_bye_world.o
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_BYE) $^
$(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@
+   $(OBJCOPY) --set-section-flags .livepatch.funcs=alloc,readonly $@
 
 xen_replace_world.o: config.h livepatch_depends.h
 
@@ -97,6 +99,7 @@ xen_replace_world.o: config.h livepatch_depends.h
 $(LIVEPATCH_REPLACE): xen_replace_world_func.o xen_replace_world.o
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_REPLACE) $^
$(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@
+   $(OBJCOPY) --set-section-flags .livepatch.funcs=alloc,readonly $@
 
 xen_nop.o: config.h livepatch_depends.h
 
@@ -104,6 +107,7 @@ xen_nop.o: config.h livepatch_depends.h
 $(LIVEPATCH_NOP): xen_nop.o
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_NOP) $^
$(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@
+   $(OBJCOPY) --set-section-flags .livepatch.funcs=alloc,readonly $@
 
 .PHONY: livepatch
 livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE) $(LIVEPATCH_NOP)
-- 
2.13.3


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

[Xen-devel] [PATCH v3 06/17] xen/livepatch/x86/arm32: Force .livepatch.depends section to be uint32_t aligned.

[Konrad Rzeszutek Wilk]

By default when using objcopy we lose the alignment when we copy it from 
xen-syms -
with the result that alignment (on ARM32 for example) can be 1:

  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf Al
..
  [ 6] .livepatch.depend PROGBITS 93 24 00   A  0   0  1

That, combined with wacky offset means it will be loaded in
memory with the wrong alignment:

(XEN) livepatch.c:425: livepatch: xen_bye_world: Loaded .livepatch.depends at 
000a08043

And later we get:
(XEN) livepatch.c:501: livepatch: xen_bye_world: .livepatch.depends is not 
aligned properly!

This fix forces all the test-cases to be built with a
.livepatch.depends structure containing the build-id extracted from
the hypervisor (except the xen_bye_world test-case).

We use the 'mkhex' tool instead of 'xxd' as the end result is an 'unsigned'
instead of 'char' type array - which naturally forces the alignment to be of 
four.
Also the 'mkhex' tools allows us to pass the section name as parameter.

The end result is much better alignment:

  [ 7] .livepatch.depend PROGBITS 94 24 00   A  0   0  4

Note that thanks to 'unsigned int .. __note_depends' the symbol becomes
global:

$ readelf --symbols *.livepatch | grep depen
23: 36 OBJECT  GLOBAL HIDDEN 6 note_depends
49: 36 OBJECT  GLOBAL HIDDEN17 note_depends
16: 36 OBJECT  GLOBAL HIDDEN 3 note_depends
21: 36 OBJECT  GLOBAL HIDDEN 6 note_depends

See patch titled: "livepatch/arm/x86: Strip note_depends symbol from 
test-cases."
which fixes this.

Signed-off-by: Konrad Rzeszutek Wilk 

---
v2: First version
---
 docs/misc/livepatch.markdown   |  2 ++
 xen/test/livepatch/Makefile| 56 +++---
 xen/test/livepatch/xen_bye_world.c |  1 +
 xen/test/livepatch/xen_hello_world.c   |  1 +
 xen/test/livepatch/xen_nop.c   |  1 +
 xen/test/livepatch/xen_replace_world.c |  1 +
 6 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 505dc37cda..922a64436f 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -430,6 +430,8 @@ checksum, MD5 checksum or any unique value.
 
 The size of these structures varies with the --build-id linker option.
 
+On ARM32 this section must by four-byte aligned.
+
 ## Hypercalls
 
 We will employ the sub operations of the system management hypercall (sysctl).
diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 6831383db1..89ad89dfd5 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -1,15 +1,7 @@
 include $(XEN_ROOT)/Config.mk
 
-ifeq ($(XEN_TARGET_ARCH),x86_64)
-OBJCOPY_MAGIC := -I binary -O elf64-x86-64 -B i386:x86-64
-endif
-ifeq ($(XEN_TARGET_ARCH),arm64)
-OBJCOPY_MAGIC := -I binary -O elf64-littleaarch64 -B aarch64
-endif
-ifeq ($(XEN_TARGET_ARCH),arm32)
-OBJCOPY_MAGIC := -I binary -O elf32-littlearm -B arm
-endif
-
+NOTE_SYMBOL = "note_depends"
+NOTE_DEPENDS = "const  __section(\".livepatch.depends\") $(NOTE_SYMBOL)"
 CODE_ADDR=$(shell nm --defined $(1) | grep $(2) | awk '{print "0x"$$1}')
 CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')
 
@@ -38,7 +30,7 @@ uninstall:
 
 .PHONY: clean
 clean::
-   rm -f *.o .*.o.d *.livepatch config.h
+   rm -f *.o .*.o.d *.livepatch config.h livepatch_depends.h 
hello_world_livepatch_depends.h *.bin
 
 #
 # To compute these values we need the binary files: xen-syms
@@ -56,10 +48,10 @@ config.h: xen_hello_world_func.o
 echo "#define MINOR_VERSION_ADDR $(MINOR_VERSION_ADDR)"; \
 echo "#define OLD_CODE_SZ $(OLD_CODE_SZ)") > $@
 
-xen_hello_world.o: config.h
+xen_hello_world.o: config.h livepatch_depends.h
 
 .PHONY: $(LIVEPATCH)
-$(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o note.o
+$(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH) $^
 
 #
@@ -71,40 +63,42 @@ $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o 
note.o
 # not be built (it is for EFI builds), and that we do not have
 # the note.o.bin to muck with (as it gets deleted)
 #
-.PHONY: note.o
-note.o:
-   $(OBJCOPY) -O binary --only-section=.note.gnu.build-id 
$(BASEDIR)/xen-syms $@.bin
-   $(OBJCOPY) $(OBJCOPY_MAGIC) \
-  
--rename-section=.data=.livepatch.depends,alloc,load,readonly,data,contents -S 
$@.bin $@
-   rm -f $@.bin
+.PHONY: note.bin
+note.bin:
+   $(OBJCOPY) -O binary --only-section=.note.gnu.build-id 
$(BASEDIR)/xen-syms $@
+
+.PHONY: livepatch_depends.h
+livepatch_depends.h: note.bin
+   $(shell (../../../tools/firmware/hvmloader/mkhex $(NOTE_DEPENDS) $^ > 
$@))
 
 #
 # Extract the build-id of the xen_hello_world.livepatch
 # (which xen_bye_world will depend on).
 #
-.PHONY: hello_world_note.o
-hello_world_note.o: $(LIVE

[Xen-devel] [PATCH v3 16/17] livepatch: Add local and global symbol resolution.

[Konrad Rzeszutek Wilk]

This way we can load livepatches with symbol names that
are the same as long as they are local ('static').

The use case here is to replace an existing livepatch
with a newer one - and one which has the same local symbols.

Without this patch we get:
livepatch.c:819: livepatch: xen_local_symbols: duplicate new symbol: revert_hook

when loading the new livepatch (before doing the replace).

This due to livepatch assuming that all symbols are all
global. With this patch:

readelf --symbols xen_hello_world.livepatch
File: xen_hello_world.livepatch

Symbol table '.symtab' contains 55 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
..snip..
34:  4 OBJECT  LOCAL  DEFAULT   25 cnt
35: 000a 8 OBJECT  LOCAL  DEFAULT7 __func__.4654
36: 006523 FUNCLOCAL  DEFAULT2 revert_hook
37: 007c23 FUNCLOCAL  DEFAULT2 apply_hook
38: 009354 FUNCLOCAL  DEFAULT2 check_fnc
..snip..

47: 54 FUNCGLOBAL HIDDEN 2 xen_hello_world
48:  0 NOTYPE  GLOBAL HIDDEN   UND xen_extra_version
..snip..
52:  0 NOTYPE  GLOBAL HIDDEN   UND printk
53: 64 OBJECT  GLOBAL HIDDEN23 
livepatch_xen_hello_world

All the 'GLOBAL' have to be unique per livepatch. But the
'LOCAL' can all be the same which means the semantic of 'static'
on functions and data variables is the right one.

Signed-off-by: Konrad Rzeszutek Wilk 
---
v1: New version
v2: No changes
---
 xen/common/livepatch.c  | 21 ++---
 xen/include/xen/livepatch.h |  3 ++-
 xen/include/xen/livepatch_elf.h |  7 +++
 3 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 2526d3a0ca..5cfce1f2ee 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -187,7 +187,10 @@ unsigned long livepatch_symbols_lookup_by_name(const char 
*symname)
 if ( !data->symtab[i].new_symbol )
 continue;
 
-if ( !strcmp(data->symtab[i].name, symname) )
+if ( strcmp(data->symtab[i].name, symname) )
+continue;
+
+if ( data->symtab[i].global_symbol )
 return data->symtab[i].value;
 }
 }
@@ -804,6 +807,7 @@ static int build_symbol_table(struct payload *payload,
 symtab[nsyms].size = elf->sym[i].sym->st_size;
 symtab[nsyms].value = elf->sym[i].sym->st_value;
 symtab[nsyms].new_symbol = 0; /* May be overwritten below. */
+symtab[nsyms].global_symbol = 
livepatch_sym_is_global(elf->sym[i].sym);
 strtab_len += strlcpy(strtab + strtab_len, elf->sym[i].name,
   KSYM_NAME_LEN) + 1;
 nsyms++;
@@ -828,21 +832,24 @@ static int build_symbol_table(struct payload *payload,
 if ( symbols_lookup_by_name(symtab[i].name) ||
  livepatch_symbols_lookup_by_name(symtab[i].name) )
 {
-dprintk(XENLOG_ERR, LIVEPATCH "%s: duplicate new symbol: %s\n",
-elf->name, symtab[i].name);
+dprintk(XENLOG_ERR, LIVEPATCH "%s: duplicate new %s symbol: 
%s\n",
+elf->name, symtab[i].global_symbol ? "global" : 
"local",
+symtab[i].name);
 xfree(symtab);
 xfree(strtab);
 return -EEXIST;
 }
 symtab[i].new_symbol = 1;
-dprintk(XENLOG_DEBUG, LIVEPATCH "%s: new symbol %s\n",
- elf->name, symtab[i].name);
+dprintk(XENLOG_DEBUG, LIVEPATCH "%s: new %s symbol %s\n",
+ elf->name, symtab[i].global_symbol ? "global" : "local",
+ symtab[i].name);
 }
 else
 {
 /* new_symbol is not set. */
-dprintk(XENLOG_DEBUG, LIVEPATCH "%s: overriding symbol %s\n",
-elf->name, symtab[i].name);
+dprintk(XENLOG_DEBUG, LIVEPATCH "%s: overriding %s symbol %s\n",
+elf->name, symtab[i].global_symbol ? "global" : "local",
+symtab[i].name);
 }
 }
 
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index e529f0e7c3..2f2d3f63e8 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -38,7 +38,8 @@ struct livepatch_symbol {
 const char *name;
 unsigned long value;
 unsigned int size;
-bool_t new_symbol;
+unsigned int new_symbol:1;
+unsigned int global_symbol:1;
 };
 
 int livepatch_op(struct xen_sysctl_livepatch_op *);
diff --git a/xen/include/xen/livepatch_elf.h b/xen/include/xen/livepatch_elf.h
index 9ad499ee8b..4d443be1c0 100644
--- a/xen/include/xen/livepatch_elf.h
+++ b/xen/include/xen/livepatch_elf.h
@@ -50,6 +50,13 @@ static inline bool livepat

[Xen-devel] [PATCH v3 15/17] livepatch/x86/arm: Utilize the arch_livepatch_lookup_mfn

[Konrad Rzeszutek Wilk]

Without this patch on x86 we would get a DOUBLE FAULT
as the virt_to_mfn does not lookup virtual addresses
that are in vmap region. This means that the livepatch_vmap.funcs
would point to an incorrect MFN (with either garbage or all
zeros).

We only use the livepatch_vmap.funcs to save the old contents
of the instruction (f->opaque) so during patching all works fine.

But when we revert and copy the contents of f->opaque we would
either get the right values, or zeros (again, depending on where the
MFN is) - and then starting instructions in the unpatched function
would end up with  .. causing a double fault.

Using the arch_livepatch_lookup_mfn solves the problem and
the applying/reverting works on all platforms properly.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/common/livepatch.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 2f5ee1ae75..2526d3a0ca 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1073,7 +1073,10 @@ static int livepatch_quiesce(struct livepatch_func 
*funcs, unsigned int nfuncs)
 if ( livepatch_vmap.text || livepatch_vmap.funcs )
 return -EINVAL;
 
-text_mfn = _mfn(virt_to_mfn(_start));
+text_mfn = arch_livepatch_lookup_mfn((unsigned long)_start);
+if ( mfn_eq(text_mfn, INVALID_MFN) )
+return -EINVAL;
+
 text_order = get_order_from_bytes(_end - _start);
 
 /*
@@ -1093,7 +1096,14 @@ static int livepatch_quiesce(struct livepatch_func 
*funcs, unsigned int nfuncs)
 livepatch_vmap.text = vmap_addr;
 livepatch_vmap.offset = offs;
 
-rodata_mfn = _mfn(virt_to_mfn(va & PAGE_MASK));
+rodata_mfn = arch_livepatch_lookup_mfn(va & PAGE_MASK);
+if ( mfn_eq(rodata_mfn, INVALID_MFN) )
+{
+vunmap(livepatch_vmap.text);
+livepatch_vmap.text = NULL;
+return -EINVAL;
+}
+
 vmap_addr  = __vmap(&rodata_mfn, size, 1, 1, PAGE_HYPERVISOR, 
VMAP_DEFAULT);
 if ( !vmap_addr )
 {
-- 
2.13.3


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

[Xen-devel] [PATCH v3 14/17] livepatch/x86/arm: arch/x86/mm: generalize do_page_walk() and implement arch_livepatch_lookup_mfn

[Konrad Rzeszutek Wilk]

With this change we can use _do_page_walk() to implement
arch_livepatch_lookup_mfn() which can be used to find out
vmap virtual addresses (as under x86 virt_to_mfn won't work
for vmap, but it does for arm!).

Signed-off-by: Blaise Boscaccy 
Signed-off-by: Vegard Nossum 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/arch/arm/livepatch.c|  7 ---
 xen/arch/x86/livepatch.c| 10 ++
 xen/arch/x86/x86_64/mm.c| 33 -
 xen/include/asm-x86/mm.h|  1 +
 xen/include/xen/livepatch.h |  3 +++
 5 files changed, 42 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index e1d5d58f97..1771b3c558 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -13,9 +13,10 @@
 #include 
 #include 
 
-/* Override macros from asm/page.h to make them work with mfn_t */
-#undef virt_to_mfn
-#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
+mfn_t arch_livepatch_lookup_mfn(unsigned long addr)
+{
+return _mfn(__virt_to_mfn(addr));
+}
 
 void arch_livepatch_revive(void)
 {
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 12287d445f..667573c6de 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -14,6 +14,16 @@
 #include 
 #include 
 
+mfn_t arch_livepatch_lookup_mfn(unsigned long addr)
+{
+unsigned long cr3 = read_cr3() >> PAGE_SHIFT;
+
+if ( !mfn_valid(_mfn(cr3)) )
+return INVALID_MFN;
+
+return _do_page_walk(cr3, addr);
+}
+
 void arch_livepatch_revive(void)
 {
 /* Nothing to do. */
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 11746730b4..f8a963bbba 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -44,29 +44,28 @@ unsigned int __read_mostly m2p_compat_vstart = 
__HYPERVISOR_COMPAT_VIRT_START;
 
 l2_pgentry_t *compat_idle_pg_table_l2;
 
-void *do_page_walk(struct vcpu *v, unsigned long addr)
+mfn_t _do_page_walk(unsigned long mfn, unsigned long addr)
 {
-unsigned long mfn = pagetable_get_pfn(v->arch.guest_table);
 l4_pgentry_t l4e, *l4t;
 l3_pgentry_t l3e, *l3t;
 l2_pgentry_t l2e, *l2t;
 l1_pgentry_t l1e, *l1t;
 
-if ( !is_pv_vcpu(v) || !is_canonical_address(addr) )
-return NULL;
+if ( !is_canonical_address(addr) )
+return INVALID_MFN;
 
 l4t = map_domain_page(_mfn(mfn));
 l4e = l4t[l4_table_offset(addr)];
 unmap_domain_page(l4t);
 if ( !(l4e_get_flags(l4e) & _PAGE_PRESENT) )
-return NULL;
+return INVALID_MFN;
 
 l3t = map_l3t_from_l4e(l4e);
 l3e = l3t[l3_table_offset(addr)];
 unmap_domain_page(l3t);
 mfn = l3e_get_pfn(l3e);
 if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) || !mfn_valid(_mfn(mfn)) )
-return NULL;
+return INVALID_MFN;
 if ( (l3e_get_flags(l3e) & _PAGE_PSE) )
 {
 mfn += PFN_DOWN(addr & ((1UL << L3_PAGETABLE_SHIFT) - 1));
@@ -78,7 +77,7 @@ void *do_page_walk(struct vcpu *v, unsigned long addr)
 unmap_domain_page(l2t);
 mfn = l2e_get_pfn(l2e);
 if ( !(l2e_get_flags(l2e) & _PAGE_PRESENT) || !mfn_valid(_mfn(mfn)) )
-return NULL;
+return INVALID_MFN;
 if ( (l2e_get_flags(l2e) & _PAGE_PSE) )
 {
 mfn += PFN_DOWN(addr & ((1UL << L2_PAGETABLE_SHIFT) - 1));
@@ -90,10 +89,26 @@ void *do_page_walk(struct vcpu *v, unsigned long addr)
 unmap_domain_page(l1t);
 mfn = l1e_get_pfn(l1e);
 if ( !(l1e_get_flags(l1e) & _PAGE_PRESENT) || !mfn_valid(_mfn(mfn)) )
-return NULL;
+return INVALID_MFN;
 
  ret:
-return map_domain_page(_mfn(mfn)) + (addr & ~PAGE_MASK);
+return _mfn(mfn);
+}
+
+void *do_page_walk(struct vcpu *v, unsigned long addr)
+{
+mfn_t mfn;
+unsigned long cr3;
+
+if ( !is_pv_vcpu(v) )
+return NULL;
+
+cr3 = pagetable_get_pfn(v->arch.guest_table);
+mfn = _do_page_walk(cr3, addr);
+if ( mfn_eq(mfn, INVALID_MFN) )
+return NULL;
+
+return map_domain_page(mfn) + (addr & ~PAGE_MASK);
 }
 
 /*
diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
index bef45e8e9f..224a94494a 100644
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -540,6 +540,7 @@ int new_guest_cr3(mfn_t mfn);
 void make_cr3(struct vcpu *v, mfn_t mfn);
 void update_cr3(struct vcpu *v);
 int vcpu_destroy_pagetables(struct vcpu *);
+mfn_t _do_page_walk(unsigned long mfn, unsigned long addr);
 void *do_page_walk(struct vcpu *v, unsigned long addr);
 
 int __sync_local_execstate(void);
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 065c1a323a..e529f0e7c3 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -72,6 +72,9 @@ int arch_livepatch_secure(const void *va, unsigned int pages, 
enum va_type types
 
 void arch_livepatch_init(void);
 
+#include  /* For mfn_t decleration. */
+mfn_t arch_livepatch_lookup_mfn(unsigned long addr);
+
 #include  /* For struct livepatch_func. */
 #include 
 int arch_livepatch_verify_func(const

[Xen-devel] [PATCH v3 05/17] alternative/x86/arm32: Align altinstructions (and altinstr_replacement) sections.

[Konrad Rzeszutek Wilk]

This is very similar to 137c59b9ff3f7a214f03b52d9c00a0a02374af1f
"bug/x86/arm: Align bug_frames sections."

On ARM and on x86 the C and assembler macros don't include
any alignment information - hence they end up being the default
byte granularity.

On ARM32 it is paramount that the alignment is word-size (4)
otherwise if one tries to use (uint32_t*) access (such
as livepatch ELF relocations) we get a Data Abort.

Specifically this issue was observed on ARM32 with a cross compiler for
the livepatches. Mainly the livepatches .data section size was not
padded to the section alignment:

ARM32 native:
Contents of section .rodata:
  68695f66 756e6300 63686563 6b5f666e  hi_func.check_fn
 0010 6300 78656e5f 65787472 615f7665  c...xen_extra_ve
 0020 7273696f 6e00rsion...

ARM32 cross compiler:
Contents of section .rodata:
  68695f66 756e6300 63686563 6b5f666e  hi_func.check_fn
 0010 6300 78656e5f 65787472 615f7665  c...xen_extra_ve
 0020 7273696f 6e00rsion.

And when we loaded it the next section would be put right behind it:

native:

(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .text at 00a02000
(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .rodata at 00a04024
(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .altinstructions at 
00a0404c

cross compiler:
(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .text at 00a02000
(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .rodata at 00a04024
(XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .altinstructions at 
00a0404a

(See 4a vs 4c)

native readelf:
  [ 4] .rodata   PROGBITS 000164 28 00   A  0   0  4
  [ 5] .altinstructions  PROGBITS 00018c 0c 00   A  0   0  1

cross compiler readelf --sections:
  [ 4] .rodata   PROGBITS 000164 26 00   A  0   0  4
  [ 5] .altinstructions  PROGBITS 00018a 0c 00   A  0   0  1

And as can be seen the .altinstructions have alignment of 1 which from
'man elf' is: "Values of zero and one mean no alignment is required."
which means we can ignore it.

Enforcing .altinstructions (and also .altinstr_replacement for
completness on ARM) to have the proper alignment across all
architectures and in both C and x86 makes them all the same.

On x86 the bloat-o-meter detects that with this change the file shrinks:
add/remove: 1/0 grow/shrink: 0/2 up/down: 156/-367 (-211)
function old new   delta
get_page_from_gfn  - 156+156
do_mmu_update   45784569  -9
do_mmuext_op56045246-358
Total: Before=3170439, After=3170228, chg -0.01%

But as found adding even "#Hi!\n" will casue this optimization, so the
bloat-o-meter value here is useless.

While on ARM 32/64:
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
function old new   delta
Total: Before=822563, After=822563, chg +0.00%

Also since the macros have the alignment coded in them there is no need
to do that for the xen.lds.S anymore.

Signed-off-by: Konrad Rzeszutek Wilk 
---
v2: - First version
v3: - Figured out the x86 bloat-o-meter results.
- Removed the .ALIGN from xen.lds.S
- Removed the .p2align on .altinstr_replacement per Jan's request.
- Put most of the commit description for the original issue
---
 xen/arch/arm/xen.lds.S| 2 --
 xen/arch/x86/xen.lds.S| 1 -
 xen/include/asm-arm/alternative.h | 4 
 xen/include/asm-x86/alternative.h | 1 +
 4 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index c9b9546435..447d33888f 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -155,11 +155,9 @@ SECTIONS
__initcall_end = .;
 
 #ifdef CONFIG_HAS_ALTERNATIVE
-   . = ALIGN(4);
__alt_instructions = .;
*(.altinstructions)
__alt_instructions_end = .;
-   . = ALIGN(4);
*(.altinstr_replacement)
 #endif
 
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d5e8821d41..9eb42048d5 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -202,7 +202,6 @@ SECTIONS
 * "Alternative instructions for different CPU types or capabilities"
 * Think locking instructions on spinlocks.
 */
-   . = ALIGN(8);
 __alt_instructions = .;
 *(.altinstructions)
 __alt_instructions_end = .;
diff --git a/xen/include/asm-arm/alternative.h 
b/xen/include/asm-arm/alternative.h
index 6cc9d0dc5f..cd1373fdd5 100644
--- a/xen/include/asm-arm/alternative.h
+++ b/xen/include/asm-arm/alternative.h
@@ -54,9 +54,11 @@ int apply_alternatives(const struct alt_instr *start, const 
struct alt_instr *en
oldinstr "\n"   \
"662:\n"   

[Xen-devel] [ovmf test] 113333: regressions - FAIL

[osstest service owner]

flight 11 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/11/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 113143
 build-amd64-xsm   6 xen-buildfail REGR. vs. 113143
 build-i386-xsm6 xen-buildfail REGR. vs. 113143
 build-i3866 xen-buildfail REGR. vs. 113143

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf 5dfba97c4d59613581f6fcc039846ff5c5817b1f
baseline version:
 ovmf 3281ebb4ae7de2a858c2e7ec4998b7e55be1a4dc

Last test of basis   113143  2017-09-08 06:17:14 Z3 days
Failing since113156  2017-09-08 19:17:56 Z3 days   21 attempts
Testing same since   11  2017-09-11 20:49:47 Z0 days1 attempts


People who touched revisions under test:
  Brijesh Singh 
  Laszlo Ersek 
  Paulo Alcantara 
  Star Zeng 
  Thomas Lamprecht 
  Yonghong Zhu 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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.

(No revision log; it would be 694 lines long.)

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

Re: [Xen-devel] [PATCH v2 3/5] xen/livepatch/ARM32: Don't load and crash on livepatches loaded with wrong alignment.

[Konrad Rzeszutek Wilk]

On Mon, Sep 11, 2017 at 03:01:15AM -0600, Jan Beulich wrote:
> >>> On 09.09.17 at 14:05,  wrote:
> > On Fri, Sep 08, 2017 at 03:30:07AM -0600, Jan Beulich wrote:
> >> >>> On 07.09.17 at 19:36,  wrote:
> >> > On Wed, Aug 02, 2017 at 03:20:05AM -0600, Jan Beulich wrote:
> >> >> >>> Konrad Rzeszutek Wilk  07/31/17 6:04 PM >>>
> >> >> >On Mon, Jul 31, 2017 at 07:55:34AM -0600, Jan Beulich wrote:
> >> >> >> >>> Konrad Rzeszutek Wilk  07/26/17 9:50 PM >>>
> >> >> >> >--- a/docs/misc/livepatch.markdown
> >> >> >> >+++ b/docs/misc/livepatch.markdown
> >> >> >> >@@ -279,6 +279,10 @@ It may also have some architecture-specific 
> >> >> >> >sections. 
> >> > For example:
> >> >> >> >* Exception tables.
> >> >> >> >* Relocations for each of these sections.
> >> >> >>  >
> >> >> >> >+Note that on ARM 32 the sections SHOULD be four byte aligned. 
> >> >> >> >Otherwise
> >> >> >> >+we risk hitting Data Abort exception as un-aligned manipulation of 
> >> >> >> >data is
> >> >> >> >+prohibited on ARM 32.
> >> >> >> 
> >> >> >> This (and hence the rest of the patch) is not in line with the 
> >> >> >> outcome of 
> >> > the
> >> >> >> earlier discussion we had. Nothing is wrong with a section having 
> >> >> >> smaller
> >> >> >> alignment, as long as there are no 32-bit (or wider, but I don't 
> >> >> >> think 
> > there
> >> >> >> are any such) relocations against such a section. And even if there 
> >> >> >> were, 
> > I
> >> >> >> think it should rather be the code doing the relocations needing to 
> >> >> >> cope, 
> >> > as
> >> >> >> I don't think the ARM ELF ABI imposes any such restriction.
> >> >> >
> >> >> >The idea behind this patch is to give advance warnings. Akin to what
> >> >> >2ff229643b739e2fd0cd0536ee9fca506cfa92f8
> >> >> >"xen/livepatch: Don't crash on encountering STN_UNDEF relocations" did.
> >> >> >
> >> >> >The other patches in this series fix the alignment issues.
> >> >> >
> >> >> >The ARM ELF ABI 
> >> > 
> > (http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf
> >  
> > 
> >> > )
> >> >> >
> >> >> >says:
> >> >> >
> >> >> >4.3.5 Section Alignment
> >> >> >There is no minimum alignment required for a section. However, 
> >> >> >sections 
> >> > containing thumb code must be at least
> >> >> >16-bit aligned and sections containing ARM code must be at least 
> >> >> >32-bit 
> >> > aligned.
> >> >> >Platform standards may set a limit on the maximum alignment that they 
> >> >> >can 
> >> > guarantee (normally the page size).
> >> >> 
> >> >> Note the "thumb code" and "ARM code" in here - iirc you're checking 
> >> >> _all_
> >> >> sections, not just ones containing code.
> >> > 
> >> > I can fix the code to only do the check for 'X' ones:
> >> > 
> >> >   [ 2] .text PROGBITS   0070
> >> >00ca    AX   0 0 16
> >> >   [ 4] .altinstr_replace PROGBITS   013c
> >> >000b    AX   0 0 4
> >> >   [ 5] .fixupPROGBITS   0147
> >> >000d    AX   0 0 1
> >> > 
> >> > 
> >> > And also have the check in the relocation - which right now are
> >> > 32-bit: R_ARM_ABS32, R_ARM_REL32, R_ARM_MOVW_ABS_NC, R_ARM_MOVT_ABS,
> >> > R_ARM_CALL, R_ARM_JUMP24 so will leave the code as in
> >> > arch_livepatch_perform.
> >> 
> >> Relocations applicable to code only _may_ be acceptable to have
> >> such an alignment check (but I could see cases where even that
> >> might be too aggressive), but afaik R_ARM_ABS32 isn't a code
> >> only one (out of the set listed above), so I doubt this should have
> >> an alignment check.
> >> 
> >> > But neither one of those is going to help in catching livepatches
> >> > that have the wrong alignment without relocations and not executable.
> >> > For example .livepatch.depends
> >> 
> >> What does "wrong alignment" mean when there's no code involved?
> > 
> > Anything which we try to access as a structure, or unsigned int,
> > that is not aligned to four bytes.
> > 
> > For example accessing .livepatch.depends from memory and blowing
> > up (hypervisor crashes) b/c it does not start at an four byte aligned
> > location.
> 
> Hmm, as long as the relocation isn't required to be against aligned
> fields only (mandated by the processor ABI) I think the code doing
> the relocations would instead need to split the access, rather than
> calling the section misaligned or increasing alignment beyond what
> the ELF section headers say.

Maybe the serial log would explain this better:

xend_config_format : 4
Executing: '(set -e;cd /root/test/livepatch;xen-livepatch load 
xen_bye_world.livepatch)' ..(XEN) livepatch.c:413: livepatch: xen_bye_world: 
Loaded .note.gnu.build-id at 00a08000
(XEN) livepatch.c:413: livepatch: xen_bye_world: Loaded .text at 00a06000
(XEN) livepatch.c:413: livepatch: xen_bye_world: Loaded .rodata at 00a080

Re: [Xen-devel] [PATCH v2 11/13] xen/pvcalls: implement release command

[Stefano Stabellini]

On Tue, 1 Aug 2017, Juergen Gross wrote:
>  +if (sock->sk == NULL)
>  +return 0;
>  +
>  +map = (struct sock_mapping *) READ_ONCE(sock->sk->sk_send_head);
>  +if (map == NULL)
>  +return 0;
>  +
>  +spin_lock(&bedata->pvcallss_lock);
>  +req_id = bedata->ring.req_prod_pvt & (RING_SIZE(&bedata->ring) 
>  - 1);
>  +if (RING_FULL(&bedata->ring) ||
>  +READ_ONCE(bedata->rsp[req_id].req_id) != 
>  PVCALLS_INVALID_ID) {
>  +spin_unlock(&bedata->pvcallss_lock);
>  +return -EAGAIN;
>  +}
>  +WRITE_ONCE(sock->sk->sk_send_head, NULL);
>  +
>  +req = RING_GET_REQUEST(&bedata->ring, req_id);
>  +req->req_id = req_id;
>  +req->cmd = PVCALLS_RELEASE;
>  +req->u.release.id = (uint64_t)sock;
>  +
>  +bedata->ring.req_prod_pvt++;
>  +RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&bedata->ring, notify);
>  +spin_unlock(&bedata->pvcallss_lock);
>  +if (notify)
>  +notify_remote_via_irq(bedata->irq);
>  +
>  +wait_event(bedata->inflight_req,
>  +READ_ONCE(bedata->rsp[req_id].req_id) == req_id);
>  +
>  +if (map->active_socket) {
>  +/* 
>  + * Set in_error and wake up inflight_conn_req to force
>  + * recvmsg waiters to exit.
>  + */
>  +map->active.ring->in_error = -EBADF;
>  +wake_up_interruptible(&map->active.inflight_conn_req);
>  +
>  +mutex_lock(&map->active.in_mutex);
>  +mutex_lock(&map->active.out_mutex);
>  +pvcalls_front_free_map(bedata, map);
>  +mutex_unlock(&map->active.out_mutex);
>  +mutex_unlock(&map->active.in_mutex);
>  +kfree(map);
> >>> Since you are locking here I assume you expect that someone else might
> >>> also be trying to lock the map. But you are freeing it immediately after
> >>> unlocking. Wouldn't that mean that whoever is trying to grab the lock
> >>> might then dereference freed memory?
> >> The lock is to make sure there are no recvmsg or sendmsg in progress. We
> >> are sure that no newer sendmsg or recvmsg are waiting for
> >> pvcalls_front_release to release the lock because before send a message
> >> to the backend we set sk_send_head to NULL.
> > 
> > Is there a chance that whoever is potentially calling send/rcvmsg has
> > checked that sk_send_head is non-NULL but hasn't grabbed the lock yet?
> > 
> > Freeing a structure containing a lock right after releasing the lock
> > looks weird (to me). Is there any other way to synchronize with
> > sender/receiver? Any other lock?
> 
> Right. This looks fishy. Either you don't need the locks or you can't
> just free the area right after releasing the lock.

I changed this code, you'll see soon in the new patch series I am going
to send. There were two very similar mutex_unlock/kfree problems:

1) pvcalls_front_release
2) pvcalls_front_remove

For 2), I introduced a refcount. I only free the data structs when the
refcount reaches 0.

For 1), I could introduce a similar refcount that would serve the same
purpose, but instead I used mutex_trylock, effectively using the
internal count in in_mutex and out_mutex for the same purpose.

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

[Xen-devel] CONFIG_SCRUB_DEBUG=y + arm64 + livepatch = Xen BUG at page_alloc.c:738

[Konrad Rzeszutek Wilk]

Hey,

I've only been able to reproduce this on ARM64 (trying right now ARM32
as well), and not on x86.

If I compile Xen without CONFIG_SCRUB_DEBUG it works great. But if
enable it and try to load a livepatch it blows up in page_alloc.c:738

This is with origin/staging (d0291f3391)

The test-case (livepatch_test.pl) is
http://xenbits.xen.org/gitweb/?p=xentesttools/bootstrap.git;a=blob;f=root_image/debugspace/livepatch_test.pl

The serial log:

oader use UART6
scsysstat_value[8].
clear reset source
last_keypoint0,reboot_type0
secdbg not DCU.
SecDbgVer exit

 xloader chipid is: 0x36600110, start at 481ms.
Build Date: Jun  1 2017, 16:54:45
[clock_init] ++
hi3660 [clk_setup]
[clock_init] --
storage type is UFS
ufs retry: 6 count v_tx:0 v_rx:0
ufs set v_tx:0 v_rx:0
Hikey960[5301] no need avs_init.
ddr ft:0xf20332a3,mode:1 target:4
UceLdOk
ch 0 gt_errfail, STATUS:0x0060
ch 0 gdst_errfail, STATUS:0x0040
ch 1 gt_errfail, STATUS:0x0060
ch 1 gdst_errfail, STATUS:0x0040
ch 2 gt_errfail, STATUS:0x0060
ch 2 gdst_errfail, STATUS:0x0040
ch 3 gt_errfail, STATUS:0x0060
ch 3 gdst_errfail, STATUS:0x0040
timeout
timeout
timeout
timeout
density: 
0x0c0c0c0c,0x,0x0c0c0c0c,0x,0x0c0c0c0c,0x,0x0c0c0c0c,0x
 
ddr info 0x0306 
400M
685M
1067M
C0R,V0x002c e:113
C1R,V0x002d e:66
C2R,V0x002c e:66
C3R,V0x002d e:66
C0R,V0x002d e:66
C1R,V0x002e e:66
C2R,V0x002d e:66
C3R,V0x002e e:66
C0R,V0x002e e:66
C1R,V0x002f e:66
C2R,V0x002e e:66
C3R,V0x002f e:66
C0R,V0x002f e:66
C1R,V0x0030 e:65
C2R,V0x002f e:65
C3R,V0x0030 e:66
1244M
1866M
C0R,V0x0015 e:66
C2R,V0x0015 e:66
C0R,V0x0016 e:66
C1R,V0x0016 e:66
C2R,V0x0016 e:66
C3R,V0x0016 e:66
C0R,V0x0017 e:66
C1R,V0x0017 e:66
C2R,V0x0017 e:66
C3R,V0x0017 e:66
iomcu_subsys_init
boot_c0 PROFILE 4
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.4(release):v1.4-8-gca5ba394
NOTICE:  BL1: Built : 21:33:21, Jul 16 2017
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v1.4(release):v1.4-8-gca5ba394
NOTICE:  BL2: Built : 20:03:29, Jul 15 2017
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v1.4(release):v1.4-8-gca5ba394
NOTICE:  BL31: Built : 20:03:29, Jul 15 2017
UEFI firmware (version Alpha built at 20:02:58 on Jul 15 2017)
add-symbol-file 
/home/konrad/960/edk2/Build/HiKey960/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
 0xBF251000
Loading DxeCore at 0x00BF25 EntryPoint=0x00BF251000
add-symbol-file 
/home/konrad/960/edk2/Build/HiKey960/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
 0xBF251000
HOBLIST address in DXE = 0xBF00D018
Memory Allocation 0x0004 0xBFFE8000 - 0xBFFE8FFF
Memory Allocation 0x0004 0xBFFE7000 - 0xBFFE7FFF
Memory Allocation 0x0004 0xBFFE6000 - 0xBFFE6FFF
Memory Allocation 0x0004 0xBFFE5000 - 0xBFFE5FFF
Memory Allocation 0x0004 0xBFFE9000 - 0xBFFF
Memory Allocation 0x0004 0xBFFD5000 - 0xBFFE4FFF
Memory Allocation 0x0004 0xBF931000 - 0xBFFD4FFF
Memory Allocation 0x0004 0xBF28D000 - 0xBF930FFF
Memory Allocation 0x0004 0xBF25 - 0xBF28CFFF
Memory Allocation 0x0003 0xBF25 - 0xBF28CFFF
FV Hob0x1AC98000 - 0x1AD87FFF
FV Hob0xBF28D000 - 0xBF92FD3F
FV2 Hob   0xBF28D000 - 0xBF92FD3F
add-symbol-file 
/home/konrad/960/edk2/Build/HiKey960/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/PCD/Dxe/Pcd/DEBUG/PcdDxe.dll
 0xBF192000
Loading driver at 0x000BF191000 EntryPoint=0x000BF192048 PcdDxe.efi
add-symbol-file 
/home/konrad/960/edk2/Build/HiKey960/DEBUG_GCC5/AARCH64/ArmPkg/Drivers/CpuDxe/CpuDxe/DEBUG/ArmCpuDxe.dll
 0xBF182000
Loading driver at 0x000BF181000 EntryPoint=0x000BF182048 ArmCpuDxe.efi
add-symbol-file 
/home/konrad/960/edk2/Build/HiKey960/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/RuntimeDxe/RuntimeDxe/DEBUG/RuntimeDxe.dll
 0xBA19
Loading driver at 0x000BA18 EntryPoint=0x000BA190048 RuntimeDxe.efi
add-symbol-file 
/home/konrad/960/edk2/Build/HiKey960/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe/DEBUG/SecurityStubDxe.dll
 0xBF172000
Loading driver at 0x000BF171000 EntryPoint=0x000BF172048 SecurityStubDxe.efi
add-symbol-file 
/home/konrad/960/edk2/Build/HiKey960/DEBUG_GCC5/AARCH64/EmbeddedPkg/EmbeddedMonotonicCounter/EmbeddedMonotonicCounter/DEBUG/EmbeddedMonotonicCounter.dll
 0xBA0F
Loading driver at 0x000BA0E EntryPoint=0x000BA0F0048 
EmbeddedMonotonicCounter.efi
add-symbol-file 
/home/konrad/960/edk2/Build/HiKey960/DEBUG_GCC5/AARCH64/EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe/DEBUG/Reset.dll
 0xBA05
Loading driver at 0x000BA04 EntryPoint=0x000BA050048 Reset.efi
add-symbol-file 
/home/konrad/960/edk2/Build/HiKey960/DEBUG_GCC5/AARCH64/EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe/DEBUG/RealTimeClock.dll
 0xB9FB
Loading driver at 0x000B9FA EntryPoint=0x000B9FB0048 RealTimeClock.efi
add-symbol-file 
/home/konrad/960/edk2/Build/HiKey960/DEBUG_GCC5/AARCH64

[Xen-devel] [qemu-mainline test] 113302: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113179
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 113179
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113179
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113179
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113179
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail 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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass

version targeted for testing:
 qemuua6e8c1dacfd37d34542e33600dcc50b7683b735a
baseline version:
 qemuufcea73709b966a7ded9efa7b106ea50c7fe9025c

Last test of basis   113179  2017-09-09 21:47:42 Z2 days
Testing same since   113302  2017-09-11 10:18:16 Z0 days1 attempts


People who touched revisions under test:
  Kamil Rytarowski 
  Laurent Vivier 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 te

[Xen-devel] [ovmf bisection] complete build-i386-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build

Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
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:  ovmf https://github.com/tianocore/edk2.git
  Bug introduced:  f5566d1530e23fa09c1bf1616efc003f35135071
  Bug not present: 99c9b9490597d2ecdb9cbccd38fd4fdc9f44109a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/113343/


  commit f5566d1530e23fa09c1bf1616efc003f35135071
  Author: Paulo Alcantara 
  Date:   Fri Sep 8 09:41:48 2017 -0300
  
  OvmfPkg: Enable UDF file system support
  
  This patch enables UDF file system support by default.
  
  Cc: Jordan Justen 
  Cc: Laszlo Ersek 
  Contributed-under: TianoCore Contribution Agreement 1.1
  Signed-off-by: Paulo Alcantara 
  Reviewed-by: Laszlo Ersek 
  Reviewed-by: Ruiyu Ni 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/build-i386-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/ovmf/build-i386-xsm.xen-build 
--summary-out=tmp/113343.bisection-summary --basis-template=113143 
--blessings=real,real-bisect ovmf build-i386-xsm xen-build
Searching for failure / basis pass:
 113313 fail [host=nobling1] / 113143 [host=elbling1] 113130 [host=baroque1] 
113115 [host=huxelrebe0] 113078 [host=chardonnay0] 113061 [host=nobling0] 
113050 [host=huxelrebe1] 113045 [host=baroque1] 113037 [host=baroque1] 113029 
[host=huxelrebe0] 113005 [host=nobling0] 113000 [host=huxelrebe0] 112991 
[host=rimava0] 112986 [host=huxelrebe0] 112971 [host=chardonnay0] 112958 
[host=rimava0] 112947 [host=baroque1] 112919 [host=italia1] 112911 
[host=huxelrebe1] 112903 [host=huxelrebe0] 112899 [host=nobling0] 112883 
[host=huxelrebe1] 112878 [host=italia1] 112867 ok.
Failure / basis pass flights: 113313 / 112867
(tree with no url: minios)
(tree with no url: seabios)
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest aa9aa47e06ac0082948b880c226c8bdf2a12102b 
8051789e982499050680a26febeada7467e18a8d 
c349189772cec43498b0bec8a84146f10b8937af 
70892c317fd56064b09a4b0fcaa0781735e64efc
Basis pass 02739b0f41300da70369be7c1982180306e8ca95 
8051789e982499050680a26febeada7467e18a8d 
c7c6232bd304568d4da4bef521603aae0035e172 
9053a74c08fd6abf43bb45ff932b4386de7e8510
Generating revisions with ./adhoc-revtuple-generator  
https://github.com/tianocore/edk2.git#02739b0f41300da70369be7c1982180306e8ca95-aa9aa47e06ac0082948b880c226c8bdf2a12102b
 
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#c7c6232bd304568d4da4bef521603aae0035e172-c349189772cec43498b0bec8a84146f10b8937af
 
git://xenbits.xen.org/xen.git#9053a74c08fd6abf43bb45ff932b4386de7e8510-70892c317fd56064b09a4b0fcaa0781735e64efc
Loaded 8362 nodes in revision graph
Searching for test results:
 112867 pass 02739b0f41300da70369be7c1982180306e8ca95 
8051789e982499050680a26febeada7467e18a8d 
c7c6232bd304568d4da4bef521603aae0035e172 
9053a74c08fd6abf43bb45ff932b4386de7e8510
 112883 [host=huxelrebe1]
 112878 [host=italia1]
 112903 [host=huxelrebe0]
 112899 [host=nobling0]
 112919 [host=italia1]
 112911 [host=huxelrebe1]
 113005 [host=nobling0]
 112971 [host=chardonnay0]
 112958 [host=rimava0]
 112947 [host=baroque1]
 112986 [host=huxelrebe0]
 113000 [host=huxelrebe0]
 112991 [host=rimava0]
 113045 [host=baroque1]
 113029 [host=huxelrebe0]
 113037 [host=baroque1]
 113050 [host=huxelrebe1]
 113061 [host=nobling0]
 113069 [host=chardonnay0]
 113130 [host=baroque1]
 113078 [host=chardonnay0]
 113143 [host=elbling1]
 113115 [host=huxelrebe0]
 113156 [host=nobling0]
 113172 fail irrelevant
 113164 fail irrelevant
 113239 [host=nobling0]
 113225 fail 0e6be43fd3e9a6de4c036935787c1d037ff76888 
8051789e982499050680a26febeada7467e18a8d 
c349189772cec43498b0bec8a84146f10b8937af 
70892c317fd56064b09a4b0fcaa0781735e64efc
 113206 fail 0e6be43fd3e9a6de4c036935787c1d037ff76888 
8051789e982499050680a26febeada7467e18a8d 
c349189772cec43498b0bec8a84146f10b8937af 
70892c317fd56064b09a4b0fcaa0781735e64efc
 113229 fail 0e6be43fd3e9a6de4c036935787c1d037ff76888 
8051789e982499050680a26febeada7467e18a8d 
c349189772cec43498b0bec8a84146f10b8937af 
70892c317fd56064b09a4b0fcaa0781735e64efc
 113190 fail 0e6be43fd3e9a6de4c036935787c1d037ff76888 
8051789e982499050680a26febeada7467e18a8d 
c349189772cec43498b0bec8a84146f10b8937af 
70892c317fd56064b09a4b0fcaa0781735e64efc
 113215 fail 0e6be43fd3e9a6de4c036935787c1d037ff76888 
805

Re: [Xen-devel] [stage1-xen PATCH v1 06/10] build/fedora: Add `xen-unstable-runit/*` scripts

[Andrew Cooper]

On 11/09/2017 21:20, Stefano Stabellini wrote:
> On Sat, 9 Sep 2017, Rajiv Ranganath wrote:
>> On Thu, Sep 07 2017 at 12:10:21 AM, Stefano Stabellini 
>>  wrote:
>>
>> [...]
>>
>>> The series is much better now thank you. One question: why did you write
>>> your own init scripts rather than reusing xencommons (with the caveat
>>> that you would have to add make sure to source_path.sh before running
>>> xencommons)?  Does it have something to do with systemd?
>> There are a few related reasons for this.
>>
>> 1. Using runit lets us abstract out our dependency on systemd and
>> upstart. We can use the same abstraction in containers [1], virtual
>> machines and on bare metal.
>>
>> 2. In Linux distributions, there is tight coupling between package
>> management system (rpm/deb), init systems (upstart/systemd), and service
>> daemons.
>>
>> With containers, if the expectation is that most service daemons and
>> apps would be containerized, and managed by a node agent then a natural
>> question to ask would be what should be the role of init systems like
>> systemd?
>>
>> By using runit (on systemd, upstart and within containers), we defer
>> answering this question. 
>>
>> 3. One of the use cases that we want to support is to have different
>> versions of xen co-exist on the same filesystem. Then a higher level
>> tool can do rolling updates and if required rollbacks.
>>
>> While it is possible to accomplish this on existing init systems,
>> depending on how xen is packaged and deployed, it might involve using
>> distro package and repository management tools.
>>
>> With runit, we can use regular docker tools, which is much more friendly
>> for mainstream developers and CI systems. We also abstract over init
>> systems, which is a desirable property to have.
>>
>> 4. I looked into xencommons script and systemd unit files when creating
>> runit scripts. Our runit scripts is straightforward translation of how
>> one would start xen manually.
>>
>> Perhaps the only part of the script that might need some explanation is
>> in `xen-init-dom0/run`.
>>
>> ```
>> exec chpst -b xen-init-dom0 runit-pause
>> ```
>>
>> This is a pattern used to build equivalent of "oneshot" service in
>> systemd. It was developed in Ignite (a Arch Linux project before they
>> switched to systemd) and later co-opted by Void Linux [2].
>>
>> I am not sure if I answered your question. Sometimes I feel, maybe we
>> should just let questions around init systems be like one of those
>> "unanswered questions" in theology. :-) [3]
>>
>> Best,
>> Rajiv
>>
>> [1] https://github.com/lambda-linux/baseimage-amzn#adding_additional_daemons
>>
>> [2] 
>> https://github.com/voidlinux/void-runit/commit/7aecf46ec589a5bc49ae2392137bcd0e7468dd08
> Thank you for the pointers. I have no opinions on the format of the init
> scripts. runit is fine by me in that respect, and I understand the
> advantages you pointed out.
>
> My only concern is about diverging from the upstream Xen codebase. I
> think the runit scripts should call xencommons underneath. If xencommons
> cannot cope with being called from runit, we could make changes to
> xencommon in xen.git to make it so.
>
> Otherwise, we will end up in a situation such as:
> - xen.git changes xencommons
> - we don't notice
> - we upgrade Xen version
> - stage1-xen doesn't work anymore
>
> If we used xencommons underneath we would avoid this, and it looks like
> xencommons could be made to work well with runit.

If possible, upstream Xen should be made to be compatible with runit
(this would be the ideal case).  If not, upstream Xen should contain
different styles of these files, which are selected between by a
./configure option (this is suboptimal, but better than locally
forking).  This offers the greatest chance that updates to one don't
cause the other to be stale.

~Andrew

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

[Xen-devel] [PATCH 1/2] ARM: ACPI: IORT: Estimate the size of hardware domain IORT table

[mjaggi]

From: Manish Jaggi 

This patch estimates size of hardware domain IORT table by parsing all
the pcirc nodes and their idmaps, and thereby calculating size by
removing smmu nodes.

Hardware domain IORT table will have only ITS and PCIRC nodes, and PCIRC
nodes' idmap will have output refrences to ITS group nodes.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/acpi/Makefile  |   1 +
 xen/arch/arm/acpi/iort.c| 242 
 xen/arch/arm/domain_build.c |  11 +-
 xen/include/asm-arm/iort.h  |  14 +++
 4 files changed, 267 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/acpi/Makefile b/xen/arch/arm/acpi/Makefile
index 23963f8..93d8868 100644
--- a/xen/arch/arm/acpi/Makefile
+++ b/xen/arch/arm/acpi/Makefile
@@ -1,2 +1,3 @@
 obj-y += lib.o
 obj-y += boot.init.o
+obj-y += iort.o
diff --git a/xen/arch/arm/acpi/iort.c b/xen/arch/arm/acpi/iort.c
new file mode 100644
index 000..01914cb
--- /dev/null
+++ b/xen/arch/arm/acpi/iort.c
@@ -0,0 +1,242 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct pcirc_idmap
+{
+struct acpi_iort_id_mapping idmap;
+struct list_head entry;
+};
+
+
+int add_to_new_idmap_list(struct list_head *new_idmap_list,
+unsigned int ib, unsigned int ob,
+unsigned int oref, unsigned int idc)
+{
+struct pcirc_idmap *new_e = xzalloc(struct pcirc_idmap);
+if ( !new_e )
+{
+printk("Unable to allocate memory\n");
+return -ENOMEM;
+}
+
+new_e->idmap.input_base = ib;
+new_e->idmap.output_base = ob;
+new_e->idmap.output_reference = oref;
+new_e->idmap.id_count = idc;
+
+list_add_tail(&new_e->entry, new_idmap_list);
+
+return 0;
+}
+
+/*
+ * returns the number of pci_idmaps created as a result of parsing
+ * the smmu nodes for this pci_idmap
+ * the pci_idmaps are added to the new_idmap_list
+ *
+ * if get_count_only is set new_idmap_list is not populated, just the
+ * id_count is updated.
+ *
+ * This method is called in estimate size flow and write hwdom iort flow
+ */
+static int update_id_mapping(struct acpi_iort_id_mapping *pci_idmap,
+struct acpi_iort_node *smmu_node,
+struct list_head *new_idmap_list /* [out] */,
+int get_count_only,
+unsigned int *id_count /* [out] */)
+{
+/* local varialbes to hold input output base and count values.
+ * p_ for pci idmap; s for smmu idmap */
+unsigned int p_ib, p_ob, p_idc, s_ib, s_ob, s_idc, delta, i;
+struct acpi_iort_id_mapping *smmu_idmap = NULL;
+int ret;
+
+p_ib = pci_idmap->input_base;
+p_ob = pci_idmap->output_base;
+p_idc = pci_idmap->id_count;
+
+if(get_count_only)
+*id_count = 0;
+
+for ( i = 0; i < smmu_node->mapping_count; i++ )
+{
+smmu_idmap = (struct acpi_iort_id_mapping*)((u8*)smmu_node
++ smmu_node->mapping_offset);
+s_ib = smmu_idmap->input_base;
+s_ob = smmu_idmap->output_base;
+s_idc = smmu_idmap->id_count;
+
+if ( s_ib <= p_ob )
+{
+if ( s_ib + s_idc < p_ob )
+continue;
+
+delta = p_ob - s_ib;
+
+if ( get_count_only )
+{
+(*id_count)++;
+continue;
+}
+
+ret = add_to_new_idmap_list(new_idmap_list, p_ib, s_ob + delta,
+smmu_idmap->output_reference,
+s_ib + s_idc <= p_ob + p_idc ? s_idc - delta : p_idc);
+if (ret)
+goto err;
+}
+else
+{
+if( p_ob + p_idc < s_ib )
+continue;
+
+delta = s_ib - p_ob;
+
+if ( get_count_only )
+{
+(*id_count)++;
+continue;
+}
+
+ret = add_to_new_idmap_list(new_idmap_list, p_ib + delta, s_ob,
+smmu_idmap->output_reference,
+s_ib + s_idc < p_ob + p_idc ? s_idc : p_idc - delta);
+if (ret)
+goto err;
+}
+}
+
+return 0;
+err:
+return ret;
+}
+
+/*
+ *  This method scans the idarray for a pcirc_node
+ *  For each idmap there could be one or more entries in smmu idmap array
+ *
+ *  update_id_mapping will add correspoding smmu idmap entries but will
+ *  change mapping, so a pci idmap entry would have output_ref as its group
+ *
+ * idlist is populated when get_num_ids == 0
+ * - stores updated ids by removing smmu output reference
+ */
+static int scan_idarray(u8 *iort_base_ptr, struct acpi_iort_node *node,
+struct list_head *idmaplist, int get_num_ids,
+unsigned int *num_ids)
+{
+int i = 0, ret = 0;
+unsigned int id_count = 0;
+struct acpi_iort_node *onode; /* output node */
+struct acpi_iort_id_mapping *idmap = (struct acpi_iort_id_mapping*)
+((u8*)node + node->mapping_offset);
+
+for ( i = 0; i < node->m

[Xen-devel] [PATCH v2 0/2] ARM: ACPI: IORT: Hide SMMU from hardware domain's IORT table

[mjaggi]

From: Manish Jaggi 

The set is divided into two patches. First one calculates the size of IORT
while second one writes the IORT table itself.

patch1: estimates size of hardware domain IORT table by parsing all
the pcirc nodes and their idmaps, and thereby calculating size by
removing smmu nodes.

Hardware domain IORT table will have only ITS and PCIRC nodes, and PCIRC
nodes' idmap will have output refrences to ITS group nodes.

patch 2: The steps are:
a. First ITS group nodes are written and their offsets are saved
along with the respective offsets from the firmware table.
This is required when smmu node is hidden and smmu node still points
to the old output_reference.

b. PCIRC idmap is parsed and a list of idmaps is created which will
have PCIRC idmap -> ITS group nodes.
Each idmap is written by resolving ITS offset from the map saved in
previous step.

Changes wrt v1:
No assumption is made wrt format of IORT / hw support

Manish Jaggi (2):
  ARM: ACPI: IORT: Estimate the size of hardware domain IORT table
  ARM: ACPI: IORT: Write Hardware domain's IORT table

 xen/arch/arm/acpi/Makefile  |   1 +
 xen/arch/arm/acpi/iort.c| 414 
 xen/arch/arm/domain_build.c |  49 +-
 xen/include/asm-arm/acpi.h  |   1 +
 xen/include/asm-arm/iort.h  |  17 ++
 5 files changed, 481 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/acpi/iort.c
 create mode 100644 xen/include/asm-arm/iort.h

-- 
2.7.4


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

[Xen-devel] [PATCH 2/2] ARM: ACPI: IORT: Write Hardware domain's IORT table

[mjaggi]

From: Manish Jaggi 

This patch writes hardware domain's IORT table. The steps are:
a. First ITS group nodes are written and their offsets are saved
along with the respective offsets from the firmware table.
This is required when smmu node is hidden and smmu node still points
to the old output_reference.

b. PCIRC idmap is parsed and a list of idmaps is created which will
have PCIRC idmap -> ITS group nodes.
Each idmap is written by resolving ITS offset from the map saved in
previous step.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/acpi/iort.c| 172 
 xen/arch/arm/domain_build.c |  38 ++
 xen/include/asm-arm/acpi.h  |   1 +
 xen/include/asm-arm/iort.h  |   3 +
 4 files changed, 214 insertions(+)

diff --git a/xen/arch/arm/acpi/iort.c b/xen/arch/arm/acpi/iort.c
index 01914cb..d506adb 100644
--- a/xen/arch/arm/acpi/iort.c
+++ b/xen/arch/arm/acpi/iort.c
@@ -240,3 +240,175 @@ int estimate_iort_size(size_t *iort_size)
 err:
 return -EINVAL;
 }
+
+void write_itsgroup_nodes (struct acpi_table_iort *hwdom_iort,
+struct acpi_table_iort *fw_iort,
+uint64_t *ofstmap, unsigned int *pos)
+{
+int i;
+struct acpi_iort_node *node = NULL;
+/* Iterate over all its groups in firmware IORT table
+ * and copy them in hwdom iort table.
+ */
+
+/* First Node */
+node = (struct acpi_iort_node *)((u8*)fw_iort + fw_iort->node_offset);
+for ( i = 0; i < fw_iort->node_count; i++ )
+{
+if ( node->type == ACPI_IORT_NODE_ITS_GROUP )
+{
+u32 l,u;
+/* Copy ITS group node into dom0 IORT Table */
+ACPI_MEMCPY((u8*)hwdom_iort + *pos, node, node->length);
+
+/* keep the new and old offsets, this would resolve smmu idarray's
+ * output ref offsets to the new offsets in hwdom iort table */
+l = (uint32_t)((u8*)node - (u8*)fw_iort);
+u = *pos ;
+*ofstmap = ((uint64_t)(u) << 32)| l;
+
+hwdom_iort->node_count++;
+*pos += node->length;
+ofstmap++;
+}
+node = (struct acpi_iort_node *)((u8*)node + node->length);
+}
+}
+
+unsigned int write_single_pcirc_node(u8 *hwdom_iort, unsigned int pos,
+struct acpi_iort_node *node,
+struct list_head *new_idmap_list)
+{
+unsigned int sz;
+struct acpi_iort_node *local;
+struct pcirc_idmap *pidmap;
+local = (struct acpi_iort_node *)(hwdom_iort + pos);
+
+/* write the pci_rc node */
+sz = sizeof(struct acpi_iort_node) -1 +
+/* -1 as acpi_iort_node has an extra char */
+sizeof (struct acpi_iort_root_complex) ;
+ACPI_MEMCPY(hwdom_iort + pos, node, sz);
+
+pos += sz;
+local->mapping_offset = sz;
+local->mapping_count = 0;
+local->length = sz;
+
+list_for_each_entry(pidmap, new_idmap_list, entry)
+{
+ACPI_MEMCPY(hwdom_iort + pos, &pidmap->idmap,
+sizeof(struct acpi_iort_id_mapping));
+pos += sizeof(struct acpi_iort_id_mapping);
+local->mapping_count++;
+local->length += sizeof(struct acpi_iort_id_mapping);
+}
+
+return pos;
+}
+
+int write_pcirc_nodes(struct acpi_table_iort *hwdom_iort,
+struct acpi_table_iort *fw_iort,
+uint64_t  *its_ofstmap, unsigned int *pos)
+{
+int i, j, ret;
+struct acpi_iort_node *node = NULL;
+
+/* Iterate over all PCI_Nodes */
+/* First Node */
+node = (struct acpi_iort_node *)((u8*)fw_iort + fw_iort->node_offset);
+for ( i = 0; i < fw_iort->node_count; i++ )
+{
+if ( node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX )
+{
+struct pcirc_idmap *pidmap;
+struct list_head new_idmap_list;
+INIT_LIST_HEAD(&new_idmap_list);
+
+/* hide smmu nodes and update new_idmap_list with output
+ * refrence of pci idarray as its group
+ */
+ret = scan_idarray((u8*)fw_iort, node, &new_idmap_list, 0, NULL);
+if ( ret ) {
+printk("%s: scan_idarry Failed \r\n", __func__);
+goto end;
+}
+
+/* fixup its_group offsets as per new iort table */
+list_for_each_entry(pidmap, &new_idmap_list, entry)
+{
+/* search output reference offset in its_ofmap
+ * and replace with new offset
+ */
+for (j =0; j < fw_iort->node_count; j++)
+{
+if( !its_ofstmap[j] )
+break;
+
+if(pidmap->idmap.output_reference
+== (its_ofstmap[j] & 0x))
+{
+pidmap->idmap.output_reference = its_ofstmap[j] >> 32;
+break;
+}
+
+}
+}
+
+*pos = write_single_pcirc_node((u8*)hwdom_iort, *pos, node,
+

[Xen-devel] [qemu-upstream-unstable test] 113301: trouble: broken/fail/pass

[osstest service owner]

flight 113301 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113301/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-vhd  broken
 test-armhf-armhf-xl-vhd   4 host-install(4)broken REGR. vs. 113162

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail like 113153
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113162
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113162
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113162
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-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-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  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-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 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-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuuf5a4c84a5d6b19c154abed4ee0380a6f8fd98c60
baseline version:
 qemuuc349189772cec43498b0bec8a84146f10b8937af

Last test of basis   113162  2017-09-09 10:03:39 Z2 days
Testing same since   113301  2017-09-11 10:16:50 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Michael S. Tsirkin 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-li

[Xen-devel] [linux-next test] 113297: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm 12 guest-start  fail REGR. vs. 113262
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
113262
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
113262
 test-armhf-armhf-xl-arndale  10 debian-install   fail REGR. vs. 113262
 test-armhf-armhf-xl-credit2  10 debian-install   fail REGR. vs. 113262

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 113262

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot  fail like 113262
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot   fail like 113262
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot   fail like 113262
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot  fail like 113262
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot  fail like 113262
 test-amd64-i386-pair 10 xen-boot/src_hostfail  like 113262
 test-amd64-i386-pair 11 xen-boot/dst_hostfail  like 113262
 test-amd64-i386-libvirt   7 xen-boot fail  like 113262
 test-amd64-i386-xl-xsm7 xen-boot fail  like 113262
 test-amd64-i386-libvirt-qcow2  7 xen-boot fail like 113262
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail  like 113262
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail  like 113262
 test-amd64-i386-freebsd10-i386  7 xen-bootfail like 113262
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot   fail like 113262
 test-amd64-i386-xl7 xen-boot fail  like 113262
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot  fail like 113262
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-bootfail like 113262
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot  fail like 113262
 test-amd64-i386-examine   7 reboot   fail  like 113262
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot  fail like 113262
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot   fail like 113262
 test-amd64-i386-freebsd10-amd64  7 xen-boot   fail like 113262
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot   fail like 113262
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail like 
113262
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot   fail like 113262
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot   fail like 113262
 test-amd64-i386-xl-raw7 xen-boot fail  like 113262
 test-amd64-i386-rumprun-i386  7 xen-boot fail  like 113262
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-bootfail like 113262
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm  7 xen-boot fail like 113262
 test-amd64-i386-libvirt-xsm   7 xen-boot fail  like 113262
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113262
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113262
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[Stefano Stabellini]

On Mon, 11 Sep 2017, Rich Persaud wrote:
> On Sep 11, 2017, at 10:16, George Dunlap  wrote:
> 
>   +### vTPM Support
> 
>   +
> 
>   +    Status: Supported, x86 only
> 
> 
> This should probably be x86/vTPM. TPM, the way we are discussing 
> it, is
> 
> an x86-only implementation. ARM-based alternatives are not called 
> TPM
> 
> AFAIK.
> 
> 
>   Someone said that because this was implemented entirely in userspace,
>   there's no reason the PV TPM couldn't work on ARM.  OTOH I suppose it
>   would be a lot less valuable if there weren't a physical TPM to back it 
> up.
> 
>   Any thoughts on that?
> 
> 
> Physical TPMs are present on both x86 and ARM Chromebooks:
> 
>   https://www.chromium.org/developers/design-documents/tpm-usage
> 
> e.g. see Step 9 in this Samsung Series 3 teardown, "Infineon SLB9635":
> 
>   https://www.ifixit.com/Teardown/Samsung+Chromebook+Series+3+Teardown/12225

Interesting. In that case, I am OK with keeping "Status: Supported, x86
only".


>   +### Intel/TXT ???
> 
> 
> Same here
> 
> 
>   Well unless someone actually says something about this I'm just going go
>   delete it.
> 
> 
> That's one way to motivate a response :)
> 
> Slide 11 of Joe Cihula's 2007 presentation documents the Xen changes for TXT: 
> 
>   http://www-archive.xenproject.org/files/xensummit_fall07/23_JosephCihula.pdf
> 
> More info in the 2007 patch and the Linux kernel doc:
> 
>   
> http://old-list-archives.xen.org/archives/html/xen-devel/2007-10/msg00897.html
>   https://www.kernel.org/doc/Documentation/intel_txt.txt
> 
> Intel TXT is used with Xen by (at least) Qubes, OpenXT and Skyport Systems.  
> There was a design discussion at Xen Summit about implementing a 
> frequently-used subset of tboot
> logic in Xen.  Hopefully Intel TXT will continue to be a Xen feature with 
> security support.

>From intel_txt.txt, this really seems to be only available on x86
platforms.___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 113313: regressions - FAIL

[osstest service owner]

flight 113313 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113313/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 113143
 build-amd64-xsm   6 xen-buildfail REGR. vs. 113143
 build-i386-xsm6 xen-buildfail REGR. vs. 113143
 build-i3866 xen-buildfail REGR. vs. 113143

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf aa9aa47e06ac0082948b880c226c8bdf2a12102b
baseline version:
 ovmf 3281ebb4ae7de2a858c2e7ec4998b7e55be1a4dc

Last test of basis   113143  2017-09-08 06:17:14 Z3 days
Failing since113156  2017-09-08 19:17:56 Z3 days   20 attempts
Testing same since   113275  2017-09-11 03:48:41 Z0 days5 attempts


People who touched revisions under test:
  Brijesh Singh 
  Laszlo Ersek 
  Paulo Alcantara 
  Star Zeng 
  Thomas Lamprecht 
  Yonghong Zhu 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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.

(No revision log; it would be 555 lines long.)

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-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  d0291f3391ab34b34092fcdc56abd8153cbe4579
baseline version:
 xen  70892c317fd56064b09a4b0fcaa0781735e64efc

Last test of basis   113152  2017-09-08 15:01:10 Z3 days
Testing same since   113321  2017-09-11 17:22:53 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Razvan Cojocaru 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  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 :

+ branch=xen-unstable-smoke
+ revision=d0291f3391ab34b34092fcdc56abd8153cbe4579
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
d0291f3391ab34b34092fcdc56abd8153cbe4579
+ branch=xen-unstable-smoke
+ revision=d0291f3391ab34b34092fcdc56abd8153cbe4579
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.:.
 PERLLIB=.:.:.
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' xd0291f3391ab34b34092fcdc56abd8153cbe4579 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenb

Re: [Xen-devel] [stage1-xen PATCH v1 06/10] build/fedora: Add `xen-unstable-runit/*` scripts

[Stefano Stabellini]

On Sat, 9 Sep 2017, Rajiv Ranganath wrote:
> On Thu, Sep 07 2017 at 12:10:21 AM, Stefano Stabellini 
>  wrote:
> 
> [...]
> 
> > The series is much better now thank you. One question: why did you write
> > your own init scripts rather than reusing xencommons (with the caveat
> > that you would have to add make sure to source_path.sh before running
> > xencommons)?  Does it have something to do with systemd?
> 
> There are a few related reasons for this.
> 
> 1. Using runit lets us abstract out our dependency on systemd and
> upstart. We can use the same abstraction in containers [1], virtual
> machines and on bare metal.
> 
> 2. In Linux distributions, there is tight coupling between package
> management system (rpm/deb), init systems (upstart/systemd), and service
> daemons.
> 
> With containers, if the expectation is that most service daemons and
> apps would be containerized, and managed by a node agent then a natural
> question to ask would be what should be the role of init systems like
> systemd?
> 
> By using runit (on systemd, upstart and within containers), we defer
> answering this question. 
> 
> 3. One of the use cases that we want to support is to have different
> versions of xen co-exist on the same filesystem. Then a higher level
> tool can do rolling updates and if required rollbacks.
> 
> While it is possible to accomplish this on existing init systems,
> depending on how xen is packaged and deployed, it might involve using
> distro package and repository management tools.
> 
> With runit, we can use regular docker tools, which is much more friendly
> for mainstream developers and CI systems. We also abstract over init
> systems, which is a desirable property to have.
> 
> 4. I looked into xencommons script and systemd unit files when creating
> runit scripts. Our runit scripts is straightforward translation of how
> one would start xen manually.
> 
> Perhaps the only part of the script that might need some explanation is
> in `xen-init-dom0/run`.
> 
> ```
> exec chpst -b xen-init-dom0 runit-pause
> ```
> 
> This is a pattern used to build equivalent of "oneshot" service in
> systemd. It was developed in Ignite (a Arch Linux project before they
> switched to systemd) and later co-opted by Void Linux [2].
> 
> I am not sure if I answered your question. Sometimes I feel, maybe we
> should just let questions around init systems be like one of those
> "unanswered questions" in theology. :-) [3]
> 
> Best,
> Rajiv
> 
> [1] https://github.com/lambda-linux/baseimage-amzn#adding_additional_daemons
> 
> [2] 
> https://github.com/voidlinux/void-runit/commit/7aecf46ec589a5bc49ae2392137bcd0e7468dd08

Thank you for the pointers. I have no opinions on the format of the init
scripts. runit is fine by me in that respect, and I understand the
advantages you pointed out.

My only concern is about diverging from the upstream Xen codebase. I
think the runit scripts should call xencommons underneath. If xencommons
cannot cope with being called from runit, we could make changes to
xencommon in xen.git to make it so.

Otherwise, we will end up in a situation such as:
- xen.git changes xencommons
- we don't notice
- we upgrade Xen version
- stage1-xen doesn't work anymore

If we used xencommons underneath we would avoid this, and it looks like
xencommons could be made to work well with runit.

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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[Rich Persaud]

On Sep 11, 2017, at 10:16, George Dunlap  wrote:
> 
>>> +### vTPM Support
>>> +
>>> +Status: Supported, x86 only
>> 
>> This should probably be x86/vTPM. TPM, the way we are discussing it, is
>> an x86-only implementation. ARM-based alternatives are not called TPM
>> AFAIK.
> 
> Someone said that because this was implemented entirely in userspace,
> there's no reason the PV TPM couldn't work on ARM.  OTOH I suppose it
> would be a lot less valuable if there weren't a physical TPM to back it up.
> 
> Any thoughts on that?

Physical TPMs are present on both x86 and ARM Chromebooks:

  https://www.chromium.org/developers/design-documents/tpm-usage

e.g. see Step 9 in this Samsung Series 3 teardown, "Infineon SLB9635":

  https://www.ifixit.com/Teardown/Samsung+Chromebook+Series+3+Teardown/12225


>>> +### Intel/TXT ???
>> 
>> Same here
> 
> Well unless someone actually says something about this I'm just going go
> delete it.

That's one way to motivate a response :)

Slide 11 of Joe Cihula's 2007 presentation documents the Xen changes for TXT: 

  http://www-archive.xenproject.org/files/xensummit_fall07/23_JosephCihula.pdf

More info in the 2007 patch and the Linux kernel doc:

  http://old-list-archives.xen.org/archives/html/xen-devel/2007-10/msg00897.html
  https://www.kernel.org/doc/Documentation/intel_txt.txt

Intel TXT is used with Xen by (at least) Qubes, OpenXT and Skyport Systems.  
There was a design discussion at Xen Summit about implementing a 
frequently-used subset of tboot logic in Xen.  Hopefully Intel TXT will 
continue to be a Xen feature with security support.

Rich___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [stage1-xen PATCH v1 09/10] build/fedora: Add `RUNNING_STAGE1_XEN.md`

[Stefano Stabellini]

On Sat, 9 Sep 2017, Rajiv Ranganath wrote:
> On Thu, Sep 07 2017 at 12:44:16 AM, Stefano Stabellini 
>  wrote:
> 
> [...]
> 
> >> +[root@localhost ~]# ls /opt
> >> +qemu-unstable  stage1-xen  xen-unstable  xen-unstable-runit
> >> +```
> >> +
> >> +This will extract all the build artifacts into `/opt` directory.
> >
> > Is there a reason to keep all the binaries under /opt? I mean, at this
> > point, we could do something like
> >
> >   cp -ar /opt/xen-unstable/* /
> >
> > and do the same for the other components.
> 
> Yes, we can do that, but I feel its a good idea. :-)
> 
> Outside of specific paths (such as /var or /etc), its better to let RPM
> manage files in the / hierarchy. That way rpm -qf can return sensible
> results when we need to login and debug issues.
> 
> > Do we keep them under /opt for ease of management, so that the next time
> > we do a build, we can easily test with a different Xen version? Or is
> > there another reason?
> 
> That's correct. Keeping things isolated in /opt lets us test different
> versions of xen during development. In production we can use the same
> approach to support multiple versions of xen and do rolling updates or
> rollbacks.
> 
> Btw, I should point out that this is not something new. NixOS has been
> using the approach of building packages in separate filesystem hierarchy
> for a while now.
> 
> We are just selectively adopting their ideas.

That's OK for me. Please add a few words on this in the commit message.

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

Re: [Xen-devel] [stage1-xen PATCH v1 04/10] build/fedora: Add `run` and `components/*` scripts

[Stefano Stabellini]

On Sat, 9 Sep 2017, Rajiv Ranganath wrote:
> On Thu, Sep 07 2017 at 12:29:54 AM, Stefano Stabellini 
>  wrote:
> 
> [...]
> 
> >> +QEMU_BRANCH = 'master'
> >
> > I am not sure we want to checkout always the latest QEMU. It is a
> > running target. It makes sense to use one of the latest releases
> > instead, such as v2.10.0?
> >
> 
> [...]
> 
> I feel once we have an understanding around what stable xen container
> experience for our users should be, it makes a lot of sense to support
> two stable versions (on a rolling basis) along with unstable/devel
> versions of xen, qemu and rkt.

Yes, I think that would be ideal too.


> I am hoping we can include the following before adding support for
> stable version.
> 
> 1. Kernel - PV Calls backend support will be in 4.14, which is few
> months away.
> 
> 2. PVHv2 - xl and PVHv2 support is inflight for 4.10. I would like to
> see xen container users start off with PVHv2 and using PV Calls
> networking. Therefore I am a bit hesitant adding support for Xen 4.9.

Yes, that would fantastic. Fortunately, from the stage1-xen code point
of view, there is very little difference between PVHv2 and PV. Switching
from one to the other should be a matter of adding one line to the xl
config file.

Regarding statements of support, see below.


> 3. Multiboot2 - One of the reasons why I documented using EFI is because
> I could not get multiboot2 to work. It looks like the fix for it is on
> its way. I anticipate using multiboot2 would be easier for users.

That's for the host right? I didn't have that problem, but maybe because
I am not using Fedora.


> 4. Rkt - Support for Kubernetes CRI and OCI image format will be of
> importance to our users. Rkt is working on it but I'm not sure of their
> progress. There are other projects that are also incubating in CNCF -
> cri-o and cri-containerd.
> 
> PV Calls networking is new to me, and I wanted to do some prototyping to
> understand how it would integrate with the rest of the container
> ecosystem it after landing this series.
> 
> By adding support for xen-4.9, qemu-2.10 or rkt-1.28.1 I feel we should
> not set some kind stability or backward compatibility expectations
> around stage1-xen as yet.

I agree we should not set any kind of backward compatibility
expectations yet. See below.


> My preference would be to keep things on master (albeit deliberately)
> till we can figure out a good xen container experience for our users.
> 
> Please let me know what you think.

You have a good point. I think we should be clear about the stability of
the project and the backward compatibility in the README. We should
openly say that it is still a "preview" and there is no "support" or
"compatibility" yet.

Choosing Xen 4.9 should not be seen as a statement of support. I think
we should choose the Xen version based only on the technical merits.

In the long term it would be great to support multiple stable versions
and a development version of Xen. As of now, I think it makes sense to
have an "add-hoc approach": I would use Xen 4.9 just because it is the
best choice at the moment. Then, I would update to other versions when
it makes sense, manually. I don't think that building against a changing
target ("master") is a good idea, because we might end up stumbling
across confusing and time-consuming bugs that have nothing to do with
stage1-xen. However, we could pick a random commit on the Xen tree if
that's convenient for us, because at this stage there is no support
really. For example, PVCalls will require some tools changes in Xen.
Once they are upstream, we'll want to update the Xen version to the
latest with PVCalls support.

Does it make sense?

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

Re: [Xen-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest

[Stefano Stabellini]

CC'ing xen-devel, and the Xen tools and x86 maintainers.

On Mon, 11 Sep 2017, Igor Mammedov wrote:
> On Mon, 11 Sep 2017 12:41:47 +0800
> Haozhong Zhang  wrote:
> 
> > This is the QEMU part patches that works with the associated Xen
> > patches to enable vNVDIMM support for Xen HVM domains. Xen relies on
> > QEMU to build guest NFIT and NVDIMM namespace devices, and allocate
> > guest address space for vNVDIMM devices.
> > 
> > All patches can be found at
> >   Xen:  https://github.com/hzzhan9/xen.git nvdimm-rfc-v3
> >   QEMU: https://github.com/hzzhan9/qemu.git xen-nvdimm-rfc-v3
> > 
> > Patch 1 is to avoid dereferencing the NULL pointer to non-existing
> > label data, as the Xen side support for labels is not implemented yet.
> > 
> > Patch 2 & 3 add a memory backend dedicated for Xen usage and a hotplug
> > memory region for Xen guest, in order to make the existing nvdimm
> > device plugging path work on Xen.
> > 
> > Patch 4 - 10 build and cooy NFIT from QEMU to Xen guest, when QEMU is
> > used as the Xen device model.
> 
> I've skimmed over patch-set and can't say that I'm happy with
> number of xen_enabled() invariants it introduced as well as
> with partial blobs it creates.

I have not read the series (Haozhong, please CC me, Anthony and
xen-devel to the whole series next time), but yes, indeed. Let's not add
more xen_enabled() if possible.

Haozhong, was there a design document thread on xen-devel about this? If
so, did it reach a conclusion? Was the design accepted? If so, please
add a link to the design doc in the introductory email, so that
everybody can read it and be on the same page.


> I'd like to reduce above and a way to do this might be making xen 
>  1. use fw_cfg
>  2. fetch QEMU build acpi tables from fw_cfg
>  3. extract nvdim tables (which is trivial) and use them
> 
> looking at xen_load_linux(), it seems possible to use fw_cfg.
> 
> So what's stopping xen from using it elsewhere?,
> instead of adding more xen specific code to do 'the same'
> job and not reusing/sharing common code with tcg/kvm.

So far, ACPI tables have not been generated by QEMU. Xen HVM machines
rely on a firmware-like application called "hvmloader" that runs in
guest context and generates the ACPI tables. I have no opinions on
hvmloader and I'll let the Xen maintainers talk about it. However, keep
in mind that with an HVM guest some devices are emulated by Xen and/or
by other device emulators that can run alongside QEMU. QEMU doesn't have
a full few of the system.

Here the question is: does it have to be QEMU the one to generate the
ACPI blobs for the nvdimm? It would be nicer if it was up to hvmloader
like the rest, instead of introducing this split-brain design about
ACPI. We need to see a design doc to fully understand this.

If the design doc thread led into thinking that it has to be QEMU to
generate them, then would it make the code nicer if we used fw_cfg to
get the (full or partial) tables from QEMU, as Igor suggested?


> > Haozhong Zhang (10):
> >   nvdimm: do not intiailize nvdimm->label_data if label size is zero
> >   hw/xen-hvm: create the hotplug memory region on Xen
> >   hostmem-xen: add a host memory backend for Xen
> >   nvdimm acpi: do not use fw_cfg on Xen
> >   hw/xen-hvm: initialize DM ACPI
> >   hw/xen-hvm: add function to copy ACPI into guest memory
> >   nvdimm acpi: copy NFIT to Xen guest
> >   nvdimm acpi: copy ACPI namespace device of vNVDIMM to Xen guest
> >   nvdimm acpi: do not build _FIT method on Xen
> >   hw/xen-hvm: enable building DM ACPI if vNVDIMM is enabled
> > 
> >  backends/Makefile.objs |   1 +
> >  backends/hostmem-xen.c | 108 ++
> >  backends/hostmem.c |   9 +++
> >  hw/acpi/aml-build.c|  10 ++-
> >  hw/acpi/nvdimm.c   |  79 ++-
> >  hw/i386/pc.c   | 102 ++---
> >  hw/i386/xen/xen-hvm.c  | 204 
> > -
> >  hw/mem/nvdimm.c|  10 ++-
> >  hw/mem/pc-dimm.c   |   6 +-
> >  include/hw/i386/pc.h   |   1 +
> >  include/hw/xen/xen.h   |  25 ++
> >  stubs/xen-hvm.c|  10 +++
> >  12 files changed, 495 insertions(+), 70 deletions(-)
> >  create mode 100644 backends/hostmem-xen.c
> > 
> 

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

Re: [Xen-devel] [PATCH] mem_access: switch to plain bool

[Stefano Stabellini]

On Mon, 11 Sep 2017, Wei Liu wrote:
> Signed-off-by: Wei Liu 

Reviewed-by: Stefano Stabellini 

> ---
> Cc: Razvan Cojocaru 
> Cc: Tamas K Lengyel 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: George Dunlap 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/arch/arm/mem_access.c|  4 ++--
>  xen/arch/x86/mm/mem_access.c | 16 
>  xen/include/asm-arm/mem_access.h |  8 
>  xen/include/asm-x86/mem_access.h |  8 
>  4 files changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
> index db9ad3f3c9..0f2cbb81d3 100644
> --- a/xen/arch/arm/mem_access.c
> +++ b/xen/arch/arm/mem_access.c
> @@ -219,10 +219,10 @@ err:
>  return page;
>  }
>  
> -bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec 
> npfec)
> +bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec npfec)
>  {
>  int rc;
> -bool_t violation;
> +bool violation;
>  xenmem_access_t xma;
>  vm_event_request_t *req;
>  struct vcpu *v = current;
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index 414e38f998..9211fc0abe 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -83,7 +83,7 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
>const vm_event_response_t *rsp)
>  {
>  xenmem_access_t access;
> -bool violation = 1;
> +bool violation = true;
>  const struct vm_event_mem_access *data = &rsp->u.mem_access;
>  struct domain *d = v->domain;
>  struct p2m_domain *p2m = NULL;
> @@ -129,7 +129,7 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
>  break;
>  
>  case XENMEM_access_rwx:
> -violation = 0;
> +violation = false;
>  break;
>  }
>  }
> @@ -137,9 +137,9 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
>  return violation;
>  }
>  
> -bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
> -struct npfec npfec,
> -vm_event_request_t **req_ptr)
> +bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
> +  struct npfec npfec,
> +  vm_event_request_t **req_ptr)
>  {
>  struct vcpu *v = current;
>  unsigned long gfn = gpa >> PAGE_SHIFT;
> @@ -167,7 +167,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long 
> gla,
>  rc = p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, 
> p2m_access_rw, -1);
>  ASSERT(rc == 0);
>  gfn_unlock(p2m, gfn, 0);
> -return 1;
> +return true;
>  }
>  else if ( p2ma == p2m_access_n2rwx )
>  {
> @@ -188,7 +188,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long 
> gla,
>"no vm_event listener VCPU %d, dom %d\n",
>v->vcpu_id, d->domain_id);
>  domain_crash(v->domain);
> -return 0;
> +return false;
>  }
>  else
>  {
> @@ -204,7 +204,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long 
> gla,
>  ASSERT(rc == 0);
>  }
>  gfn_unlock(p2m, gfn, 0);
> -return 1;
> +return true;
>  }
>  }
>  
> diff --git a/xen/include/asm-arm/mem_access.h 
> b/xen/include/asm-arm/mem_access.h
> index 3a155f84eb..1610635c5b 100644
> --- a/xen/include/asm-arm/mem_access.h
> +++ b/xen/include/asm-arm/mem_access.h
> @@ -22,20 +22,20 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
>const vm_event_response_t *rsp)
>  {
>  /* Not supported on ARM. */
> -return 0;
> +return false;
>  }
>  
>  /* vm_event and mem_access are supported on any ARM guest */
> -static inline bool_t p2m_mem_access_sanity_check(struct domain *d)
> +static inline bool p2m_mem_access_sanity_check(struct domain *d)
>  {
> -return 1;
> +return true;
>  }
>  
>  /*
>   * Send mem event based on the access. Boolean return value indicates if trap
>   * needs to be injected into guest.
>   */
> -bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec 
> npfec);
> +bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec 
> npfec);
>  
>  struct page_info*
>  p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned long flag,
> diff --git a/xen/include/asm-x86/mem_access.h 
> b/xen/include/asm-x86/mem_access.h
> index 9f7b409b4e..4043c9fb4d 100644
> --- a/xen/include/asm-x86/mem_access.h
> +++ b/xen/include/asm-x86/mem_access.h
> @@ -34,9 +34,9 @@
>   * ring. Once having released get_gfn* locks caller must also xfree the
>   * request.
>   */
> -bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
> -struct npfec npfec,
> -vm_event_request_t **req_ptr);
> +bool p2m_mem_access_ch

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[Julien Grall]

On 11/09/17 17:39, Stefano Stabellini wrote:

On Mon, 11 Sep 2017, Julien Grall wrote:

On 07/09/17 22:54, Stefano Stabellini wrote:

On Thu, 31 Aug 2017, George Dunlap wrote:

+### Direct-boot kernel image format
+
+Supported, x86: bzImage
+Supported, ARM32: zImage
+Supported, ARM64: Image [XXX - Not sure if this is correct]


On ARM64 it's called Image.gz.


That's not true. Linux produces an Image. You can compress after if you want,
but it is not the default.


Are you sure? Why do you say Image it's the default? If I do `make
help', the result is:


The format is call Image. Image.gz is just a compressed version and 
unlike zImage you can't boot it directly without the help of an external 
loader to uncompress it.


For instance, today, Xen is not able to decompress Image.gz by itself. 
It relies on the bootloader (assuming it has support for it).


Cheers,




Architecture specific targets (arm64):
* Image.gz  - Compressed kernel image (arch/arm64/boot/Image.gz)
   Image - Uncompressed kernel image (arch/arm64/boot/Image)
* dtbs  - Build device tree blobs for enabled boards
   dtbs_install  - Install dtbs to /boot/dtbs/4.13.0-rc1+
   install   - Install uncompressed kernel
   zinstall  - Install compressed kernel
   Install using (your) ~/bin/installkernel or
   (distribution) /sbin/installkernel or
   install to $(INSTALL_PATH) and run lilo


Note that the default build targets are the ones that are starred.



--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md

[Andrew Cooper]

On 11/09/17 18:01, George Dunlap wrote:
> +### x86/PV
> +
> +Status: Supported
> +
> +Traditional Xen Project PV guest

What's a "Xen Project" PV guest?  Just Xen here.

Also, a perhaps a statement of "No hardware requirements" ?

> +### x86/RAM
> +
> +Limit, x86: 16TiB
> +Limit, ARM32: 16GiB
> +Limit, ARM64: 5TiB
> +
> +[XXX: Andy to suggest what this should say for x86]

The limit for x86 is either 16TiB or 123TiB, depending on
CONFIG_BIGMEM.  CONFIG_BIGMEM is exposed via menuconfig without
XEN_CONFIG_EXPERT, so falls into at least some kind of support statement.

As for practical limits, I don't think its reasonable to claim anything
which we can't test.  What are the specs in the MA colo?

> +
> +## Limits/Guest
> +
> +### Virtual CPUs
> +
> +Limit, x86 PV: 512

Where did this number come from?  The actual limit as enforced in Xen is
8192, and it has been like that for a very long time (i.e. the 3.x days)

[root@fusebot ~]# python
Python 2.7.5 (default, Nov 20 2015, 02:00:19)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xen.lowlevel.xc import xc as XC
>>> xc = XC()
>>> xc.domain_create()
1
>>> xc.domain_max_vcpus(1, 8192)
0
>>> xc.domain_create()
2
>>> xc.domain_max_vcpus(2, 8193)
Traceback (most recent call last):
  File "", line 1, in 
xen.lowlevel.xc.Error: (22, 'Invalid argument')

Trying to shut such a domain down however does tickle a host watchdog
timeout as the for_each_vcpu() loops in domain_kill() are very long.

> +Limit, x86 HVM: 128
> +Limit, ARM32: 8
> +Limit, ARM64: 128
> +
> +[XXX Andrew Cooper: Do want to add "Limit-Security" here for some of these?]

32 for each.  64 vcpu HVM guests can excerpt enough p2m lock pressure to
trigger a 5 second host watchdog timeout.

> +
> +### Virtual RAM
> +
> +Limit, x86 PV: >1TB
> +Limit, x86 HVM: 1TB
> +Limit, ARM32: 16GiB
> +Limit, ARM64: 1TB

There is no specific upper bound on the size of PV or HVM guests that I
am aware of.  1.5TB HVM domains definitely work, because that's what we
test and support in XenServer.

> +
> +### x86 PV/Event Channels
> +
> +Limit: 131072

Why do we call out event channel limits but not grant table limits? 
Also, why is this x86?  The 2l and fifo ABIs are arch agnostic, as far
as I am aware.

> +## High Availability and Fault Tolerance
> +
> +### Live Migration, Save & Restore
> +
> +Status, x86: Supported

With caveats.  From docs/features/migration.pandoc

* x86 HVM guest physmap operations (not reflected in logdirty bitmap)
* x86 HVM with PoD pages (attempts to map cause PoD allocations)
* x86 HVM with nested-virt (no relevant information included in the stream)
* x86 PV ballooning (P2M marked dirty, target frame not marked)
* x86 PV P2M structure changes (not noticed, stale mappings used) for
  guests not using the linear p2m layout

Also, features such as vNUMA and nested virt (which are two I know for
certain) have all state discarded on the source side, because they were
never suitably plumbed in.

~Andrew

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf  broken
 build-armhf   4 host-install(4)broken REGR. vs. 113031
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
113031
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 113031
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 113031
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 113031
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 113031
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 113031
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 113031
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 113031
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
113031
 test-amd64-i386-examine   7 reboot   fail REGR. vs. 113031

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop   fail REGR. vs. 113031

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qcow2  7 xen-boot   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
113031
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113031
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version tar

[Xen-devel] [PATCH v5 03/12] libxl: add vdispl device

[Oleksandr Grytsov]

From: Oleksandr Grytsov 

Signed-off-by: Oleksandr Grytsov 
---
 tools/libxl/Makefile |   2 +-
 tools/libxl/libxl.h  |  24 +++
 tools/libxl/libxl_create.c   |   1 +
 tools/libxl/libxl_internal.h |   1 +
 tools/libxl/libxl_types.idl  |  36 +
 tools/libxl/libxl_types_internal.idl |   1 +
 tools/libxl/libxl_utils.h|   4 +
 tools/libxl/libxl_vdispl.c   | 284 +++
 8 files changed, 352 insertions(+), 1 deletion(-)
 create mode 100644 tools/libxl/libxl_vdispl.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 082af8f..56f90e1 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -138,7 +138,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_dom_suspend.o libxl_dom_save.o libxl_usb.o \
libxl_vtpm.o libxl_nic.o libxl_disk.o libxl_console.o \
libxl_cpupool.o libxl_mem.o libxl_sched.o libxl_tmem.o \
-   libxl_9pfs.o libxl_domain.o \
+   libxl_9pfs.o libxl_domain.o libxl_vdispl.o \
 $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 812b7ea..e386357 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1877,6 +1877,30 @@ libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx 
*ctx, uint32_t domid, int *n
 int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
libxl_device_vtpm *vtpm, libxl_vtpminfo 
*vtpminfo);
 
+/* Virtual displays */
+int libxl_device_vdispl_add(libxl_ctx *ctx, uint32_t domid,
+libxl_device_vdispl *displ,
+const libxl_asyncop_how *ao_how)
+LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vdispl_remove(libxl_ctx *ctx, uint32_t domid,
+   libxl_device_vdispl *vdispl,
+   const libxl_asyncop_how *ao_how)
+   LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vdispl_destroy(libxl_ctx *ctx, uint32_t domid,
+libxl_device_vdispl *vdispl,
+const libxl_asyncop_how *ao_how)
+LIBXL_EXTERNAL_CALLERS_ONLY;
+
+libxl_device_vdispl *libxl_device_vdispl_list(libxl_ctx *ctx,
+  uint32_t domid, int *num)
+  LIBXL_EXTERNAL_CALLERS_ONLY;
+void libxl_device_vdispl_list_free(libxl_device_vdispl* list, int num)
+   LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vdispl_getinfo(libxl_ctx *ctx, uint32_t domid,
+libxl_device_vdispl *vdispl,
+libxl_vdisplinfo *vdisplinfo)
+LIBXL_EXTERNAL_CALLERS_ONLY;
+
 /* Keyboard */
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb,
  const libxl_asyncop_how *ao_how)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index efd1459..f20bbf9 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1446,6 +1446,7 @@ const struct libxl_device_type *device_type_tbl[] = {
 &libxl__usbdev_devtype,
 &libxl__pcidev_devtype,
 &libxl__dtdev_devtype,
+&libxl__vdispl_devtype,
 NULL
 };
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c94a117..c6f5868 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3563,6 +3563,7 @@ extern const struct libxl_device_type libxl__vtpm_devtype;
 extern const struct libxl_device_type libxl__usbctrl_devtype;
 extern const struct libxl_device_type libxl__usbdev_devtype;
 extern const struct libxl_device_type libxl__pcidev_devtype;
+extern const struct libxl_device_type libxl__vdispl_devtype;
 
 extern const struct libxl_device_type *device_type_tbl[];
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 173d70a..756e120 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -779,6 +779,20 @@ libxl_device_channel = Struct("device_channel", [
])),
 ])
 
+libxl_connector_param = Struct("connector_param", [
+("id", string),
+("width", uint32),
+("height", uint32)
+])
+
+libxl_device_vdispl = Struct("device_vdispl", [
+("backend_domid", libxl_domid),
+("backend_domname", string),
+("devid", libxl_devid),
+("be_alloc", bool),
+("connectors", Array(libxl_connector_param, "num_connectors"))
+])
+
 libxl_domain_config = Struct("domain_config", [
 ("c_info", libxl_domain_create_info),
 ("b_info", libxl_domain_build_info),
@@ -792,6 +806,7 @@ libxl_domain_config = Struct("domai

[Xen-devel] [PATCH v5 11/12] libxl: change vtpm to use generec add function

[Oleksandr Grytsov]

From: Oleksandr Grytsov 

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 
---
 tools/libxl/libxl.h  |  12 +--
 tools/libxl/libxl_vtpm.c | 221 +--
 tools/xl/xl_vtpm.c   |   3 +-
 3 files changed, 69 insertions(+), 167 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index abe129e..65c4aaa 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1606,9 +1606,6 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t 
domid,
 int *nb_vcpu, int *nr_cpus_out);
 void libxl_vcpuinfo_list_free(libxl_vcpuinfo *, int nr_vcpus);
 
-void libxl_device_vtpm_list_free(libxl_device_vtpm*, int nr_vtpms);
-void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms);
-
 /*
  * Devices
  * ===
@@ -1883,9 +1880,14 @@ int libxl_device_vtpm_destroy(libxl_ctx *ctx, uint32_t 
domid,
   const libxl_asyncop_how *ao_how)
   LIBXL_EXTERNAL_CALLERS_ONLY;
 
-libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid, int 
*num);
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx,
+  uint32_t domid, int *num)
+  LIBXL_EXTERNAL_CALLERS_ONLY;
+void libxl_device_vtpm_list_free(libxl_device_vtpm*, int num)
+ LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
-   libxl_device_vtpm *vtpm, libxl_vtpminfo 
*vtpminfo);
+  libxl_device_vtpm *vtpm, libxl_vtpminfo 
*vtpminfo)
+  LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /* Virtual displays */
 int libxl_device_vdispl_add(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl_vtpm.c b/tools/libxl/libxl_vtpm.c
index 3eca38e..2132087 100644
--- a/tools/libxl/libxl_vtpm.c
+++ b/tools/libxl/libxl_vtpm.c
@@ -51,165 +51,72 @@ static void libxl__update_config_vtpm(libxl__gc *gc, 
libxl_device_vtpm *dst,
 
 static LIBXL_DEFINE_UPDATE_DEVID(vtpm, "vtpm")
 
+static int libxl__set_xenstore_vtpm(libxl__gc *gc, uint32_t domid,
+libxl_device_vtpm *vtpm,
+flexarray_t *back, flexarray_t *front,
+flexarray_t *ro_front)
+{
+flexarray_append_pair(back, "handle", GCSPRINTF("%d", vtpm->devid));
+flexarray_append_pair(back, "uuid",
+  GCSPRINTF(LIBXL_UUID_FMT,
+LIBXL_UUID_BYTES(vtpm->uuid)));
+flexarray_append_pair(back, "resume", "False");
+
+flexarray_append_pair(front, "handle", GCSPRINTF("%d", vtpm->devid));
+
+return 0;
+}
+
 static void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
libxl_device_vtpm *vtpm,
libxl__ao_device *aodev)
 {
-STATE_AO_GC(aodev->ao);
-flexarray_t *front;
-flexarray_t *back;
-libxl__device *device;
-int rc;
-xs_transaction_t t = XBT_NULL;
-libxl_domain_config d_config;
-libxl_device_vtpm vtpm_saved;
-libxl__domain_userdata_lock *lock = NULL;
-
-libxl_domain_config_init(&d_config);
-libxl_device_vtpm_init(&vtpm_saved);
-libxl_device_vtpm_copy(CTX, &vtpm_saved, vtpm);
-
-rc = libxl__device_vtpm_setdefault(gc, domid, vtpm, aodev->update_json);
-if (rc) goto out;
-
-front = flexarray_make(gc, 16, 1);
-back = flexarray_make(gc, 16, 1);
-
-rc = libxl__device_vtpm_update_devid(gc, domid, vtpm);
-if (rc) goto out;
-
-libxl__update_config_vtpm(gc, &vtpm_saved, vtpm);
-
-GCNEW(device);
-rc = libxl__device_from_vtpm(gc, domid, vtpm, device);
-if ( rc != 0 ) goto out;
-
-flexarray_append(back, "frontend-id");
-flexarray_append(back, GCSPRINTF("%d", domid));
-flexarray_append(back, "online");
-flexarray_append(back, "1");
-flexarray_append(back, "state");
-flexarray_append(back, GCSPRINTF("%d", XenbusStateInitialising));
-flexarray_append(back, "handle");
-flexarray_append(back, GCSPRINTF("%d", vtpm->devid));
-
-flexarray_append(back, "uuid");
-flexarray_append(back, GCSPRINTF(LIBXL_UUID_FMT, 
LIBXL_UUID_BYTES(vtpm->uuid)));
-flexarray_append(back, "resume");
-flexarray_append(back, "False");
-
-flexarray_append(front, "backend-id");
-flexarray_append(front, GCSPRINTF("%d", vtpm->backend_domid));
-flexarray_append(front, "state");
-flexarray_append(front, GCSPRINTF("%d", XenbusStateInitialising));
-flexarray_append(front, "handle");
-flexarray_append(front, GCSPRINTF("%d", vtpm->devid));
-
-if (aodev->update_json) {
-lock = libxl__lock_domain_userdata(gc, domid);
-if (!lock) {
-rc = ERROR_LOCK_FAIL;
-goto out;
-}
+libxl__device_add_async(egc, domid, &libxl__vtpm_devtype, vtpm, aodev);
+}
 
-rc

[Xen-devel] [PATCH v5 00/12] libxl: add PV display device driver interface

[Oleksandr Grytsov]

From: Oleksandr Grytsov 

Changes since V4:
  * Use new LIBXL_DEFINE_UPDATE_DEVID for all device types;
  * Align device setdefault function parameters with set_default
device type callback;
  * revert libxl_mac_to_device_nic to existing implementation;
  * previous comments are applied.

Patches on github [1].

[1] https://github.com/al1img/xen/tree/xl-vdispl-v5


Oleksandr Grytsov (12):
  libxl: add generic function to add device
  libxl: add generic functions to get and free device list
  libxl: add vdispl device
  xl: add PV display device commands
  docs: add PV display driver information
  libxl: change p9 to use generec add function
  libxl: change vkb to use generec add function
  libxl: change vfb to use generec add function
  libxl: change disk to use generic getting list functions
  libxl: change nic to use generec add function
  libxl: change vtpm to use generec add function
  libxl: remove unneeded DEVICE_ADD macro

 docs/man/xl.cfg.pod.5.in  |  49 ++
 docs/man/xl.pod.1.in  |  42 +
 tools/libxl/Makefile  |   2 +-
 tools/libxl/libxl.h   |  54 +--
 tools/libxl/libxl_9pfs.c  |  64 +++-
 tools/libxl/libxl_checkpoint_device.c |  16 +-
 tools/libxl/libxl_colo_save.c |   4 +-
 tools/libxl/libxl_console.c   | 151 --
 tools/libxl/libxl_create.c|  17 +-
 tools/libxl/libxl_device.c| 256 ++
 tools/libxl/libxl_disk.c  |  99 
 tools/libxl/libxl_dm.c|  16 +-
 tools/libxl/libxl_internal.h  | 126 ++-
 tools/libxl/libxl_nic.c   | 199 +---
 tools/libxl/libxl_pci.c   |  10 +-
 tools/libxl/libxl_types.idl   |  36 +
 tools/libxl/libxl_types_internal.idl  |   1 +
 tools/libxl/libxl_usb.c   |  43 ++---
 tools/libxl/libxl_utils.h |   4 +
 tools/libxl/libxl_vdispl.c| 284 ++
 tools/libxl/libxl_vtpm.c  | 230 ---
 tools/ocaml/libs/xl/xenlight_stubs.c  |   6 +-
 tools/xl/Makefile |   1 +
 tools/xl/xl.h |   3 +
 tools/xl/xl_block.c   |   3 +-
 tools/xl/xl_cmdtable.c|  19 +++
 tools/xl/xl_nic.c |   3 +-
 tools/xl/xl_parse.c   |  75 -
 tools/xl/xl_parse.h   |   2 +-
 tools/xl/xl_vdispl.c  | 163 +++
 tools/xl/xl_vtpm.c|   3 +-
 31 files changed, 1281 insertions(+), 700 deletions(-)
 create mode 100644 tools/libxl/libxl_vdispl.c
 create mode 100644 tools/xl/xl_vdispl.c

-- 
2.7.4


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

[Xen-devel] [PATCH v5 05/12] docs: add PV display driver information

[Oleksandr Grytsov]

From: Oleksandr Grytsov 

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 
---
 docs/man/xl.cfg.pod.5.in | 49 
 docs/man/xl.pod.1.in | 42 +
 2 files changed, 91 insertions(+)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 79cb2ea..247ae99 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1116,6 +1116,55 @@ FIFO-based event channel ABI support up to 131,071 event 
channels.
 Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit
 x86).
 
+=item B
+
+Specifies the virtual display devices to be provided to the guest.
+
+Each B is a comma-separated list of C
+settings, from the following list:
+
+=over 4
+
+=item C
+
+Specifies the backend domain name or id. If not specified Domain-0 is used.
+
+=item C
+
+Indicates if backend can be a buffer provider/allocator for this domain. See
+display protocol for details.
+
+=item C
+
+Specifies virtual connectors for the device in following format
+:x;:x... where:
+
+=over 4
+
+=item C
+
+String connector ID. Space, comma symbols are not allowed.
+
+=item C
+
+Connector width in pixels.
+
+=item C
+
+Connector height in pixels.
+
+=back
+
+B
+
+=over 4
+
+connectors=id0:1920x1080;id1:800x600;id2:640x480
+
+=back
+
+=back
+
 =back
 
 =head2 Paravirtualised (PV) Guest Specific Options
diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index 3d5f2f7..cd8bb1c 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -1434,6 +1434,48 @@ List virtual Trusted Platform Modules for a domain.
 
 =back
 
+=head2 VDISPL DEVICES
+
+=over 4
+
+=item B I I
+
+Creates a new vdispl device in the domain specified by I.
+I describes the device to attach, using the same format as the
+B string in the domain config file. See L for
+more information.
+
+B
+
+=over 4
+
+As in I string semicolon is used then put quotes or escaping
+when using from the shell.
+
+B
+
+=over 4
+
+xl vdispl-attach DomU connectors='id0:1920x1080;id1:800x600;id2:640x480'
+
+or
+
+xl vdispl-attach DomU connectors=id0:1920x1080\;id1:800x600\;id2:640x480
+
+=back
+
+=back
+
+=item B I I
+
+Removes the vdispl device specified by I from the domain specified by 
I.
+
+=item B I
+
+List virtual displays for a domain.
+
+=back
+
 =head1 PCI PASS-THROUGH
 
 =over 4
-- 
2.7.4


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

[Xen-devel] [PATCH v5 01/12] libxl: add generic function to add device

[Oleksandr Grytsov]

From: Oleksandr Grytsov 

Add libxl__device_add to simple write XenStore device conifg
and libxl__device_add_async to update domain configuration
and write XenStore device config asynchroniously.
Almost all devices have similar libxl__device__add function.
This generic functions implement same functionality but
using the device handling framework. Th device specific
part such as setting xen store configurationis moved
to set_xenstore_config callback of the device framework.

Signed-off-by: Oleksandr Grytsov 
---
 tools/libxl/libxl_9pfs.c |   9 +-
 tools/libxl/libxl_console.c  |  20 ++---
 tools/libxl/libxl_create.c   |   6 +-
 tools/libxl/libxl_device.c   | 197 +++
 tools/libxl/libxl_disk.c |  15 ++--
 tools/libxl/libxl_dm.c   |   2 +-
 tools/libxl/libxl_internal.h |  45 --
 tools/libxl/libxl_nic.c  |  18 ++--
 tools/libxl/libxl_pci.c  |   7 +-
 tools/libxl/libxl_usb.c  |  35 
 tools/libxl/libxl_vtpm.c |  15 ++--
 11 files changed, 301 insertions(+), 68 deletions(-)

diff --git a/tools/libxl/libxl_9pfs.c b/tools/libxl/libxl_9pfs.c
index 07e3e5f..5443f7a 100644
--- a/tools/libxl/libxl_9pfs.c
+++ b/tools/libxl/libxl_9pfs.c
@@ -39,6 +39,7 @@ static int libxl__device_from_p9(libxl__gc *gc, uint32_t 
domid,
return 0;
 }
 
+static LIBXL_DEFINE_UPDATE_DEVID(p9, "9pfs")
 
 int libxl__device_p9_add(libxl__gc *gc, uint32_t domid,
  libxl_device_p9 *p9)
@@ -54,12 +55,8 @@ int libxl__device_p9_add(libxl__gc *gc, uint32_t domid,
 front = flexarray_make(gc, 16, 1);
 back = flexarray_make(gc, 16, 1);
 
-if (p9->devid == -1) {
-if ((p9->devid = libxl__device_nextid(gc, domid, "9pfs")) < 0) {
-rc = ERROR_FAIL;
-goto out;
-}
-}
+rc = libxl__device_p9_update_devid(gc, domid, p9);
+if (rc) goto out;
 
 rc = libxl__device_from_p9(gc, domid, p9, &device);
 if (rc != 0) goto out;
diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index 446e766..6181b05 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -621,6 +621,8 @@ out:
 return AO_INPROGRESS;
 }
 
+static LIBXL_DEFINE_UPDATE_DEVID(vkb, "vkb")
+
 int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
   libxl_device_vkb *vkb)
 {
@@ -635,12 +637,8 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
 front = flexarray_make(gc, 16, 1);
 back = flexarray_make(gc, 16, 1);
 
-if (vkb->devid == -1) {
-if ((vkb->devid = libxl__device_nextid(gc, domid, "vkb")) < 0) {
-rc = ERROR_FAIL;
-goto out;
-}
-}
+rc = libxl__device_vkb_update_devid(gc, domid, vkb);
+if (rc) goto out;
 
 rc = libxl__device_from_vkb(gc, domid, vkb, &device);
 if (rc != 0) goto out;
@@ -719,6 +717,8 @@ out:
 return AO_INPROGRESS;
 }
 
+static LIBXL_DEFINE_UPDATE_DEVID(vfb, "vfb")
+
 int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb)
 {
 flexarray_t *front;
@@ -732,12 +732,8 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, 
libxl_device_vfb *vfb)
 front = flexarray_make(gc, 16, 1);
 back = flexarray_make(gc, 16, 1);
 
-if (vfb->devid == -1) {
-if ((vfb->devid = libxl__device_nextid(gc, domid, "vfb")) < 0) {
-rc = ERROR_FAIL;
-goto out;
-}
-}
+rc = libxl__device_vfb_update_devid(gc, domid, vfb);
+if (rc) goto out;
 
 rc = libxl__device_from_vfb(gc, domid, vfb, &device);
 if (rc != 0) goto out;
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 9123585..efd1459 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -938,7 +938,8 @@ static void initiate_domain_create(libxl__egc *egc,
 store_libxl_entry(gc, domid, &d_config->b_info);
 
 for (i = 0; i < d_config->num_disks; i++) {
-ret = libxl__device_disk_setdefault(gc, &d_config->disks[i], domid);
+ret = libxl__device_disk_setdefault(gc, domid, &d_config->disks[i],
+false);
 if (ret) {
 LOGD(ERROR, domid, "Unable to set disk defaults for disk %d", i);
 goto error_out;
@@ -1432,6 +1433,9 @@ out:
 
 #define libxl_device_dtdev_list NULL
 #define libxl_device_dtdev_compare NULL
+#define libxl__device_from_dtdev NULL
+#define libxl__device_dtdev_setdefault NULL
+#define libxl__device_dtdev_update_devid NULL
 static DEFINE_DEVICE_TYPE_STRUCT(dtdev);
 
 const struct libxl_device_type *device_type_tbl[] = {
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 00356af..3296e83 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -1793,6 +1793,203 @@ out:
 return AO_CREATE_FAIL(rc);
 }
 
+static void device_add_domain_config(libxl__gc *gc,
+ libxl_domain_config *d_config,
+

[Xen-devel] [PATCH v5 04/12] xl: add PV display device commands

[Oleksandr Grytsov]

From: Oleksandr Grytsov 

Add commands: vdispl-attach, vdispl-list, vdispl-detach
and domain config vdispl parser

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 
---
 tools/xl/Makefile  |   1 +
 tools/xl/xl.h  |   3 +
 tools/xl/xl_cmdtable.c |  19 ++
 tools/xl/xl_parse.c|  75 ++-
 tools/xl/xl_parse.h|   2 +-
 tools/xl/xl_vdispl.c   | 163 +
 6 files changed, 261 insertions(+), 2 deletions(-)
 create mode 100644 tools/xl/xl_vdispl.c

diff --git a/tools/xl/Makefile b/tools/xl/Makefile
index c868899..41a09ed 100644
--- a/tools/xl/Makefile
+++ b/tools/xl/Makefile
@@ -21,6 +21,7 @@ XL_OBJS += xl_vtpm.o xl_block.o xl_nic.o xl_usb.o
 XL_OBJS += xl_sched.o xl_pci.o xl_vcpu.o xl_cdrom.o xl_mem.o
 XL_OBJS += xl_psr.o xl_info.o xl_console.o xl_misc.o
 XL_OBJS += xl_vmcontrol.o xl_saverestore.o xl_migrate.o
+XL_OBJS += xl_vdispl.o
 
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
 $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index 5d3d2a4..98d62e9 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -167,6 +167,9 @@ int main_blockdetach(int argc, char **argv);
 int main_vtpmattach(int argc, char **argv);
 int main_vtpmlist(int argc, char **argv);
 int main_vtpmdetach(int argc, char **argv);
+int main_vdisplattach(int argc, char **argv);
+int main_vdispllist(int argc, char **argv);
+int main_vdispldetach(int argc, char **argv);
 int main_usbctrl_attach(int argc, char **argv);
 int main_usbctrl_detach(int argc, char **argv);
 int main_usbdev_attach(int argc, char **argv);
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index ba0159d..d0330cd 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -377,6 +377,25 @@ struct cmd_spec cmd_table[] = {
   "Destroy a domain's virtual TPM device",
   " ",
 },
+{ "vdispl-attach",
+  &main_vdisplattach, 1, 1,
+  "Create a new virtual display device",
+  " [backend=] [be-alloc=] 
[connectors='']",
+  "BackAlloc  - set to 1 to if backend allocates display buffers\n"
+  "Connectors - list of connector's description in ID:WxH format,\n"
+  " where: ID - unique connector ID, W - connector 
width,\n"
+  " H - connector height: 
connectors='id0:800x600;id1:1024x768'\n"
+},
+{ "vdispl-list",
+  &main_vdispllist, 0, 0,
+  "List virtual display devices for a domain",
+  "",
+},
+{ "vdispl-detach",
+  &main_vdispldetach, 0, 1,
+  "Destroy a domain's virtual display device",
+  " ",
+},
 { "uptime",
   &main_uptime, 0, 0,
   "Print uptime for all/some domains",
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 02ddd2e..9965b83 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -804,6 +804,51 @@ int parse_usbdev_config(libxl_device_usbdev *usbdev, char 
*token)
 return 0;
 }
 
+int parse_vdispl_config(libxl_device_vdispl *vdispl, char *token)
+{
+char *oparg;
+libxl_string_list connectors = NULL;
+int i;
+int rc;
+
+if (MATCH_OPTION("backend", token, oparg)) {
+vdispl->backend_domname = strdup(oparg);
+} else if (MATCH_OPTION("be-alloc", token, oparg)) {
+vdispl->be_alloc = strtoul(oparg, NULL, 0);
+} else if (MATCH_OPTION("connectors", token, oparg)) {
+split_string_into_string_list(oparg, ";", &connectors);
+
+vdispl->num_connectors = libxl_string_list_length(&connectors);
+vdispl->connectors = calloc(vdispl->num_connectors,
+sizeof(*vdispl->connectors));
+
+for(i = 0; i < vdispl->num_connectors; i++)
+{
+char *resolution;
+
+rc = split_string_into_pair(connectors[i], ":",
+&vdispl->connectors[i].id,
+&resolution);
+
+rc= sscanf(resolution, "%ux%u", &vdispl->connectors[i].width,
+   &vdispl->connectors[i].height);
+if (rc != 2) {
+fprintf(stderr, "Can't parse connector resolution\n");
+goto out;
+}
+}
+} else {
+fprintf(stderr, "Unknown string \"%s\" in vdispl spec\n", token);
+rc = 1; goto out;
+}
+
+rc = 0;
+
+out:
+libxl_string_list_dispose(&connectors);
+return rc;
+}
+
 void parse_config_data(const char *config_source,
const char *config_data,
int config_len,
@@ -813,7 +858,7 @@ void parse_config_data(const char *config_source,
 long l, vcpus = 0;
 XLU_Config *config;
 XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
-   *usbctrls, *usbdevs, *p9devs;
+   *usbctrls, *usbdevs, *p9devs, *vdispls;
 XLU_ConfigList *channels, *ioports, *irqs, *iomem, *viridian, *dtdevs,
*mca_caps;
 int num_ioport

[Xen-devel] [PATCH v5 07/12] libxl: change vkb to use generec add function

[Oleksandr Grytsov]

From: Oleksandr Grytsov 

Signed-off-by: Oleksandr Grytsov 
---
 tools/libxl/libxl_console.c  | 74 +++-
 tools/libxl/libxl_create.c   |  5 +--
 tools/libxl/libxl_dm.c   |  6 ++--
 tools/libxl/libxl_internal.h |  6 +---
 4 files changed, 19 insertions(+), 72 deletions(-)

diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index 6181b05..e4a0daf 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -583,11 +583,10 @@ int libxl_device_channel_getinfo(libxl_ctx *ctx, uint32_t 
domid,
 return rc;
 }
 
-int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb)
+static int libxl__device_vkb_setdefault(libxl__gc *gc, uint32_t domid,
+libxl_device_vkb *vkb, bool hotplug)
 {
-int rc;
-rc = libxl__resolve_domid(gc, vkb->backend_domname, &vkb->backend_domid);
-return rc;
+return libxl__resolve_domid(gc, vkb->backend_domname, &vkb->backend_domid);
 }
 
 static int libxl__device_from_vkb(libxl__gc *gc, uint32_t domid,
@@ -604,66 +603,8 @@ static int libxl__device_from_vkb(libxl__gc *gc, uint32_t 
domid,
 return 0;
 }
 
-int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb,
- const libxl_asyncop_how *ao_how)
-{
-AO_CREATE(ctx, domid, ao_how);
-int rc;
-
-rc = libxl__device_vkb_add(gc, domid, vkb);
-if (rc) {
-LOGD(ERROR, domid, "Unable to add vkb device");
-goto out;
-}
-
-out:
-libxl__ao_complete(egc, ao, rc);
-return AO_INPROGRESS;
-}
-
 static LIBXL_DEFINE_UPDATE_DEVID(vkb, "vkb")
 
-int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
-  libxl_device_vkb *vkb)
-{
-flexarray_t *front;
-flexarray_t *back;
-libxl__device device;
-int rc;
-
-rc = libxl__device_vkb_setdefault(gc, vkb);
-if (rc) goto out;
-
-front = flexarray_make(gc, 16, 1);
-back = flexarray_make(gc, 16, 1);
-
-rc = libxl__device_vkb_update_devid(gc, domid, vkb);
-if (rc) goto out;
-
-rc = libxl__device_from_vkb(gc, domid, vkb, &device);
-if (rc != 0) goto out;
-
-flexarray_append(back, "frontend-id");
-flexarray_append(back, GCSPRINTF("%d", domid));
-flexarray_append(back, "online");
-flexarray_append(back, "1");
-flexarray_append(back, "state");
-flexarray_append(back, GCSPRINTF("%d", XenbusStateInitialising));
-
-flexarray_append(front, "backend-id");
-flexarray_append(front, GCSPRINTF("%d", vkb->backend_domid));
-flexarray_append(front, "state");
-flexarray_append(front, GCSPRINTF("%d", XenbusStateInitialising));
-
-libxl__device_generic_add(gc, XBT_NULL, &device,
-  libxl__xs_kvs_of_flexarray(gc, back),
-  libxl__xs_kvs_of_flexarray(gc, front),
-  NULL);
-rc = 0;
-out:
-return rc;
-}
-
 int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
 {
 int rc;
@@ -785,8 +726,17 @@ out:
  * 2. dynamically add/remove qemu chardevs via qmp messages. */
 
 /* vkb */
+
+#define libxl__add_vkbs NULL
+#define libxl_device_vkb_list NULL
+#define libxl_device_vkb_compare NULL
+
 LIBXL_DEFINE_DEVICE_REMOVE(vkb)
 
+DEFINE_DEVICE_TYPE_STRUCT(vkb,
+.skip_attach = 1
+);
+
 /* vfb */
 LIBXL_DEFINE_DEVICE_REMOVE(vfb)
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 26aa2a4..8c0c12d 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1349,7 +1349,7 @@ static void domcreate_launch_dm(libxl__egc *egc, 
libxl__multidev *multidev,
 }
 
 libxl_device_vkb_init(&vkb);
-libxl__device_vkb_add(gc, domid, &vkb);
+libxl__device_add(gc, domid, &libxl__vkb_devtype, &vkb);
 libxl_device_vkb_dispose(&vkb);
 
 dcs->sdss.dm.guest_domid = domid;
@@ -1375,7 +1375,8 @@ static void domcreate_launch_dm(libxl__egc *egc, 
libxl__multidev *multidev,
 
 for (i = 0; i < d_config->num_vfbs; i++) {
 libxl__device_vfb_add(gc, domid, &d_config->vfbs[i]);
-libxl__device_vkb_add(gc, domid, &d_config->vkbs[i]);
+libxl__device_add(gc, domid, &libxl__vkb_devtype,
+  &d_config->vkbs[i]);
 }
 
 init_console_info(gc, &console, 0);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index ee20930..0712a34 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1986,9 +1986,9 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
 goto out;
 }
 if (dm_config->num_vkbs) {
-ret = libxl__device_vkb_add(gc, dm_domid, &dm_config->vkbs[0]);
-if (ret)
-goto out;
+ret = libxl__device_add(gc, dm_domid, &libxl__vkb_devtype,
+&dm_config->vkbs[0]);
+if (ret) goto out;
 }
 
 if (guest_config->b_info.u.hvm.serial)
diff --git a/tools/lib

[Xen-devel] [PATCH v5 10/12] libxl: change nic to use generec add function

[Oleksandr Grytsov]

From: Oleksandr Grytsov 

Signed-off-by: Oleksandr Grytsov 
---
 tools/libxl/libxl.h   |   9 +-
 tools/libxl/libxl_checkpoint_device.c |   9 +-
 tools/libxl/libxl_colo_save.c |   4 +-
 tools/libxl/libxl_dm.c|   4 +-
 tools/libxl/libxl_internal.h  |   2 -
 tools/libxl/libxl_nic.c   | 191 +++---
 tools/ocaml/libs/xl/xenlight_stubs.c  |   3 +-
 tools/xl/xl_nic.c |   3 +-
 8 files changed, 52 insertions(+), 173 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index d5a3ab7..abe129e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1850,9 +1850,14 @@ int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t 
domid,
  const libxl_asyncop_how *ao_how)
  LIBXL_EXTERNAL_CALLERS_ONLY;
 
-libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int 
*num);
+libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx,
+uint32_t domid, int *num)
+LIBXL_EXTERNAL_CALLERS_ONLY;
+void libxl_device_nic_list_free(libxl_device_nic* list, int num)
+LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
-  libxl_device_nic *nic, libxl_nicinfo *nicinfo);
+ libxl_device_nic *nic, libxl_nicinfo *nicinfo)
+ LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /*
  * Virtual Channels
diff --git a/tools/libxl/libxl_checkpoint_device.c 
b/tools/libxl/libxl_checkpoint_device.c
index f6a4437..d1cc155 100644
--- a/tools/libxl/libxl_checkpoint_device.c
+++ b/tools/libxl/libxl_checkpoint_device.c
@@ -63,7 +63,8 @@ void libxl__checkpoint_devices_setup(libxl__egc *egc,
 cds->num_disks = 0;
 
 if (cds->device_kind_flags & (1 << LIBXL__DEVICE_KIND_VIF))
-cds->nics = libxl_device_nic_list(CTX, cds->domid, &cds->num_nics);
+cds->nics = libxl__device_list(gc, &libxl__nic_devtype, cds->domid,
+   "vif", &cds->num_nics);
 
 if (cds->device_kind_flags & (1 << LIBXL__DEVICE_KIND_VBD))
 cds->disks = libxl__device_list(gc, &libxl__disk_devtype, cds->domid,
@@ -206,8 +207,6 @@ static void devices_teardown_cb(libxl__egc *egc,
 libxl__multidev *multidev,
 int rc)
 {
-int i;
-
 STATE_AO_GC(multidev->ao);
 
 /* Convenience aliases */
@@ -215,9 +214,7 @@ static void devices_teardown_cb(libxl__egc *egc,
 CONTAINER_OF(multidev, *cds, multidev);
 
 /* clean nic */
-for (i = 0; i < cds->num_nics; i++)
-libxl_device_nic_dispose(&cds->nics[i]);
-free(cds->nics);
+libxl__device_list_free(&libxl__nic_devtype, cds->nics, cds->num_nics);
 cds->nics = NULL;
 cds->num_nics = 0;
 
diff --git a/tools/libxl/libxl_colo_save.c b/tools/libxl/libxl_colo_save.c
index f687d5a..8a9d37a 100644
--- a/tools/libxl/libxl_colo_save.c
+++ b/tools/libxl/libxl_colo_save.c
@@ -87,6 +87,7 @@ void libxl__colo_save_setup(libxl__egc *egc, 
libxl__colo_save_state *css)
 libxl__srm_save_autogen_callbacks *const callbacks =
 &dss->sws.shs.callbacks.save.a;
 libxl_device_nic *nics;
+int nb;
 
 STATE_AO_GC(dss->ao);
 
@@ -122,9 +123,10 @@ void libxl__colo_save_setup(libxl__egc *egc, 
libxl__colo_save_state *css)
 cds->device_kind_flags = (1 << LIBXL__DEVICE_KIND_VBD);
 
 /* Use this args we can connect to qemu colo-compare */
-nics = libxl_device_nic_list(CTX, cds->domid, &cds->num_nics);
+nics = libxl_device_nic_list(CTX, cds->domid, &nb);
 css->cps.checkpoint_host = nics->colo_checkpoint_host;
 css->cps.checkpoint_port = nics->colo_checkpoint_port;
+libxl_device_nic_list_free(nics, nb);
 } else {
 cds->device_kind_flags = (1 << LIBXL__DEVICE_KIND_VIF) |
  (1 << LIBXL__DEVICE_KIND_VBD);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 275fabc..98f89a9 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1975,8 +1975,8 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
  * called libxl_device_nic_add at this point, but qemu needs
  * the nic information to be complete.
  */
-ret = libxl__device_nic_setdefault(gc, dm_domid, &dm_config->nics[i],
-   false);
+ret = libxl__nic_devtype.set_default(gc, dm_domid, &dm_config->nics[i],
+ false);
 if (ret)
 goto out;
 }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index de1706c..976827a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1242,8 +1242,6 @@ _hidden int 
libxl__domain_create_i

[Xen-devel] [PATCH v5 08/12] libxl: change vfb to use generec add function

[Oleksandr Grytsov]

From: Oleksandr Grytsov 

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 
---
 tools/libxl/libxl_console.c  | 69 
 tools/libxl/libxl_create.c   |  3 +-
 tools/libxl/libxl_dm.c   |  6 ++--
 tools/libxl/libxl_internal.h |  6 +---
 4 files changed, 25 insertions(+), 59 deletions(-)

diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index e4a0daf..6dcad8a 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -605,7 +605,8 @@ static int libxl__device_from_vkb(libxl__gc *gc, uint32_t 
domid,
 
 static LIBXL_DEFINE_UPDATE_DEVID(vkb, "vkb")
 
-int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb)
+static int libxl__device_vfb_setdefault(libxl__gc *gc, uint32_t domid,
+libxl_device_vfb *vfb, bool hotplug)
 {
 int rc;
 
@@ -641,47 +642,13 @@ static int libxl__device_from_vfb(libxl__gc *gc, uint32_t 
domid,
 return 0;
 }
 
-int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb,
- const libxl_asyncop_how *ao_how)
-{
-AO_CREATE(ctx, domid, ao_how);
-int rc;
-
-rc = libxl__device_vfb_add(gc, domid, vfb);
-if (rc) {
-LOGD(ERROR, domid, "Unable to add vfb device");
-goto out;
-}
-
-out:
-libxl__ao_complete(egc, ao, rc);
-return AO_INPROGRESS;
-}
-
 static LIBXL_DEFINE_UPDATE_DEVID(vfb, "vfb")
 
-int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb)
+static int libxl__set_xenstore_vfb(libxl__gc *gc, uint32_t domid,
+   libxl_device_vfb *vfb,
+  flexarray_t *back, flexarray_t *front,
+  flexarray_t *ro_front)
 {
-flexarray_t *front;
-flexarray_t *back;
-libxl__device device;
-int rc;
-
-rc = libxl__device_vfb_setdefault(gc, vfb);
-if (rc) goto out;
-
-front = flexarray_make(gc, 16, 1);
-back = flexarray_make(gc, 16, 1);
-
-rc = libxl__device_vfb_update_devid(gc, domid, vfb);
-if (rc) goto out;
-
-rc = libxl__device_from_vfb(gc, domid, vfb, &device);
-if (rc != 0) goto out;
-
-flexarray_append_pair(back, "frontend-id", GCSPRINTF("%d", domid));
-flexarray_append_pair(back, "online", "1");
-flexarray_append_pair(back, "state", GCSPRINTF("%d", 
XenbusStateInitialising));
 flexarray_append_pair(back, "vnc",
   libxl_defbool_val(vfb->vnc.enable) ? "1" : "0");
 flexarray_append_pair(back, "vnclisten", vfb->vnc.listen);
@@ -701,17 +668,7 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, 
libxl_device_vfb *vfb)
 flexarray_append_pair(back, "display", vfb->sdl.display);
 }
 
-flexarray_append_pair(front, "backend-id",
-  GCSPRINTF("%d", vfb->backend_domid));
-flexarray_append_pair(front, "state", GCSPRINTF("%d", 
XenbusStateInitialising));
-
-libxl__device_generic_add(gc, XBT_NULL, &device,
-  libxl__xs_kvs_of_flexarray(gc, back),
-  libxl__xs_kvs_of_flexarray(gc, front),
-  NULL);
-rc = 0;
-out:
-return rc;
+return 0;
 }
 
 /* The following functions are defined:
@@ -737,9 +694,21 @@ DEFINE_DEVICE_TYPE_STRUCT(vkb,
 .skip_attach = 1
 );
 
+#define libxl__add_vfbs NULL
+#define libxl_device_vfb_list NULL
+#define libxl_device_vfb_compare NULL
+
 /* vfb */
 LIBXL_DEFINE_DEVICE_REMOVE(vfb)
 
+DEFINE_DEVICE_TYPE_STRUCT(vfb,
+.skip_attach = 1,
+.set_xenstore_config = (int (*)(libxl__gc *, uint32_t, void *,
+flexarray_t *back, flexarray_t *front,
+flexarray_t *ro_front))
+   libxl__set_xenstore_vfb
+);
+
 libxl_xen_console_reader *
 libxl_xen_console_read_start(libxl_ctx *ctx, int clear)
 {
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 8c0c12d..70048fe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1374,7 +1374,8 @@ static void domcreate_launch_dm(libxl__egc *egc, 
libxl__multidev *multidev,
 libxl__device device;
 
 for (i = 0; i < d_config->num_vfbs; i++) {
-libxl__device_vfb_add(gc, domid, &d_config->vfbs[i]);
+libxl__device_add(gc, domid, &libxl__vfb_devtype,
+  &d_config->vfbs[i]);
 libxl__device_add(gc, domid, &libxl__vkb_devtype,
   &d_config->vkbs[i]);
 }
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 0712a34..275fabc 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1981,9 +1981,9 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
 goto out;
 }
 if (dm_config->num_vfbs) {
-ret = libxl__device_vfb_add(gc, dm_domid, &dm_config->vfbs[0]);
-if (ret)
-got

[Xen-devel] [PATCH v5 09/12] libxl: change disk to use generic getting list functions

[Oleksandr Grytsov]

From: Oleksandr Grytsov 

Signed-off-by: Oleksandr Grytsov 
---
 tools/libxl/libxl.h   |  9 +++-
 tools/libxl/libxl_checkpoint_device.c |  7 ++-
 tools/libxl/libxl_create.c|  4 +-
 tools/libxl/libxl_disk.c  | 83 +--
 tools/libxl/libxl_internal.h  |  7 ---
 tools/ocaml/libs/xl/xenlight_stubs.c  |  3 +-
 tools/xl/xl_block.c   |  3 +-
 7 files changed, 34 insertions(+), 82 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index e386357..d5a3ab7 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1749,9 +1749,14 @@ int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t 
domid,
   const libxl_asyncop_how *ao_how)
   LIBXL_EXTERNAL_CALLERS_ONLY;
 
-libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t domid, int 
*num);
+libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx,
+  uint32_t domid, int *num)
+  LIBXL_EXTERNAL_CALLERS_ONLY;
+void libxl_device_disk_list_free(libxl_device_disk* list, int num)
+ LIBXL_EXTERNAL_CALLERS_ONLY;
 int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
-  libxl_device_disk *disk, libxl_diskinfo 
*diskinfo);
+  libxl_device_disk *disk, libxl_diskinfo 
*diskinfo)
+  LIBXL_EXTERNAL_CALLERS_ONLY;
 
 /*
  * Insert a CD-ROM device. A device corresponding to disk must already
diff --git a/tools/libxl/libxl_checkpoint_device.c 
b/tools/libxl/libxl_checkpoint_device.c
index 01e74b5..f6a4437 100644
--- a/tools/libxl/libxl_checkpoint_device.c
+++ b/tools/libxl/libxl_checkpoint_device.c
@@ -66,7 +66,8 @@ void libxl__checkpoint_devices_setup(libxl__egc *egc,
 cds->nics = libxl_device_nic_list(CTX, cds->domid, &cds->num_nics);
 
 if (cds->device_kind_flags & (1 << LIBXL__DEVICE_KIND_VBD))
-cds->disks = libxl_device_disk_list(CTX, cds->domid, &cds->num_disks);
+cds->disks = libxl__device_list(gc, &libxl__disk_devtype, cds->domid,
+"disk", &cds->num_disks);
 
 if (cds->num_nics == 0 && cds->num_disks == 0)
 goto out;
@@ -221,9 +222,7 @@ static void devices_teardown_cb(libxl__egc *egc,
 cds->num_nics = 0;
 
 /* clean disk */
-for (i = 0; i < cds->num_disks; i++)
-libxl_device_disk_dispose(&cds->disks[i]);
-free(cds->disks);
+libxl__device_list_free(&libxl__disk_devtype, cds->disks, cds->num_disks);
 cds->disks = NULL;
 cds->num_disks = 0;
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 70048fe..0ef54d2 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -938,8 +938,8 @@ static void initiate_domain_create(libxl__egc *egc,
 store_libxl_entry(gc, domid, &d_config->b_info);
 
 for (i = 0; i < d_config->num_disks; i++) {
-ret = libxl__device_disk_setdefault(gc, domid, &d_config->disks[i],
-false);
+ret = libxl__disk_devtype.set_default(gc, domid, &d_config->disks[i],
+  false);
 if (ret) {
 LOGD(ERROR, domid, "Unable to set disk defaults for disk %d", i);
 goto error_out;
diff --git a/tools/libxl/libxl_disk.c b/tools/libxl/libxl_disk.c
index 91c77ad..0f72874 100644
--- a/tools/libxl/libxl_disk.c
+++ b/tools/libxl/libxl_disk.c
@@ -152,8 +152,8 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, 
libxl_evgen_disk_eject *evg) {
 GC_FREE;
 }
 
-int libxl__device_disk_setdefault(libxl__gc *gc, uint32_t domid,
-  libxl_device_disk *disk, bool hotplug)
+static int libxl__device_disk_setdefault(libxl__gc *gc, uint32_t domid,
+ libxl_device_disk *disk, bool hotplug)
 {
 int rc;
 
@@ -181,7 +181,7 @@ int libxl__device_disk_setdefault(libxl__gc *gc, uint32_t 
domid,
 return rc;
 }
 
-int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
+static int libxl__device_from_disk(libxl__gc *gc, uint32_t domid,
const libxl_device_disk *disk,
libxl__device *device)
 {
@@ -472,17 +472,15 @@ static void libxl__device_disk_add(libxl__egc *egc, 
uint32_t domid,
 device_disk_add(egc, domid, disk, aodev, NULL, NULL);
 }
 
-static int libxl__device_disk_from_xenstore(libxl__gc *gc,
- const char *libxl_path,
- libxl_device_disk *disk)
+static int libxl__disk_from_xenstore(libxl__gc *gc, const char *libxl_path,
+ libxl_devid devid,
+ libxl_device_disk *disk)
 {
 libxl_ctx *ctx = libxl__gc_owner(gc);
 unsigned i

[Xen-devel] [PATCH v5 02/12] libxl: add generic functions to get and free device list

[Oleksandr Grytsov]

From: Oleksandr Grytsov 

Add libxl__device_list and libxl__device_list_free
functions to handle device list using the device
framework.

Signed-off-by: Oleksandr Grytsov 
---
 tools/libxl/libxl_device.c   | 61 
 tools/libxl/libxl_internal.h |  8 ++
 2 files changed, 69 insertions(+)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 3296e83..487be28 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -1990,6 +1990,67 @@ out:
 return rc;
 }
 
+void *libxl__device_list(libxl__gc *gc, const struct libxl_device_type *dt,
+ uint32_t domid, const char* name, int *num)
+{
+void *r = NULL;
+void *list = NULL;
+void *item = NULL;
+char *libxl_path;
+char **dir = NULL;
+unsigned int ndirs = 0;
+int rc;
+
+*num = 0;
+
+libxl_path = GCSPRINTF("%s/device/%s",
+   libxl__xs_libxl_path(gc, domid), name);
+
+dir = libxl__xs_directory(gc, XBT_NULL, libxl_path, &ndirs);
+
+if (dir && ndirs) {
+list = libxl__malloc(NOGC, dt->dev_elem_size * ndirs);
+item = list;
+
+while (*num < ndirs) {
+dt->init(item);
+++(*num);
+
+if (dt->from_xenstore) {
+char *device_libxl_path = GCSPRINTF("%s/%s", libxl_path, *dir);
+rc = dt->from_xenstore(gc, device_libxl_path, atoi(*dir), 
item);
+if (rc) goto out;
+}
+
+item = (uint8_t *)item + dt->dev_elem_size;
+++dir;
+}
+}
+
+r = list;
+list = NULL;
+
+out:
+
+if (list) {
+libxl__device_list_free(dt, list, *num);
+*num = 0;
+}
+
+return r;
+}
+
+void libxl__device_list_free(const struct libxl_device_type *dt,
+ void *list, int num)
+{
+int i;
+
+for (i = 0; i < num; i++)
+dt->dispose((uint8_t*)list + i * dt->dev_elem_size);
+
+free(list);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c99ef3b..c94a117 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3505,6 +3505,7 @@ struct libxl_device_type {
 int (*dm_needed)(void *, unsigned);
 void (*update_config)(libxl__gc *, void *, void *);
 int (*update_devid)(libxl__gc *, uint32_t, void *);
+int (*from_xenstore)(libxl__gc *, const char *, libxl_devid, void *);
 int (*set_xenstore_config)(libxl__gc *, uint32_t, void *, flexarray_t *,
flexarray_t *, flexarray_t *);
 };
@@ -4385,6 +4386,13 @@ void libxl__device_add_async(libxl__egc *egc, uint32_t 
domid,
 int libxl__device_add(libxl__gc *gc, uint32_t domid,
   const struct libxl_device_type *dt, void *type);
 
+/* Caller is responsible for freeing the memory by calling
+ * libxl__device_list_free
+ */
+void* libxl__device_list(libxl__gc *gc, const struct libxl_device_type *dt,
+ uint32_t domid, const char* name, int *num);
+void libxl__device_list_free(const struct libxl_device_type *dt,
+ void *list, int num);
 #endif
 
 /*
-- 
2.7.4


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

[Xen-devel] [PATCH v5 06/12] libxl: change p9 to use generec add function

[Oleksandr Grytsov]

From: Oleksandr Grytsov 

Signed-off-by: Oleksandr Grytsov 
---
 tools/libxl/libxl_9pfs.c | 59 
 tools/libxl/libxl_create.c   |  2 +-
 tools/libxl/libxl_internal.h |  7 +-
 3 files changed, 23 insertions(+), 45 deletions(-)

diff --git a/tools/libxl/libxl_9pfs.c b/tools/libxl/libxl_9pfs.c
index 5443f7a..61d284c 100644
--- a/tools/libxl/libxl_9pfs.c
+++ b/tools/libxl/libxl_9pfs.c
@@ -17,12 +17,10 @@
 
 #include "libxl_internal.h"
 
-int libxl__device_p9_setdefault(libxl__gc *gc, libxl_device_p9 *p9)
+static int libxl__device_p9_setdefault(libxl__gc *gc, uint32_t domid,
+   libxl_device_p9 *p9, bool hotplug)
 {
-int rc;
-
-rc = libxl__resolve_domid(gc, p9->backend_domname, &p9->backend_domid);
-return rc;
+return libxl__resolve_domid(gc, p9->backend_domname, &p9->backend_domid);
 }
 
 static int libxl__device_from_p9(libxl__gc *gc, uint32_t domid,
@@ -41,44 +39,29 @@ static int libxl__device_from_p9(libxl__gc *gc, uint32_t 
domid,
 
 static LIBXL_DEFINE_UPDATE_DEVID(p9, "9pfs")
 
-int libxl__device_p9_add(libxl__gc *gc, uint32_t domid,
- libxl_device_p9 *p9)
+static int libxl__set_xenstore_p9(libxl__gc *gc, uint32_t domid,
+  libxl_device_p9 *p9,
+  flexarray_t *back, flexarray_t *front,
+  flexarray_t *ro_front)
 {
-flexarray_t *front;
-flexarray_t *back;
-libxl__device device;
-int rc;
-
-rc = libxl__device_p9_setdefault(gc, p9);
-if (rc) goto out;
-
-front = flexarray_make(gc, 16, 1);
-back = flexarray_make(gc, 16, 1);
-
-rc = libxl__device_p9_update_devid(gc, domid, p9);
-if (rc) goto out;
-
-rc = libxl__device_from_p9(gc, domid, p9, &device);
-if (rc != 0) goto out;
-
-flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", 
domid));
-flexarray_append_pair(back, "online", "1");
-flexarray_append_pair(back, "state", GCSPRINTF("%d", 
XenbusStateInitialising));
-flexarray_append_pair(front, "backend-id",
-  libxl__sprintf(gc, "%d", p9->backend_domid));
-flexarray_append_pair(front, "state", GCSPRINTF("%d", 
XenbusStateInitialising));
-flexarray_append_pair(front, "tag", p9->tag);
 flexarray_append_pair(back, "path", p9->path);
 flexarray_append_pair(back, "security_model", p9->security_model);
 
-libxl__device_generic_add(gc, XBT_NULL, &device,
-  libxl__xs_kvs_of_flexarray(gc, back),
-  libxl__xs_kvs_of_flexarray(gc, front),
-  NULL);
-rc = 0;
-out:
-return rc;
+flexarray_append_pair(front, "tag", p9->tag);
+
+return 0;
 }
 
+#define libxl__add_p9s NULL
+#define libxl_device_p9_list NULL
+#define libxl_device_p9_compare NULL
+
 LIBXL_DEFINE_DEVICE_REMOVE(p9)
 
+DEFINE_DEVICE_TYPE_STRUCT(p9,
+.skip_attach = 1,
+.set_xenstore_config = (int (*)(libxl__gc *, uint32_t, void *,
+flexarray_t *back, flexarray_t *front,
+flexarray_t *ro_front))
+   libxl__set_xenstore_p9
+);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f20bbf9..26aa2a4 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1328,7 +1328,7 @@ static void domcreate_launch_dm(libxl__egc *egc, 
libxl__multidev *multidev,
 }
 
 for (i = 0; i < d_config->num_p9s; i++)
-libxl__device_p9_add(gc, domid, &d_config->p9s[i]);
+libxl__device_add(gc, domid, &libxl__p9_devtype, &d_config->p9s[i]);
 
 switch (d_config->c_info.type) {
 case LIBXL_DOMAIN_TYPE_HVM:
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c6f5868..87f6d32 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1251,8 +1251,6 @@ _hidden int libxl__device_vfb_setdefault(libxl__gc *gc, 
libxl_device_vfb *vfb);
 _hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb);
 _hidden void libxl__rdm_setdefault(libxl__gc *gc,
libxl_domain_build_info *b_info);
-_hidden int libxl__device_p9_setdefault(libxl__gc *gc,
-libxl_device_p9 *p9);
 
 _hidden const char *libxl__device_nic_devname(libxl__gc *gc,
   uint32_t domid,
@@ -2667,10 +2665,6 @@ _hidden int libxl__device_vkb_add(libxl__gc *gc, 
uint32_t domid,
 _hidden int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid,
   libxl_device_vfb *vfb);
 
-/* Internal function to connect a 9pfs device */
-_hidden int libxl__device_p9_add(libxl__gc *gc, uint32_t domid,
- libxl_device_p9 *p9);
-
 /* Waits for the passed device to reach state XenbusStateInitWait.
  * This is not really u

[Xen-devel] [PATCH v5 12/12] libxl: remove unneeded DEVICE_ADD macro

[Oleksandr Grytsov]

From: Oleksandr Grytsov 

Signed-off-by: Oleksandr Grytsov 
Acked-by: Wei Liu 
---
 tools/libxl/libxl_device.c   |  6 ++---
 tools/libxl/libxl_disk.c |  5 +++--
 tools/libxl/libxl_internal.h | 52 +++-
 tools/libxl/libxl_pci.c  |  3 ++-
 tools/libxl/libxl_usb.c  |  8 +++
 5 files changed, 14 insertions(+), 60 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 487be28..67b7afb 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -1793,10 +1793,8 @@ out:
 return AO_CREATE_FAIL(rc);
 }
 
-static void device_add_domain_config(libxl__gc *gc,
- libxl_domain_config *d_config,
- const struct libxl_device_type *dt,
- void *type)
+void device_add_domain_config(libxl__gc *gc, libxl_domain_config *d_config,
+  const struct libxl_device_type *dt, void *type)
 {
 int *num_dev;
 unsigned int i;
diff --git a/tools/libxl/libxl_disk.c b/tools/libxl/libxl_disk.c
index 0f72874..e36c7bf 100644
--- a/tools/libxl/libxl_disk.c
+++ b/tools/libxl/libxl_disk.c
@@ -277,7 +277,8 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid,
 rc = libxl__get_domain_configuration(gc, domid, &d_config);
 if (rc) goto out;
 
-DEVICE_ADD(disk, disks, domid, &disk_saved, COMPARE_DISK, &d_config);
+device_add_domain_config(gc, &d_config, &libxl__disk_devtype,
+ &disk_saved);
 
 rc = libxl__dm_check_start(gc, &d_config, domid);
 if (rc) goto out;
@@ -832,7 +833,7 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, 
libxl_device_disk *disk,
 rc = libxl__get_domain_configuration(gc, domid, &d_config);
 if (rc) goto out;
 
-DEVICE_ADD(disk, disks, domid, &disk_saved, COMPARE_DISK, &d_config);
+device_add_domain_config(gc, &d_config, &libxl__disk_devtype, &disk_saved);
 
 rc = libxl__dm_check_start(gc, &d_config, domid);
 if (rc) goto out;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 976827a..81e87ae 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4281,55 +4281,6 @@ void libxl__xcinfo2xlinfo(libxl_ctx *ctx,
(a)->port == (b)->port)
 #define COMPARE_USBCTRL(a, b) ((a)->devid == (b)->devid)
 
-/* DEVICE_ADD
- *
- * Add a device in libxl_domain_config structure
- *
- * It takes 6 parameters:
- *  type: the type of the device, say nic, vtpm, disk, pci etc
- *  ptr:  pointer to the start of the array, the array must be
- *of type libxl_device_#type
- *  domid:domain id of target domain
- *  dev:  the device that is to be added / removed / updated
- *  compare:  the COMPARE_* macro used to compare @dev's identifier to
- *those in the array pointed to by @ptr
- *  d_config: pointer to template domain config
- *
- * For most device types (nic, vtpm), the array pointer @ptr can be
- * derived from @type, pci device being the exception, hence we need
- * to have @ptr.
- *
- * If there is already a device with the same identifier in d_config,
- * that entry is updated.
- */
-#define DEVICE_ADD(type, ptr, domid, dev, compare, d_config)\
-({  \
-int DA_x;   \
-libxl_device_##type *DA_p = NULL;   \
-\
-/* Check for existing device */ \
-for (DA_x = 0; DA_x < (d_config)->num_##ptr; DA_x++) {  \
-if (compare(&(d_config)->ptr[DA_x], (dev))) {   \
-DA_p = &(d_config)->ptr[DA_x];  \
-break;  \
-}   \
-}   \
-\
-if (!DA_p) {\
-(d_config)->ptr =   \
-libxl__realloc(NOGC, (d_config)->ptr,   \
-   ((d_config)->num_##ptr + 1) *\
-   sizeof(libxl_device_##type));\
-DA_p = &(d_config)->ptr[(d_config)->num_##ptr]; \
-(d_config)->num_##ptr++;\
-} else {\
-libxl_device_##type##_dispose(DA_p);\
-}   \
-\
-libxl_device_##type##_init(DA_p);   \
-libxl_device_##type##_copy(CTX, D

[Xen-devel] [PATCH RFC v2] Add SUPPORT.md

[George Dunlap]

Add a machine-readable file to describe what features are in what
state of being 'supported', as well as information about how long this
release will be supported, and so on.

The document should be formatted using "semantic newlines" [1], to make
changes easier.

Signed-off-by: Ian Jackson 
Signed-off-by: George Dunlap 

[1] http://rhodesmill.org/brandon/2012/one-sentence-per-line/
---

Sorry, I wrote a 'changes since v1' but managed to lose it.  I'll
reply to this mail tomorrow with a list of changes.

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Tim Deegan 
CC: Dario Faggioli 
CC: Tamas K Lengyel 
CC: Roger Pau Monne 
CC: Stefano Stabellini 
CC: Anthony Perard 
CC: Paul Durrant 
CC: Konrad Wilk 
CC: Julien Grall 
---
 SUPPORT.md | 821 +
 1 file changed, 821 insertions(+)
 create mode 100644 SUPPORT.md

diff --git a/SUPPORT.md b/SUPPORT.md
new file mode 100644
index 00..e30664feca
--- /dev/null
+++ b/SUPPORT.md
@@ -0,0 +1,821 @@
+# Support statement for this release
+
+This document describes the support status and in particular the
+security support status of the Xen branch within which you find it.
+
+See the bottom of the file for the definitions of the support status
+levels etc.
+
+# Release Support
+
+Xen-Version: 4.10-unstable
+Initial-Release: n/a
+Supported-Until: TBD
+Security-Support-Until: Unreleased - not yet security-supported
+
+# Feature Support
+
+## Host Architecture
+
+### x86-64
+
+Status: Supported
+
+### ARM v7 + Virtualization Extensions
+
+Status: Supported
+
+### ARM v8
+
+Status: Supported
+
+## Guest Type
+
+### x86/PV
+
+Status: Supported
+
+Traditional Xen Project PV guest
+
+### x86/HVM
+
+Status: Supported
+
+Fully virtualised guest using hardware virtualisation extensions
+
+Requires hardware virtualisation support
+
+### x86/PVH guest
+
+Status: Tech Preview
+
+PVHv2 guest support
+
+Requires hardware virtualisation support
+
+### ARM guest
+
+Status: Supported
+
+ARM only has one guest type at the moment
+
+## Limits/Host
+
+### CPUs
+
+Limit, x86: 4095
+Limit, ARM32: 8
+Limit, ARM64: 128
+
+Note that for x86, very large number of cpus may not work/boot,
+but we will still provide security support
+
+### x86/RAM
+
+Limit, x86: 16TiB
+Limit, ARM32: 16GiB
+Limit, ARM64: 5TiB
+
+[XXX: Andy to suggest what this should say for x86]
+
+## Limits/Guest
+
+### Virtual CPUs
+
+Limit, x86 PV: 512
+Limit, x86 HVM: 128
+Limit, ARM32: 8
+Limit, ARM64: 128
+
+[XXX Andrew Cooper: Do want to add "Limit-Security" here for some of these?]
+
+### Virtual RAM
+
+Limit, x86 PV: >1TB
+Limit, x86 HVM: 1TB
+Limit, ARM32: 16GiB
+Limit, ARM64: 1TB
+
+### x86 PV/Event Channels
+
+Limit: 131072
+
+## Toolstack
+
+### xl
+
+Status: Supported
+
+### Direct-boot kernel image format
+
+Supported, x86: bzImage
+Supported, ARM32: zImage
+Supported, ARM64: Image
+
+Format which the toolstack accept for direct-boot kernels
+
+### Qemu based disk backend (qdisk) for xl
+
+Status: Supported
+
+### Open vSwitch integration for xl
+
+Status: Supported
+
+### systemd support for xl
+
+Status: Supported
+
+### JSON output support for xl
+
+Status: Experimental
+
+Output of information in machine-parseable JSON format
+
+### AHCI support for xl
+
+Status, x86: Supported
+
+### ACPI guest
+
+Status, x86 HVM: Supported
+Status, ARM: Tech Preview
+
+### PVUSB support for xl
+
+Status: Supported
+
+### HVM USB passthrough for xl
+
+Status, x86: Supported
+
+### QEMU backend hotplugging for xl
+
+Status: Supported
+
+### Virtual cpu hotplug
+
+Status: Supported
+
+## Toolstack/3rd party
+
+### libvirt driver for xl
+
+Status: Supported, Security support external
+
+## Debugging, analysis, and crash post-mortem
+
+### gdbsx
+
+Status, x86: Supported
+
+Debugger to debug ELF guests
+
+### Guest serial sonsole
+
+Status: Supported
+
+Logs key hypervisor and Dom0 kernel events to a file
+
+### Soft-reset for PV guests
+
+Status: Supported
+   
+Soft-reset allows a new kernel to start 'from scratch' with a fresh VM state, 
+but with all the memory from the previous state of the VM intact.
+This is primarily designed to allow "crash kernels", 
+which can do core dumps of memory to help with debugging in the event of a 
crash.
+
+### xentrace
+
+Status, x86: Supported
+
+Tool to capture Xen trace buffer data
+
+### gcov
+
+Status: Supported, Not security supported
+
+Export hypervisor coverage data suitable for analysis by gcov or lcov.
+
+## Memory Management
+
+### Memory Ballooning
+
+Status: Supported
+
+### Memory Sharing
+
+Status, x86 HVM: Tech Preview
+Status, ARM: Tech Preview
+
+Allow sharing of identical pages between guests
+
+### Memory Paging
+
+Status, x86 HVM: Experimenal
+
+Allow pages belonging to guests to be p

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[Stefano Stabellini]

On Mon, 11 Sep 2017, Julien Grall wrote:
> On 07/09/17 22:54, Stefano Stabellini wrote:
> > On Thu, 31 Aug 2017, George Dunlap wrote:
> > > +### Direct-boot kernel image format
> > > +
> > > +Supported, x86: bzImage
> > > +Supported, ARM32: zImage
> > > +Supported, ARM64: Image [XXX - Not sure if this is correct]
> > 
> > On ARM64 it's called Image.gz.
> 
> That's not true. Linux produces an Image. You can compress after if you want,
> but it is not the default.

Are you sure? Why do you say Image it's the default? If I do `make
help', the result is:


Architecture specific targets (arm64):
* Image.gz  - Compressed kernel image (arch/arm64/boot/Image.gz)
  Image - Uncompressed kernel image (arch/arm64/boot/Image)
* dtbs  - Build device tree blobs for enabled boards
  dtbs_install  - Install dtbs to /boot/dtbs/4.13.0-rc1+
  install   - Install uncompressed kernel
  zinstall  - Install compressed kernel
  Install using (your) ~/bin/installkernel or
  (distribution) /sbin/installkernel or
  install to $(INSTALL_PATH) and run lilo


Note that the default build targets are the ones that are starred.

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

Re: [Xen-devel] [PATCH 26/27 v8] xen/arm: vpl011: Correct the logic for asserting/de-asserting SBSA UART TX interrupt

[Bhupinder Thakur]

Hi Andre,


>> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
>> index 56d9cbe..1e72fca 100644
>> --- a/xen/arch/arm/vpl011.c
>> +++ b/xen/arch/arm/vpl011.c
>> @@ -152,12 +152,20 @@ static void vpl011_write_data(struct domain *d, 
>> uint8_t data)
>>  else
>>  gprintk(XENLOG_ERR, "vpl011: Unexpected OUT ring buffer full\n");
>>
>> -if ( xencons_queued(out_prod, out_cons, sizeof(intf->out)) ==
>> - sizeof (intf->out) )
>> -{
>> -vpl011->uartfr |= TXFF;
>> +/*
>> + * Ensure that there is space for atleast 16 bytes before asserting the
>> + * TXI interrupt status bit because the SBSA UART driver may write
>> + * 16 bytes (i.e. half the SBSA UART fifo size of 32) on getting
>> + * a TX interrupt.
>> + */
>> +if ( xencons_queued(out_prod, out_cons, sizeof(intf->out)) <=
>> + (sizeof (intf->out) - 16) )
>> +vpl011->uartris |= TXI;
>> +else if ( xencons_queued(out_prod, out_cons, sizeof(intf->out)) !=
>> +  sizeof (intf->out) )
>
> Now this is really hard to read. Can't you use:
>
> fifo_level = xencons_queued(out_prod, out_cons, sizeof(intf->out));

ok.

>
> Also I think you could start the patch a few lines above, where you
> check for any free space in the buffer.

ok. I will move the logic inside the case when there is space in the buffer.

>
>>  vpl011->uartris &= ~TXI;
>> -}
>> +else
>> +vpl011->uartfr |= TXFF;
>
> And I believe we should separate the FIFO full condition from the
> interrupt condition. I think it should more look like:
>
> vpl011->uartfr |= BUSY;
> vpl011->uartfr &= ~TXFE;
>
> if ( fifo_level == sizeof(intf->out) )
> vpl011->uartfr |= TXFF;
>
> if ( fifo_level >= sizeof(intf->out) - 16 )
> vpl011->uartris &= ~TXI;
>
> Which is much easier to read and understand, also follows the spec
> closely. The "16" should be either expressed at FIFOSIZE / 2 or
> explained in a comment.
ok.

>
>>
>>  vpl011->uartfr |= BUSY;
>>
>> @@ -368,7 +376,16 @@ static void vpl011_data_avail(struct domain *d)
>>  if ( out_ring_qsize != sizeof(intf->out) )
>>  {
>>  vpl011->uartfr &= ~TXFF;
>> -vpl011->uartris |= TXI;
>> +
>> +/*
>> + * Ensure that there is space for atleast 16 bytes before asserting 
>> the
>> + * TXI interrupt status bit because the SBSA UART driver may write 
>> upto
>> + * 16 bytes (i.e. half the SBSA UART fifo size of 32) on getting
>> + * a TX interrupt.
>
> The comment sounds a bit like this is hack, where it actually is a
> totally legit spec requirement (the interrupt is asserted/deasserted
> around the *trigger level*, which is half way by default and always half
> for the SBSA).
ok. I will modify the comment to mention that TX interrupt is
asserted/de-aserted based
on the trigger level which is fifo_size/2.

>
> Also I think the same logic/fix needs to be applied to the receiving side.
>
That may delay the processing of incoming data. To verify that I
changed the code to assert the RX interrupt only
when the RX FIFO becomes half full. With that change, the input data
is delayed as the SBSA UART driver starts
processing the incoming data only when the RX interrupt is asserted.

> And while I see that Julien requested a follow-up patch, I believe this
> should eventually be squashed into 02/27, to not have wrong code in the
> repo. But can could be done at commit time, I guess.
>
ok.

Regards,
Bhupinder

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

Re: [Xen-devel] [RFC XEN PATCH v3 12/39] tools/xen-ndctl: add NVDIMM management util 'xen-ndctl'

[Dan Williams]

On Sun, Sep 10, 2017 at 10:39 PM, Haozhong Zhang
 wrote:
> On 09/10/17 22:10 -0700, Dan Williams wrote:
>> On Sun, Sep 10, 2017 at 9:37 PM, Haozhong Zhang
>>  wrote:
>> > The kernel NVDIMM driver and the traditional NVDIMM management
>> > utilities in Dom0 does not work now. 'xen-ndctl' is added as an
>> > alternatively, which manages NVDIMM via Xen hypercalls.
>> >
>> > Signed-off-by: Haozhong Zhang 
>> > ---
>> > Cc: Ian Jackson 
>> > Cc: Wei Liu 
>> > ---
>> >  .gitignore |   1 +
>> >  tools/misc/Makefile|   4 ++
>> >  tools/misc/xen-ndctl.c | 172 
>> > +
>> >  3 files changed, 177 insertions(+)
>> >  create mode 100644 tools/misc/xen-ndctl.c
>>
>> What about my offer to move this functionality into the upstream ndctl
>> utility [1]? I think it is thoroughly confusing that you are reusing
>> the name 'ndctl' and avoiding integration with the upstream ndctl
>> utility.
>>
>> [1]: https://patchwork.kernel.org/patch/9632865/
>
> I'm not object to integrate it with ndctl.
>
> My only concern is that the integration will introduces two types of
> user interface. The upstream ndctl works with the kernel driver and
> provides easily used *names* (e.g., namespace0.0, region0, nmem0,
> etc.) for user input. However, this version patchset hides NFIT from
> Dom0 (to simplify the first implementation), so the kernel driver does
> not work in Dom0, neither does ndctl. Instead, xen-ndctl has to use
> *the physical address* for users to specify their interested NVDIMM
> region, which is different from upstream ndctl.

Ok, I think this means that xen-ndctl should be renamed (xen-nvdimm?)
so that the distinction between the 2 tools is clear.

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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[George Dunlap]

On 09/11/2017 05:16 PM, Julien Grall wrote:
> 
> 
> On 11/09/17 15:16, George Dunlap wrote:
>> On 09/07/2017 10:54 PM, Stefano Stabellini wrote:
>>> On Thu, 31 Aug 2017, George Dunlap wrote:
 +### Direct-boot kernel image format
 +
 +    Supported, x86: bzImage
 +    Supported, ARM32: zImage
 +    Supported, ARM64: Image [XXX - Not sure if this is correct]
>>>
>>> On ARM64 it's called Image.gz.
>>
>> Ack.
 +### vTPM Support
 +
 +    Status: Supported, x86 only
>>>
>>> This should probably be x86/vTPM. TPM, the way we are discussing it, is
>>> an x86-only implementation. ARM-based alternatives are not called TPM
>>> AFAIK.
>>
>> Someone said that because this was implemented entirely in userspace,
>> there's no reason the PV TPM couldn't work on ARM.  OTOH I suppose it
>> would be a lot less valuable if there weren't a physical TPM to back
>> it up.
>>
>> Any thoughts on that?
> 
> Per my understanding TPM is a specification and not tie to Arm, x86 or
> else. So if providing the PV driver is agnostic to x86 it should work.
> Note that I haven't looked at the code nor I am aware of some that
> tested it.

OK -- in my local copy I'm not making a distinction between x86 and ARM
then.

But I do wonder if we should make this 'Tech Preview', since it's not
being tested by osstest, and the most recent message from the maintainer
wasn't terribly promising [1].

 -George

[1]
marc.info/?i=

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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[Julien Grall]

On 11/09/17 17:15, George Dunlap wrote:

On 09/11/2017 04:54 PM, Julien Grall wrote:

Hi,

Sorry I missed e-mail. It seems I was not CCed on it.


Sorry -- already had a pretty large CC list.  I'll add you for the next one.



+### ARM/SMMU
+
+Status: Supported, with caveats
+
+Only ARM SMMU hardware is supported; non-ARM SMMU hardware is not
supported.


I'm not sure of the purpose of this sentence, it's quite clear that
the SMMU is only supported if available. Also, I'm not sure this
should be spelled out in this document, x86 doesn't have a VT-d or SVM
section.


As George wrote, there are many SMMUs in the market for ARM based
platforms, not all of them of ARM design.


Few remarks here.

Firstly, what do you mean by Arm design? Is it spec compliant (i.e
SMMUv1, SMMUv2, SMMUv3) ? Or is it implementation coming from Arm
(SMMU-400, SMMU-401, SMMU-500,...)?


Well as you and Stefano are going to be primarily doing security
support, I think whatever you think is most reasonable for you to
support, and whatever communicates best to your users what functionality
actually works and what will be security supported.


At the moment we have no support of SMMUv3 at all (this would be a
separate driver as the spec is very different).

Regarding SMMUv1 and SMMUv2. Technically we should support all SMMUs
which are compliant with the spec, providing there are no workaround
necessary (yes there are some hardware only 99.9% compliant).

But, we can't even claim that we support Arm implementation. At least
SMMU-401 (used by Seattle and Versatile Express) is not supported.

Furthermore, Arm may release new IP in the future. Does it mean we
support them by default?

So there are some clarifications needed on what we actually support.

If we decide the support status is based on hardware, then it raise the
questions on what about other specifications (e.g GICv2, GICv3, GICv4)?
Each vendor is free to provide its own implementation (not necessarily
bug free and fully compliant).


On the whole it sounds like we ought to have separate stanzas for SMMUv1
and SMMUv2.

I'd say focus on accurately implementing the spec.  Call out specific
non-compliant implementations as and when you feel like you need to be
specific.

Shall I make this:

---
### ARM/SMMUv1

 Status: Supported

### ASM/SMMUv2

 Status: Supported
---

Will that communicate effectively that you only support ARM-spec SMMUs?
Or do we need to add some extra verbiage to make sure people know that
non-ARM specs are not supported?


I think this would be fine.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[Julien Grall]

On 11/09/17 15:16, George Dunlap wrote:

On 09/07/2017 10:54 PM, Stefano Stabellini wrote:

On Thu, 31 Aug 2017, George Dunlap wrote:

+### Direct-boot kernel image format
+
+Supported, x86: bzImage
+Supported, ARM32: zImage
+Supported, ARM64: Image [XXX - Not sure if this is correct]


On ARM64 it's called Image.gz.


Ack.

+### vTPM Support
+
+Status: Supported, x86 only


This should probably be x86/vTPM. TPM, the way we are discussing it, is
an x86-only implementation. ARM-based alternatives are not called TPM
AFAIK.


Someone said that because this was implemented entirely in userspace,
there's no reason the PV TPM couldn't work on ARM.  OTOH I suppose it
would be a lot less valuable if there weren't a physical TPM to back it up.

Any thoughts on that?


Per my understanding TPM is a specification and not tie to Arm, x86 or 
else. So if providing the PV driver is agnostic to x86 it should work. 
Note that I haven't looked at the code nor I am aware of some that 
tested it.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[George Dunlap]

On 09/11/2017 04:54 PM, Julien Grall wrote:
> Hi,
> 
> Sorry I missed e-mail. It seems I was not CCed on it.

Sorry -- already had a pretty large CC list.  I'll add you for the next one.


 +### ARM/SMMU
 +
 +    Status: Supported, with caveats
 +
 +Only ARM SMMU hardware is supported; non-ARM SMMU hardware is not
 supported.
>>>
>>> I'm not sure of the purpose of this sentence, it's quite clear that
>>> the SMMU is only supported if available. Also, I'm not sure this
>>> should be spelled out in this document, x86 doesn't have a VT-d or SVM
>>> section.
>>
>> As George wrote, there are many SMMUs in the market for ARM based
>> platforms, not all of them of ARM design.
> 
> Few remarks here.
> 
> Firstly, what do you mean by Arm design? Is it spec compliant (i.e
> SMMUv1, SMMUv2, SMMUv3) ? Or is it implementation coming from Arm
> (SMMU-400, SMMU-401, SMMU-500,...)?

Well as you and Stefano are going to be primarily doing security
support, I think whatever you think is most reasonable for you to
support, and whatever communicates best to your users what functionality
actually works and what will be security supported.

> At the moment we have no support of SMMUv3 at all (this would be a
> separate driver as the spec is very different).
> 
> Regarding SMMUv1 and SMMUv2. Technically we should support all SMMUs
> which are compliant with the spec, providing there are no workaround
> necessary (yes there are some hardware only 99.9% compliant).
> 
> But, we can't even claim that we support Arm implementation. At least
> SMMU-401 (used by Seattle and Versatile Express) is not supported.
> 
> Furthermore, Arm may release new IP in the future. Does it mean we
> support them by default?
> 
> So there are some clarifications needed on what we actually support.
> 
> If we decide the support status is based on hardware, then it raise the
> questions on what about other specifications (e.g GICv2, GICv3, GICv4)?
> Each vendor is free to provide its own implementation (not necessarily
> bug free and fully compliant).

On the whole it sounds like we ought to have separate stanzas for SMMUv1
and SMMUv2.

I'd say focus on accurately implementing the spec.  Call out specific
non-compliant implementations as and when you feel like you need to be
specific.

Shall I make this:

---
### ARM/SMMUv1

Status: Supported

### ASM/SMMUv2

Status: Supported
---

Will that communicate effectively that you only support ARM-spec SMMUs?
Or do we need to add some extra verbiage to make sure people know that
non-ARM specs are not supported?

 -George

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

Re: [Xen-devel] Xen 4.8.2 released

[Lars Kurth]

Fixed
Apologies
Lars

On 11/09/2017, 03:26, "Marek Marczykowski-Górecki" 
 wrote:

On Mon, Sep 11, 2017 at 03:06:48AM -0600, Jan Beulich wrote:
> >>> On 10.09.17 at 01:53,  wrote:
> > On Wed, Sep 06, 2017 at 08:42:33AM -0600, Jan Beulich wrote:
> >> All,
> >> 
> >> I am pleased to announce the release of Xen 4.8.2. This is
> >> available immediately from its git repository
> >> 
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8 
> >> (tag RELEASE-4.8.2) or from the XenProject download page
> >> 
http://www.xenproject.org/downloads/xen-archives/xen-project-48-series/xen-482.html
 
> >> (where a list of changes can also be found).
> >> 
> >> We recommend all users of the 4.8 stable series to update to this
> >> latest point release.
> > 
> > The announcement on the website has wrong link (to 4.8.1 instead of
> > 4.8.2).
> 
> Hmm, thanks for pointing this out, but unless Lars knows without
> further context where this wrong link is, it would have helped if
> you identified the page having that bad link. I can spot such a
> wrong link in the blog post - is that what you're referring to? 

Yes, this one:
https://blog.xenproject.org/2017/09/06/xen-project-4-8-2-is-available/

> Lars,
> could you correct that?
> 
> Jan
> 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[George Dunlap]

On 09/11/2017 05:00 PM, Julien Grall wrote:
> 
> 
> On 07/09/17 22:54, Stefano Stabellini wrote:
>> On Thu, 31 Aug 2017, George Dunlap wrote:
>>> +### Direct-boot kernel image format
>>> +
>>> +    Supported, x86: bzImage
>>> +    Supported, ARM32: zImage
>>> +    Supported, ARM64: Image [XXX - Not sure if this is correct]
>>
>> On ARM64 it's called Image.gz.
> 
> That's not true. Linux produces an Image. You can compress after if you
> want, but it is not the default.

I've left it as 'Image'.

> 
> [...]
> 
>>> +### ARM/ITS
>>> +
>>> +    Status: experimental
>>> +
>>> +[XXX What is this?]
>>
>> A particularly complex extension to the interrupt controller.
> 
> To complete, it is an extension of GICv3 to support MSI. So it would be
> better to name it ARM/GICv3 ITS

Renamed it and added the following description:

Extension to the GICv3 interrupt controller to support MSI.

 -George

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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[Julien Grall]

On 07/09/17 22:54, Stefano Stabellini wrote:

On Thu, 31 Aug 2017, George Dunlap wrote:

+### Direct-boot kernel image format
+
+Supported, x86: bzImage
+Supported, ARM32: zImage
+Supported, ARM64: Image [XXX - Not sure if this is correct]


On ARM64 it's called Image.gz.


That's not true. Linux produces an Image. You can compress after if you 
want, but it is not the default.


[...]


+### ARM/ITS
+
+Status: experimental
+
+[XXX What is this?]


A particularly complex extension to the interrupt controller.


To complete, it is an extension of GICv3 to support MSI. So it would be 
better to name it ARM/GICv3 ITS


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[Julien Grall]

Hi,

Sorry I missed e-mail. It seems I was not CCed on it.

On 07/09/17 22:36, Stefano Stabellini wrote:

On Thu, 31 Aug 2017, Roger Pau Monne wrote:

+### ARM/Non-PCI device passthrough
+
+Status: Supported


I guess non-pci devices on ARM also use the IOMMU? (SMMU)


Yes, they do.



+### ARM/SMMU
+
+Status: Supported, with caveats
+
+Only ARM SMMU hardware is supported; non-ARM SMMU hardware is not supported.


I'm not sure of the purpose of this sentence, it's quite clear that
the SMMU is only supported if available. Also, I'm not sure this
should be spelled out in this document, x86 doesn't have a VT-d or SVM
section.


As George wrote, there are many SMMUs in the market for ARM based
platforms, not all of them of ARM design.


Few remarks here.

Firstly, what do you mean by Arm design? Is it spec compliant (i.e 
SMMUv1, SMMUv2, SMMUv3) ? Or is it implementation coming from Arm 
(SMMU-400, SMMU-401, SMMU-500,...)?


At the moment we have no support of SMMUv3 at all (this would be a 
separate driver as the spec is very different).


Regarding SMMUv1 and SMMUv2. Technically we should support all SMMUs 
which are compliant with the spec, providing there are no workaround 
necessary (yes there are some hardware only 99.9% compliant).


But, we can't even claim that we support Arm implementation. At least 
SMMU-401 (used by Seattle and Versatile Express) is not supported.


Furthermore, Arm may release new IP in the future. Does it mean we 
support them by default?


So there are some clarifications needed on what we actually support.

If we decide the support status is based on hardware, then it raise the 
questions on what about other specifications (e.g GICv2, GICv3, GICv4)? 
Each vendor is free to provide its own implementation (not necessarily 
bug free and fully compliant).


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v10 2/3] x86emul: New return code for unimplemented instruction

[Petre Ovidiu PIRCALABU]

On Jo, 2017-09-07 at 09:08 -0600, Jan Beulich wrote:
> > 
> > > 
> > > > 
> > > > On 07.09.17 at 16:26,  wrote:
> > After discussing with Andrew I'm willing to agree with the changes
> > you do here, with one extra requirement: At least on non-debug
> > builds X86EMUL_UNIMPLEMENTED should always result in #UD being
> > raised by the final consumer of it. It should never, like would be
> > the case with the changes you do to vmx/realmode.c, result in
> > the domain being crashed. Please change that one and check
> > carefully whether there are any other similar cases.

Hi Jan,

Changing the way we handle X86EMUL_UNIMPLEMENTED in some of the
functions will modify the existing behavior, and I'm a little bit wary
of making so many changes unrelated to the current patchset'a purpose
without a thourough way of testing them.

e.g.: "hvm_descriptor_access_intercept".
The current behavior is to return false if X86EMUL_UNHANDLEABLE is
returned by hvm_emulate_one. Up until now, this return code covered
also the "unimplemented instruction" case.
If X86EMUL_UNIMPLEMENTED will be handled separately (e.g. by calling
hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC),
hvm_emulate_writeback, and finally returning true) some of the
scenarios where the domain got crashed will result only in an UD being
injected.

The same reasoning applies also to vmx/realmode. My patch didn't change
the current behavior, the domain crash logic was added by patch
3502a233e0132cb2facfe90c5c4872c823a5cb69.

However, in the end the decision if yours to take. I can add those
changes, but I will require a little help in order to make sure I don't
break anything.

Many thanks,
Petre

> Oh, and please make the comment next to the definition of
> X86EMUL_UNIMPLEMENTED also say so.
> 
> Jan
> 
> 
> 
> This email was scanned by Bitdefender
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] hvmloader: cast to avoid potential overflow in shadow_gs_test

[Jan Beulich]

>>> On 11.09.17 at 17:01,  wrote:
> On Mon, Sep 11, 2017 at 08:55:53AM -0600, Jan Beulich wrote:
>> >>> On 11.09.17 at 16:07,  wrote:
>> > e2fc5bb5cb4 ("hvmloader: dynamically determine scratch memory range
>> > for tests") makes the test dependent on _end. Coverity reported that
>> > the shift might overflow and suggested we cast i to uint64_t.
>> > 
>> > Coverity-ID: 1417660
>> > 
>> > Signed-off-by: Wei Liu 
>> > ---
>> > Cc: Jan Beulich 
>> > Cc: Andrew Cooper 
>> > ---
>> >  tools/firmware/hvmloader/tests.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > 
>> > diff --git a/tools/firmware/hvmloader/tests.c 
>> > b/tools/firmware/hvmloader/tests.c
>> > index a70c72dffb..3c4c29a6c7 100644
>> > --- a/tools/firmware/hvmloader/tests.c
>> > +++ b/tools/firmware/hvmloader/tests.c
>> > @@ -231,7 +231,7 @@ static int shadow_gs_test(void)
>> >  pd += 512;
>> >  /* Level 2: */
>> >  for ( i = 0; i <= (unsigned long)(_end - 1) >> (PAGE_SHIFT + 9); i++ )
>> 
>> With the shift here there's no way ...
>> 
>> > -*pd++ = (i << (PAGE_SHIFT + 9)) + 0x1e3;
>> > +*pd++ = ((uint64_t)i << (PAGE_SHIFT + 9)) + 0x1e3;
>> 
>> ... this shift (or the add) can overflow, irrespective of the actual
>> value of _end, and with my dislike of casts I'm a little hesitant to
>> give my ack for such a tool weakness workaround.
> 
> We can also mark that as false positive.

I would prefer that.

> It's you and Andrew's call.

Andrew?

Jan


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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[Anthony PERARD]

On Mon, Sep 11, 2017 at 04:07:08PM +0100, George Dunlap wrote:
> On 09/11/2017 04:02 PM, Anthony PERARD wrote:
> > On Mon, Sep 11, 2017 at 03:16:13PM +0100, George Dunlap wrote:
> >> On 09/07/2017 10:54 PM, Stefano Stabellini wrote:
> >>> On Thu, 31 Aug 2017, George Dunlap wrote:
>  +### Netback
>  +
>  +Status, Linux (netback): Supported
>  +Status, FreeBSD (netback): Supported
>  +Status, QEMU (xen_nic): Experimental
> >>>
> >>> I suggest to Deprecate xen_nic
> >>
> >> That's fine with me.  Anthony?
> > 
> > Yes, that fine by me.  xen_nic is only for PV guest, and I don't known
> > how it can be used, there does not seems to be any support in libxl.
> 
> Is this a holdover from 'xenner', which was supposed to allow you to run
> a Xen guest on a non-Xen system?

Yes, it looks like that it can be use with xenner.

> Anyway, I'm happy to call it experimental, or just to leave it off
> entirely if it can't actually be used.
> 
>  -George

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[George Dunlap]

On 09/11/2017 04:02 PM, Anthony PERARD wrote:
> On Mon, Sep 11, 2017 at 03:16:13PM +0100, George Dunlap wrote:
>> On 09/07/2017 10:54 PM, Stefano Stabellini wrote:
>>> On Thu, 31 Aug 2017, George Dunlap wrote:
 +### Netback
 +
 +Status, Linux (netback): Supported
 +Status, FreeBSD (netback): Supported
 +Status, QEMU (xen_nic): Experimental
>>>
>>> I suggest to Deprecate xen_nic
>>
>> That's fine with me.  Anthony?
> 
> Yes, that fine by me.  xen_nic is only for PV guest, and I don't known
> how it can be used, there does not seems to be any support in libxl.

Is this a holdover from 'xenner', which was supposed to allow you to run
a Xen guest on a non-Xen system?

Anyway, I'm happy to call it experimental, or just to leave it off
entirely if it can't actually be used.

 -George

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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[Anthony PERARD]

On Mon, Sep 11, 2017 at 03:16:13PM +0100, George Dunlap wrote:
> On 09/07/2017 10:54 PM, Stefano Stabellini wrote:
> > On Thu, 31 Aug 2017, George Dunlap wrote:
> >> +### Netback
> >> +
> >> +Status, Linux (netback): Supported
> >> +Status, FreeBSD (netback): Supported
> >> +Status, QEMU (xen_nic): Experimental
> > 
> > I suggest to Deprecate xen_nic
> 
> That's fine with me.  Anthony?

Yes, that fine by me.  xen_nic is only for PV guest, and I don't known
how it can be used, there does not seems to be any support in libxl.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH] hvmloader: cast to avoid potential overflow in shadow_gs_test

[Wei Liu]

On Mon, Sep 11, 2017 at 08:55:53AM -0600, Jan Beulich wrote:
> >>> On 11.09.17 at 16:07,  wrote:
> > e2fc5bb5cb4 ("hvmloader: dynamically determine scratch memory range
> > for tests") makes the test dependent on _end. Coverity reported that
> > the shift might overflow and suggested we cast i to uint64_t.
> > 
> > Coverity-ID: 1417660
> > 
> > Signed-off-by: Wei Liu 
> > ---
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > ---
> >  tools/firmware/hvmloader/tests.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/firmware/hvmloader/tests.c 
> > b/tools/firmware/hvmloader/tests.c
> > index a70c72dffb..3c4c29a6c7 100644
> > --- a/tools/firmware/hvmloader/tests.c
> > +++ b/tools/firmware/hvmloader/tests.c
> > @@ -231,7 +231,7 @@ static int shadow_gs_test(void)
> >  pd += 512;
> >  /* Level 2: */
> >  for ( i = 0; i <= (unsigned long)(_end - 1) >> (PAGE_SHIFT + 9); i++ )
> 
> With the shift here there's no way ...
> 
> > -*pd++ = (i << (PAGE_SHIFT + 9)) + 0x1e3;
> > +*pd++ = ((uint64_t)i << (PAGE_SHIFT + 9)) + 0x1e3;
> 
> ... this shift (or the add) can overflow, irrespective of the actual
> value of _end, and with my dislike of casts I'm a little hesitant to
> give my ack for such a tool weakness workaround.

We can also mark that as false positive. It's you and Andrew's call.

I'm indifferent to the final solution.

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

Re: [Xen-devel] [PATCH] hvmloader: cast to avoid potential overflow in shadow_gs_test

[Jan Beulich]

>>> On 11.09.17 at 16:07,  wrote:
> e2fc5bb5cb4 ("hvmloader: dynamically determine scratch memory range
> for tests") makes the test dependent on _end. Coverity reported that
> the shift might overflow and suggested we cast i to uint64_t.
> 
> Coverity-ID: 1417660
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  tools/firmware/hvmloader/tests.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/firmware/hvmloader/tests.c 
> b/tools/firmware/hvmloader/tests.c
> index a70c72dffb..3c4c29a6c7 100644
> --- a/tools/firmware/hvmloader/tests.c
> +++ b/tools/firmware/hvmloader/tests.c
> @@ -231,7 +231,7 @@ static int shadow_gs_test(void)
>  pd += 512;
>  /* Level 2: */
>  for ( i = 0; i <= (unsigned long)(_end - 1) >> (PAGE_SHIFT + 9); i++ )

With the shift here there's no way ...

> -*pd++ = (i << (PAGE_SHIFT + 9)) + 0x1e3;
> +*pd++ = ((uint64_t)i << (PAGE_SHIFT + 9)) + 0x1e3;

... this shift (or the add) can overflow, irrespective of the actual
value of _end, and with my dislike of casts I'm a little hesitant to
give my ack for such a tool weakness workaround.

Jan


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

Re: [Xen-devel] [PATCH] mem_access: switch to plain bool

[Razvan Cojocaru]

On 11.09.2017 14:16, Wei Liu wrote:

Signed-off-by: Wei Liu 
---
Cc: Razvan Cojocaru 
Cc: Tamas K Lengyel 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
  xen/arch/arm/mem_access.c|  4 ++--
  xen/arch/x86/mm/mem_access.c | 16 
  xen/include/asm-arm/mem_access.h |  8 
  xen/include/asm-x86/mem_access.h |  8 
  4 files changed, 18 insertions(+), 18 deletions(-)


Acked-by: Razvan Cojocaru 

Thanks for doing this!


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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md\

[George Dunlap]

On 09/07/2017 03:56 PM, Wei Liu wrote:
> On Thu, Sep 07, 2017 at 02:52:49PM +0100, George Dunlap wrote:
>> On 09/01/2017 04:00 PM, Wei Liu wrote:
>>> On Thu, Aug 31, 2017 at 11:27:19AM +0100, George Dunlap wrote:
 +### Direct-boot kernel image format
 +
 +Supported, x86: bzImage
>>>
>>> Do you mean booting a PV guest? If so there are a few more formats.
>>>
 +Supported, ARM32: zImage
 +Supported, ARM64: Image [XXX - Not sure if this is correct]
 +
 +Format which the toolstack accept for direct-boot kernels
>>> [...]
 +### JSON support for xl
 +
 +Status: Preview
 +
>>>
>>> What is this?
>>
>> JSON output; e.g., `xl list -l`.
>>
>> Perhaps this should be called 'JSON output support'. :-)
>>
> 
> OK. Anyway, no security support for this please. I'm not even very sure
> if the output is going to be stable.

"Tech Preview" means no security support.  But given how incomplete it
is, maybe "Experimental" would be a better designation.

> 
 +### AHCI support for xl
 +
 +Status, x86: Supported
 +
>>>
>>> There is only one knob to change, I'm not sure whether makes sense to
>>> list it separately.
>>>
 +### Soft-reset for xl
 +
 +Status: Supported
 +
>>>
>>> We never tested this in osstest so I'm not sure about if this is the
>>> correct status. Furthermore there is also moving parts in hypervisor.
>>
>> Hmm, maybe this would go better under a hypervisor section somewhere; as
>> you say, the core functionality doesn't reside in xl, xl just enables it.
>>
> 
> A bit more than that, there are moving parts in libxl to handle that as
> well -- some initialisation needs to be skipped or whatever, some can't.

A large proportion of features require support both in the hypervisor
and in the toolstack.  It doesn't make sense to talk about them
separately; it makes sense to put them where the "core" of their
implementation resides.

 -George

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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

[George Dunlap]

On 09/07/2017 10:54 PM, Stefano Stabellini wrote:
> On Thu, 31 Aug 2017, George Dunlap wrote:
>> +### Direct-boot kernel image format
>> +
>> +Supported, x86: bzImage
>> +Supported, ARM32: zImage
>> +Supported, ARM64: Image [XXX - Not sure if this is correct]
> 
> On ARM64 it's called Image.gz.

Ack.


>> +### Alternative p2m
>> +
>> +Status, x86: Preview
>> +
>> +Allows external monitoring of hypervisor memory using Intel EPT by allowing 
>> to maintain multiple physical memory to machine physical mappings
>> +
>> +[XXX Should this be x86/Alternative p2m?]
> 
> No, the technology could be available on ARM.

Yup, got that change already.

>> +### Null Scheduler
>> +
>> +Status: Experimental
>> +
>> +A very simple, very static scheduling posicy that always schedules the same 
>> vCPU(s) on the same pCPU(s). It is designed for maximum determinism and 
>> minimum overhead on embedded platforms.
> 
> Can we say more than Experimental? I think it should be at least Tech
> Preview.

I was going to wait for Dario to respond to this (I had just copied what
was already there).  Tech Preview should look like this:

Functional completeness: Yes
Functional stability: Quirky
Interface stability: Provisionally stable
Security supported: No

I think that's probably accurate.  Dario?

>> +### Xen Framebuffer
> 
> Please write "Xen Framebuffer Frontend" in the title.

It is in a section labelled 'guest side'.  On the other hand, the list
is long, and the headings in markdown aren't actually that easy to scan
in text mode.

Let me give it some thought. (I'll put an XXX to make sure it gets
considered.)

>> +### Netback
>> +
>> +Status, Linux (netback): Supported
>> +Status, FreeBSD (netback): Supported
>> +Status, QEMU (xen_nic): Experimental
> 
> I suggest to Deprecate xen_nic

That's fine with me.  Anthony?

>> +### vTPM Support
>> +
>> +Status: Supported, x86 only
> 
> This should probably be x86/vTPM. TPM, the way we are discussing it, is
> an x86-only implementation. ARM-based alternatives are not called TPM
> AFAIK.

Someone said that because this was implemented entirely in userspace,
there's no reason the PV TPM couldn't work on ARM.  OTOH I suppose it
would be a lot less valuable if there weren't a physical TPM to back it up.

Any thoughts on that?

>> +### Intel/TXT ???
> 
> Same here

Well unless someone actually says something about this I'm just going go
delete it.

>> +### ARM/ITS
>> +
>> +Status: experimental
>> +
>> +[XXX What is this?]
> 
> A particularly complex extension to the interrupt controller.

But what people reading this want to know isn't how complicated it is,
but what it would be for.

I could put "An extension to the ARM interrupt controller", but it would
be nice if I could also say, "...that implements $FEATURE" or
"...targeted at $APPLICATION".

Thanks for the feedback,
 -George


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

Re: [Xen-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest

[Igor Mammedov]

On Mon, 11 Sep 2017 12:41:47 +0800
Haozhong Zhang  wrote:

> This is the QEMU part patches that works with the associated Xen
> patches to enable vNVDIMM support for Xen HVM domains. Xen relies on
> QEMU to build guest NFIT and NVDIMM namespace devices, and allocate
> guest address space for vNVDIMM devices.
> 
> All patches can be found at
>   Xen:  https://github.com/hzzhan9/xen.git nvdimm-rfc-v3
>   QEMU: https://github.com/hzzhan9/qemu.git xen-nvdimm-rfc-v3
> 
> Patch 1 is to avoid dereferencing the NULL pointer to non-existing
> label data, as the Xen side support for labels is not implemented yet.
> 
> Patch 2 & 3 add a memory backend dedicated for Xen usage and a hotplug
> memory region for Xen guest, in order to make the existing nvdimm
> device plugging path work on Xen.
> 
> Patch 4 - 10 build and cooy NFIT from QEMU to Xen guest, when QEMU is
> used as the Xen device model.

I've skimmed over patch-set and can't say that I'm happy with
number of xen_enabled() invariants it introduced as well as
with partial blobs it creates.

I'd like to reduce above and a way to do this might be making xen 
 1. use fw_cfg
 2. fetch QEMU build acpi tables from fw_cfg
 3. extract nvdim tables (which is trivial) and use them

looking at xen_load_linux(), it seems possible to use fw_cfg.

So what's stopping xen from using it elsewhere?,
instead of adding more xen specific code to do 'the same'
job and not reusing/sharing common code with tcg/kvm.


> Haozhong Zhang (10):
>   nvdimm: do not intiailize nvdimm->label_data if label size is zero
>   hw/xen-hvm: create the hotplug memory region on Xen
>   hostmem-xen: add a host memory backend for Xen
>   nvdimm acpi: do not use fw_cfg on Xen
>   hw/xen-hvm: initialize DM ACPI
>   hw/xen-hvm: add function to copy ACPI into guest memory
>   nvdimm acpi: copy NFIT to Xen guest
>   nvdimm acpi: copy ACPI namespace device of vNVDIMM to Xen guest
>   nvdimm acpi: do not build _FIT method on Xen
>   hw/xen-hvm: enable building DM ACPI if vNVDIMM is enabled
> 
>  backends/Makefile.objs |   1 +
>  backends/hostmem-xen.c | 108 ++
>  backends/hostmem.c |   9 +++
>  hw/acpi/aml-build.c|  10 ++-
>  hw/acpi/nvdimm.c   |  79 ++-
>  hw/i386/pc.c   | 102 ++---
>  hw/i386/xen/xen-hvm.c  | 204 
> -
>  hw/mem/nvdimm.c|  10 ++-
>  hw/mem/pc-dimm.c   |   6 +-
>  include/hw/i386/pc.h   |   1 +
>  include/hw/xen/xen.h   |  25 ++
>  stubs/xen-hvm.c|  10 +++
>  12 files changed, 495 insertions(+), 70 deletions(-)
>  create mode 100644 backends/hostmem-xen.c
> 


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

[Xen-devel] [PATCH] hvmloader: cast to avoid potential overflow in shadow_gs_test

[Wei Liu]

e2fc5bb5cb4 ("hvmloader: dynamically determine scratch memory range
for tests") makes the test dependent on _end. Coverity reported that
the shift might overflow and suggested we cast i to uint64_t.

Coverity-ID: 1417660

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 tools/firmware/hvmloader/tests.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/firmware/hvmloader/tests.c b/tools/firmware/hvmloader/tests.c
index a70c72dffb..3c4c29a6c7 100644
--- a/tools/firmware/hvmloader/tests.c
+++ b/tools/firmware/hvmloader/tests.c
@@ -231,7 +231,7 @@ static int shadow_gs_test(void)
 pd += 512;
 /* Level 2: */
 for ( i = 0; i <= (unsigned long)(_end - 1) >> (PAGE_SHIFT + 9); i++ )
-*pd++ = (i << (PAGE_SHIFT + 9)) + 0x1e3;
+*pd++ = ((uint64_t)i << (PAGE_SHIFT + 9)) + 0x1e3;
 
 asm volatile (
 /* CR4.PAE=1 */
-- 
2.11.0


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

Re: [Xen-devel] Faulting linear address??

[Dario Faggioli]

On Mon, 2017-09-11 at 02:00 +0900, Minjun Hong wrote:
> I made the new Xen4.5 binary with 'debug=y' option that I modified
> and install it.
> Then, there was a kernel panic caused by the debugging code triggered
> by 'debug=y' during booting process(of dom0):
> 
Once again, can you show us here what you are changing?

> (XEN) [ Xen-4.5.0  x86_64  debug=y  Not tainted ]
> (XEN) CPU:    7
> (XEN) RIP:    e008:[] vcpu_migrate+0x1bd/0x374
> (XEN) RFLAGS: 00010096   CONTEXT: hypervisor
> [...]
> (XEN) Xen call trace:
> (XEN)    [] vcpu_migrate+0x1bd/0x374
> (XEN)    [] vcpu_force_reschedule+0x9e/0xa7
> (XEN)    [] do_vcpu_op+0x2e7/0x69d
> (XEN)    [] syscall_enter+0xeb/0x145
> (XEN)
> (XEN) Pagetable walk from 82d081422020:
> (XEN)  L4[0x105] = 86092063 
> (XEN)  L3[0x142] = 8608f063 
> (XEN)  L2[0x00a] =  
> (XEN)
> (XEN) 
> (XEN) Panic on CPU 7:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=]
> (XEN) Faulting linear address: 82d081422020
> (XEN) 
> 
> Because I received a solution from my professor, I think it is a hard
> work to change Xen version.
>
This makes it a bit harder for us to give effective advices, but if you
really can't move forward, then fine, we still can at least try.

> Anyway, even if I turned on the 'debug=y' option, I could not get
> accurate information like with 'debug=n'; I get only linear
> address(82d081422020).
>
Well, the difference is that now, if Xen is compiled with frame
pointers, we are (much more) sure that the stack trace is accurate,
i.e., about where the problem is actually happening, and how you got
there.

> So, I want to use a dis-assembly utility like 'addr2line' or
> 'objdump', which binaries can I use as input to the utility?
> I'm using Ubuntu and previously I used '/boot/xen-syms-4.5.0' as
> input to the utilities.
>
Yes, if that is the binary of the hypervisor you compiled (with
debug=y), that's what you should use. You should also have it, in the
source tree, as xen/xen-syms.

> But I could get wrong information, which told me a code line that is
> never related this problem.
> 
The address you pass to addr2line is not the 'Faulting linear address'.
It must be the address of the instruction that was being executing when
the exception occurred. IOW, you shall use 82d08012ba6c, from here:

 (XEN)[] vcpu_migrate+0x1bd/0x374

Which, in fact, is the address present in the program counter register
(RIP):

 (XEN) RIP:e008:[] vcpu_migrate+0x1bd/0x374


> I know that a beginner in the Xen developer community like me might
> be annoying you, but I ask you one more help.
>
You being a beginner is not a problem. :-)

The biggest problem I have right now, while trying to help you, is that
I can't see what you are doing, and how you're changing the code.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

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

Re: [Xen-devel] [PATCH v2 2/4] x86/hvm: Rename enum hvm_copy_result to hvm_translation_result

[Andrew Cooper]

On 11/09/17 14:27, George Dunlap wrote:
> On 09/08/2017 05:05 PM, Alexandru Isaila wrote:
>> diff --git a/xen/include/asm-x86/hvm/support.h 
>> b/xen/include/asm-x86/hvm/support.h
>> index b18dbb6..e3b035d 100644
>> --- a/xen/include/asm-x86/hvm/support.h
>> +++ b/xen/include/asm-x86/hvm/support.h
>> @@ -53,23 +53,23 @@ extern unsigned int opt_hvm_debug_level;
>>  
>>  extern unsigned long hvm_io_bitmap[];
>>  
>> -enum hvm_copy_result {
>> -HVMCOPY_okay = 0,
>> -HVMCOPY_bad_gva_to_gfn,
>> -HVMCOPY_bad_gfn_to_mfn,
>> -HVMCOPY_unhandleable,
>> -HVMCOPY_gfn_paged_out,
>> -HVMCOPY_gfn_shared,
>> +enum hvm_translation_result {
>> +HVMTRANS_okay,
>> +HVMTRANS_bad_linear_to_gfn,
>> +HVMTRANS_bad_gfn_to_mfn,
>> +HVMTRANS_unhandleable,
>> +HVMTRANS_gfn_paged_out,
>> +HVMTRANS_gfn_shared,
> Somehow "translation result" doesn't seem like the right name for this.
> gfn_to_mfn is a translation result; linear_to_gfn includes access checks.
>
> I'll admit though that by the end of the series, "Copy result" is *also*
> not the right name for it, and I can't think of a better name at the moment.

Architecturally, "translation" is the most accurate term.

This entire set of infrastructure will improve in my longterm emulator
plans.

~Andrew

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

Re: [Xen-devel] [PATCH v2 2/4] x86/hvm: Rename enum hvm_copy_result to hvm_translation_result

[Wei Liu]

On Mon, Sep 11, 2017 at 02:27:34PM +0100, George Dunlap wrote:
> On 09/08/2017 05:05 PM, Alexandru Isaila wrote:
> > diff --git a/xen/include/asm-x86/hvm/support.h 
> > b/xen/include/asm-x86/hvm/support.h
> > index b18dbb6..e3b035d 100644
> > --- a/xen/include/asm-x86/hvm/support.h
> > +++ b/xen/include/asm-x86/hvm/support.h
> > @@ -53,23 +53,23 @@ extern unsigned int opt_hvm_debug_level;
> >  
> >  extern unsigned long hvm_io_bitmap[];
> >  
> > -enum hvm_copy_result {
> > -HVMCOPY_okay = 0,
> > -HVMCOPY_bad_gva_to_gfn,
> > -HVMCOPY_bad_gfn_to_mfn,
> > -HVMCOPY_unhandleable,
> > -HVMCOPY_gfn_paged_out,
> > -HVMCOPY_gfn_shared,
> > +enum hvm_translation_result {
> > +HVMTRANS_okay,
> > +HVMTRANS_bad_linear_to_gfn,
> > +HVMTRANS_bad_gfn_to_mfn,
> > +HVMTRANS_unhandleable,
> > +HVMTRANS_gfn_paged_out,
> > +HVMTRANS_gfn_shared,
> 
> Somehow "translation result" doesn't seem like the right name for this.
> gfn_to_mfn is a translation result; linear_to_gfn includes access checks.
> 
> I'll admit though that by the end of the series, "Copy result" is *also*
> not the right name for it, and I can't think of a better name at the moment.
> 

hvm_access_result?

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

Re: [Xen-devel] [PATCH v2 2/4] x86/hvm: Rename enum hvm_copy_result to hvm_translation_result

[George Dunlap]

On 09/08/2017 05:05 PM, Alexandru Isaila wrote:
> diff --git a/xen/include/asm-x86/hvm/support.h 
> b/xen/include/asm-x86/hvm/support.h
> index b18dbb6..e3b035d 100644
> --- a/xen/include/asm-x86/hvm/support.h
> +++ b/xen/include/asm-x86/hvm/support.h
> @@ -53,23 +53,23 @@ extern unsigned int opt_hvm_debug_level;
>  
>  extern unsigned long hvm_io_bitmap[];
>  
> -enum hvm_copy_result {
> -HVMCOPY_okay = 0,
> -HVMCOPY_bad_gva_to_gfn,
> -HVMCOPY_bad_gfn_to_mfn,
> -HVMCOPY_unhandleable,
> -HVMCOPY_gfn_paged_out,
> -HVMCOPY_gfn_shared,
> +enum hvm_translation_result {
> +HVMTRANS_okay,
> +HVMTRANS_bad_linear_to_gfn,
> +HVMTRANS_bad_gfn_to_mfn,
> +HVMTRANS_unhandleable,
> +HVMTRANS_gfn_paged_out,
> +HVMTRANS_gfn_shared,

Somehow "translation result" doesn't seem like the right name for this.
gfn_to_mfn is a translation result; linear_to_gfn includes access checks.

I'll admit though that by the end of the series, "Copy result" is *also*
not the right name for it, and I can't think of a better name at the moment.

 -George

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

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

[Wei Liu]

On Fri, Sep 08, 2017 at 04:21:37PM +0100, Paul Durrant wrote:
> +static int hvm_ioreq_server_alloc_pages(struct hvm_ioreq_server *s)
> +{
> +int rc = -ENOMEM;
> +

Pointless initialisation.

With this fixed:

Reviewed-by: Wei Liu 

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

[Xen-devel] [distros-debian-sid test] 72091: tolerable trouble: blocked/broken/fail/pass

[Platform Team regression test user]

flight 72091 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72091/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-sid-netboot-pygrub  1 build-check(1)blocked n/a
 build-arm64-pvops 2 hosts-allocate   broken like 72058
 build-arm64   2 hosts-allocate   broken like 72058
 build-arm64-pvops 3 capture-logs broken like 72058
 build-arm64   3 capture-logs broken like 72058
 test-amd64-amd64-i386-sid-netboot-pygrub 22 leak-check/check fail blocked in 
72058
 test-armhf-armhf-armhf-sid-netboot-pygrub  7 xen-boot  fail like 72058
 test-amd64-i386-i386-sid-netboot-pvgrub 11 guest-start fail like 72058
 test-amd64-amd64-amd64-sid-netboot-pvgrub 11 guest-start   fail like 72058

baseline version:
 flight   72058

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub pass
 test-arm64-arm64-armhf-sid-netboot-pygrubblocked 
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub fail



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


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

[Xen-devel] [ovmf test] 113307: regressions - FAIL

[osstest service owner]

flight 113307 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113307/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 113143
 build-amd64-xsm   6 xen-buildfail REGR. vs. 113143
 build-i386-xsm6 xen-buildfail REGR. vs. 113143
 build-i3866 xen-buildfail REGR. vs. 113143

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf aa9aa47e06ac0082948b880c226c8bdf2a12102b
baseline version:
 ovmf 3281ebb4ae7de2a858c2e7ec4998b7e55be1a4dc

Last test of basis   113143  2017-09-08 06:17:14 Z3 days
Failing since113156  2017-09-08 19:17:56 Z2 days   19 attempts
Testing same since   113275  2017-09-11 03:48:41 Z0 days4 attempts


People who touched revisions under test:
  Brijesh Singh 
  Laszlo Ersek 
  Paulo Alcantara 
  Star Zeng 
  Thomas Lamprecht 
  Yonghong Zhu 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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.

(No revision log; it would be 555 lines long.)

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

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

[Wei Liu]

On Fri, Sep 08, 2017 at 04:21:36PM +0100, Paul Durrant wrote:
> A subsequent patch will introduce a new scheme to allow an emulator to
> map ioreq server pages directly from Xen rather than the guest P2M.
> 
> This patch lays the groundwork for that change by deferring mapping of
> gfns until their values are requested by an emulator. To that end, the
> pad field of the xen_dm_op_get_ioreq_server_info structure is re-purposed
> to a flags field and new flag, XEN_DMOP_no_gfns, defined which modifies the
> behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to avoid
> requesting the gfn values.
> 
> Signed-off-by: Paul Durrant 
> Reviewed-by: Roger Pau Monné 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] vt-d: use two 32-bit writes to update DMAR fault address registers

[Haozhong Zhang]

On 09/11/17 10:38 +0100, Roger Pau Monné wrote:
> On Mon, Sep 11, 2017 at 02:00:48PM +0800, Haozhong Zhang wrote:
> > The 64-bit DMAR fault address is composed of two 32 bits registers
> > DMAR_FEADDR_REG and DMAR_FEUADDR_REG. According to VT-d spec:
> > "Software is expected to access 32-bit registers as aligned doublewords",
> > a hypervisor should use two 32-bit writes to DMAR_FEADDR_REG and
> > DMAR_FEUADDR_REG separately in order to update a 64-bit fault address,
> > rather than a 64-bit write to DMAR_FEADDR_REG.
> > 
> > Though I haven't seen any errors caused by such one 64-bit write on
> > real machines, it's still better to follow the specification.
> 
> Either the patch description is missing something or the patch is
> wrong. You should mention why is the write to the high part of the
> address now conditional on x2APIC being enabled, when it didn't use to
> be before.
>

When x2APIC is disabled, DMAR_FEUADDR_REG is reserved and it's not
necessary to update it. The original code always writes zero to it in
that case, which is also correct.

Haozhong

> [...]
> > -dmar_writeq(iommu->reg, DMAR_FEADDR_REG, msg.address);
> > +dmar_writel(iommu->reg, DMAR_FEADDR_REG, msg.address_lo);
> > +if (x2apic_enabled)
> > +dmar_writel(iommu->reg, DMAR_FEUADDR_REG, msg.address_hi);
> >  spin_unlock_irqrestore(&iommu->register_lock, flags);
> 
> Thanks, Roger.

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

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Simon Kuenzer]

Hi Alexander,

thanks a lot for your review.

On 10.09.2017 22:48, Alexander Dubinin wrote:

Hi Felipe, all,

Great that it's going to start :) Looking forward to join :)


I am looking forward to your contributions. ;)



Just my 2 cents:

1. Is this academic project, or it have specific goals and areas of 
application? Would be good to have some practical use-cases and well 
formulated list of problems (we all feel these by guts, but...), it 
aiming to solve. IMHO that will help to prioritize functionality and get 
usable result faster :)


It is kind of both, however we aim a strong focus on real world 
problems: IoT, Mobile Edge Computing (MEC), Automotive, Virtual Network 
Functions (VNFs), and others.
We have played with many Unikernels (ClickOS, Mirage, Rump, OSv, and 
others) and tried to apply them in the several areas. While doing this, 
we noticed that each area benefits differently from the properties that 
Unikernels give - which is great (e.g., instant boot times for MEC, high 
performance for NFV, resource efficiency for IoT). However, building and 
maintaining new Unikernels (as we did with ClickOS, MiniCache, and 
Minipython) is currently painful.
Because of different focuses on properties and ported/implemented 
applications, most Unikernel today are bound to their own OS layers 
(e.g., ClickOS uses a different Mini-OS than Mirage). Each application 
requires a different subset of OS layers but also enables different 
optimizations of them.


In order to solve this, we came up with the Unicore proposal. But I 
agree with your suggestion at this point: It helps for the project start 
to focus on some initial areas. For now, I hope this is driven by the 
first contributors, and I have personally IoT in mind. Since the project 
goal is so ambitious, we should keep the long-term goal in mind from the 
beginning.




2. Does any security subsystem planned? XEN have XSM/FLASK, but IMHO is 
should be supplemented by some security layer in control/stub domains as 
well. So far only known implementation is OpenXT, but it is very 
specific. Probably some generalized security layer needed in Unicore to 
supplement FLASK/XSM... Correct me please, if I misunderstanding :)


I agree that many projects (especially embedded, stubdomains, driver 
domains, NFV) have a vested interest in security and isolation. In my 
view, XSM/FLASK further restricts what a VM can do and sounds kind of 
orthogonal to the functionality of a VM (am I right?). The fact that 
Unikernels should only pick components that are actually required to do 
the job reduces the attack surface compared to general purpose OSes.
Do you see further value with FLASK/XSM which requires early 
implementation and design decisions for Unicore? As far as I can tell 
something like Flask is implemented mostly in the hypervisor and 
toolstack, not in the guests themselves, is this right?



Thanks,

Simon



Regards,
   Alexander

On Fri, Sep 8, 2017 at 3:31 PM, Felipe Huici > wrote:


Hi Wei, Stefano,

Thank you so much for agreeing to be sponsors! I’ll update the document.

— Felipe


Dr. Felipe Huici
Chief Researcher, Networked Systems and Data
Analytics Group
NEC Laboratories Europe, Network Research Division
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel. +49
(0)6221 4342-241
Fax: +49
(0)6221 4342-155

e-mail:
felipe.hu...@neclab.eu 

NEC Europe Limited Registered Office: NEC House, 1
Victoria Road, London W3 6BL Registered in England 2832014




On 9/8/17, 1:00 PM, "Lars Kurth" mailto:lars.ku...@citrix.com>> wrote:

 >@Wei, @Stefano,
 >
 >On 07/09/2017, 22:16, "Stefano Stabellini" mailto:sstabell...@kernel.org>> wrote:
 >
 >Hi all,
 >
 >I would be glad to sponsor this proposal. I think it will be
of great
 >benefit to the ecosystem. Let me know if I need to do anything
 >specific.
 >
 >Basically, all which is needed is an agreement. Which we have from you
 >both. Felipe, can then add your names to the proposal.
 >
 >Looking out for the evolving project and helping (e.g. through
advice) is
 >not strictly necessary, but always welcome.
 >
 >Lars
 >




--
Regards,
   Alexander Dubinin


--

Simon Kuenzer
シモン クゥンツァー
Research Scientist,
Networked Systems and Data Analytics Group
NEC Laboratories Europe, Network Research Division
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel. +49 (0)6221 4342-264
Fax: +49 (0)6221 4342-5264
e-mail:  simon.kuen...@neclab.eu

NEC Europe Ltd | Registered Office: Athene, Odyssey
Business Park, West End Road, London, HA4 6QE, GB
Registered in

[Xen-devel] [xen-unstable test] 113266: FAIL

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-amd 12 host-ping-check-native/l1running
 test-amd64-amd64-qemuu-nested-amd  3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113209
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 113209
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 113209
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 113209
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 113209
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113209
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113209
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113209
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 113209
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-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-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail 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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-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-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-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  70892c317fd56064b09a4b0fcaa0781735e64efc
baseline version:
 xen  70892c317fd56064b09a4b0fcaa0781735e64efc

Last test of basis   113266  2017-09-11 02:02:27 Z0 days
Testing same since  (not found) 0 attempts

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass

Re: [Xen-devel] [PATCH v5 1/8] xen: move XENMAPSPACE_grant_table code into grant_table.c

[George Dunlap]

On 09/08/2017 07:56 AM, Juergen Gross wrote:
> The x86 and arm versions of XENMAPSPACE_grant_table handling are nearly
> identical. Move the code into a function in grant_table.c and add an
> architecture dependant hook to handle the differences.
> 
> Switch to mfn_t in order to be more type safe.
> 
> Signed-off-by: Juergen Gross 
> Reviewed-by: Paul Durrant 
> Reviewed-by: Wei Liu 

FWIW I agree with Jan's comment about ignoring the error return value.

Other than that it looks good to me.

 -George

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

Re: [Xen-devel] [PATCH v5 3/8] xen: delay allocation of grant table sub structures

[Juergen Gross]

On 11/09/17 13:02, Jan Beulich wrote:
 On 11.09.17 at 11:39,  wrote:
>> On 11/09/17 11:23, Jan Beulich wrote:
>> On 11.09.17 at 11:03,  wrote:
 On 08/09/17 17:28, Jan Beulich wrote:
 On 08.09.17 at 08:56,  wrote:
> And if you special case Dom0,
> wouldn't it be better to (also) special case the hardware domain
> (in case that's not Dom0)?

 As a hardware domain not being dom0 would need to be created via the
 appropriate domctl hypercalls I don't see why the measures for all
 other domains wouldn't be enough for that case.
>>>
>>> Yes, that's true especially when making the domctl mandatory to be
>>> used. Whether suitable default values for that case wouldn't better
>>> live in a single place (the hypervisor) is a point to be considered
>>> here, though (by default values I mean ones to be used when the
>>> config file doesn't specify any, not ones to be used by the domctl
>>> handler if the passed in values are zero or some other "use
>>> defaults" indicator, as you had elsewhere).
>>
>> But this is exactly what happens: the hypervisor defaults are being
>> used in case nothing is specified in the domain's config file: a value
>> of 0 for a value (grant table frame limit or maptrack frame limit)
>> specified in the domctl will just use the default values.
>>
>> Or did I misunderstand you here?
> 
> Hypervisor defaults are in general meaningless when the domctl
> becomes mandatory (as indicated elsewhere, at least for the
> maptrack table size I view zero as a valid to use option). The only
> time hypervisor defaults would continue to be needed would be
> for Dom0 and, maybe (for consistency as explained) for the
> hardware and/or control domains.
> 
 Just to be sure I understand you correctly: you want to get rid of
 INITIAL_NR_GRANT_FRAMES and just grow from 0 on instead of starting at
 the current value 4, right?
>>>
>>> Yes, the use of INITIAL_NR_GRANT_FRAMES would move to that
>>> first "grow" invocation.
>>
>> Hmm, shouldn't we just grow one frame after the other? Is it really true
>> that most domains will need more than 1500 grants? A simple test domain
>> with one disk and one NIC seems to be okay with a little bit more than
>> 300 grants, so 1 grant table frame would be enough for that case.
> 
> Yes and no. Yes because indeed many domains will not need more.
> No, however, because of the risk of memory shortage: By giving all
> domains a certain minimum, they can prepare themselves for how
> much (or really how little) they can do without depending on there
> being memory available to grow the tables later on. IOW I don't
> generally object to the limit being reduced, but not as a side effect
> of the re-work. In case of problems this needs to be easy to revert
> (or adjust). I.e. the change can be in the same series, but ought to
> be a separate patch.

Okay, I'll add another patch for that purpose.


Juergen

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

Re: [Xen-devel] [PATCH v4 10/11] public: add XENFEAT_ARM_SMCCC_supported feature

[Julien Grall]

On 04/09/17 10:57, Sergej Proskurin wrote:

Hi Julien,


On 09/04/2017 08:07 AM, Julien Grall wrote:

Hello,

Sorry for the formatting, writing from my phone. Ki

On Thu, 31 Aug 2017, 22:18 Sergej Proskurin  wrote:



[...]



On your first mail, you started with "smc injection doesn't work", then "I
replace instruction" and now you mention about single-stepping.

This doesn't help at all to understand what you are doing and really not
related to this thread.

So can you please details exactly what you are doing rather than giving
bits by bits?



I will provide more information in a separate thread soon so that the
actual issue, hopefully, will become clearer. Thank you.


I use SMC instructions as the guest can register for BRK events. The
guest cannot register for SMC events. So, in order stay stealthy towards
the guest and also not to cope with BRK re-injections, SMC's seemed to
be the right choice :


I have already said that using SMC is a pretty bad idea when Tamas added
the trapping and you guys still seem to think it is a good idea...


I did not know about this conversation with Tamas. Why do you believe
that using SMC instructions is not a good idea? Could you please refer
me to the particular thread? Thank you.


I am not sure on which thread it was discussed. 
https://lists.gt.net/xen/devel/427459 may contain some details.


By definition SMC is for Secure Monitor Call. It might be possible to 
have a guest access the secure firmware (e.g imagine an Android guest 
doing video decoding). Given that you don't identify the immediate of 
the SMC (which is BTW not easily available on ARMv7), you cannot have 
both interacting together. And even with that you don't know if the SMC 
#imm might be used by the firmware...


Furthermore, SMC cannot be executed at EL0 so you can't monitor 
application. They also won't be available if the platform that does not 
have EL3.


So yes SMC is a pretty bad choice here if you want to get a generic 
solution.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 6/8] xen: add new domctl hypercall to set grant table resource limits

[Juergen Gross]

On 11/09/17 13:14, Jan Beulich wrote:
 On 11.09.17 at 12:48,  wrote:
>> On 08/09/17 17:55, Jan Beulich wrote:
>> On 08.09.17 at 08:56,  wrote:
 --- a/xen/common/grant_table.c
 +++ b/xen/common/grant_table.c
 @@ -3667,6 +3667,32 @@ void grant_table_init_vcpu(struct vcpu *v)
  v->maptrack_tail = MAPTRACK_TAIL;
  }
  
 +int grant_table_set_limits(struct domain *d, unsigned int grant_frames,
 +   unsigned int maptrack_frames)
 +{
 +struct grant_table *gt = d->grant_table;
 +int ret = -EBUSY;
 +
 +if ( !gt )
 +return -EEXIST;
>>>
>>> How does EEXIST represent the error condition?
>>
>> Yes, this was a bad choice. What about ENOENT?
> 
> Fine with me. Or ENODEV.
> 
 +ret = 0;
 +if ( grant_frames )
 +gt->max_grant_frames = grant_frames;
 +if ( maptrack_frames )
 +gt->max_maptrack_frames = maptrack_frames;
>>>
>>> Together with what I have said regarding making the invocation
>>> of this domctl mandatory, I think these two shouldn't be conditional.
>>> In particular for maptrack I also don't see why a domain couldn't
>>> do with a limit of zero, as long as it's not serving as a backend for
>>> another guest.
>>
>> Okay, then I'd need to specify a "take hypervisor default" value (e.g.
>> ~0) in order to handle the case where no value was specified in the
>> domain's config file.
> 
> Well, part of the point I was trying to make in earlier replies on
> other patches of this series is that I think the lack of a guest
> config file setting should not invoke a _hypervisor_ default.
> Instead, the tool stack should establish a sensible one.

Okay, I can add this to the series.

> 
>> The question would be then: do we want to set maptrack to 0 as default
>> and require it to be specified for backend domains (driver domains,
>> stubdoms)?
> 
> I think so, yes. Question is whether there's a way for the tool stack
> to easily recognize a driver domain when it's being created.

I could think of various mechanisms for driver domains:

1. Add an explicit config item (I guess this could be utilized for other
   cases like XSM, too).

2. Do some guess work, e.g. any domain with PCI-passthrough configured
   could be regarded as a potential driver domain.

3. Just require the max_maptrack_frames= config item.

Starting with 3. is the easiest solution for now, it can be switched to
1. or 2. later.


Juergen

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

[Xen-devel] [PATCH] mem_access: switch to plain bool

[Wei Liu]

Signed-off-by: Wei Liu 
---
Cc: Razvan Cojocaru 
Cc: Tamas K Lengyel 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/arm/mem_access.c|  4 ++--
 xen/arch/x86/mm/mem_access.c | 16 
 xen/include/asm-arm/mem_access.h |  8 
 xen/include/asm-x86/mem_access.h |  8 
 4 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
index db9ad3f3c9..0f2cbb81d3 100644
--- a/xen/arch/arm/mem_access.c
+++ b/xen/arch/arm/mem_access.c
@@ -219,10 +219,10 @@ err:
 return page;
 }
 
-bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec npfec)
+bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec npfec)
 {
 int rc;
-bool_t violation;
+bool violation;
 xenmem_access_t xma;
 vm_event_request_t *req;
 struct vcpu *v = current;
diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index 414e38f998..9211fc0abe 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -83,7 +83,7 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
   const vm_event_response_t *rsp)
 {
 xenmem_access_t access;
-bool violation = 1;
+bool violation = true;
 const struct vm_event_mem_access *data = &rsp->u.mem_access;
 struct domain *d = v->domain;
 struct p2m_domain *p2m = NULL;
@@ -129,7 +129,7 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
 break;
 
 case XENMEM_access_rwx:
-violation = 0;
+violation = false;
 break;
 }
 }
@@ -137,9 +137,9 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
 return violation;
 }
 
-bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
-struct npfec npfec,
-vm_event_request_t **req_ptr)
+bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
+  struct npfec npfec,
+  vm_event_request_t **req_ptr)
 {
 struct vcpu *v = current;
 unsigned long gfn = gpa >> PAGE_SHIFT;
@@ -167,7 +167,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
 rc = p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw, 
-1);
 ASSERT(rc == 0);
 gfn_unlock(p2m, gfn, 0);
-return 1;
+return true;
 }
 else if ( p2ma == p2m_access_n2rwx )
 {
@@ -188,7 +188,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
   "no vm_event listener VCPU %d, dom %d\n",
   v->vcpu_id, d->domain_id);
 domain_crash(v->domain);
-return 0;
+return false;
 }
 else
 {
@@ -204,7 +204,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
 ASSERT(rc == 0);
 }
 gfn_unlock(p2m, gfn, 0);
-return 1;
+return true;
 }
 }
 
diff --git a/xen/include/asm-arm/mem_access.h b/xen/include/asm-arm/mem_access.h
index 3a155f84eb..1610635c5b 100644
--- a/xen/include/asm-arm/mem_access.h
+++ b/xen/include/asm-arm/mem_access.h
@@ -22,20 +22,20 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
   const vm_event_response_t *rsp)
 {
 /* Not supported on ARM. */
-return 0;
+return false;
 }
 
 /* vm_event and mem_access are supported on any ARM guest */
-static inline bool_t p2m_mem_access_sanity_check(struct domain *d)
+static inline bool p2m_mem_access_sanity_check(struct domain *d)
 {
-return 1;
+return true;
 }
 
 /*
  * Send mem event based on the access. Boolean return value indicates if trap
  * needs to be injected into guest.
  */
-bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec 
npfec);
+bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec npfec);
 
 struct page_info*
 p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned long flag,
diff --git a/xen/include/asm-x86/mem_access.h b/xen/include/asm-x86/mem_access.h
index 9f7b409b4e..4043c9fb4d 100644
--- a/xen/include/asm-x86/mem_access.h
+++ b/xen/include/asm-x86/mem_access.h
@@ -34,9 +34,9 @@
  * ring. Once having released get_gfn* locks caller must also xfree the
  * request.
  */
-bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
-struct npfec npfec,
-vm_event_request_t **req_ptr);
+bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
+  struct npfec npfec,
+  vm_event_request_t **req_ptr);
 
 /* Check for emulation and mark vcpu for skipping one instruction
  * upon rescheduling if required. */
@@ -44,7 +44,7 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
   const vm_event_re