[Xen-devel] [qemu-upstream-unstable baseline-only test] 74494: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74494 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74494/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64  broken
 build-i386   broken
 build-armhf-pvopsbroken
 build-i386-xsm   broken
 build-amd64-xsm  broken
 build-amd64-pvopsbroken
 build-i386-pvops broken
 build-armhf-xsm  broken
 build-armhf  broken
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning
 build-armhf-xsm   3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 

[Xen-devel] [xen-4.7-testing baseline-only test] 74489: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74489 xen-4.7-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74489/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64  broken
 build-amd64-prev broken
 build-i386   broken
 build-armhf-pvopsbroken
 build-i386-xsm   broken
 build-amd64-xtf  broken
 build-amd64-xsm  broken
 build-amd64-pvopsbroken
 build-i386-pvops broken
 build-armhf-xsm  broken
 build-armhf  broken
 build-i386-prev  broken
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning
 build-armhf-xsm   3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   

Re: [Xen-devel] Patches for stable

[Thomas Backlund]

Den 05.04.2018 kl. 10:02, skrev Juergen Gross:



The kernel is wrong here. You don't want to take the patches fixing the
issue. That's rather sad as PVH mode was meant to replace PV in the
future, which will remove the need for most of the paravirt ops stuff.
You are just shifting that possibility some months further into the
future.

I won't fight against you any longer.



Please post the series adapted for 4.14 anyway for distros & users 
wanting to have the 4.14 series kernels working with new xen.


--
Thomas

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

Re: [Xen-devel] [PATCH v3 2/2] xen/arm: Add Marvell ARMADA 3700 early printk support

[Amit Tomer]

Hi,

> Compiled with CONFIG_EARLY_PRINTK=mvebu, I see Xen's pre-DT boot
> messages. In addition to my Reviewed-by:
>
> Tested-by: Andre Przywara 
>

Thank you!

Thanks
-Amit

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

Re: [Xen-devel] [PATCH v3 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC

[Amit Tomer]

Hi,

> Works like a charm, can log into Dom0, Xen console works as well. So in
> addition to my Reviewed-by:
>
> Tested-by: Andre Przywara 
>

 Thank you for your time on this!

Thanks
-Amit

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 121876
 build-armhf   6 xen-buildfail REGR. vs. 121876

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  18d12056ccea435dca7fcbe2085fff15bca19046
baseline version:
 xen  451004603247205467ec34b366b4cfa3814a5d95

Last test of basis   121876  2018-04-05 10:04:25 Z0 days
Failing since121889  2018-04-05 13:02:10 Z0 days5 attempts
Testing same since   121920  2018-04-05 19:01:57 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Wei Liu 

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


Not pushing.


commit 18d12056ccea435dca7fcbe2085fff15bca19046
Author: Julien Grall 
Date:   Wed Feb 21 13:46:25 2018 +

xen/pdx: Introduce helper to convert MFN <-> PDX

This will avoid use of pfn_to_pdx(mfn_x(mfn)) over the code base.

Signed-off-by: Julien Grall 
Reviewed-by: Wei Liu 
Acked-by: Andrew Cooper 

commit cf2239a6288c7095583d3351f5024ab8c1e37f87
Author: Julien Grall 
Date:   Wed Feb 21 13:46:24 2018 +

xen/x86: mm: Switch x86/mm.c to use typesafe for virt_to_mfn

No functional change intended.

While we are here, use PFN_DOWN() rather than open coding it.

Signed-off Julien Grall 
Acked-by: Jan Beulich 

commit da588a0dbe76c52fdfd90582bf560643a1f9eb20
Author: Julien Grall 
Date:   Wed Feb 21 13:46:24 2018 +

xen/x86: Remove unused override of page_to_mfn/mfn_to_page

A few files override page_to_mfn/mfn_to_page but actually never use
those macros. So drop them.

Signed-off-by: Julien Grall 
Acked-by: George Dunlap 
Acked-by: Jan Beulich 

commit acf92c83b58e404374300397801deb80fb8d883e
Author: Wei Liu 
Date:   Fri Mar 9 17:20:14 2018 +

x86/mm: skip incrementing mfn if it is not a valid mfn

In a follow-up patch, some callers will be switched to pass
INVALID_MFN instead of zero for non-present mappings. So skip
incrementing mfn if it is not a valid one.

Signed-off-by: Wei Liu 
Signed-off-by: Julien Grall 
Reviewed-by: Jan Beulich 

commit 454efb2a31b64b98e3dd55c083ce41b87375faa6
Author: Jan Beulich 
Date:   Mon Mar 19 07:40:12 2018 -0600

x86/XPTI: reduce .text.entry

This exposes less code pieces and at the same time reduces the range
covered from slightly above 3 pages to a little below 2 of them.

The code being moved is unchanged, except for the removal of trailing
blanks, insertion of blanks between operands, and a pointless q suffix
from "retq".

A few more small pieces could be moved, but it seems better 

[Xen-devel] [xen-4.6-testing baseline-only test] 74488: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74488 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74488/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64  broken
 build-amd64-prev broken
 build-i386   broken
 build-armhf-pvopsbroken
 build-i386-xsm   broken
 build-amd64-xtf  broken
 build-amd64-xsm  broken
 build-amd64-pvopsbroken
 build-i386-pvops broken
 build-armhf-xsm  broken
 build-armhf  broken
 build-i386-prev  broken
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning
 build-armhf-xsm   3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   

[Xen-devel] [xtf test] 121817: all pass - PUSHED

[osstest service owner]

flight 121817 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121817/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  e8debcece867acffc2c0c477f4572948c585940b
baseline version:
 xtf  086cad25a948e54cf84319f94c1799cbcf6b4d97

Last test of basis   121750  2018-04-03 18:31:58 Z2 days
Testing same since   121817  2018-04-04 20:44:11 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xtf.git
   086cad2..e8debce  e8debcece867acffc2c0c477f4572948c585940b -> 
xen-tested-master

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

[Xen-devel] [xen-4.6-testing test] 121799: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
119227

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 121744 pass 
in 121799
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail in 
121744 pass in 121799
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 
fail in 121744 pass in 121799
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 121744 pass 
in 121799
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail pass 
in 121744
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail pass in 121744

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

[Xen-devel] [ovmf baseline-only test] 74496: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74496 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74496/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm  broken
 build-i386   broken
 build-amd64-pvopsbroken
 build-i386-xsm   broken
 build-amd64  broken
 build-i386-pvops broken
 build-amd64-xsm   4 host-install(4) broken REGR. vs. 72229
 build-amd64   4 host-install(4) broken REGR. vs. 72229
 build-amd64-pvops 4 host-install(4) broken REGR. vs. 72229
 build-i3864 host-install(4) broken REGR. vs. 72229
 build-i386-xsm4 host-install(4) broken REGR. vs. 72229
 build-i386-pvops  4 host-install(4) broken REGR. vs. 72229

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 c4172f80051effc62f3eceeeced4c0b66a80eb94
baseline version:
 ovmf a63be426f8e327181dda369348eae2768439536b

Last test of basis72229  2017-10-11 23:48:00 Z  176 days
Testing same since74496  2018-04-05 12:23:44 Z0 days1 attempts


People who touched revisions under test:
  Achin Gupta 
  Aleksei Kovura 
  Alex James 
  Ard Biesheuvel 
  Ard Biesheuvel  # ArmVirtQemu
  Arthur Heymans 
  Bell Song 
  Benjamin You 
  Bi, Dandan 
  Bin Wang 
  Bob Feng 
  BobCF 
  Bret Barkelew 
  Bret Barkelew 
  Brijesh Singh 
  Carsey, Jaben 
  Chao Zhang 
  Chao Zhang '
  Chasel Chiu 
  Chasel, Chiu 
  Chema Gonzalez 
  Chema Gonzalez 
  chenc2 
  Christian Ehrhardt 
  Dakota Chiang 
  Dandan Bi 
  Daniil Egranov 
  dann frazier 
  Eric Dong 
  Evan Lloyd 
  fanwang2 
  Felix Polyudov 
  Feng Bob C 
  Feng, Bob C 
  Feng, YunhuaX 
  Feng, YunhuaX 
  From: Yunhua Feng 
  Fu Siyuan 
  Gabriel Somlo 
  Gao, Liming 
  Gary Lin 
  Ge Song 
  Girish Pathak 
  Hao Wu 
  Hess Chen 
  Heyi Guo 
  Huajing Li 
  Jaben Carsey 
  Jeff Brasen 
  Jian J Wang 
  Jiaxin Wu 
  Jiewen Yao 
  Julien Grall 
  Junbiao Hong 
  Karunakar P 
  Kinney, Michael D 
  Laszlo Ersek 
  Leif Lindholm 
  Leo Duran 
  Liang Vincent 
  Liao Jui-peng 
  Liming Gao 
  Long Qin 
  M1cha 
  Marc Zyngier 
  Marc-Andr? Lureau 
  Marc-André Lureau 
  Marcin Wojtas 
  Marvin Haeuser 
  marvin.haeu...@outlook.com 
  Meenakshi Aggarwal 
  Michael D Kinney 
  Michael Kinney 
  Michael Turner 
  Michael Zimmermann 
  Ming Huang 
  Ming Huang 
  Pankaj Bansal 
  Paolo Bonzini 
  Paulo Alcantara 
  Peicong Li 

[Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm

[osstest service owner]

branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  74fd984ae699727ae98f4fc36450ff76c8fc7ff3
  Bug not present: 451004603247205467ec34b366b4cfa3814a5d95
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/121945/


  commit 74fd984ae699727ae98f4fc36450ff76c8fc7ff3
  Author: Andrew Cooper 
  Date:   Fri Mar 9 12:24:13 2018 +
  
  tools/libxl: Drop xc_domain_configuration_t from libxl__domain_build_state
  
  The data it stores is initialised and exclusively used within
  libxl__domain_make(), with the important details written back elsewhere by
  libxl__arch_domain_save_config().  Prepare xc_config on 
libxl__domain_make()'s
  stack, and drop the parameter.
  
  Signed-off-by: Andrew Cooper 
  Reviewed-by: Roger Pau Monné 
  Acked-by: Wei Liu 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build
 --summary-out=tmp/121945.bisection-summary --basis-template=121876 
--blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build
Searching for failure / basis pass:
 121936 fail [host=laxton1] / 121876 ok.
Failure / basis pass flights: 121936 / 121876
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 5c3fdee026a204a59cb392e43a313ab558de9682 
18d12056ccea435dca7fcbe2085fff15bca19046
Basis pass 5c3fdee026a204a59cb392e43a313ab558de9682 
451004603247205467ec34b366b4cfa3814a5d95
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen.git#5c3fdee026a204a59cb392e43a313ab558de9682-5c3fdee026a204a59cb392e43a313ab558de9682
 
git://xenbits.xen.org/xen.git#451004603247205467ec34b366b4cfa3814a5d95-18d12056ccea435dca7fcbe2085fff15bca19046
Loaded 1001 nodes in revision graph
Searching for test results:
 121876 pass 5c3fdee026a204a59cb392e43a313ab558de9682 
451004603247205467ec34b366b4cfa3814a5d95
 121889 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
c0d98b35714fb707217c9062b6518e158cd72eea
 121931 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
18d12056ccea435dca7fcbe2085fff15bca19046
 121902 pass 5c3fdee026a204a59cb392e43a313ab558de9682 
451004603247205467ec34b366b4cfa3814a5d95
 121938 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
74fd984ae699727ae98f4fc36450ff76c8fc7ff3
 121909 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
c0d98b35714fb707217c9062b6518e158cd72eea
 121905 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
c0d98b35714fb707217c9062b6518e158cd72eea
 121915 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
2649612686f968a52ce53d173f5c2a3088ad17dd
 121923 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
74fd984ae699727ae98f4fc36450ff76c8fc7ff3
 121920 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
18d12056ccea435dca7fcbe2085fff15bca19046
 121925 pass 5c3fdee026a204a59cb392e43a313ab558de9682 
451004603247205467ec34b366b4cfa3814a5d95
 121936 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
18d12056ccea435dca7fcbe2085fff15bca19046
 121939 pass 5c3fdee026a204a59cb392e43a313ab558de9682 
451004603247205467ec34b366b4cfa3814a5d95
 121945 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
74fd984ae699727ae98f4fc36450ff76c8fc7ff3
Searching for interesting versions
 Result found: flight 121876 (pass), for basis pass
 Result found: flight 121920 (fail), for basis failure
 Repro found: flight 121925 (pass), for basis pass
 Repro found: flight 121931 (fail), for basis failure
 0 revisions at 5c3fdee026a204a59cb392e43a313ab558de9682 
451004603247205467ec34b366b4cfa3814a5d95
No revisions left to test, checking graph state.
 Result found: flight 121876 (pass), for last pass
 Result found: flight 121923 (fail), for first failure
 Repro found: flight 121925 (pass), for last pass
 Repro found: flight 121938 (fail), for first failure
 Repro found: flight 121939 (pass), for last pass
 Repro found: flight 121945 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  74fd984ae699727ae98f4fc36450ff76c8fc7ff3
  Bug not present: 451004603247205467ec34b366b4cfa3814a5d95
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/121945/


  commit 74fd984ae699727ae98f4fc36450ff76c8fc7ff3
  Author: Andrew Cooper 
  Date:   Fri Mar 9 12:24:13 2018 +
  
  tools/libxl: Drop xc_domain_configuration_t from 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 121876
 build-armhf   6 xen-buildfail REGR. vs. 121876

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  18d12056ccea435dca7fcbe2085fff15bca19046
baseline version:
 xen  451004603247205467ec34b366b4cfa3814a5d95

Last test of basis   121876  2018-04-05 10:04:25 Z0 days
Failing since121889  2018-04-05 13:02:10 Z0 days4 attempts
Testing same since   121920  2018-04-05 19:01:57 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Wei Liu 

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


Not pushing.


commit 18d12056ccea435dca7fcbe2085fff15bca19046
Author: Julien Grall 
Date:   Wed Feb 21 13:46:25 2018 +

xen/pdx: Introduce helper to convert MFN <-> PDX

This will avoid use of pfn_to_pdx(mfn_x(mfn)) over the code base.

Signed-off-by: Julien Grall 
Reviewed-by: Wei Liu 
Acked-by: Andrew Cooper 

commit cf2239a6288c7095583d3351f5024ab8c1e37f87
Author: Julien Grall 
Date:   Wed Feb 21 13:46:24 2018 +

xen/x86: mm: Switch x86/mm.c to use typesafe for virt_to_mfn

No functional change intended.

While we are here, use PFN_DOWN() rather than open coding it.

Signed-off Julien Grall 
Acked-by: Jan Beulich 

commit da588a0dbe76c52fdfd90582bf560643a1f9eb20
Author: Julien Grall 
Date:   Wed Feb 21 13:46:24 2018 +

xen/x86: Remove unused override of page_to_mfn/mfn_to_page

A few files override page_to_mfn/mfn_to_page but actually never use
those macros. So drop them.

Signed-off-by: Julien Grall 
Acked-by: George Dunlap 
Acked-by: Jan Beulich 

commit acf92c83b58e404374300397801deb80fb8d883e
Author: Wei Liu 
Date:   Fri Mar 9 17:20:14 2018 +

x86/mm: skip incrementing mfn if it is not a valid mfn

In a follow-up patch, some callers will be switched to pass
INVALID_MFN instead of zero for non-present mappings. So skip
incrementing mfn if it is not a valid one.

Signed-off-by: Wei Liu 
Signed-off-by: Julien Grall 
Reviewed-by: Jan Beulich 

commit 454efb2a31b64b98e3dd55c083ce41b87375faa6
Author: Jan Beulich 
Date:   Mon Mar 19 07:40:12 2018 -0600

x86/XPTI: reduce .text.entry

This exposes less code pieces and at the same time reduces the range
covered from slightly above 3 pages to a little below 2 of them.

The code being moved is unchanged, except for the removal of trailing
blanks, insertion of blanks between operands, and a pointless q suffix
from "retq".

A few more small pieces could be moved, but it seems better 

[Xen-devel] [libvirt test] 121771: tolerable all pass - PUSHED

[osstest service owner]

flight 121771 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121771/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 121707
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 121707
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 121707
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-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-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  9c75425aa263abe248ab6c4895b57b9dae2a53ae
baseline version:
 libvirt  439c27b1ae35e0daab6e86fc6320ea1682a3aabd

Last test of basis   121707  2018-04-02 04:20:30 Z3 days
Failing since121735  2018-04-03 04:27:24 Z2 days2 attempts
Testing same since   121771  2018-04-04 11:06:18 Z1 days1 attempts


People who touched revisions under test:
  Daniel P. Berrangé 
  Erik Skultety 
  Jiri Denemark 
  John Ferlan 
  Kashyap Chamarthy 
  Peter Krempa 
  Radostin Stoyanov 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd 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 

[Xen-devel] Xen and certifications, Minutes of the meeting on Apr 4th

[Stefano Stabellini]

Hi all,

The main topic of the meeting was certifications for Xen on ARM. The gap
analysis document, mentioned in the previous call, is copyrighted. It
might not be possible to relicense it. Regardless of the document, we
started discussing the major work items and next steps.

1) Requirements to the code, a subset of MISRA for ASIL B
Next step: get more information about requirements and publish it to
xen-devel.

2) Create a subset of functions that need to go through certifications
Next step: create a small Kconfig. We could use the Renesas Rcar as
reference. We need a discussion about the features we need, for example
real-time schedulers, do we need them or not?

3) Understand how to address dom0. FreeRTOS Dom0 sounds like a good
solution.
Next step: reach out to Dornerworks and/or others that worked with
FreeRTOS on Xen before. Figure out whether FreeRTOS is actually a
suitable solution and what needs to be done to run FreeRTOS as Dom0.

4) Create artifacts, such as docs, fault analysis, prove fault tolerance,
safety management docs, development processes.
Next step: we need to bring in a company, a certification body, to guide
us through the process.


I wrote these items to the Xen Project wiki:
https://wiki.xenproject.org/wiki/Safety_Certification

I contacted Lars (CC'ed) who volunteered to help.


We also briefly discussed other topics during the call, see below.

AGL will select 2 hypervisors out of the list. Artem has already an
out-of-the-box solution for AGL. Artem will chase up and make sure that
Xen will be one of the two.

Genivi has an hypervisor group. It is leaning toward Xen now. Genivi is
trying to ensure that they are aligned with all vendors.

Chase up with Konrad on missing ACKs on patches for PV Audio.

Artem suggested to write a whitepaper about Xen real-time capabilities.
Stefano volunteered to help.

On Spectre: we need to update XSA with the status.

Mirela is ready to send patches for cpu suspend and power saving. Julien
suggested that cpu hotplug needs to be fixed before suspend/resume.


Cheers,

Stefano

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

Re: [Xen-devel] [PATCH v2] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE

[Boris Ostrovsky]

On 04/05/2018 11:42 AM, Paul Durrant wrote:
> My recent Xen patch series introduces a new HYPERVISOR_memory_op to
> support direct priv-mapping of certain guest resources (such as ioreq
> pages, used by emulators) by a tools domain, rather than having to access
> such resources via the guest P2M.
>
> This patch adds the necessary infrastructure to the privcmd driver and
> Xen MMU code to support direct resource mapping.
>
> NOTE: The adjustment in the MMU code is partially cosmetic. Xen will now
>   allow a PV tools domain to map guest pages either by GFN or MFN, thus
>   the term 'mfn' has been swapped for 'pfn' in the lower layers of the
>   remap code.
>
> Signed-off-by: Paul Durrant 
> ---
> Cc: Boris Ostrovsky 
> Cc: Juergen Gross 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
>
> v2:
>  - Fix bug when mapping multiple pages of a resource


Only a few nits below.

> ---
>  arch/x86/xen/mmu.c |  50 +++-
>  drivers/xen/privcmd.c  | 130 
> +
>  include/uapi/xen/privcmd.h |  11 
>  include/xen/interface/memory.h |  66 +
>  include/xen/interface/xen.h|   7 ++-
>  include/xen/xen-ops.h  |  24 +++-
>  6 files changed, 270 insertions(+), 18 deletions(-)
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index d33e7dbe3129..8453d7be415c 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -65,37 +65,42 @@ static void xen_flush_tlb_all(void)
>  #define REMAP_BATCH_SIZE 16
>  
>  struct remap_data {
> - xen_pfn_t *mfn;
> + xen_pfn_t *pfn;
>   bool contiguous;
> + bool no_translate;
>   pgprot_t prot;
>   struct mmu_update *mmu_update;
>  };
>  
> -static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
> +static int remap_area_pfn_pte_fn(pte_t *ptep, pgtable_t token,
>unsigned long addr, void *data)
>  {
>   struct remap_data *rmd = data;
> - pte_t pte = pte_mkspecial(mfn_pte(*rmd->mfn, rmd->prot));
> + pte_t pte = pte_mkspecial(mfn_pte(*rmd->pfn, rmd->prot));
>  
>   /* If we have a contiguous range, just update the mfn itself,
>  else update pointer to be "next mfn". */

This probably also needs to be updated (and while at it, comment style
fixed)

>   if (rmd->contiguous)
> - (*rmd->mfn)++;
> + (*rmd->pfn)++;
>   else
> - rmd->mfn++;
> + rmd->pfn++;
>  
> - rmd->mmu_update->ptr = virt_to_machine(ptep).maddr | 
> MMU_NORMAL_PT_UPDATE;
> + rmd->mmu_update->ptr = virt_to_machine(ptep).maddr;
> + rmd->mmu_update->ptr |= rmd->no_translate ?
> + MMU_PT_UPDATE_NO_TRANSLATE :
> + MMU_NORMAL_PT_UPDATE;
>   rmd->mmu_update->val = pte_val_ma(pte);
>   rmd->mmu_update++;
>  
>   return 0;
>  }
>  
> -static int do_remap_gfn(struct vm_area_struct *vma,
> +static int do_remap_pfn(struct vm_area_struct *vma,
>   unsigned long addr,
> - xen_pfn_t *gfn, int nr,
> + xen_pfn_t *pfn, int nr,
>   int *err_ptr, pgprot_t prot,
> - unsigned domid,
> + unsigned int domid,
> + bool no_translate,
>   struct page **pages)
>  {
>   int err = 0;
> @@ -106,11 +111,12 @@ static int do_remap_gfn(struct vm_area_struct *vma,
>  
>   BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
>  
> - rmd.mfn = gfn;
> + rmd.pfn = pfn;
>   rmd.prot = prot;
>   /* We use the err_ptr to indicate if there we are doing a contiguous
>* mapping or a discontigious mapping. */

Style.

>   rmd.contiguous = !err_ptr;
> + rmd.no_translate = no_translate;
>  
>   while (nr) {
>   int index = 0;
> @@ -121,7 +127,7 @@ static int do_remap_gfn(struct vm_area_struct *vma,
>  
>   rmd.mmu_update = mmu_update;
>   err = apply_to_page_range(vma->vm_mm, addr, range,
> -   remap_area_mfn_pte_fn, );
> +   remap_area_pfn_pte_fn, );
>   if (err)
>   goto out;
>  
> @@ -175,7 +181,8 @@ int xen_remap_domain_gfn_range(struct vm_area_struct *vma,
>   if (xen_feature(XENFEAT_auto_translated_physmap))
>   return -EOPNOTSUPP;
>  
> - return do_remap_gfn(vma, addr, , nr, NULL, prot, domid, pages);
> + return do_remap_pfn(vma, addr, , nr, NULL, prot, domid, false,
> + pages);
>  }
>  EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_range);
>  
> @@ -183,7 +190,7 @@ int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
>  unsigned long addr,
>  xen_pfn_t *gfn, int nr,
>

[Xen-devel] [seabios baseline-only test] 74495: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74495 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74495/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm  broken
 build-i386   broken
 build-amd64-pvopsbroken
 build-i386-xsm   broken
 build-amd64  broken
 build-i386-pvops broken
 build-i3864 host-install(4) broken REGR. vs. 72427
 build-amd64-xsm   4 host-install(4) broken REGR. vs. 72427
 build-amd64-pvops 4 host-install(4) broken REGR. vs. 72427
 build-amd64   4 host-install(4) broken REGR. vs. 72427
 build-i386-pvops  4 host-install(4) broken REGR. vs. 72427
 build-i386-xsm4 host-install(4) broken REGR. vs. 72427

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a

version targeted for testing:
 seabios  4922d6cb391b8ea48a35a73c46e484cf5f1a9b1a
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis72427  2017-11-04 12:47:25 Z  152 days
Testing same since74495  2018-04-05 12:21:43 Z0 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Marc-André Lureau 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Nikolay Nikolov 
  Paul Menzel 
  Stefan Berger 
  Stephen Douthit 

jobs:
 build-amd64-xsm  broken  
 build-i386-xsm   broken  
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked 
 test-amd64-amd64-qemuu-nested-amdblocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ws16-amd64 blocked 
 test-amd64-i386-xl-qemuu-ws16-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win10-i386 blocked 
 test-amd64-i386-xl-qemuu-win10-i386  blocked 
 test-amd64-amd64-qemuu-nested-intel  blocked 
 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 121876
 build-armhf   6 xen-buildfail REGR. vs. 121876

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  18d12056ccea435dca7fcbe2085fff15bca19046
baseline version:
 xen  451004603247205467ec34b366b4cfa3814a5d95

Last test of basis   121876  2018-04-05 10:04:25 Z0 days
Failing since121889  2018-04-05 13:02:10 Z0 days3 attempts
Testing same since   121920  2018-04-05 19:01:57 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Wei Liu 

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


Not pushing.


commit 18d12056ccea435dca7fcbe2085fff15bca19046
Author: Julien Grall 
Date:   Wed Feb 21 13:46:25 2018 +

xen/pdx: Introduce helper to convert MFN <-> PDX

This will avoid use of pfn_to_pdx(mfn_x(mfn)) over the code base.

Signed-off-by: Julien Grall 
Reviewed-by: Wei Liu 
Acked-by: Andrew Cooper 

commit cf2239a6288c7095583d3351f5024ab8c1e37f87
Author: Julien Grall 
Date:   Wed Feb 21 13:46:24 2018 +

xen/x86: mm: Switch x86/mm.c to use typesafe for virt_to_mfn

No functional change intended.

While we are here, use PFN_DOWN() rather than open coding it.

Signed-off Julien Grall 
Acked-by: Jan Beulich 

commit da588a0dbe76c52fdfd90582bf560643a1f9eb20
Author: Julien Grall 
Date:   Wed Feb 21 13:46:24 2018 +

xen/x86: Remove unused override of page_to_mfn/mfn_to_page

A few files override page_to_mfn/mfn_to_page but actually never use
those macros. So drop them.

Signed-off-by: Julien Grall 
Acked-by: George Dunlap 
Acked-by: Jan Beulich 

commit acf92c83b58e404374300397801deb80fb8d883e
Author: Wei Liu 
Date:   Fri Mar 9 17:20:14 2018 +

x86/mm: skip incrementing mfn if it is not a valid mfn

In a follow-up patch, some callers will be switched to pass
INVALID_MFN instead of zero for non-present mappings. So skip
incrementing mfn if it is not a valid one.

Signed-off-by: Wei Liu 
Signed-off-by: Julien Grall 
Reviewed-by: Jan Beulich 

commit 454efb2a31b64b98e3dd55c083ce41b87375faa6
Author: Jan Beulich 
Date:   Mon Mar 19 07:40:12 2018 -0600

x86/XPTI: reduce .text.entry

This exposes less code pieces and at the same time reduces the range
covered from slightly above 3 pages to a little below 2 of them.

The code being moved is unchanged, except for the removal of trailing
blanks, insertion of blanks between operands, and a pointless q suffix
from "retq".

A few more small pieces could be moved, but it seems better 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm 10 debian-install   fail REGR. vs. 121723
 test-arm64-arm64-xl  10 debian-install   fail REGR. vs. 121723
 test-armhf-armhf-xl-xsm  10 debian-install   fail REGR. vs. 121723
 test-armhf-armhf-xl-arndale  10 debian-install   fail REGR. vs. 121723
 test-armhf-armhf-xl  10 debian-install   fail REGR. vs. 121723

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 10 debian-install   fail REGR. vs. 121723

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail 
blocked in 121723
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 121723
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 121723
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop   fail blocked in 121723
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 121723
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 121723
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 121723
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 121723
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 121723
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 121723
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-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-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-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-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-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 17 guest-stop  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-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux5cdf9a5fa3f9caf79e16f4053b53010e36d93eb8
baseline version:
 linux0adb32858b0bddf4ada5f364a84ed60b196dbcda

Last test of basis  (not found) 
Failing since   (not found) 
Testing same since   121768  2018-04-04 09:39:19 Z1 days1 attempts

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

[Xen-devel] [linux-3.18 baseline-only test] 74486: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74486 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74486/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64  broken
 build-i386   broken
 build-armhf-pvopsbroken
 build-i386-xsm   broken
 build-amd64-xsm  broken
 build-amd64-pvopsbroken
 build-i386-pvops broken
 build-armhf-xsm  broken
 build-armhf  broken
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning
 build-armhf-xsm   3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-examine   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 

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

[Stefano Stabellini]

On Tue, 3 Apr 2018, Julien Grall wrote:
> Most of the users of page_to_mfn and mfn_to_page are either overriding
> the macros to make them work with mfn_t or use mfn_x/_mfn because the
> rest of the function use mfn_t.
> 
> So make page_to_mfn and mfn_to_page return mfn_t by default. The __*
> version are now dropped as this patch will convert all the remaining
> non-typesafe callers.
> 
> Only reasonable clean-ups are done in this patch. The rest will use
> _mfn/mfn_x for the time being.
> 
> Lastly, domain_page_to_mfn is also converted to use mfn_t given that
> most of the callers are now switched to _mfn(domain_page_to_mfn(...)).
> 
> Signed-off-by: Julien Grall 
> Acked-by: Razvan Cojocaru 
> Reviewed-by: Paul Durrant 
> Reviewed-by: Boris Ostrovsky 
> Reviewed-by: Kevin Tian 
> Reviewed-by: Wei Liu 
> Acked-by: Jan Beulich 
> Reviewed-by: George Dunlap 
> Acked-by: Tim Deegan 

for the arm parts

Acked-by: Stefano Stabellini 

> ---
> 
> Andrew suggested to drop IS_VALID_PAGE in xen/tmem_xen.h. His comment
> was:
> 
> "/sigh  This is tautological.  The definition of a "valid mfn" in this
> case is one for which we have frametable entry, and by having a struct
> page_info in our hands, this is by definition true (unless you have a
> wild pointer, at which point your bug is elsewhere).
> 
> IS_VALID_PAGE() is only ever used in assertions and never usefully, so
> instead I would remove it entirely rather than trying to fix it up."
> 
> I can remove the function in a separate patch at the begining of the
> series if Konrad (TMEM maintainer) is happy with that.
> 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Tamas K Lengyel 
> Cc: Suravee Suthikulpanit 
> Cc: Jun Nakajima 
> Cc: George Dunlap 
> Cc: Gang Wei 
> Cc: Shane Wang 
> 
> Changes in v7:
> - Add Tim's acked-by
> 
> Changes in v6:
> - Add Jan's acked-by
> - Add George's reviewed-by for x86/mm bits
> 
> Changes in v5:
> - Remove some spurious parentheses in the code changed
> - Remove spurious change in _set_gpfn_from_mfn
> - Add Razvan's acked-by
> - Add Paul's reviewed-by
> - Add Boris's reviewed-by
> - Add Kevin's reviewed-by
> - Add Wei's reviewed-by
> 
> Changes in v4:
> - Drop __page_to_mfn and __mfn_to_page. Reword the commit
> title/message to reflect that.
> 
> Changes in v3:
> - Rebase on the latest staging and fix some conflicts. Tags
> haven't be retained.
> - Switch the printf format to PRI_mfn
> 
> Changes in v2:
> - Some part have been moved in separate patch
> - Remove one spurious comment
> - Convert domain_page_to_mfn to use mfn_t
> ---
>  xen/arch/arm/domain_build.c |  2 --
>  xen/arch/arm/kernel.c   |  2 +-
>  xen/arch/arm/mem_access.c   |  2 +-
>  xen/arch/arm/mm.c   |  8 
>  xen/arch/arm/p2m.c  | 10 ++
>  xen/arch/x86/cpu/vpmu.c |  4 ++--
>  xen/arch/x86/domain.c   | 21 +++--
>  xen/arch/x86/domain_page.c  |  6 +++---
>  xen/arch/x86/hvm/dm.c   |  2 +-
>  xen/arch/x86/hvm/dom0_build.c   |  6 +++---
>  xen/arch/x86/hvm/emulate.c  |  6 +++---
>  xen/arch/x86/hvm/hvm.c  | 12 ++--
>  xen/arch/x86/hvm/ioreq.c|  4 ++--
>  xen/arch/x86/hvm/stdvga.c   |  2 +-
>  xen/arch/x86/hvm/svm/svm.c  |  4 ++--
>  xen/arch/x86/hvm/viridian.c |  6 +++---
>  xen/arch/x86/hvm/vmx/vmcs.c |  2 +-
>  xen/arch/x86/hvm/vmx/vmx.c  | 10 +-
>  xen/arch/x86/hvm/vmx/vvmx.c |  6 +++---
>  xen/arch/x86/mm.c   |  4 
>  xen/arch/x86/mm/guest_walk.c|  6 +++---
>  xen/arch/x86/mm/hap/guest_walk.c|  2 +-
>  xen/arch/x86/mm/hap/hap.c   |  6 --
>  xen/arch/x86/mm/hap/nested_ept.c|  2 +-
>  xen/arch/x86/mm/mem_sharing.c   |  5 -
>  xen/arch/x86/mm/p2m-ept.c   |  8 
>  xen/arch/x86/mm/p2m-pod.c   |  6 --
>  xen/arch/x86/mm/p2m.c   |  6 --
>  xen/arch/x86/mm/paging.c|  6 --
>  

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

[Stefano Stabellini]

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

Acked-by: Stefano Stabellini 

> ---
> 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> 
> Changes in v6:
> - s/_mfn(0)/MFN 0/
> - Add Jan's and Wei's reviewed-by
> 
> Changes in v5:
> - Remove _mfn(0) when not needed or replace by INVALID_MFN.
> 
> Changes in v4:
> - Patch added
> ---
>  xen/arch/arm/mm.c |   2 +-
>  xen/common/grant_table.c  | 147 
> --
>  xen/include/asm-arm/grant_table.h |   2 +-
>  xen/include/asm-x86/grant_table.h |   2 +-
>  4 files changed, 82 insertions(+), 71 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 49080ca0ac..eb3659f913 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1408,7 +1408,7 @@ void gnttab_clear_flag(unsigned long nr, uint16_t *addr)
>  } while (cmpxchg(addr, old, old & mask) != old);
>  }
>  
> -void gnttab_mark_dirty(struct domain *d, unsigned long l)
> +void gnttab_mark_dirty(struct domain *d, mfn_t mfn)
>  {
>  /* XXX: mark dirty */
>  static int warning;
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index f9e3d1bb95..4bedf5984a 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -40,6 +40,12 @@
>  #include 
>  #include 
>  
> +/* Override macros from asm/page.h to make them work with mfn_t */
> +#undef page_to_mfn
> +#define page_to_mfn(pg) _mfn(__page_to_mfn(pg))
> +#undef mfn_to_page
> +#define mfn_to_page(mfn) __mfn_to_page(mfn_x(mfn))
> +
>  /* Per-domain grant information. */
>  struct grant_table {
>  /*
> @@ -167,7 +173,7 @@ struct gnttab_unmap_common {
>  
>  /* Shared state beteen *_unmap and *_unmap_complete */
>  uint16_t done;
> -unsigned long frame;
> +mfn_t frame;
>  struct domain *rd;
>  grant_ref_t ref;
>  };
> @@ -266,7 +272,7 @@ struct active_grant_entry {
>  grant.*/
>  grant_ref_t   trans_gref;
>  struct domain *trans_domain;
> -unsigned long frame;  /* Frame being granted. */
> +mfn_t frame;  /* Frame being granted. */
>  #ifndef NDEBUG
>  gfn_t gfn;/* Guest's idea of the frame being granted. */
>  #endif
> @@ -371,14 +377,14 @@ static inline unsigned int 
> grant_to_status_frames(unsigned int grant_frames)
> If rc == GNTST_okay, *page contains the page struct with a ref taken.
> Caller must do put_page(*page).
> If any error, *page = NULL, *frame = INVALID_MFN, no ref taken. */
> -static int get_paged_frame(unsigned long gfn, unsigned long *frame,
> +static int get_paged_frame(unsigned long gfn, mfn_t *frame,
> struct page_info **page, bool readonly,
> struct domain *rd)
>  {
>  int rc = GNTST_okay;
>  p2m_type_t p2mt;
>  
> -*frame = mfn_x(INVALID_MFN);
> +*frame = INVALID_MFN;
>  *page = get_page_from_gfn(rd, gfn, ,
>readonly ? P2M_ALLOC : P2M_UNSHARE);
>  if ( !*page )
> @@ -823,7 +829,7 @@ static int _set_status(unsigned gt_version,
>  
>  static struct active_grant_entry *grant_map_exists(const struct domain *ld,
> struct grant_table *rgt,
> -   unsigned long mfn,
> +   mfn_t mfn,
> grant_ref_t *cur_ref)
>  {
>  grant_ref_t ref, max_iter;
> @@ -842,7 +848,8 @@ static struct active_grant_entry *grant_map_exists(const 
> struct domain *ld,
>  {
>  struct active_grant_entry *act = active_entry_acquire(rgt, ref);
>  
> -if ( act->pin && act->domid == ld->domain_id && act->frame == mfn )
> +if ( act->pin && act->domid == ld->domain_id &&
> + mfn_eq(act->frame, mfn) )
>  return act;
>  active_entry_release(act);
>  }
> @@ -859,7 +866,7 @@ static struct active_grant_entry *grant_map_exists(const 
> struct domain *ld,
>  #define MAPKIND_READ 1
>  #define MAPKIND_WRITE 2
>  static unsigned int 

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

[Stefano Stabellini]

On Tue, 3 Apr 2018, Julien Grall wrote:
> The current prototype is slightly confusing because it takes a guest
> physical address and a machine physical frame (not address!). Switching to
> MFN will improve safety and reduce the chance to mistakenly invert the
> 2 parameters.
> 
> Signed-off-by: Julien grall 
> Reviewed-by: Wei Liu 
> Reviewed-by: Jan Beulich 

Acked-by: Stefano Stabellini 


> ---
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> 
> Changes in v5:
> - Add Wei's and Jan's reviewed-by
> 
> Changes in v4:
> - Patch added
> ---
>  xen/arch/arm/mm.c | 10 +-
>  xen/arch/x86/hvm/grant_table.c| 14 +++---
>  xen/arch/x86/pv/grant_table.c | 10 +-
>  xen/common/grant_table.c  |  8 
>  xen/include/asm-arm/grant_table.h |  9 -
>  xen/include/asm-x86/grant_table.h |  4 ++--
>  xen/include/asm-x86/hvm/grant_table.h |  8 
>  xen/include/asm-x86/pv/grant_table.h  |  8 
>  8 files changed, 35 insertions(+), 36 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 7af6baa3d6..49080ca0ac 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1418,7 +1418,7 @@ void gnttab_mark_dirty(struct domain *d, unsigned long 
> l)
>  }
>  }
>  
> -int create_grant_host_mapping(unsigned long addr, unsigned long frame,
> +int create_grant_host_mapping(unsigned long addr, mfn_t frame,
>unsigned int flags, unsigned int cache_flags)
>  {
>  int rc;
> @@ -1431,7 +1431,7 @@ int create_grant_host_mapping(unsigned long addr, 
> unsigned long frame,
>  t = p2m_grant_map_ro;
>  
>  rc = guest_physmap_add_entry(current->domain, gaddr_to_gfn(addr),
> - _mfn(frame), 0, t);
> + frame, 0, t);
>  
>  if ( rc )
>  return GNTST_general_error;
> @@ -1439,8 +1439,8 @@ int create_grant_host_mapping(unsigned long addr, 
> unsigned long frame,
>  return GNTST_okay;
>  }
>  
> -int replace_grant_host_mapping(unsigned long addr, unsigned long mfn,
> -unsigned long new_addr, unsigned int flags)
> +int replace_grant_host_mapping(unsigned long addr, mfn_t mfn,
> +   unsigned long new_addr, unsigned int flags)
>  {
>  gfn_t gfn = gaddr_to_gfn(addr);
>  struct domain *d = current->domain;
> @@ -1449,7 +1449,7 @@ int replace_grant_host_mapping(unsigned long addr, 
> unsigned long mfn,
>  if ( new_addr != 0 || (flags & GNTMAP_contains_pte) )
>  return GNTST_general_error;
>  
> -rc = guest_physmap_remove_page(d, gfn, _mfn(mfn), 0);
> +rc = guest_physmap_remove_page(d, gfn, mfn, 0);
>  
>  return rc ? GNTST_general_error : GNTST_okay;
>  }
> diff --git a/xen/arch/x86/hvm/grant_table.c b/xen/arch/x86/hvm/grant_table.c
> index 9ca9fe0425..ecd7d078ab 100644
> --- a/xen/arch/x86/hvm/grant_table.c
> +++ b/xen/arch/x86/hvm/grant_table.c
> @@ -25,7 +25,7 @@
>  
>  #include 
>  
> -int create_grant_p2m_mapping(uint64_t addr, unsigned long frame,
> +int create_grant_p2m_mapping(uint64_t addr, mfn_t frame,
>   unsigned int flags,
>   unsigned int cache_flags)
>  {
> @@ -41,14 +41,14 @@ int create_grant_p2m_mapping(uint64_t addr, unsigned long 
> frame,
>  p2mt = p2m_grant_map_rw;
>  rc = guest_physmap_add_entry(current->domain,
>   _gfn(addr >> PAGE_SHIFT),
> - _mfn(frame), PAGE_ORDER_4K, p2mt);
> + frame, PAGE_ORDER_4K, p2mt);
>  if ( rc )
>  return GNTST_general_error;
>  else
>  return GNTST_okay;
>  }
>  
> -int replace_grant_p2m_mapping(uint64_t addr, unsigned long frame,
> +int replace_grant_p2m_mapping(uint64_t addr, mfn_t frame,
>uint64_t new_addr, unsigned int flags)
>  {
>  unsigned long gfn = (unsigned long)(addr >> PAGE_SHIFT);
> @@ -60,15 +60,15 @@ int replace_grant_p2m_mapping(uint64_t addr, unsigned 
> long frame,
>  return GNTST_general_error;
>  
>  old_mfn = get_gfn(d, gfn, );
> -if ( !p2m_is_grant(type) || mfn_x(old_mfn) != frame )
> +if ( !p2m_is_grant(type) || !mfn_eq(old_mfn, frame) )
>  {
>  put_gfn(d, gfn);
>  gdprintk(XENLOG_WARNING,
> - "old mapping invalid (type %d, mfn %" PRI_mfn ", frame 
> %lx)\n",
> - type, mfn_x(old_mfn), frame);
> + 

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

[Stefano Stabellini]

On Tue, 3 Apr 2018, Julien Grall wrote:
> The current prototype is slightly confusing because it takes a virtual
> address and a physical frame (not address!). Switching to MFN will improve
> safety and reduce the chance to mistakenly invert the 2 parameters.
> 
> Also, take the opportunity to switch (a - b) >> PAGE_SHIFT to
> PFN_DOWN(a - b) in the code modified.
> 
> Signed-off-by: Julien Grall 
> Acked-by: Andrew Cooper 
> Reviewed-by: Wei Liu 
> Reviewed-by: George Dunlap 

Acked-by: Stefano Stabellini 


> ---
> 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Cc: Gang Wei 
> Cc: Shane Wang 
> Cc: Kevin Tian 
> 
> Changes in v6:
> - Add Andrew's acked-by
> - Add Wei's and George's reviewed-by
> 
> Changes in v5:
> - Use PFN_DOWN as suggested by Jan
> - Replace _mfn(0) by INVALID_MFN where relevant
> 
> Changes in v4:
> - Patch added
> ---
>  xen/arch/arm/mm.c  |  4 +--
>  xen/arch/x86/mm.c  | 58 
> +++---
>  xen/arch/x86/setup.c   | 20 ++---
>  xen/arch/x86/smpboot.c |  2 +-
>  xen/arch/x86/tboot.c   | 11 
>  xen/arch/x86/x86_64/mm.c   | 27 ++
>  xen/arch/x86/x86_64/mmconfig_64.c  |  6 ++--
>  xen/common/efi/boot.c  |  2 +-
>  xen/common/vmap.c  | 10 +--
>  xen/drivers/acpi/apei/erst.c   |  2 +-
>  xen/drivers/acpi/apei/hest.c   |  2 +-
>  xen/drivers/passthrough/vtd/dmar.c |  2 +-
>  xen/include/asm-arm/mm.h   |  2 +-
>  xen/include/xen/mm.h   |  2 +-
>  14 files changed, 80 insertions(+), 70 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 436df6936b..7af6baa3d6 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1065,11 +1065,11 @@ out:
>  }
>  
>  int map_pages_to_xen(unsigned long virt,
> - unsigned long mfn,
> + mfn_t mfn,
>   unsigned long nr_mfns,
>   unsigned int flags)
>  {
> -return create_xen_entries(INSERT, virt, _mfn(mfn), nr_mfns, flags);
> +return create_xen_entries(INSERT, virt, mfn, nr_mfns, flags);
>  }
>  
>  int populate_pt_range(unsigned long virt, unsigned long nr_mfns)
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 6d5f40482e..ec61887d76 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -213,7 +213,7 @@ static void __init init_frametable_chunk(void *start, 
> void *end)
>  while ( step && s + (step << PAGE_SHIFT) > e + (4 << PAGE_SHIFT) )
>  step >>= PAGETABLE_ORDER;
>  mfn = alloc_boot_pages(step, step);
> -map_pages_to_xen(s, mfn_x(mfn), step, PAGE_HYPERVISOR);
> +map_pages_to_xen(s, mfn, step, PAGE_HYPERVISOR);
>  }
>  
>  memset(start, 0, end - start);
> @@ -787,12 +787,12 @@ static int update_xen_mappings(unsigned long mfn, 
> unsigned int cacheattr)
>  XEN_VIRT_START + ((mfn - PFN_DOWN(xen_phys_start)) << PAGE_SHIFT);
>  
>  if ( unlikely(alias) && cacheattr )
> -err = map_pages_to_xen(xen_va, mfn, 1, 0);
> +err = map_pages_to_xen(xen_va, _mfn(mfn), 1, 0);
>  if ( !err )
> -err = map_pages_to_xen((unsigned long)mfn_to_virt(mfn), mfn, 1,
> +err = map_pages_to_xen((unsigned long)mfn_to_virt(mfn), _mfn(mfn), 1,
>   PAGE_HYPERVISOR | cacheattr_to_pte_flags(cacheattr));
>  if ( unlikely(alias) && !cacheattr && !err )
> -err = map_pages_to_xen(xen_va, mfn, 1, PAGE_HYPERVISOR);
> +err = map_pages_to_xen(xen_va, _mfn(mfn), 1, PAGE_HYPERVISOR);
>  return err;
>  }
>  
> @@ -4645,7 +4645,7 @@ l1_pgentry_t *virt_to_xen_l1e(unsigned long v)
>  
>  int map_pages_to_xen(
>  unsigned long virt,
> -unsigned long mfn,
> +mfn_t mfn,
>  unsigned long nr_mfns,
>  unsigned int flags)
>  {
> @@ -4677,13 +4677,13 @@ int map_pages_to_xen(
>  ol3e = *pl3e;
>  
>  if ( cpu_has_page1gb &&
> - !(((virt >> PAGE_SHIFT) | mfn) &
> + !(((virt >> PAGE_SHIFT) | mfn_x(mfn)) &
> ((1UL << (L3_PAGETABLE_SHIFT - PAGE_SHIFT)) - 1)) &&
>   nr_mfns >= (1UL << (L3_PAGETABLE_SHIFT - PAGE_SHIFT)) &&
>   !(flags & (_PAGE_PAT | MAP_SMALL_PAGES)) )
>  {
>  /* 1GB-page mapping. */
> -l3e_write_atomic(pl3e, l3e_from_pfn(mfn, 

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

[Stefano Stabellini]

On Tue, 3 Apr 2018, Julien Grall wrote:
> The function populate_pt_range is used to populate in advance the
> page-table but it will not do the actual mapping. So passing the MFN in
> parameter is pointless. Note that the only caller pass 0...
> 
> At the same time replace 0 by INVALID_MFNs. While this does not matter
> as the entry will marked as not valid and populated, INVALID_MFN
> helps the reader to know the MFN is invalid.
> 
> Signed-off-by: Julien Grall 
> Acked-by: Andrew Cooper 
> Reviewed-by: Wei Liu 
> Reviewed-by: George Dunlap 

Acked-by: Stefano Stabellini 


> --
> 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Tim Deegan 
> 
> Changes in v6:
> - Add George's and Wei's reviewed-by
> - Add Andrew's acked-by
> 
> Changes in v5:
> - Update the commit message to explain why 0 -> INVALID_MFN.
> 
> Changes in v4:
> - Patch added.
> ---
>  xen/arch/arm/mm.c| 5 ++---
>  xen/arch/x86/mm.c| 5 ++---
>  xen/common/vmap.c| 2 +-
>  xen/include/xen/mm.h | 3 +--
>  4 files changed, 6 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 1126e246c0..436df6936b 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1072,10 +1072,9 @@ int map_pages_to_xen(unsigned long virt,
>  return create_xen_entries(INSERT, virt, _mfn(mfn), nr_mfns, flags);
>  }
>  
> -int populate_pt_range(unsigned long virt, unsigned long mfn,
> -  unsigned long nr_mfns)
> +int populate_pt_range(unsigned long virt, unsigned long nr_mfns)
>  {
> -return create_xen_entries(RESERVE, virt, _mfn(mfn), nr_mfns, 0);
> +return create_xen_entries(RESERVE, virt, INVALID_MFN, nr_mfns, 0);
>  }
>  
>  int destroy_xen_mappings(unsigned long v, unsigned long e)
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 605f4377fa..6d5f40482e 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -5007,10 +5007,9 @@ int map_pages_to_xen(
>  return 0;
>  }
>  
> -int populate_pt_range(unsigned long virt, unsigned long mfn,
> -  unsigned long nr_mfns)
> +int populate_pt_range(unsigned long virt, unsigned long nr_mfns)
>  {
> -return map_pages_to_xen(virt, mfn, nr_mfns, MAP_SMALL_PAGES);
> +return map_pages_to_xen(virt, mfn_x(INVALID_MFN), nr_mfns, 
> MAP_SMALL_PAGES);
>  }
>  
>  /*
> diff --git a/xen/common/vmap.c b/xen/common/vmap.c
> index 0b23f8fb97..11785ffb0a 100644
> --- a/xen/common/vmap.c
> +++ b/xen/common/vmap.c
> @@ -42,7 +42,7 @@ void __init vm_init_type(enum vmap_region type, void 
> *start, void *end)
>  bitmap_fill(vm_bitmap(type), vm_low[type]);
>  
>  /* Populate page tables for the bitmap if necessary. */
> -populate_pt_range(va, 0, vm_low[type] - nr);
> +populate_pt_range(va, vm_low[type] - nr);
>  }
>  
>  static void *vm_alloc(unsigned int nr, unsigned int align,
> diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
> index 142aa73354..538478fa24 100644
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -175,8 +175,7 @@ int destroy_xen_mappings(unsigned long v, unsigned long 
> e);
>   * Create only non-leaf page table entries for the
>   * page range in Xen virtual address space.
>   */
> -int populate_pt_range(unsigned long virt, unsigned long mfn,
> -  unsigned long nr_mfns);
> +int populate_pt_range(unsigned long virt, unsigned long nr_mfns);
>  /* Claim handling */
>  unsigned long domain_adjust_tot_pages(struct domain *d, long pages);
>  int domain_set_outstanding_pages(struct domain *d, unsigned long pages);
> -- 
> 2.11.0
> 

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

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

[Stefano Stabellini]

On Tue, 3 Apr 2018, Julien Grall wrote:
> relinquish_shared_pages is never called on Arm.
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: George Dunlap 

Acked-by: Stefano Stabellini 


> ---
> 
> Cc: Stefano Stabellini 
> 
> Changes in v6:
> - Add George's reviewed-by
> 
> Changes in v4:
> - Patch added
> ---
>  xen/include/asm-arm/mm.h | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index cabb1daf30..09bec67f63 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -314,10 +314,6 @@ struct page_info *get_page_from_gva(struct vcpu *v, 
> vaddr_t va,
>  unsigned long flags);
>  
>  static inline void put_gfn(struct domain *d, unsigned long gfn) {}
> -static inline int relinquish_shared_pages(struct domain *d)
> -{
> -return 0;
> -}
>  
>  /*
>   * Arm does not have an M2P, but common code expects a handful of
> -- 
> 2.11.0
> 

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

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

[Stefano Stabellini]

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

Acked-by: Stefano Stabellini 


> ---
> 
> Cc: Stefano Stabellini 
> 
> Changes in v6:
> - Add a comment to explain why we implement dummy version of M2P
> for Arm.
> - Add George's reviewed-by
> - Fix typo in the commit message
> 
> Changes in v4:
> - Patch added.
> ---
>  xen/include/asm-arm/mm.h | 29 -
>  1 file changed, 8 insertions(+), 21 deletions(-)
> 
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index a0e922f360..cabb1daf30 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -313,33 +313,20 @@ static inline void *page_to_virt(const struct page_info 
> *pg)
>  struct page_info *get_page_from_gva(struct vcpu *v, vaddr_t va,
>  unsigned long flags);
>  
> -/*
> - * The MPT (machine->physical mapping table) is an array of word-sized
> - * values, indexed on machine frame number. It is expected that guest OSes
> - * will use it to store a "physical" frame number to give the appearance of
> - * contiguous (or near contiguous) physical memory.
> - */
> -#undef  machine_to_phys_mapping
> -#define machine_to_phys_mapping  ((unsigned long *)RDWR_MPT_VIRT_START)
> -#define INVALID_M2P_ENTRY(~0UL)
> -#define VALID_M2P(_e)(!((_e) & (1UL<<(BITS_PER_LONG-1
> -#define SHARED_M2P_ENTRY (~0UL - 1UL)
> -#define SHARED_M2P(_e)   ((_e) == SHARED_M2P_ENTRY)
> -
> -#define _set_gpfn_from_mfn(mfn, pfn) ({\
> -struct domain *d = page_get_owner(__mfn_to_page(mfn)); \
> -if(d && (d == dom_cow))\
> -machine_to_phys_mapping[(mfn)] = SHARED_M2P_ENTRY; \
> -else   \
> -machine_to_phys_mapping[(mfn)] = (pfn);\
> -})
> -
>  static inline void put_gfn(struct domain *d, unsigned long gfn) {}
>  static inline int relinquish_shared_pages(struct domain *d)
>  {
>  return 0;
>  }
>  
> +/*
> + * Arm does not have an M2P, but common code expects a handful of
> + * M2P-related defines and functions. Provide dummy versions of these.
> + */
> +#define INVALID_M2P_ENTRY(~0UL)
> +#define SHARED_M2P_ENTRY (~0UL - 1UL)
> +#define SHARED_M2P(_e)   ((_e) == SHARED_M2P_ENTRY)
> +
>  /* Xen always owns P2M on ARM */
>  #define set_gpfn_from_mfn(mfn, pfn) do { (void) (mfn), (void)(pfn); } while 
> (0)
>  #define mfn_to_gmfn(_d, mfn)  (mfn)
> -- 
> 2.11.0
> 

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

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

[Stefano Stabellini]

On Tue, 3 Apr 2018, Julien Grall wrote:
> Signed-off-by: Julien Grall 
> Reviewed-by: George Dunlap 

Acked-by: Stefano Stabellini 

> ---
> Cc: Stefano Stabellini 
> 
> Changes in v7:
> - Add George's reviewed-by
> 
> Changes in v6:
> - Remove the justification from the commit message
> - Add George's reviewed-by
> 
> Changes in v4:
> - Patch added
> ---
>  xen/arch/arm/mm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index baa3b0de1d..1126e246c0 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1431,7 +1431,7 @@ int create_grant_host_mapping(unsigned long addr, 
> unsigned long frame,
>  if ( flags & GNTMAP_readonly )
>  t = p2m_grant_map_ro;
>  
> -rc = guest_physmap_add_entry(current->domain, _gfn(addr >> PAGE_SHIFT),
> +rc = guest_physmap_add_entry(current->domain, gaddr_to_gfn(addr),
>   _mfn(frame), 0, t);
>  
>  if ( rc )
> @@ -1443,7 +1443,7 @@ int create_grant_host_mapping(unsigned long addr, 
> unsigned long frame,
>  int replace_grant_host_mapping(unsigned long addr, unsigned long mfn,
>  unsigned long new_addr, unsigned int flags)
>  {
> -gfn_t gfn = _gfn(addr >> PAGE_SHIFT);
> +gfn_t gfn = gaddr_to_gfn(addr);
>  struct domain *d = current->domain;
>  int rc;
>  
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [for-4.11][PATCH v7 02/16] xen/arm: setup: use maddr_to_mfn rather than _mfn(paddr_to_pfn(...))

[Stefano Stabellini]

On Tue, 3 Apr 2018, Julien Grall wrote:
> Signed-off-by: Julien Grall 
> Reviewed-by: George Dunlap 

Acked-by: Stefano Stabellini 

> ---
> Cc: Stefano Stabellini 
> 
> Changes in v6:
> - Remove the justification from the commit message
> - Add George's reviewed-by
> 
> Changes in v4:
> - Patch added
> ---
>  xen/arch/arm/setup.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index b17797dc97..1ce6a26e84 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -268,8 +268,8 @@ void __init discard_initial_modules(void)
>  if ( mi->module[i].kind == BOOTMOD_XEN )
>  continue;
>  
> -if ( !mfn_valid(_mfn(paddr_to_pfn(s))) ||
> - !mfn_valid(_mfn(paddr_to_pfn(e
> +if ( !mfn_valid(maddr_to_mfn(s)) ||
> + !mfn_valid(maddr_to_mfn(e)) )
>  continue;
>  
>  dt_unreserved_regions(s, e, init_domheap_pages, 0);
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH v2 07/17] arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

[Stefano Stabellini]

On Thu, 5 Apr 2018, Julien Grall wrote:
> On 02/04/18 12:17, Manish Jaggi wrote:
> > 
> > 
> > On 04/02/2018 04:33 PM, Manish Jaggi wrote:
> > > 
> > > On 03/27/2018 03:48 PM, Marc Zyngier wrote:
> > > > On 27/03/18 10:07, Manish Jaggi wrote:
> > > > > This patch is ported to xen from linux commit
> > > > > b6f49035b4bf6e2709f2a5fed3107f5438c1fd02
> > > > > KVM: arm64: vgic-v3: Add ICV_EOIR1_EL1 handler
> > > > > 
> > > > > Add a handler for writing the guest's view of the ICC_EOIR1_EL1
> > > > > register. This involves dropping the priority of the interrupt,
> > > > > and deactivating it if required (EOImode == 0).
> > > > > 
> > > > > Signed-off-by : Manish Jaggi 
> > > > > ---
> > > > >   xen/arch/arm/arm64/vgic-v3-sr.c | 136
> > > > > 
> > > > >   xen/include/asm-arm/arm64/sysregs.h |   1 +
> > > > >   xen/include/asm-arm/gic_v3_defs.h   |   4 ++
> > > > >   3 files changed, 141 insertions(+)
> > > > > 
> > > > > diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c
> > > > > b/xen/arch/arm/arm64/vgic-v3-sr.c
> > > > > index 026d64506f..e32ec01f56 100644
> > > > > --- a/xen/arch/arm/arm64/vgic-v3-sr.c
> > > > > +++ b/xen/arch/arm/arm64/vgic-v3-sr.c
> > > > > @@ -33,6 +33,7 @@
> > > > >     #define ICC_IAR1_EL1_SPURIOUS    0x3ff
> > > > >   #define VGIC_MAX_SPI 1019
> > > > > +#define VGIC_MIN_LPI 8192
> > > > >     static int vgic_v3_bpr_min(void)
> > > > >   {
> > > > > @@ -482,6 +483,137 @@ static void vreg_emulate_iar(struct
> > > > > cpu_user_regs *regs, const union hsr hsr)
> > > > >   vgic_v3_read_iar(regs, hsr);
> > > > >   }
> > > > >   +static int vgic_v3_find_active_lr(int intid, uint64_t *lr_val)
> > > > > +{
> > > > > +    int i;
> > > > > +    unsigned int used_lrs =  gic_get_num_lrs();
> > > > This is quite a departure from the existing code. KVM always allocate
> > > > LRs sequentially, and used_lrs represents the current upper bound.
> > > IIUC, Xen uses a function gic_find_unused_lr to find an unused LR.
> > > 
> > > xen/arch/arm/gic.c:
> > > gic_raise_guest_irq
> > >     gic_find_unused_lr
> > > > Here,
> > > > you seem to be looking at *all* the LRs. Is that safe?
> > > IIUC Xen does not maintain a used_lrs, it does have an lr_mask, but that
> > > is static in gic.c
> > > 
> > > To do something like
> > > +for_each_set_bit(i, lr_mask, nr_lrs)
> > > + {
> > > +  u64 val = __gic_v3_get_lr(i);
> > > +  u8 lr_prio = (val & ICH_LR_PRIORITY_MASK) >> ICH_LR_PRIORITY_SHIFT;
> > > +     /* Not pending in the state? */
> > > + if ((val & ICH_LR_STATE) != ICH_LR_PENDING_BIT)
> > > + continue;
> > > 
> > > 
> > > I need to do some jugglery to make lr_mask visible outside of
> > > xen/arch/arm/gic.c
> > > The easiest would be to add an extern function, harder way would be to add
> > > it in gic_hw_operations
> > > 
> > > - vgic_v3_highest_priority_lr iterates is interested in used LR's which
> > > sre in Pending state.
> > > - emulating IAR is done with interrupts disabled
> > > - iterating over all the LRs and finding which ones are in Pending.
> > > 
> > > 
> > Just to add I was answering for using num_lrs for used_lrs, above was for
> > IAR flow.
> > This holds the same for EOIR flow as well.
> > 
> > The bigger point is unless I add some jugglery to access static value
> > outside gic.c
> > this is the only solution.
> > 
> > Stefano/Andre/Julien
> > Please suggest if there is some better way...
> 
> lr_mask is already exported. So I am not sure what you need here.
> 
> However, despite the fact the variable is living in gic.c it is only used by
> the old vGIC. Newer vGIC is based on KVM, so used_lrs would be fine to use.
> 
> For the old vGIC, see below.
> 
> > > >   Are you
> > > > guaranteed not to have any stale state?
> 
> LRs are zeroed when unused and AFAICT they should always be accurate. Stefano
> can you confirm it?
> 
> So it would be ok go through all the LRs (thought with a performance hit).

Yes, in the old vgic LRs are always accurate (obvioulsy when read on the
right pcpu).___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 2/2] xen/arm: Add Marvell ARMADA 3700 early printk support

[André Przywara]

On 05/04/18 11:16, Amit Singh Tomar wrote:
> Signed-off-by: Amit Singh Tomar 

Compiled with CONFIG_EARLY_PRINTK=mvebu, I see Xen's pre-DT boot
messages. In addition to my Reviewed-by:

Tested-by: Andre Przywara 

Cheers,
Andre.

> ---
> Changes since v2:
> * Addressed Andre's comments.
> Changes since v1:
> * Removed header file dependency.
> ---
>  docs/misc/arm/early-printk.txt |  1 +
>  xen/arch/arm/Rules.mk  |  1 +
>  xen/arch/arm/arm64/debug-mvebu.inc | 50 
> ++
>  3 files changed, 52 insertions(+)
>  create mode 100644 xen/arch/arm/arm64/debug-mvebu.inc
> 
> diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
> index 20a8af8..f765f59 100644
> --- a/docs/misc/arm/early-printk.txt
> +++ b/docs/misc/arm/early-printk.txt
> @@ -41,6 +41,7 @@ the name of the machine:
>- juno: printk with pl011 on Juno platform
>- lager: printk with SCIF0 on Renesas R-Car H2 processors
>- midway: printk with the pl011 on Calxeda Midway processors
> +  - mvebu: printk with the MVEBU for Marvell Armada 3700 SoCs
>- omap5432: printk with UART3 on TI OMAP5432 processors
>- rcar3: printk with SCIF2 on Renesas R-Car Gen3 processors
>- seattle: printk with pl011 for AMD Seattle processor
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index b66c19f..f264592 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -36,6 +36,7 @@ EARLY_PRINTK_hikey960   := pl011,0xfff32000
>  EARLY_PRINTK_juno   := pl011,0x7ff8
>  EARLY_PRINTK_lager  := scif,0xe6e6
>  EARLY_PRINTK_midway := pl011,0xfff36000
> +EARLY_PRINTK_mvebu  := mvebu,0xd0012000
>  EARLY_PRINTK_omap5432   := 8250,0x4802,2
>  EARLY_PRINTK_rcar3  := scif,0xe6e88000
>  EARLY_PRINTK_seattle:= pl011,0xe101
> diff --git a/xen/arch/arm/arm64/debug-mvebu.inc 
> b/xen/arch/arm/arm64/debug-mvebu.inc
> new file mode 100644
> index 000..3579ea6
> --- /dev/null
> +++ b/xen/arch/arm/arm64/debug-mvebu.inc
> @@ -0,0 +1,50 @@
> +/*
> + * xen/arch/arm/arm64/debug-mvebu.inc
> + *
> + * MVEBU specific debug code.
> + *
> + * Copyright (c) 2018, Amit Singh Tomar .
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#define UART_STATUS_REG 0x0c
> +#define UART_TX_REG 0x04
> +
> +/*
> + * MVEBU UART wait UART to be ready to transmit
> + * xb: register which contains the UART base address
> + * c: scratch register
> + */
> +.macro early_uart_ready xb c
> +1:
> +ldrh   w\c, [\xb, #UART_STATUS_REG]  /* status register */
> +tstw\c, #(1 << 11)/* Check TXFIFO FULL 
> bit */
> +b.ne   1b/* Wait for the UART to be 
> ready */
> +.endm
> +
> +/*
> + * MVEBU UART transmit character
> + * xb: register which contains the UART base address
> + * wt: register which contains the character to transmit
> + */
> +.macro early_uart_transmit xb wt
> + strb  \wt, [\xb, #UART_TX_REG]
> +.endm
> +
> +/*
> + * Local variables:
> + * mode: ASM
> + * indent-tabs-mode: nil
> + * End:
> + */
> --
> 1.9.1
> 


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

Re: [Xen-devel] [PATCH v3 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC

[André Przywara]

On 05/04/18 11:16, Amit Singh Tomar wrote:
> This patch adds driver for UART controller found on Armada 3700 SoC.
> 
> There is no reference manuals available for 3700 SoC in public and it
> is derived by looking at Linux driver[1].
> 
> [1]https://github.com/torvalds/linux/blob/master/drivers/tty/serial/mvebu-uart.c
> 
> Signed-off-by: Amit Singh Tomar 

Works like a charm, can log into Dom0, Xen console works as well. So in
addition to my Reviewed-by:

Tested-by: Andre Przywara 

Cheers,
Andre.

> ---
> Changes since v2:
> * Addressed Andre's comments.
> Changes since v1:
> * Addressed Wei Liu's comments
> * Addressed Andre's comments.
> Changes since RFC:
> * Addressed Julien's comments.
> ---
>  xen/drivers/char/Kconfig  |   8 ++
>  xen/drivers/char/Makefile |   1 +
>  xen/drivers/char/mvebu-uart.c | 296 
> ++
>  3 files changed, 305 insertions(+)
>  create mode 100644 xen/drivers/char/mvebu-uart.c
> 
> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> index fb53dd8..04a4087 100644
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -12,6 +12,14 @@ config HAS_CADENCE_UART
> This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq
> based board, say Y.
> 
> +config HAS_MVEBU
> +bool
> +default y
> +depends on ARM_64
> +help
> +  This selects the Marvell MVEBU UART. If you have a ARMADA 3700
> +  based board, say Y.
> +
>  config HAS_PL011
>   bool
>   default y
> diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> index 0d48b16..b68c330 100644
> --- a/xen/drivers/char/Makefile
> +++ b/xen/drivers/char/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_HAS_NS16550) += ns16550.o
>  obj-$(CONFIG_HAS_CADENCE_UART) += cadence-uart.o
>  obj-$(CONFIG_HAS_PL011) += pl011.o
>  obj-$(CONFIG_HAS_EXYNOS4210) += exynos4210-uart.o
> +obj-$(CONFIG_HAS_MVEBU) += mvebu-uart.o
>  obj-$(CONFIG_HAS_OMAP) += omap-uart.o
>  obj-$(CONFIG_HAS_SCIF) += scif-uart.o
>  obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
> diff --git a/xen/drivers/char/mvebu-uart.c b/xen/drivers/char/mvebu-uart.c
> new file mode 100644
> index 000..1561a50
> --- /dev/null
> +++ b/xen/drivers/char/mvebu-uart.c
> @@ -0,0 +1,296 @@
> +/*
> + * xen/drivers/char/mvebu3700-uart.c
> + *
> + * Driver for Marvell MVEBU UART.
> + *
> + * Copyright (c) 2018, Amit Singh Tomar .
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Register offsets */
> +#define UART_RX_REG 0x00
> +
> +#define UART_TX_REG 0x04
> +
> +#define UART_CTRL_REG   0x08
> +#define CTRL_TXFIFO_RST BIT(15)
> +#define CTRL_RXFIFO_RST BIT(14)
> +#define CTRL_TX_RDY_INT BIT(5)
> +#define CTRL_RX_RDY_INT BIT(4)
> +#define CTRL_BRK_DET_INTBIT(3)
> +#define CTRL_FRM_ERR_INTBIT(2)
> +#define CTRL_PAR_ERR_INTBIT(1)
> +#define CTRL_OVR_ERR_INTBIT(0)
> +#define CTRL_ERR_INT(CTRL_BRK_DET_INT | CTRL_FRM_ERR_INT | \
> + CTRL_PAR_ERR_INT | CTRL_OVR_ERR_INT)
> +
> +#define UART_STATUS_REG 0x0c
> +#define STATUS_TXFIFO_EMP   BIT(13)
> +#define STAT_TX_FIFO_FULBIT(11)
> +#define STAT_TX_FIFO_HFLBIT(10)
> +#define STATUS_TX_RDY   BIT(5)
> +#define STATUS_RX_RDY   BIT(4)
> +#define STATUS_BRK_DET  BIT(3)
> +#define STATUS_FRM_ERR  BIT(2)
> +#define STATUS_PAR_ERR  BIT(1)
> +#define STATUS_OVR_ERR  BIT(0)
> +#define STATUS_BRK_ERR  (STATUS_BRK_DET | STATUS_FRM_ERR | \
> + STATUS_PAR_ERR | STATUS_OVR_ERR)
> +
> +#define TX_FIFO_SIZE32
> +
> +static struct mvebu3700_uart {
> +unsigned int irq;
> +void __iomem *regs;
> +struct irqaction irqaction;
> +struct vuart_info vuart;
> +} mvebu3700_com = {0};
> +
> +#define mvebu3700_read(uart, off)   readl((uart)->regs + off)
> +#define mvebu3700_write(uart, off, val) writel(val, (uart->regs) + off)
> +
> +static void mvebu3700_uart_interrupt(int irq, void *data,
> + struct cpu_user_regs *regs)
> +{
> +struct serial_port *port = data;
> +struct mvebu3700_uart *uart 

[Xen-devel] [PATCH] tools/libxl: Fix build following c/s 74fd984ae

[Andrew Cooper]

c/s 74fd984ae "tools/libxl: Drop xc_domain_configuration_t from
libxl__domain_build_state" removed state->config completely, but the GIC
version is available in info.  Use the up-to-date version.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Juergen Gross 

Completely untested.  I don't even have a compile environment to hand, which
is how this got missed before.  Sorry.
---
 tools/libxl/libxl_arm.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index fbe8786..177c6b7 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -846,9 +846,6 @@ static int libxl__prepare_dtb(libxl__gc *gc, 
libxl_domain_build_info *info,
 const libxl_version_info *vers;
 const struct arch_info *ainfo;
 
-/* convenience aliases */
-xc_domain_configuration_t *xc_config = >config;
-
 vers = libxl_get_version_info(CTX);
 if (vers == NULL) return ERROR_FAIL;
 
@@ -857,7 +854,8 @@ static int libxl__prepare_dtb(libxl__gc *gc, 
libxl_domain_build_info *info,
 
 LOG(DEBUG, "constructing DTB for Xen version %d.%d guest",
 vers->xen_version_major, vers->xen_version_minor);
-LOG(DEBUG, " - vGIC version: %s", gicv_to_string(xc_config->gic_version));
+LOG(DEBUG, " - vGIC version: %s",
+gicv_to_string(info->arch_arm.gic_version));
 
 if (info->device_tree) {
 LOG(DEBUG, " - Partial device tree provided: %s", info->device_tree);
-- 
2.1.4


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

Re: [Xen-devel] Patches for stable

[Boris Ostrovsky]

On 04/05/2018 01:11 PM, Juergen Gross wrote:
> On 05/04/18 16:56, George Dunlap wrote:
>> On Thu, Apr 5, 2018 at 3:09 PM, Juergen Gross  wrote:
>>> On 05/04/18 15:42, George Dunlap wrote:
 On Thu, Apr 5, 2018 at 2:06 PM, Juergen Gross  wrote:
> On 05/04/18 15:00, Boris Ostrovsky wrote:
>> On 04/05/2018 08:19 AM, Juergen Gross wrote:
>>> On 05/04/18 12:06, George Dunlap wrote:
>>>
 Aren't there flags in the binary somewhere that could tell the
 toolstack / Xen whether the kernel in question needs the RSDP table in
 lowmem, or whether it can be put higher?
>>> Not really. Analyzing the binary whether it accesses the rsdp_addr in
>>> the start_info isn't the way to go, IMO.
>>>
>>> I've sent a patch to xen-devel adding a quirk flag to the domain's
>>> config to enable the admin special casing such an "old" kernel.
>> Can we backport latest struct hvm_start_info changes (which bumped
>> interface version) to 4.11 and pass RSDP only for versions >=1?
> And this would help how?
>
> RSDP address is passed today, the kernel just doesn't read it. And
> how should Xen know which interface version the kernel is supporting?
> And Xen needs to know that in advance in order to place the RSDP in
> low memory in case the kernel isn't reading the RSDP address from
> start_info.
 But the kernel image has ELF notes, right?  You can put one that
 indicates that this binary *does* know how to read the RSDP from the
 start_info, and if you don't find that, put it in lowmem.
>>> Sow you would hurt BSD which does read the RSDP address correctly but
>>> (today) has no such ELF note.


This can be predicated on
    ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS,   .asciz "linux")

BSD will behave as it does now. For linux we could add feature flag (or
errata flag). Unfortunately I don't see a way to extract major.minor
from the headers, otherwise we could use that.

-boris


>>>
>>> I think extending the PVH interface in such a way is no good idea.
>> Option 1: Put the RSDP in lowmem unless we know the guest will use the
>> address in start_info
>> Pro: Existing Linux instances boot
>> Con: Existing BSD instances whose memory is an exact multiple of 1 GiB
>> will have slightly slower TLB miss times.
> ... whose memory is >=1GiB ...
>
>> Option 2: Put the RSDP in highmem regardless
>> Pro: Existing BSD instances whose memory is an exact multiple of 1GiB
> ... whose memory is >=1GiB ...
>
>> will have slightly faster TLB miss times
>> Con: Existing Linux instances don't boot at all
> Option 3: add a config item to domain config for selecting the RSDP
>   placement, defaulting to highmem (my patch)
> Pro: Existing BSD and new Linux instances whose memory is >=1GiB will
>  have slightly faster TLB miss times
> Pro: Existing Linux instances can be made bootable by adding a new
>  item to their domain config
>
>


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 121876
 build-armhf   6 xen-buildfail REGR. vs. 121876

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  c0d98b35714fb707217c9062b6518e158cd72eea
baseline version:
 xen  451004603247205467ec34b366b4cfa3814a5d95

Last test of basis   121876  2018-04-05 10:04:25 Z0 days
Testing same since   121889  2018-04-05 13:02:10 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Wei Liu 

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


Not pushing.


commit c0d98b35714fb707217c9062b6518e158cd72eea
Author: Andrew Cooper 
Date:   Thu Jan 25 15:45:37 2018 +

x86/vtx: Introduce a typed union for CR access exit information

This reduces code volume, and has a minor improvement on compiled size,
probably due to the removal of several temporary variables.

  add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-50 (-50)
  function old new   delta
  vmx_vmexit_handler  68816878  -3
  nvmx_n2_vmexit_handler  34733426 -47

Take the opportunity to make some style corrections, and add some
ASSERT_UNREACHABLE()s in appropriate places.

No functional change.

Signed-off-by: Andrew Cooper 
Acked-by: Kevin Tian 

commit 36bc5fc631b08bcf03c6977e79f026a459d76302
Author: Andrew Cooper 
Date:   Fri Mar 16 16:57:18 2018 +

xen/public: Rename xen_domctl_createdomain.config to arch

This is a tools only hypercall so fine to change.  Altering the name avoids
having confusing code such as config->config all over the hypervisor and
toolstack.

Signed-off-by: Andrew Cooper 
Acked-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Wei Liu 

commit 2649612686f968a52ce53d173f5c2a3088ad17dd
Author: Andrew Cooper 
Date:   Fri Mar 9 13:03:26 2018 +

tools/libxl: Don't prepare or save xc_config when soft resetting a domain

xc_config is only used by xc_domain_create(), but by calling
libxl__arch_domain_{prepare,save}_config() we clobber the real settings with
the default settings.

Move all data and calls relating to xc_domain_create() into the path which
calls it.

As far as I can tell, soft_reset has always been broken for ARM domains 
using
LIBXL_GIC_VERSION_DEFAULT, which elicits a hard error out of
libxl__arch_domain_save_config(), and only works on x86 because this 
function
is a no-op.

Signed-off-by: Andrew Cooper 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 

commit 74fd984ae699727ae98f4fc36450ff76c8fc7ff3
Author: Andrew Cooper 
Date:   Fri Mar 9 12:24:13 2018 

Re: [Xen-devel] [PATCH] python: xc: fix max_cpu_index sign error

[Juergen Gross]

On 05/04/18 18:45, Marek Marczykowski-Górecki wrote:
> On Thu, Apr 05, 2018 at 01:54:03PM +0100, Wei Liu wrote:
>> CC Marek
>>
>> On Thu, Apr 05, 2018 at 12:49:23PM +, Petre Eftime wrote:
>>> When 0-indexing, maximum index is num_entries - 1. The python xc library 
>>> had a
>>> sign error where the minus was replaced by a plus, making tools that 
>>> depended
>>> on it to look for CPUs that did not exist.
>>>
>>> Signed-off-by: Petre Eftime 
> 
> Acked-by: Marek Marczykowski-Górecki 

Release-acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH 1/1] tools: reduce copies b/w ocaml Strings and Bytes

[Christian Lindig]

I think this is a good patch as it reduces the amount of copying. I 
believe it is safe as it is. There is one place where I am a little 
hesitant:


@@ -291,7 +291,9 @@ let access_logging ~con ~tid ?(data="") ~level 
access_type =


let date = string_of_date() in
let tid = string_of_tid ~con tid in
let access_type = string_of_access_type 
access_type in
-   let data = sanitize_data (Bytes.of_string data) 
in
+   (* we can use unsafe_of_string here as the 
sanitize_data function
+  immediately makes a copy of the data and 
operates on that. *)
+   let data = sanitize_data 
(Bytes.unsafe_of_string data) in
let prefix = prefix !access_log_destination 
date in
let msg = Printf.sprintf "%s %s %s %s" prefix 
tid access_type data in
logger.write ~level msg)

This relies on the implementation of sanitize_data() and somebody could 
change it in the future
and invalidate the assumption being made here. However, this is the only 
call site and the
function is defined above. Anybody making changes in the context of 
String/Byte conversion

come across the comment here.

So: I'm happy to take the patch as it is.

On 05/04/18 11:40, Marcello Seri wrote:

When xenstore was ported to the new safe-string interface, it mostly
happened by making copyies of string into bytes and back.  The ideal
fix would be to rewrite all of the relevant interfaces to be uniformly
using bytes, but in the meanwhile we can improve the code by using unsafe
conversion functions (see
  
https://caml.inria.fr/pub/docs/manual-ocaml/libref/Bytes.html#3_Unsafeconversionsforadvancedusers).

In most cases we own the bytes that we are converting to string, or we
immediately make copies that we then mutate, or we use them immutably
as payloads for writes. In all these cases it is safe to use the unsafe
functions and prevent a copy.

This patch updates the code to use the unsafe conversions where possible.

Signed-off-by: Marcello Seri 

Reviewed-by: Christian Lindig 


---
  tools/ocaml/libs/xb/xb.ml| 4 +++-
  tools/ocaml/xenstored/logging.ml | 8 +---
  tools/ocaml/xenstored/stdext.ml  | 2 +-
  tools/ocaml/xenstored/utils.ml   | 6 +++---
  4 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/tools/ocaml/libs/xb/xb.ml b/tools/ocaml/libs/xb/xb.ml
index 519842723b..660224f895 100644
--- a/tools/ocaml/libs/xb/xb.ml
+++ b/tools/ocaml/libs/xb/xb.ml
@@ -100,7 +100,9 @@ let write_mmap back con s len =
  
  let write con s len =

match con.backend with
-   | Fd backfd -> write_fd backfd con (Bytes.of_string s) len
+   (* we can use unsafe_of_string here as the bytes are used immutably
+  in the Unix.write operation. *)
+   | Fd backfd -> write_fd backfd con (Bytes.unsafe_of_string s) len
| Xenmmap backmmap -> write_mmap backmmap con s len
  
  (* NB: can throw Reconnect *)

diff --git a/tools/ocaml/xenstored/logging.ml b/tools/ocaml/xenstored/logging.ml
index e3c769fb2c..45a2c222e6 100644
--- a/tools/ocaml/xenstored/logging.ml
+++ b/tools/ocaml/xenstored/logging.ml
@@ -64,7 +64,7 @@ let truncate_line nb_chars line =
Bytes.blit_string line 0 dst_line 0 (len - 2);
Bytes.set dst_line (len-2) '.';
Bytes.set dst_line (len-1) '.';
-   Bytes.to_string dst_line
+   Bytes.unsafe_to_string dst_line
else line
  
  let log_rotate ref_ch log_file log_nb_files =

@@ -258,7 +258,7 @@ let sanitize_data data =
if Bytes.get data i = '\000' then
Bytes.set data i ' '
done;
-   String.escaped (Bytes.to_string data)
+   String.escaped (Bytes.unsafe_to_string data)
  
  let activate_access_log = ref true

  let access_log_destination = ref (File (Paths.xen_log_dir ^ 
"/xenstored-access.log"))
@@ -291,7 +291,9 @@ let access_logging ~con ~tid ?(data="") ~level access_type =
let date = string_of_date() in
let tid = string_of_tid ~con tid in
let access_type = string_of_access_type 
access_type in
-   let data = sanitize_data (Bytes.of_string data) 
in
+   (* we can use unsafe_of_string here as the 
sanitize_data function
+  immediately makes a copy of the data and 
operates on that. *)
+   let data = sanitize_data 
(Bytes.unsafe_of_string data) in
let prefix = prefix !access_log_destination 
date in
let msg = Printf.sprintf "%s %s %s %s" prefix 
tid access_type 

[Xen-devel] [PATCH v2] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE

[Paul Durrant]

My recent Xen patch series introduces a new HYPERVISOR_memory_op to
support direct priv-mapping of certain guest resources (such as ioreq
pages, used by emulators) by a tools domain, rather than having to access
such resources via the guest P2M.

This patch adds the necessary infrastructure to the privcmd driver and
Xen MMU code to support direct resource mapping.

NOTE: The adjustment in the MMU code is partially cosmetic. Xen will now
  allow a PV tools domain to map guest pages either by GFN or MFN, thus
  the term 'mfn' has been swapped for 'pfn' in the lower layers of the
  remap code.

Signed-off-by: Paul Durrant 
---
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 

v2:
 - Fix bug when mapping multiple pages of a resource
---
 arch/x86/xen/mmu.c |  50 +++-
 drivers/xen/privcmd.c  | 130 +
 include/uapi/xen/privcmd.h |  11 
 include/xen/interface/memory.h |  66 +
 include/xen/interface/xen.h|   7 ++-
 include/xen/xen-ops.h  |  24 +++-
 6 files changed, 270 insertions(+), 18 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index d33e7dbe3129..8453d7be415c 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -65,37 +65,42 @@ static void xen_flush_tlb_all(void)
 #define REMAP_BATCH_SIZE 16
 
 struct remap_data {
-   xen_pfn_t *mfn;
+   xen_pfn_t *pfn;
bool contiguous;
+   bool no_translate;
pgprot_t prot;
struct mmu_update *mmu_update;
 };
 
-static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
+static int remap_area_pfn_pte_fn(pte_t *ptep, pgtable_t token,
 unsigned long addr, void *data)
 {
struct remap_data *rmd = data;
-   pte_t pte = pte_mkspecial(mfn_pte(*rmd->mfn, rmd->prot));
+   pte_t pte = pte_mkspecial(mfn_pte(*rmd->pfn, rmd->prot));
 
/* If we have a contiguous range, just update the mfn itself,
   else update pointer to be "next mfn". */
if (rmd->contiguous)
-   (*rmd->mfn)++;
+   (*rmd->pfn)++;
else
-   rmd->mfn++;
+   rmd->pfn++;
 
-   rmd->mmu_update->ptr = virt_to_machine(ptep).maddr | 
MMU_NORMAL_PT_UPDATE;
+   rmd->mmu_update->ptr = virt_to_machine(ptep).maddr;
+   rmd->mmu_update->ptr |= rmd->no_translate ?
+   MMU_PT_UPDATE_NO_TRANSLATE :
+   MMU_NORMAL_PT_UPDATE;
rmd->mmu_update->val = pte_val_ma(pte);
rmd->mmu_update++;
 
return 0;
 }
 
-static int do_remap_gfn(struct vm_area_struct *vma,
+static int do_remap_pfn(struct vm_area_struct *vma,
unsigned long addr,
-   xen_pfn_t *gfn, int nr,
+   xen_pfn_t *pfn, int nr,
int *err_ptr, pgprot_t prot,
-   unsigned domid,
+   unsigned int domid,
+   bool no_translate,
struct page **pages)
 {
int err = 0;
@@ -106,11 +111,12 @@ static int do_remap_gfn(struct vm_area_struct *vma,
 
BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
 
-   rmd.mfn = gfn;
+   rmd.pfn = pfn;
rmd.prot = prot;
/* We use the err_ptr to indicate if there we are doing a contiguous
 * mapping or a discontigious mapping. */
rmd.contiguous = !err_ptr;
+   rmd.no_translate = no_translate;
 
while (nr) {
int index = 0;
@@ -121,7 +127,7 @@ static int do_remap_gfn(struct vm_area_struct *vma,
 
rmd.mmu_update = mmu_update;
err = apply_to_page_range(vma->vm_mm, addr, range,
- remap_area_mfn_pte_fn, );
+ remap_area_pfn_pte_fn, );
if (err)
goto out;
 
@@ -175,7 +181,8 @@ int xen_remap_domain_gfn_range(struct vm_area_struct *vma,
if (xen_feature(XENFEAT_auto_translated_physmap))
return -EOPNOTSUPP;
 
-   return do_remap_gfn(vma, addr, , nr, NULL, prot, domid, pages);
+   return do_remap_pfn(vma, addr, , nr, NULL, prot, domid, false,
+   pages);
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_range);
 
@@ -183,7 +190,7 @@ int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
   unsigned long addr,
   xen_pfn_t *gfn, int nr,
   int *err_ptr, pgprot_t prot,
-  unsigned domid, struct page **pages)
+  unsigned int domid, struct page **pages)
 {
if (xen_feature(XENFEAT_auto_translated_physmap))
return xen_xlate_remap_gfn_array(vma, 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   6 xen-buildfail REGR. vs. 121876
 build-armhf   6 xen-buildfail REGR. vs. 121876

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  c0d98b35714fb707217c9062b6518e158cd72eea
baseline version:
 xen  451004603247205467ec34b366b4cfa3814a5d95

Last test of basis   121876  2018-04-05 10:04:25 Z0 days
Testing same since   121889  2018-04-05 13:02:10 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Wei Liu 

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


Not pushing.


commit c0d98b35714fb707217c9062b6518e158cd72eea
Author: Andrew Cooper 
Date:   Thu Jan 25 15:45:37 2018 +

x86/vtx: Introduce a typed union for CR access exit information

This reduces code volume, and has a minor improvement on compiled size,
probably due to the removal of several temporary variables.

  add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-50 (-50)
  function old new   delta
  vmx_vmexit_handler  68816878  -3
  nvmx_n2_vmexit_handler  34733426 -47

Take the opportunity to make some style corrections, and add some
ASSERT_UNREACHABLE()s in appropriate places.

No functional change.

Signed-off-by: Andrew Cooper 
Acked-by: Kevin Tian 

commit 36bc5fc631b08bcf03c6977e79f026a459d76302
Author: Andrew Cooper 
Date:   Fri Mar 16 16:57:18 2018 +

xen/public: Rename xen_domctl_createdomain.config to arch

This is a tools only hypercall so fine to change.  Altering the name avoids
having confusing code such as config->config all over the hypervisor and
toolstack.

Signed-off-by: Andrew Cooper 
Acked-by: Jan Beulich 
Acked-by: Julien Grall 
Acked-by: Wei Liu 

commit 2649612686f968a52ce53d173f5c2a3088ad17dd
Author: Andrew Cooper 
Date:   Fri Mar 9 13:03:26 2018 +

tools/libxl: Don't prepare or save xc_config when soft resetting a domain

xc_config is only used by xc_domain_create(), but by calling
libxl__arch_domain_{prepare,save}_config() we clobber the real settings with
the default settings.

Move all data and calls relating to xc_domain_create() into the path which
calls it.

As far as I can tell, soft_reset has always been broken for ARM domains 
using
LIBXL_GIC_VERSION_DEFAULT, which elicits a hard error out of
libxl__arch_domain_save_config(), and only works on x86 because this 
function
is a no-op.

Signed-off-by: Andrew Cooper 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 

commit 74fd984ae699727ae98f4fc36450ff76c8fc7ff3
Author: Andrew Cooper 
Date:   Fri Mar 9 12:24:13 2018 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf aae02dccf5b0ad07e60d2738f350b3b39df389d7
baseline version:
 ovmf c4172f80051effc62f3eceeeced4c0b66a80eb94

Last test of basis   121741  2018-04-03 09:47:46 Z2 days
Testing same since   121769  2018-04-04 09:47:35 Z1 days1 attempts


People who touched revisions under test:
  Star Zeng 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   c4172f8005..aae02dccf5  aae02dccf5b0ad07e60d2738f350b3b39df389d7 -> 
xen-tested-master

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

Re: [Xen-devel] Patches for stable

[George Dunlap]

On Thu, Apr 5, 2018 at 3:09 PM, Juergen Gross  wrote:
> On 05/04/18 15:42, George Dunlap wrote:
>> On Thu, Apr 5, 2018 at 2:06 PM, Juergen Gross  wrote:
>>> On 05/04/18 15:00, Boris Ostrovsky wrote:
 On 04/05/2018 08:19 AM, Juergen Gross wrote:
> On 05/04/18 12:06, George Dunlap wrote:
>
>> Aren't there flags in the binary somewhere that could tell the
>> toolstack / Xen whether the kernel in question needs the RSDP table in
>> lowmem, or whether it can be put higher?
> Not really. Analyzing the binary whether it accesses the rsdp_addr in
> the start_info isn't the way to go, IMO.
>
> I've sent a patch to xen-devel adding a quirk flag to the domain's
> config to enable the admin special casing such an "old" kernel.

 Can we backport latest struct hvm_start_info changes (which bumped
 interface version) to 4.11 and pass RSDP only for versions >=1?
>>>
>>> And this would help how?
>>>
>>> RSDP address is passed today, the kernel just doesn't read it. And
>>> how should Xen know which interface version the kernel is supporting?
>>> And Xen needs to know that in advance in order to place the RSDP in
>>> low memory in case the kernel isn't reading the RSDP address from
>>> start_info.
>>
>> But the kernel image has ELF notes, right?  You can put one that
>> indicates that this binary *does* know how to read the RSDP from the
>> start_info, and if you don't find that, put it in lowmem.
>
> Sow you would hurt BSD which does read the RSDP address correctly but
> (today) has no such ELF note.
>
> I think extending the PVH interface in such a way is no good idea.

Option 1: Put the RSDP in lowmem unless we know the guest will use the
address in start_info
Pro: Existing Linux instances boot
Con: Existing BSD instances whose memory is an exact multiple of 1 GiB
will have slightly slower TLB miss times.

Option 2: Put the RSDP in highmem regardless
Pro: Existing BSD instances whose memory is an exact multiple of 1GiB
will have slightly faster TLB miss times
Con: Existing Linux instances don't boot at all

This seems like a no-brainer to me.  But anyway, maybe we should move
the discussion elsewhere and stop bothering Greg. :-)

 -George

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

[Xen-devel] [OSSTEST PATCH] email output: Add MIME headers

[Ian Jackson]

We universally use UTF-8 in git commit messages and other kinds of
messages.  The RFC-*822 default is us-ascii.  Fix this by providing a
set of MIME headers.

Reported-by: Andrew Cooper 
Signed-off-by: Ian Jackson 
---
 Osstest.pm | 6 ++
 cri-args-hostlists | 1 +
 mg-execute-flight  | 2 ++
 3 files changed, 9 insertions(+)

diff --git a/Osstest.pm b/Osstest.pm
index ceb62ca..2263786 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -246,6 +246,12 @@ sub readglobalconfig () {
 
 $c{DebianMirrorHost} ||= 'ftp.debian.org' if $c{DebianMirrorProxy};
 
+$c{EmailStdHeaders} ||= <<'END';
+Content-Type: text/plain; charset="UTF-8"
+Content-Transfer-Encoding: 8bit
+MIME-Version: 1.0
+END
+
 my $pubbaseprefix = $c{PubBaseDir} ? "$c{PubBaseDir}/" : "";
 foreach my $l (qw(logs results)) {
my $u = ucfirst $l;
diff --git a/cri-args-hostlists b/cri-args-hostlists
index 58a2252..a75ff7b 100644
--- a/cri-args-hostlists
+++ b/cri-args-hostlists
@@ -103,6 +103,7 @@ start_email () {
cat $OSSTEST_EMAIL_HEADER
fi
echo "Message-ID: "
+   printf '%s\n' "`getconfig EmailStdHeaders`"
printf 'Subject: %s' "${subject_prefix:-[$branch test] }"
 
local flight_html_dir=$OSSTEST_HTMLPUB_DIR/
diff --git a/mg-execute-flight b/mg-execute-flight
index 5a861b0..98aca45 100755
--- a/mg-execute-flight
+++ b/mg-execute-flight
@@ -58,6 +58,7 @@ if [ x"$flight" = x ]; then badusage; fi
 
 : ${blessing:=play}
 : ${email:=`getconfig Username`}
+: ${email_std_headers:=`getconfig EmailStdHeaders`}
 
 set +e
 tty=`exec 2>/dev/null; tty`
@@ -88,6 +89,7 @@ exec >tmp/$flight.email
 cat 

[Xen-devel] [OSSTEST PATCH] cr-ensure-disk-space: Actually quit before taking lock if all is well

[Ian Jackson]

5d2466dc0f26 "cr-ensure-disk-space: Correct stdout output" was
supposed to change an `exit 0' into a `quit_ok' but erroneously
changed it into `check_space'.  Fix this.

Signed-off-by: Ian Jackson 
---
 cr-ensure-disk-space | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cr-ensure-disk-space b/cr-ensure-disk-space
index 8d3d443..7091314 100755
--- a/cr-ensure-disk-space
+++ b/cr-ensure-disk-space
@@ -79,7 +79,7 @@ sub quit_ok () {
 
 $|=1;
 
-check_space if check_space;
+quit_ok if check_space;
 
 print "taking lock...";
 
-- 
2.1.4


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

Re: [Xen-devel] Xen-4.10 Domain-0 crashes at bootup

[Ajay Garg]

Hi All.

As suggested by Michael. I compiled the kernel as per
https://lkml.org/lkml/2018/2/23/59, containing the patch
https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00045.html.

Upon installing this fresh kernel, the machine booted fine with Xen
enabled (just needed an additional "sudo apt-get install libyajl-dev"
and another reboot to get the proper listing of "Domain-0".

So, at least from my side, this thread can be marked solved/closed.


Thanks and Regards,
Ajay

On Wed, Apr 4, 2018 at 8:45 PM, Juergen Gross  wrote:
> On 04/04/18 17:00, M A Young wrote:
>> On Wed, 4 Apr 2018, Ajay Garg wrote:
>>
>>> Thanks Michael for the reply.
>>>
>>> I want to give this patch a try, as the symptoms look identical.
>>> However, I see no xen-head.S when I clone the repo from
>>> git://xenbits.xen.org/xen.git
>>>
>>> What am I missing?
>>
>> The patch is for the xen code in the kernel. It was accepted in the kernel
>> upstream (in 4.15.5 and probably backported to other maintained kernels)
>> so you probably just need a kernel less than a month old, but as has
>> already been said, the kernel may not be the problem.
>
> And the symptoms are completely different (well, at least for me).
>
> Ajay's crash is due to an illegal instruction, so probably a BUG().
>
> The patch above fixes an early page fault in the kernel.
>
>
> Juergen



-- 
Regards,
Ajay

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1   fail REGR. vs. 120095
 test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail REGR. vs. 120095

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

version targeted for testing:
 qemuu9abfc88af3ffd3b33c7fab4471da86462ee71d95
baseline version:
 qemuu6697439794f72b3501ee16bb95d16854f9981421

Last test of basis   120095  2018-02-28 13:46:33 Z   35 days
Failing since120146  2018-03-02 10:10:57 Z   34 days   22 attempts
Testing same since   121765  2018-04-04 07:34:05 Z1 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Bennée 
  Alex Bennée 
  Alex Williamson 
  Alexey Kardashevskiy 
  Alistair Francis 
  Alistair Francis 
  Andrew Jones 
  Andrey Smirnov 
  Anton 

Re: [Xen-devel] Patches for stable

[Juergen Gross]

On 05/04/18 15:42, George Dunlap wrote:
> On Thu, Apr 5, 2018 at 2:06 PM, Juergen Gross  wrote:
>> On 05/04/18 15:00, Boris Ostrovsky wrote:
>>> On 04/05/2018 08:19 AM, Juergen Gross wrote:
 On 05/04/18 12:06, George Dunlap wrote:

> Aren't there flags in the binary somewhere that could tell the
> toolstack / Xen whether the kernel in question needs the RSDP table in
> lowmem, or whether it can be put higher?
 Not really. Analyzing the binary whether it accesses the rsdp_addr in
 the start_info isn't the way to go, IMO.

 I've sent a patch to xen-devel adding a quirk flag to the domain's
 config to enable the admin special casing such an "old" kernel.
>>>
>>> Can we backport latest struct hvm_start_info changes (which bumped
>>> interface version) to 4.11 and pass RSDP only for versions >=1?
>>
>> And this would help how?
>>
>> RSDP address is passed today, the kernel just doesn't read it. And
>> how should Xen know which interface version the kernel is supporting?
>> And Xen needs to know that in advance in order to place the RSDP in
>> low memory in case the kernel isn't reading the RSDP address from
>> start_info.
> 
> But the kernel image has ELF notes, right?  You can put one that
> indicates that this binary *does* know how to read the RSDP from the
> start_info, and if you don't find that, put it in lowmem.

Sow you would hurt BSD which does read the RSDP address correctly but
(today) has no such ELF note.

I think extending the PVH interface in such a way is no good idea.


Juergen


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

Re: [Xen-devel] [PATCH] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE

[Paul Durrant]

> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 05 April 2018 10:32
> To: xen-devel@lists.xenproject.org; linux-ker...@vger.kernel.org;
> x...@kernel.org
> Cc: Paul Durrant ; Boris Ostrovsky
> ; Juergen Gross ; Thomas
> Gleixner ; Ingo Molnar 
> Subject: [PATCH] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE
> 
> My recent Xen patch series introduces a new HYPERVISOR_memory_op to
> support direct priv-mapping of certain guest resources (such as ioreq
> pages, used by emulators) by a tools domain, rather than having to access
> such resources via the guest P2M.
> 
> This patch adds the necessary infrastructure to the privcmd driver and
> Xen MMU code to support direct resource mapping.
> 
> NOTE: The adjustment in the MMU code is partially cosmetic. Xen will now
>   allow a PV tools domain to map guest pages either by GFN or MFN, thus
>   the term 'gfn' has been swapped for 'pfn' in the lower layers of the
>   remap code.
> 
> Signed-off-by: Paul Durrant 

Unfortunately I have just found a bug in this patch when it comes to mapping 
multiple frames. I will send a v2 shortly. Apologies for the noise.

  Paul

> ---
> Cc: Boris Ostrovsky 
> Cc: Juergen Gross 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> ---
>  arch/x86/xen/mmu.c |  50 -
>  drivers/xen/privcmd.c  | 119
> +
>  include/uapi/xen/privcmd.h |  11 
>  include/xen/interface/memory.h |  67 +++
>  include/xen/interface/xen.h|   7 +--
>  include/xen/xen-ops.h  |  24 -
>  6 files changed, 260 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index d33e7dbe3129..8453d7be415c 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -65,37 +65,42 @@ static void xen_flush_tlb_all(void)
>  #define REMAP_BATCH_SIZE 16
> 
>  struct remap_data {
> - xen_pfn_t *mfn;
> + xen_pfn_t *pfn;
>   bool contiguous;
> + bool no_translate;
>   pgprot_t prot;
>   struct mmu_update *mmu_update;
>  };
> 
> -static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
> +static int remap_area_pfn_pte_fn(pte_t *ptep, pgtable_t token,
>unsigned long addr, void *data)
>  {
>   struct remap_data *rmd = data;
> - pte_t pte = pte_mkspecial(mfn_pte(*rmd->mfn, rmd->prot));
> + pte_t pte = pte_mkspecial(mfn_pte(*rmd->pfn, rmd->prot));
> 
>   /* If we have a contiguous range, just update the mfn itself,
>  else update pointer to be "next mfn". */
>   if (rmd->contiguous)
> - (*rmd->mfn)++;
> + (*rmd->pfn)++;
>   else
> - rmd->mfn++;
> + rmd->pfn++;
> 
> - rmd->mmu_update->ptr = virt_to_machine(ptep).maddr |
> MMU_NORMAL_PT_UPDATE;
> + rmd->mmu_update->ptr = virt_to_machine(ptep).maddr;
> + rmd->mmu_update->ptr |= rmd->no_translate ?
> + MMU_PT_UPDATE_NO_TRANSLATE :
> + MMU_NORMAL_PT_UPDATE;
>   rmd->mmu_update->val = pte_val_ma(pte);
>   rmd->mmu_update++;
> 
>   return 0;
>  }
> 
> -static int do_remap_gfn(struct vm_area_struct *vma,
> +static int do_remap_pfn(struct vm_area_struct *vma,
>   unsigned long addr,
> - xen_pfn_t *gfn, int nr,
> + xen_pfn_t *pfn, int nr,
>   int *err_ptr, pgprot_t prot,
> - unsigned domid,
> + unsigned int domid,
> + bool no_translate,
>   struct page **pages)
>  {
>   int err = 0;
> @@ -106,11 +111,12 @@ static int do_remap_gfn(struct vm_area_struct
> *vma,
> 
>   BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) ==
> (VM_PFNMAP | VM_IO)));
> 
> - rmd.mfn = gfn;
> + rmd.pfn = pfn;
>   rmd.prot = prot;
>   /* We use the err_ptr to indicate if there we are doing a contiguous
>* mapping or a discontigious mapping. */
>   rmd.contiguous = !err_ptr;
> + rmd.no_translate = no_translate;
> 
>   while (nr) {
>   int index = 0;
> @@ -121,7 +127,7 @@ static int do_remap_gfn(struct vm_area_struct *vma,
> 
>   rmd.mmu_update = mmu_update;
>   err = apply_to_page_range(vma->vm_mm, addr, range,
> -   remap_area_mfn_pte_fn, );
> +   remap_area_pfn_pte_fn, );
>   if (err)
>   goto out;
> 
> @@ -175,7 +181,8 @@ int xen_remap_domain_gfn_range(struct
> vm_area_struct *vma,
>   if (xen_feature(XENFEAT_auto_translated_physmap))
>   return -EOPNOTSUPP;
> 
> - return do_remap_gfn(vma, addr, , nr, NULL, prot, 

Re: [Xen-devel] X86 Community Call - Wed Apr 11, 14:00 - 15:00 UTC - Call for Agenda Items

[Lars Kurth]

> On 28 Mar 2018, at 16:40, George Dunlap  wrote:
> 
> On 03/22/2018 10:22 AM, Lars Kurth wrote:
>> Hi all,
>> 
>> please find attached
>> a) Meeting details (just a link with timezones) – the meeting invite will 
>> follow when we have an agenda
>>   Bridge details – will be sent with the meeting invite
>>   I am thinking of using GotoMeeting, but want to try this with a Linux only 
>> user before I commit
>> c) Call for agenda items
>> 
>> A few suggestions were made, such as XPTI status (if applicable), PVH status
>> Also we have some left-overs from the last call: see 
>> https://lists.xenproject.org/archives/html/xen-devel/2018-03/threads.html#01571
>> 
>> Regards
>> Lars
>> 
>> == Meeting Details ==
>> Wed April 11, 15:00 - 16:00 UTC
>> 
>> International meeting times: 
>> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2018=4=11=14=0=0=224=24=179=136=37=33
> 
> It looks like the above should say "15:00 - 16:00 BST"?
> 
> I'll send agenda items closer to the time of the meeting.

That's a copy and paste thing. Yes, it should say
> 15:00 - 16:00 BST
or
> 14:00 - 15:00 UTC

Please send agenda items by tomorrow

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

Re: [Xen-devel] [OSSTEST PATCH 2/2] make-flight: Run some shadow paging tests (`hap=false')

[Wei Liu]

On Thu, Apr 05, 2018 at 02:04:18PM +0100, Ian Jackson wrote:
> Add four tests to most flights:
> 
> test-amd64-amd64-xl-shadow
> test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow
> test-amd64-i386-xl-shadow
> test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow
> 
> These are the same as the corresponding ones without -shadow, except
> that they set xen_boot_append to `hap=false', so that that will be
> passed to the hypervisor to force shadow paging.
> 
> CC: Andrew Cooper 
> CC: Jan Beulich 
> CC: George Dunlap 
> Signed-off-by: Ian Jackson 

hap=false is correct.

> ---
>  make-flight | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/make-flight b/make-flight
> index 1a8f0a6..6b53c94 100755
> --- a/make-flight
> +++ b/make-flight
> @@ -500,6 +500,16 @@ do_rtds_tests () {
>  $debian_runvars all_hostflags=$most_hostflags
>  }
>  
> +do_shadow_tests () {
> +  job_create_test test-$xenarch$kern-$dom0arch-xl-shadow  \
> +   test-debian xl $xenarch $dom0arch  \
> +guests_vcpus=4 xen_boot_append='hap=false'\
> +$debian_runvars all_hostflags=$most_hostflags
> +
> +  do_hvm_debian_test_one debianhvm xl seabios false '' -shadow \
> + "xen_boot_append=hap=false"
> +}
> +
>  do_xtf_tests () {
>if ! branch_wants_xtf_tests; then
>return
> @@ -848,6 +858,8 @@ test_matrix_do_one () {
>do_pygrub_tests
>do_pvgrub_tests
>  
> +  do_shadow_tests
> +
>do_xtf_tests
>do_livepatch_tests
>  }
> -- 
> 2.1.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] Patches for stable

[George Dunlap]

On Thu, Apr 5, 2018 at 2:06 PM, Juergen Gross  wrote:
> On 05/04/18 15:00, Boris Ostrovsky wrote:
>> On 04/05/2018 08:19 AM, Juergen Gross wrote:
>>> On 05/04/18 12:06, George Dunlap wrote:
>>>
 Aren't there flags in the binary somewhere that could tell the
 toolstack / Xen whether the kernel in question needs the RSDP table in
 lowmem, or whether it can be put higher?
>>> Not really. Analyzing the binary whether it accesses the rsdp_addr in
>>> the start_info isn't the way to go, IMO.
>>>
>>> I've sent a patch to xen-devel adding a quirk flag to the domain's
>>> config to enable the admin special casing such an "old" kernel.
>>
>> Can we backport latest struct hvm_start_info changes (which bumped
>> interface version) to 4.11 and pass RSDP only for versions >=1?
>
> And this would help how?
>
> RSDP address is passed today, the kernel just doesn't read it. And
> how should Xen know which interface version the kernel is supporting?
> And Xen needs to know that in advance in order to place the RSDP in
> low memory in case the kernel isn't reading the RSDP address from
> start_info.

But the kernel image has ELF notes, right?  You can put one that
indicates that this binary *does* know how to read the RSDP from the
start_info, and if you don't find that, put it in lowmem.

 -George

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

Re: [Xen-devel] Patches for stable

[Juergen Gross]

On 05/04/18 15:00, Boris Ostrovsky wrote:
> On 04/05/2018 08:19 AM, Juergen Gross wrote:
>> On 05/04/18 12:06, George Dunlap wrote:
>>
>>> Aren't there flags in the binary somewhere that could tell the
>>> toolstack / Xen whether the kernel in question needs the RSDP table in
>>> lowmem, or whether it can be put higher?
>> Not really. Analyzing the binary whether it accesses the rsdp_addr in
>> the start_info isn't the way to go, IMO.
>>
>> I've sent a patch to xen-devel adding a quirk flag to the domain's
>> config to enable the admin special casing such an "old" kernel.
> 
> Can we backport latest struct hvm_start_info changes (which bumped
> interface version) to 4.11 and pass RSDP only for versions >=1?

And this would help how?

RSDP address is passed today, the kernel just doesn't read it. And
how should Xen know which interface version the kernel is supporting?
And Xen needs to know that in advance in order to place the RSDP in
low memory in case the kernel isn't reading the RSDP address from
start_info.


Juergen

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

[Xen-devel] [OSSTEST PATCH 1/2] make-flight: do_hvm_debian_test_one: new testname_sfx and testvars args

[Ian Jackson]

Currently no callers pass these, so no functional change.

Signed-off-by: Ian Jackson 
---
 make-flight | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/make-flight b/make-flight
index 7cde5c2..1a8f0a6 100755
--- a/make-flight
+++ b/make-flight
@@ -396,9 +396,10 @@ do_hvm_debian_test_one () {
   bios=$3
   xsm=$4 # 'false' or 'true'
   stubdom=$5 # '' (or unset) or 'true'
+  testname_sfx=$6
+  testvars=$7
 
   local arch=$(branch_debianhvm_arch)
-  local testvars
 
   case "$arch" in
 amd64) iso_dir='install.amd' ;;
@@ -415,7 +416,7 @@ do_hvm_debian_test_one () {
   stubdom_runvar="debianhvm_stubdom=$stubdom"
   fi
 
-  job_create_test 
test-$xenarch$kern-$dom0arch-$toolstack$qemuu_suffix$stubdom_suffix-$testname-$arch\
+  job_create_test 
test-$xenarch$kern-$dom0arch-$toolstack$qemuu_suffix$stubdom_suffix-$testname-$arch$testname_sfx\
 test-debianhvm $toolstack $xenarch $dom0arch $qemuu_runvar \
 enable_xsm=$xsm \
 $stubdom_runvar $testvars   \
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 2/2] make-flight: Run some shadow paging tests (`hap=false')

[Ian Jackson]

Add four tests to most flights:

test-amd64-amd64-xl-shadow
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow
test-amd64-i386-xl-shadow
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow

These are the same as the corresponding ones without -shadow, except
that they set xen_boot_append to `hap=false', so that that will be
passed to the hypervisor to force shadow paging.

CC: Andrew Cooper 
CC: Jan Beulich 
CC: George Dunlap 
Signed-off-by: Ian Jackson 
---
 make-flight | 12 
 1 file changed, 12 insertions(+)

diff --git a/make-flight b/make-flight
index 1a8f0a6..6b53c94 100755
--- a/make-flight
+++ b/make-flight
@@ -500,6 +500,16 @@ do_rtds_tests () {
 $debian_runvars all_hostflags=$most_hostflags
 }
 
+do_shadow_tests () {
+  job_create_test test-$xenarch$kern-$dom0arch-xl-shadow  \
+   test-debian xl $xenarch $dom0arch  \
+guests_vcpus=4 xen_boot_append='hap=false'\
+$debian_runvars all_hostflags=$most_hostflags
+
+  do_hvm_debian_test_one debianhvm xl seabios false '' -shadow \
+ "xen_boot_append=hap=false"
+}
+
 do_xtf_tests () {
   if ! branch_wants_xtf_tests; then
   return
@@ -848,6 +858,8 @@ test_matrix_do_one () {
   do_pygrub_tests
   do_pvgrub_tests
 
+  do_shadow_tests
+
   do_xtf_tests
   do_livepatch_tests
 }
-- 
2.1.4


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

Re: [Xen-devel] Patches for stable

[Boris Ostrovsky]

On 04/05/2018 08:19 AM, Juergen Gross wrote:
> On 05/04/18 12:06, George Dunlap wrote:
>
>> Aren't there flags in the binary somewhere that could tell the
>> toolstack / Xen whether the kernel in question needs the RSDP table in
>> lowmem, or whether it can be put higher?
> Not really. Analyzing the binary whether it accesses the rsdp_addr in
> the start_info isn't the way to go, IMO.
>
> I've sent a patch to xen-devel adding a quirk flag to the domain's
> config to enable the admin special casing such an "old" kernel.

Can we backport latest struct hvm_start_info changes (which bumped
interface version) to 4.11 and pass RSDP only for versions >=1?

-boris

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

Re: [Xen-devel] [PATCH] python: xc: fix max_cpu_index sign error

[Wei Liu]

CC Marek

On Thu, Apr 05, 2018 at 12:49:23PM +, Petre Eftime wrote:
> When 0-indexing, maximum index is num_entries - 1. The python xc library had a
> sign error where the minus was replaced by a plus, making tools that depended
> on it to look for CPUs that did not exist.
> 
> Signed-off-by: Petre Eftime 
> ---
>  tools/python/xen/lowlevel/xc/xc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/python/xen/lowlevel/xc/xc.c 
> b/tools/python/xen/lowlevel/xc/xc.c
> index f501764..694bfa0 100644
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -1079,7 +1079,7 @@ static PyObject *pyxc_topologyinfo(XcObject *self)
>  }
>  }
>  
> -ret_obj = Py_BuildValue("{s:i}", "max_cpu_index", num_cpus + 1);
> +ret_obj = Py_BuildValue("{s:i}", "max_cpu_index", num_cpus - 1);
>  
>  PyDict_SetItemString(ret_obj, "cpu_to_core", cpu_to_core_obj);
>  Py_DECREF(cpu_to_core_obj);
> -- 
> 2.7.3.AMZN
> 
> 
> 
> 
> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar 
> Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in 
> Romania. Registration number J22/2621/2005.
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Xen-devel] [PATCH] python: xc: fix max_cpu_index sign error

[Petre Eftime]

When 0-indexing, maximum index is num_entries - 1. The python xc library had a
sign error where the minus was replaced by a plus, making tools that depended
on it to look for CPUs that did not exist.

Signed-off-by: Petre Eftime 
---
 tools/python/xen/lowlevel/xc/xc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index f501764..694bfa0 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1079,7 +1079,7 @@ static PyObject *pyxc_topologyinfo(XcObject *self)
 }
 }
 
-ret_obj = Py_BuildValue("{s:i}", "max_cpu_index", num_cpus + 1);
+ret_obj = Py_BuildValue("{s:i}", "max_cpu_index", num_cpus - 1);
 
 PyDict_SetItemString(ret_obj, "cpu_to_core", cpu_to_core_obj);
 Py_DECREF(cpu_to_core_obj);
-- 
2.7.3.AMZN




Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar 
Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in 
Romania. Registration number J22/2621/2005.


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

Re: [Xen-devel] [PATCH 0/7] Fix warnings found by gcc 8

[Juergen Gross]

On 05/04/18 11:03, Wei Liu wrote:
> On Thu, Apr 05, 2018 at 03:50:48AM +0200, Marek Marczykowski-Górecki wrote:
>> A few patches enabling build with gcc 8.
>>
>> Marek Marczykowski-Górecki (7):
>>   tools/libxc: fix strncpy size
>>   tools/misc: fix hypothetical buffer overflow in xen-lowmemd
>>   tools/blktap2: fix hypothetical buffer overflow
>>   tools/blktap2: fix possible '\0' truncation
>>   tools/xenpmd: fix possible '\0' truncation
>>   tools/gdbsx: fix -Wstringop-truncation warning
>>   tools/kdd: mute spurious gcc warning
> 
> Acked-by: Wei Liu 

Release-Acked-by: Juergen Gross 


Juergen

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  451004603247205467ec34b366b4cfa3814a5d95
baseline version:
 xen  9383de210e747f15d0fd10ade89e35d543fbc4e8

Last test of basis   121791  2018-04-04 15:01:25 Z0 days
Testing same since   121876  2018-04-05 10:04:25 Z0 days1 attempts


People who touched revisions under test:
  Sergey Dyasli 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   9383de210e..4510046032  451004603247205467ec34b366b4cfa3814a5d95 -> smoke

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

[Xen-devel] [OSSTEST PATCH] adhoc-revtuple-generator: Recognise http://example.net/example.git/ as git

[Ian Jackson]

In some circumstances the trailing slash appears, in a way that is
outside our control.  Eg some people with git submodules.

Signed-off-by: Ian Jackson 
---
 adhoc-revtuple-generator | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/adhoc-revtuple-generator b/adhoc-revtuple-generator
index 1e04773..be3f375 100755
--- a/adhoc-revtuple-generator
+++ b/adhoc-revtuple-generator
@@ -507,7 +507,7 @@ sub parse_trees () {
 $tree->{Latest}= $2;
 }
 $tree->{Url}= $_;
-if (m,/(\w[^/]+)\.git$,) {
+if (m,/(\w[^/]+)\.git/?$,) {
 $tree->{Gen}= \_generator;
 $tree->{Show}= \_revshower;
 $tree->{Treename}= $1;
-- 
2.1.4


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

Re: [Xen-devel] Patches for stable

[Juergen Gross]

On 05/04/18 12:06, George Dunlap wrote:
> On Thu, Apr 5, 2018 at 9:00 AM, Juergen Gross  wrote:
>>> These are not just "patches to fix the issue", they are "patches to add
>>> new features" that touch core acpi bits, right?  Support for new
>>> hardware and platforms and such are not normally part of the stable
>>> kernel patches at all (with the exceptions of tiny patches that add
>>> device ids and quirks.)
>>
>> The way the patches are written are the result of requests of the
>> maintainers (x86, acpi). This way they don't break layering of the
>> components. I'd be happy to rewrite them for stable kernels if you
>> like that better.
>>
>>> That's my main objection here, combined with the obvious one of "Xen
>>> does not care about their users".
>>
>> Xen does care. PVH support in Linux is relatively new (the first working
>> kernel was 4.11), Xen has full PVH guest support since Xen 4.10.
>>
>> For being able to replace PV mode it is mandatory for PVH to not add
>> unnecessary performance overhead, as performance is the main reason for
>> customers to run their guests in PV mode (yes, PV guests _are_ faster,
>> especially with many vcpus).
> 
> I'm afraid I have to agree with Greg here regarding the meaning of
> "supported"; and I remember expressing a similar sentiment when I
> discovered that a recent Linux kernel wouldn't boot on the development
> version of Xen.  Either we declare PVH in Linux 4.11-4.16 as

You finally said:

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

> "supported", in which case we have to maintain backwards compatibility
> and attempt not to break it; or we declare PVH in Linux 4.11-4.16 as
> "tech preview" (retroactively), and Greg should feel free to ignore
> these backports.

I still believe he should take them, as they are correcting a bug in
the kernel.

> It's unfortunate that Linux 4.11 didn't follow the spec, but whose
> fault is that?

Linux? ;-)

I have no problem to admit that the patches adding PVH support to the
Linux kernel were wrong in this regard and I didn't detect that when
reviewing them.

> The fact is, that as it stands, a user could have a perfectly working
> system with Xen 4.10 and a load of PVH guests running stock Linux
> 4.15, and then upgrade to Xen 4.11 and have all those guests break for
> no apparent reason.  That's a pretty obnoxious thing to do,
> particularly as we made such a fanfare about Xen 4.10 finally having
> PVH support, and encouraging everyone to go and use it.  How are all
> of those users going to feel about Xen?

Point taken.

> Aren't there flags in the binary somewhere that could tell the
> toolstack / Xen whether the kernel in question needs the RSDP table in
> lowmem, or whether it can be put higher?

Not really. Analyzing the binary whether it accesses the rsdp_addr in
the start_info isn't the way to go, IMO.

I've sent a patch to xen-devel adding a quirk flag to the domain's
config to enable the admin special casing such an "old" kernel.


Juergen

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

[Xen-devel] [PATCH-for-4.11] tools: add quirk for loading PVH RSDP into low memory

[Juergen Gross]

Commit 4a5733771e6f33918eba07b584e564a67ac1 ("libxl: put RSDP for
PVH guest near 4GB") broke PVH guests with Linux kernels before 4.17
as those kernels are not taking the RSDP address from the PVH
start_info structure, but are searching it as on legacy system by
scanning low memory.

Add a quirk to the domain config to enable loading the RSDP at low
addresses again.

Specifying "pvh_quirk_rsdp=1" will accomplish that.

Signed-off-by: Juergen Gross 
---
 docs/man/xl.cfg.pod.5.in | 8 
 tools/libxl/libxl_create.c   | 1 +
 tools/libxl/libxl_types.idl  | 1 +
 tools/libxl/libxl_x86_acpi.c | 8 ++--
 tools/xl/xl_parse.c  | 2 ++
 5 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 47d88243b1..4c00bc2d2f 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -541,6 +541,14 @@ If supplied, appended to the value for pvshim_cmdline.
 Default is empty.
 Ignored if pvhsim is false.
 
+=item 

Re: [Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

[Chao Gao]

On Thu, Apr 05, 2018 at 11:08:59AM +0100, George Dunlap wrote:
>On 04/05/2018 10:59 AM, Roger Pau Monné wrote:
>> On Thu, Apr 05, 2018 at 10:52:09AM +0100, George Dunlap wrote:
>>> On 04/05/2018 10:46 AM, Roger Pau Monné wrote:
 On Thu, Apr 05, 2018 at 10:40:37AM +0100, George Dunlap wrote:
> On 04/05/2018 10:34 AM, Roger Pau Monné wrote:
>> On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote:
>>> ... the same page with other registers which are not relevant to MSI-X. 
>>> Xen
>>> marks pages where PBA resides as read-only. When assigning such devices 
>>> to
>>> guest, device driver writes MSI-X irrelevant registers on those pages 
>>> would
>>> lead to an EPT violation and the guest is destroyed because no handler 
>>> is
>>> registered for those address range. In order to make guest capable to 
>>> use such
>>> kind of devices, trapping very frequent write accesses is not a good 
>>> idea for
>>> it would significantly impact the performance.
>>>
>>> This patch provides a workaround with caveat. Specifically, an option is
>>> introduced to specify a list of devices. For those devices, Xen doesn't
>>> control the access right to pages where PBA resides. Hence, guest device
>>> driver is able to write those pages and functions well. Note that 
>>> adding an
>>> untrusted device to this option may endanger security of the entire 
>>> system.
>>>
>>> Signed-off-by: Chao Gao 
>>> ---
>>>  docs/misc/xen-command-line.markdown | 10 +
>>>  xen/arch/x86/msi.c  |  7 --
>>>  xen/drivers/passthrough/pci.c   | 45 
>>> +++--
>>>  xen/include/asm-x86/msi.h   |  1 +
>>>  4 files changed, 59 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/docs/misc/xen-command-line.markdown 
>>> b/docs/misc/xen-command-line.markdown
>>> index b353352..e382513 100644
>>> --- a/docs/misc/xen-command-line.markdown
>>> +++ b/docs/misc/xen-command-line.markdown
>>> @@ -1423,6 +1423,16 @@ Defaults to booting secondary processors.
>>>  
>>>  > Default: `on`
>>>  
>>> +### pba\_quirk
>>
>> pba_write_allowed would be better, pba_quirk is too generic IMO.
>
> 'quirk' was I think requested by Jan; and my understanding is that the
> word clearly indicates that the behavior in question is a workaround for
> hardware which is not compliant with the appropriate specification.  If
> you grep the source tree for 'quirk' you'll find a fairly large number.
>
> pba_shared_quirk might be slightly more descriptive.

 pba_write_quirk?

 I just think it should be slightly more descriptive than pba_quirk in
 case Xen has to add further PBA-related quirks in the future.
>>>
>>> "shared" tells you something about the quirk itself: The PBA is shared
>>> across multiple devices.  "write" tells you about the work-around:
>>> unsafe writes to the PBA region are allowed.
>> 
>> I don't think the PBA page is shared with multiple devices in any
>> case. The problem here is that the PBA page contains other registers
>> (from the same device as the PBA) that must be RW instead of RO.
>
>Yes, I realized that after I'd clicked 'send'.  "Shared" still makes
>sense though: the pba shares a page with registers which must be kept RO.

pba_shared_quirk is fine with me. I will use it.

Thanks
Chao

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

Re: [Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

[Chao Gao]

On Thu, Apr 05, 2018 at 12:25:26PM +0100, Roger Pau Monné wrote:
>On Thu, Apr 05, 2018 at 07:00:41PM +0800, Chao Gao wrote:
>> On Thu, Apr 05, 2018 at 10:34:39AM +0100, Roger Pau Monné wrote:
>> >On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote:
>> >> diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
>> >> index 5567990..2abf2cf 100644
>> >> --- a/xen/arch/x86/msi.c
>> >> +++ b/xen/arch/x86/msi.c
>> >> @@ -992,7 +992,9 @@ static int msix_capability_init(struct pci_dev *dev,
>> >>  if ( rangeset_add_range(mmio_ro_ranges, msix->table.first,
>> >>  msix->table.last) )
>> >>  WARN();
>> >> -if ( rangeset_add_range(mmio_ro_ranges, msix->pba.first,
>> >> +
>> >> +if ( !msix->pba_quirk_enabled &&
>> >> + rangeset_add_range(mmio_ro_ranges, msix->pba.first,
>> >>  msix->pba.last) )
>> >>  WARN();
>> >
>> >This will work fine as long as the PBA is not in the same page as the
>> >MSI-X table. In such case you will also need changes to QEMU (see
>> >pci_msix_write), so that writes to the memory in the same page as the
>> >MSI-X/PBA tables are forwarded to the underlying hardware.
>> >
>> >You should add least add something like:
>> >
>> >if ( msix->pba_quirk_enabled &&
>> > msix->table.first <= msix->pba.last &&
>> > msix->pba.first <= msix->table.last )
>> >{
>> >printk("PBA write not allowed to dev %04x:%02x:%02x.%u due to MSI-X 
>> > table overlap\n");
>> >return -ENXIO;
>> >}
>> >
>> >Or similar if the QEMU side is not fixed.
>> >
>> >Note that in order to fix the QEMU side you would probably have to add
>> >a flag to xl 'pci' config option and pass it to both QEMU and Xen.
>> 
>> Thanks for your comments.
>> 
>> First of all, I don't intend to also support devices which has MSI-X
>> table, MSI-X PBA and other MSI-X irrelevant registers in the same page.
>> Because as you said, it cleary violates MSI-X spec. IMO, we can extend
>> the workaround when we found such a device.
>>
>> I also had the same concern with yours. But after careful thinking, I
>> found it wouldn't be a problem. If MSI-X table resides the same pages
>> with MSI-X PBA, we will mark the pages as RO when handling MSI-X table.
>> As a consequence, guest isn't able to write MSI-X table directly in this
>> case. Hence, it won't affect MSI-X table emulation and furthermore the
>> quirk won't override the decision, marking the page RO, made for other
>> reasons.
>
>My suggestion is not because it would be dangerous from a security
>PoV, it's simply because the quirk won't be applied, and hence we need
>to notify the user that the desired quirk has not been applied.

Got it. It is reasonable.

Thanks
Chao


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

Re: [Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

[Chao Gao]

On Thu, Apr 05, 2018 at 10:34:39AM +0100, Roger Pau Monné wrote:
>On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote:
>> ... the same page with other registers which are not relevant to MSI-X. Xen
>> marks pages where PBA resides as read-only. When assigning such devices to
>> guest, device driver writes MSI-X irrelevant registers on those pages would
>> lead to an EPT violation and the guest is destroyed because no handler is
>> registered for those address range. In order to make guest capable to use 
>> such
>> kind of devices, trapping very frequent write accesses is not a good idea for
>> it would significantly impact the performance.
>> 
>> This patch provides a workaround with caveat. Specifically, an option is
>> introduced to specify a list of devices. For those devices, Xen doesn't
>> control the access right to pages where PBA resides. Hence, guest device
>> driver is able to write those pages and functions well. Note that adding an
>> untrusted device to this option may endanger security of the entire system.
>> 
>> Signed-off-by: Chao Gao 
>> ---
>>  docs/misc/xen-command-line.markdown | 10 +
>>  xen/arch/x86/msi.c  |  7 --
>>  xen/drivers/passthrough/pci.c   | 45 
>> +++--
>>  xen/include/asm-x86/msi.h   |  1 +
>>  4 files changed, 59 insertions(+), 4 deletions(-)
>> 
>> diff --git a/docs/misc/xen-command-line.markdown 
>> b/docs/misc/xen-command-line.markdown
>> index b353352..e382513 100644
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -1423,6 +1423,16 @@ Defaults to booting secondary processors.
>>  
>>  > Default: `on`
>>  
>> +### pba\_quirk
>
>pba_write_allowed would be better, pba_quirk is too generic IMO.
>
>> +> `= List of [:]:.
>> +
>> +Specify a list of SBDF of devices. When assigning devices in this list to
>> +guest, reading or writing the page where MSI-X PBA resides are allowed.
>> +This option provides a workaround for nonstandard PCI devices whose
>> +MSI-X PBA shares the same 4K-byte page with other registers. Note that
>> +adding an untrusted device to this option would undermine security of
>> +the entire system.
>> +
>>  ### pci
>>  > `= {no-}serr | {no-}perr`
>>  
>> diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
>> index 5567990..2abf2cf 100644
>> --- a/xen/arch/x86/msi.c
>> +++ b/xen/arch/x86/msi.c
>> @@ -992,7 +992,9 @@ static int msix_capability_init(struct pci_dev *dev,
>>  if ( rangeset_add_range(mmio_ro_ranges, msix->table.first,
>>  msix->table.last) )
>>  WARN();
>> -if ( rangeset_add_range(mmio_ro_ranges, msix->pba.first,
>> +
>> +if ( !msix->pba_quirk_enabled &&
>> + rangeset_add_range(mmio_ro_ranges, msix->pba.first,
>>  msix->pba.last) )
>>  WARN();
>
>This will work fine as long as the PBA is not in the same page as the
>MSI-X table. In such case you will also need changes to QEMU (see
>pci_msix_write), so that writes to the memory in the same page as the
>MSI-X/PBA tables are forwarded to the underlying hardware.
>
>You should add least add something like:
>
>if ( msix->pba_quirk_enabled &&
> msix->table.first <= msix->pba.last &&
> msix->pba.first <= msix->table.last )
>{
>printk("PBA write not allowed to dev %04x:%02x:%02x.%u due to MSI-X table 
> overlap\n");
>return -ENXIO;
>}
>
>Or similar if the QEMU side is not fixed.
>
>Note that in order to fix the QEMU side you would probably have to add
>a flag to xl 'pci' config option and pass it to both QEMU and Xen.

Thanks for your comments.

First of all, I don't intend to also support devices which has MSI-X
table, MSI-X PBA and other MSI-X irrelevant registers in the same page.
Because as you said, it cleary violates MSI-X spec. IMO, we can extend
the workaround when we found such a device.

I also had the same concern with yours. But after careful thinking, I
found it wouldn't be a problem. If MSI-X table resides the same pages
with MSI-X PBA, we will mark the pages as RO when handling MSI-X table.
As a consequence, guest isn't able to write MSI-X table directly in this
case. Hence, it won't affect MSI-X table emulation and furthermore the
quirk won't override the decision, marking the page RO, made for other
reasons.
>
>>  
>> @@ -1139,7 +1141,8 @@ static void _pci_cleanup_msix(struct arch_msix *msix)
>>  if ( rangeset_remove_range(mmio_ro_ranges, msix->table.first,
>> msix->table.last) )
>>  WARN();
>> -if ( rangeset_remove_range(mmio_ro_ranges, msix->pba.first,
>> +if ( !msix->pba_quirk_enabled &&
>> + rangeset_remove_range(mmio_ro_ranges, msix->pba.first,
>> msix->pba.last) )
>>  WARN();
>>  }
>> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
>> 

[Xen-devel] [PATCH 0/1] Reduce copies between ocaml Strings and Bytes

[Marcello Seri]

The port of the ocaml libraries to the new safe-string interface
introduced some unnecessary copies between ocaml strings and bytes. The
bytes module provides unsafe conversion functions that avoid the copies
and are safe to use when the bytes are used immutably (as in Unix.write
calls) or when the ownership of the bytes is clear. For reference see
https://caml.inria.fr/pub/docs/manual-ocaml/libref/Bytes.html#3_Unsafeconversionsforadvancedusers

This patch replaces the conversion functions with unsafe conversions
when possible.

Marcello Seri (1):
  tools: reduce copies b/w ocaml Strings and Bytes

 tools/ocaml/libs/xb/xb.ml| 4 +++-
 tools/ocaml/xenstored/logging.ml | 8 +---
 tools/ocaml/xenstored/stdext.ml  | 2 +-
 tools/ocaml/xenstored/utils.ml   | 6 +++---
 4 files changed, 12 insertions(+), 8 deletions(-)

-- 
2.14.1


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

[Xen-devel] [PATCH 1/1] tools: reduce copies b/w ocaml Strings and Bytes

[Marcello Seri]

When xenstore was ported to the new safe-string interface, it mostly
happened by making copyies of string into bytes and back.  The ideal
fix would be to rewrite all of the relevant interfaces to be uniformly
using bytes, but in the meanwhile we can improve the code by using unsafe
conversion functions (see
 
https://caml.inria.fr/pub/docs/manual-ocaml/libref/Bytes.html#3_Unsafeconversionsforadvancedusers).

In most cases we own the bytes that we are converting to string, or we
immediately make copies that we then mutate, or we use them immutably
as payloads for writes. In all these cases it is safe to use the unsafe
functions and prevent a copy.

This patch updates the code to use the unsafe conversions where possible.

Signed-off-by: Marcello Seri 
---
 tools/ocaml/libs/xb/xb.ml| 4 +++-
 tools/ocaml/xenstored/logging.ml | 8 +---
 tools/ocaml/xenstored/stdext.ml  | 2 +-
 tools/ocaml/xenstored/utils.ml   | 6 +++---
 4 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/tools/ocaml/libs/xb/xb.ml b/tools/ocaml/libs/xb/xb.ml
index 519842723b..660224f895 100644
--- a/tools/ocaml/libs/xb/xb.ml
+++ b/tools/ocaml/libs/xb/xb.ml
@@ -100,7 +100,9 @@ let write_mmap back con s len =
 
 let write con s len =
match con.backend with
-   | Fd backfd -> write_fd backfd con (Bytes.of_string s) len
+   (* we can use unsafe_of_string here as the bytes are used immutably
+  in the Unix.write operation. *)
+   | Fd backfd -> write_fd backfd con (Bytes.unsafe_of_string s) len
| Xenmmap backmmap -> write_mmap backmmap con s len
 
 (* NB: can throw Reconnect *)
diff --git a/tools/ocaml/xenstored/logging.ml b/tools/ocaml/xenstored/logging.ml
index e3c769fb2c..45a2c222e6 100644
--- a/tools/ocaml/xenstored/logging.ml
+++ b/tools/ocaml/xenstored/logging.ml
@@ -64,7 +64,7 @@ let truncate_line nb_chars line =
Bytes.blit_string line 0 dst_line 0 (len - 2);
Bytes.set dst_line (len-2) '.';
Bytes.set dst_line (len-1) '.';
-   Bytes.to_string dst_line
+   Bytes.unsafe_to_string dst_line
else line
 
 let log_rotate ref_ch log_file log_nb_files =
@@ -258,7 +258,7 @@ let sanitize_data data =
if Bytes.get data i = '\000' then
Bytes.set data i ' '
done;
-   String.escaped (Bytes.to_string data)
+   String.escaped (Bytes.unsafe_to_string data)
 
 let activate_access_log = ref true
 let access_log_destination = ref (File (Paths.xen_log_dir ^ 
"/xenstored-access.log"))
@@ -291,7 +291,9 @@ let access_logging ~con ~tid ?(data="") ~level access_type =
let date = string_of_date() in
let tid = string_of_tid ~con tid in
let access_type = string_of_access_type 
access_type in
-   let data = sanitize_data (Bytes.of_string data) 
in
+   (* we can use unsafe_of_string here as the 
sanitize_data function
+  immediately makes a copy of the data and 
operates on that. *)
+   let data = sanitize_data 
(Bytes.unsafe_of_string data) in
let prefix = prefix !access_log_destination 
date in
let msg = Printf.sprintf "%s %s %s %s" prefix 
tid access_type data in
logger.write ~level msg)
diff --git a/tools/ocaml/xenstored/stdext.ml b/tools/ocaml/xenstored/stdext.ml
index 41411ee535..869fec36f2 100644
--- a/tools/ocaml/xenstored/stdext.ml
+++ b/tools/ocaml/xenstored/stdext.ml
@@ -122,7 +122,7 @@ let pidfile_write filename =
let pid = Unix.getpid () in
let buf = string_of_int pid ^ "\n" in
let len = String.length buf in
-   if Unix.write fd (Bytes.of_string buf) 0 len <> len
+   if Unix.write fd (Bytes.unsafe_of_string buf) 0 len <> len
then failwith "pidfile_write failed";
)
(fun () -> Unix.close fd)
diff --git a/tools/ocaml/xenstored/utils.ml b/tools/ocaml/xenstored/utils.ml
index 5fcb042351..73affb7ea4 100644
--- a/tools/ocaml/xenstored/utils.ml
+++ b/tools/ocaml/xenstored/utils.ml
@@ -52,7 +52,7 @@ let hexify s =
Bytes.set hs (i * 2) seq.[0];
Bytes.set hs (i * 2 + 1) seq.[1];
done;
-   Bytes.to_string hs
+   Bytes.unsafe_to_string hs
 
 let unhexify hs =
let char_of_hexseq seq0 seq1 = Char.chr (int_of_string (sprintf 
"0x%c%c" seq0 seq1)) in
@@ -61,7 +61,7 @@ let unhexify hs =
do
Bytes.set b i (char_of_hexseq hs.[i * 2] hs.[i * 2 + 1])
done;
-   Bytes.to_string b
+   Bytes.unsafe_to_string b
 
 let trim_path path =
try
@@ -87,7 +87,7 @@ let read_file_single_integer filename =
let buf = Bytes.make 20 (char_of_int 0) in
let 

[Xen-devel] [xen-4.9-testing test] 121761: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 
121704 pass in 121761
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 121704 
pass in 121761
 test-armhf-armhf-xl-arndale   6 xen-install  fail in 121704 pass in 121761
 test-amd64-i386-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail in 121728 
pass in 121761
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 121728 
pass in 121761
 test-armhf-armhf-xl-vhd 10 debian-di-install fail in 121728 pass in 121761
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
pass in 121704
 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail pass in 
121704
 test-amd64-i386-freebsd10-i386 10 freebsd-install  fail pass in 121728
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
pass in 121728
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail pass in 
121728
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeat  fail pass in 121728

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 121015

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop  fail blocked in 121015
 test-armhf-armhf-xl-rtds   16 guest-start/debian.repeat fail blocked in 121015
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 121704 
like 121015
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop   fail in 121704 like 121015
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail in 121728 like 121015
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 121015
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 121015
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 121015
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 121015
 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 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-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-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-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-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-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-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never 

Re: [Xen-devel] [PATCH v3 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC

[Andre Przywara]

Hi,

On 05/04/18 11:16, Amit Singh Tomar wrote:
> This patch adds driver for UART controller found on Armada 3700 SoC.
> 
> There is no reference manuals available for 3700 SoC in public and it
> is derived by looking at Linux driver[1].
> 
> [1]https://github.com/torvalds/linux/blob/master/drivers/tty/serial/mvebu-uart.c
> 
> Signed-off-by: Amit Singh Tomar 
> ---
> Changes since v2:
> * Addressed Andre's comments.
> Changes since v1:
> * Addressed Wei Liu's comments
> * Addressed Andre's comments.
> Changes since RFC:
> * Addressed Julien's comments.
> ---
>  xen/drivers/char/Kconfig  |   8 ++
>  xen/drivers/char/Makefile |   1 +
>  xen/drivers/char/mvebu-uart.c | 296 
> ++
>  3 files changed, 305 insertions(+)
>  create mode 100644 xen/drivers/char/mvebu-uart.c
> 
> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> index fb53dd8..04a4087 100644
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -12,6 +12,14 @@ config HAS_CADENCE_UART
> This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq
> based board, say Y.
> 
> +config HAS_MVEBU
> +bool
> +default y
> +depends on ARM_64
> +help
> +  This selects the Marvell MVEBU UART. If you have a ARMADA 3700
> +  based board, say Y.
> +

That still looks wrong.

>  config HAS_PL011
>   bool
>   default y
> diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> index 0d48b16..b68c330 100644
> --- a/xen/drivers/char/Makefile
> +++ b/xen/drivers/char/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_HAS_NS16550) += ns16550.o
>  obj-$(CONFIG_HAS_CADENCE_UART) += cadence-uart.o
>  obj-$(CONFIG_HAS_PL011) += pl011.o
>  obj-$(CONFIG_HAS_EXYNOS4210) += exynos4210-uart.o
> +obj-$(CONFIG_HAS_MVEBU) += mvebu-uart.o
>  obj-$(CONFIG_HAS_OMAP) += omap-uart.o
>  obj-$(CONFIG_HAS_SCIF) += scif-uart.o
>  obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
> diff --git a/xen/drivers/char/mvebu-uart.c b/xen/drivers/char/mvebu-uart.c
> new file mode 100644
> index 000..1561a50
> --- /dev/null
> +++ b/xen/drivers/char/mvebu-uart.c
> @@ -0,0 +1,296 @@
> +/*
> + * xen/drivers/char/mvebu3700-uart.c
> + *
> + * Driver for Marvell MVEBU UART.
> + *
> + * Copyright (c) 2018, Amit Singh Tomar .
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Register offsets */
> +#define UART_RX_REG 0x00
> +
> +#define UART_TX_REG 0x04
> +
> +#define UART_CTRL_REG   0x08
> +#define CTRL_TXFIFO_RST BIT(15)
> +#define CTRL_RXFIFO_RST BIT(14)
> +#define CTRL_TX_RDY_INT BIT(5)
> +#define CTRL_RX_RDY_INT BIT(4)
> +#define CTRL_BRK_DET_INTBIT(3)
> +#define CTRL_FRM_ERR_INTBIT(2)
> +#define CTRL_PAR_ERR_INTBIT(1)
> +#define CTRL_OVR_ERR_INTBIT(0)
> +#define CTRL_ERR_INT(CTRL_BRK_DET_INT | CTRL_FRM_ERR_INT | \
> + CTRL_PAR_ERR_INT | CTRL_OVR_ERR_INT)
> +
> +#define UART_STATUS_REG 0x0c
> +#define STATUS_TXFIFO_EMP   BIT(13)
> +#define STAT_TX_FIFO_FULBIT(11)
> +#define STAT_TX_FIFO_HFLBIT(10)

Nit: those names should be consistent.

> +#define STATUS_TX_RDY   BIT(5)
> +#define STATUS_RX_RDY   BIT(4)
> +#define STATUS_BRK_DET  BIT(3)
> +#define STATUS_FRM_ERR  BIT(2)
> +#define STATUS_PAR_ERR  BIT(1)
> +#define STATUS_OVR_ERR  BIT(0)
> +#define STATUS_BRK_ERR  (STATUS_BRK_DET | STATUS_FRM_ERR | \
> + STATUS_PAR_ERR | STATUS_OVR_ERR)
> +
> +#define TX_FIFO_SIZE32
> +
> +static struct mvebu3700_uart {
> +unsigned int irq;
> +void __iomem *regs;
> +struct irqaction irqaction;
> +struct vuart_info vuart;
> +} mvebu3700_com = {0};
> +
> +#define mvebu3700_read(uart, off)   readl((uart)->regs + off)
> +#define mvebu3700_write(uart, off, val) writel(val, (uart->regs) + off)
> +
> +static void mvebu3700_uart_interrupt(int irq, void *data,
> + struct cpu_user_regs *regs)
> +{
> +struct serial_port *port = data;
> +struct mvebu3700_uart *uart = port->uart;
> +uint32_t st = mvebu3700_read(uart, UART_STATUS_REG);
> +
> +if ( st & 

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

[kbuild test robot]

Hi Maran,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on next-20180405]
[cannot apply to tip/x86/core xen-tip/linux-next v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Maran-Wilson/KVM-x86-Allow-Qemu-KVM-to-use-PVH-entry-point/20180405-165048
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from arch/x86/platform/pvh/enlighten.c:12:0:
   arch/x86/include/asm/xen/hypercall.h: In function 
'HYPERVISOR_update_va_mapping':
>> arch/x86/include/asm/xen/hypercall.h:366:33: warning: right shift count >= 
>> width of type [-Wshift-count-overflow]
   new_val.pte, new_val.pte >> 32, flags);
^
   arch/x86/include/asm/xen/hypercall.h:132:52: note: in definition of macro 
'__HYPERCALL_3ARG'
 __HYPERCALL_2ARG(a1,a2)  __arg3 = (unsigned long)(a3);
   ^~
>> arch/x86/include/asm/xen/hypercall.h:192:2: note: in expansion of macro 
>> '__HYPERCALL_4ARG'
 __HYPERCALL_4ARG(a1, a2, a3, a4);\
 ^~~~
>> arch/x86/include/asm/xen/hypercall.h:365:10: note: in expansion of macro 
>> '_hypercall4'
  return _hypercall4(int, update_va_mapping, va,
 ^~~
   arch/x86/include/asm/xen/hypercall.h: In function 
'HYPERVISOR_update_va_mapping_otherdomain':
   arch/x86/include/asm/xen/hypercall.h:417:33: warning: right shift count >= 
width of type [-Wshift-count-overflow]
   new_val.pte, new_val.pte >> 32,
^
   arch/x86/include/asm/xen/hypercall.h:132:52: note: in definition of macro 
'__HYPERCALL_3ARG'
 __HYPERCALL_2ARG(a1,a2)  __arg3 = (unsigned long)(a3);
   ^~
   arch/x86/include/asm/xen/hypercall.h:136:2: note: in expansion of macro 
'__HYPERCALL_4ARG'
 __HYPERCALL_4ARG(a1,a2,a3,a4) __arg5 = (unsigned long)(a5);
 ^~~~
>> arch/x86/include/asm/xen/hypercall.h:203:2: note: in expansion of macro 
>> '__HYPERCALL_5ARG'
 __HYPERCALL_5ARG(a1, a2, a3, a4, a5);\
 ^~~~
>> arch/x86/include/asm/xen/hypercall.h:416:10: note: in expansion of macro 
>> '_hypercall5'
  return _hypercall5(int, update_va_mapping_otherdomain, va,
 ^~~
   arch/x86/include/asm/xen/hypercall.h: In function 'MULTI_update_va_mapping':
   arch/x86/include/asm/xen/hypercall.h:511:30: warning: right shift count >= 
width of type [-Wshift-count-overflow]
  mcl->args[2] = new_val.pte >> 32;
 ^~
   arch/x86/include/asm/xen/hypercall.h: In function 
'MULTI_update_va_mapping_otherdomain':
   arch/x86/include/asm/xen/hypercall.h:543:30: warning: right shift count >= 
width of type [-Wshift-count-overflow]
  mcl->args[2] = new_val.pte >> 32;
 ^~

vim +366 arch/x86/include/asm/xen/hypercall.h

a42089dd3 include/asm-i386/xen/hypercall.h Jeremy Fitzhardinge
2007-07-17  188  
a42089dd3 include/asm-i386/xen/hypercall.h Jeremy Fitzhardinge
2007-07-17  189  #define _hypercall4(type, name, a1, a2, a3, a4)
  \
a42089dd3 include/asm-i386/xen/hypercall.h Jeremy Fitzhardinge
2007-07-17  190  ({ 
  \
e74359028 include/asm-x86/xen/hypercall.h  Jeremy Fitzhardinge
2008-07-08  191   __HYPERCALL_DECLS;
  \
e74359028 include/asm-x86/xen/hypercall.h  Jeremy Fitzhardinge
2008-07-08 @192   __HYPERCALL_4ARG(a1, a2, a3, a4); 
  \
e74359028 include/asm-x86/xen/hypercall.h  Jeremy Fitzhardinge
2008-07-08  193   asm volatile (__HYPERCALL 
  \
e74359028 include/asm-x86/xen/hypercall.h  Jeremy Fitzhardinge
2008-07-08  194 : __HYPERCALL_4PARAM
  \
e74359028 include/asm-x86/xen/hypercall.h  Jeremy Fitzhardinge
2008-07-08  195 : __HYPERCALL_ENTRY(name)   
  \
e74359028 include/asm-x86/xen/hypercall.h  Jeremy Fitzhardinge
2008-07-08  196 : __HYPERCALL_CLOBBER4);
  \
a42089dd3 include/asm-i386/xen/hypercall.h Jeremy Fitzhardinge
2007-07-17  197   (type)__res;  
  \
a42089dd3 include/asm-i386/xen/hypercall.h Jeremy Fitzhardinge
2007-07-17  19

Re: [Xen-devel] [PATCH v3 2/2] xen/arm: Add Marvell ARMADA 3700 early printk support

[Andre Przywara]

Hi,

On 05/04/18 11:16, Amit Singh Tomar wrote:
> Signed-off-by: Amit Singh Tomar 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
> Changes since v2:
> * Addressed Andre's comments.
> Changes since v1:
> * Removed header file dependency.
> ---
>  docs/misc/arm/early-printk.txt |  1 +
>  xen/arch/arm/Rules.mk  |  1 +
>  xen/arch/arm/arm64/debug-mvebu.inc | 50 
> ++
>  3 files changed, 52 insertions(+)
>  create mode 100644 xen/arch/arm/arm64/debug-mvebu.inc
> 
> diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
> index 20a8af8..f765f59 100644
> --- a/docs/misc/arm/early-printk.txt
> +++ b/docs/misc/arm/early-printk.txt
> @@ -41,6 +41,7 @@ the name of the machine:
>- juno: printk with pl011 on Juno platform
>- lager: printk with SCIF0 on Renesas R-Car H2 processors
>- midway: printk with the pl011 on Calxeda Midway processors
> +  - mvebu: printk with the MVEBU for Marvell Armada 3700 SoCs
>- omap5432: printk with UART3 on TI OMAP5432 processors
>- rcar3: printk with SCIF2 on Renesas R-Car Gen3 processors
>- seattle: printk with pl011 for AMD Seattle processor
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index b66c19f..f264592 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -36,6 +36,7 @@ EARLY_PRINTK_hikey960   := pl011,0xfff32000
>  EARLY_PRINTK_juno   := pl011,0x7ff8
>  EARLY_PRINTK_lager  := scif,0xe6e6
>  EARLY_PRINTK_midway := pl011,0xfff36000
> +EARLY_PRINTK_mvebu  := mvebu,0xd0012000
>  EARLY_PRINTK_omap5432   := 8250,0x4802,2
>  EARLY_PRINTK_rcar3  := scif,0xe6e88000
>  EARLY_PRINTK_seattle:= pl011,0xe101
> diff --git a/xen/arch/arm/arm64/debug-mvebu.inc 
> b/xen/arch/arm/arm64/debug-mvebu.inc
> new file mode 100644
> index 000..3579ea6
> --- /dev/null
> +++ b/xen/arch/arm/arm64/debug-mvebu.inc
> @@ -0,0 +1,50 @@
> +/*
> + * xen/arch/arm/arm64/debug-mvebu.inc
> + *
> + * MVEBU specific debug code.
> + *
> + * Copyright (c) 2018, Amit Singh Tomar .
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#define UART_STATUS_REG 0x0c
> +#define UART_TX_REG 0x04
> +
> +/*
> + * MVEBU UART wait UART to be ready to transmit
> + * xb: register which contains the UART base address
> + * c: scratch register
> + */
> +.macro early_uart_ready xb c
> +1:
> +ldrh   w\c, [\xb, #UART_STATUS_REG]  /* status register */
> +tstw\c, #(1 << 11)/* Check TXFIFO FULL 
> bit */
> +b.ne   1b/* Wait for the UART to be 
> ready */
> +.endm
> +
> +/*
> + * MVEBU UART transmit character
> + * xb: register which contains the UART base address
> + * wt: register which contains the character to transmit
> + */
> +.macro early_uart_transmit xb wt
> + strb  \wt, [\xb, #UART_TX_REG]
> +.endm
> +
> +/*
> + * Local variables:
> + * mode: ASM
> + * indent-tabs-mode: nil
> + * End:
> + */
> --
> 1.9.1
> 

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

[Xen-devel] [PATCH v3 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC

[Amit Singh Tomar]

This patch adds driver for UART controller found on Armada 3700 SoC.

There is no reference manuals available for 3700 SoC in public and it
is derived by looking at Linux driver[1].

[1]https://github.com/torvalds/linux/blob/master/drivers/tty/serial/mvebu-uart.c

Signed-off-by: Amit Singh Tomar 
---
Changes since v2:
* Addressed Andre's comments.
Changes since v1:
* Addressed Wei Liu's comments
* Addressed Andre's comments.
Changes since RFC:
* Addressed Julien's comments.
---
 xen/drivers/char/Kconfig  |   8 ++
 xen/drivers/char/Makefile |   1 +
 xen/drivers/char/mvebu-uart.c | 296 ++
 3 files changed, 305 insertions(+)
 create mode 100644 xen/drivers/char/mvebu-uart.c

diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index fb53dd8..04a4087 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -12,6 +12,14 @@ config HAS_CADENCE_UART
  This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq
  based board, say Y.

+config HAS_MVEBU
+bool
+default y
+depends on ARM_64
+help
+  This selects the Marvell MVEBU UART. If you have a ARMADA 3700
+  based board, say Y.
+
 config HAS_PL011
bool
default y
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 0d48b16..b68c330 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_HAS_NS16550) += ns16550.o
 obj-$(CONFIG_HAS_CADENCE_UART) += cadence-uart.o
 obj-$(CONFIG_HAS_PL011) += pl011.o
 obj-$(CONFIG_HAS_EXYNOS4210) += exynos4210-uart.o
+obj-$(CONFIG_HAS_MVEBU) += mvebu-uart.o
 obj-$(CONFIG_HAS_OMAP) += omap-uart.o
 obj-$(CONFIG_HAS_SCIF) += scif-uart.o
 obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
diff --git a/xen/drivers/char/mvebu-uart.c b/xen/drivers/char/mvebu-uart.c
new file mode 100644
index 000..1561a50
--- /dev/null
+++ b/xen/drivers/char/mvebu-uart.c
@@ -0,0 +1,296 @@
+/*
+ * xen/drivers/char/mvebu3700-uart.c
+ *
+ * Driver for Marvell MVEBU UART.
+ *
+ * Copyright (c) 2018, Amit Singh Tomar .
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/* Register offsets */
+#define UART_RX_REG 0x00
+
+#define UART_TX_REG 0x04
+
+#define UART_CTRL_REG   0x08
+#define CTRL_TXFIFO_RST BIT(15)
+#define CTRL_RXFIFO_RST BIT(14)
+#define CTRL_TX_RDY_INT BIT(5)
+#define CTRL_RX_RDY_INT BIT(4)
+#define CTRL_BRK_DET_INTBIT(3)
+#define CTRL_FRM_ERR_INTBIT(2)
+#define CTRL_PAR_ERR_INTBIT(1)
+#define CTRL_OVR_ERR_INTBIT(0)
+#define CTRL_ERR_INT(CTRL_BRK_DET_INT | CTRL_FRM_ERR_INT | \
+ CTRL_PAR_ERR_INT | CTRL_OVR_ERR_INT)
+
+#define UART_STATUS_REG 0x0c
+#define STATUS_TXFIFO_EMP   BIT(13)
+#define STAT_TX_FIFO_FULBIT(11)
+#define STAT_TX_FIFO_HFLBIT(10)
+#define STATUS_TX_RDY   BIT(5)
+#define STATUS_RX_RDY   BIT(4)
+#define STATUS_BRK_DET  BIT(3)
+#define STATUS_FRM_ERR  BIT(2)
+#define STATUS_PAR_ERR  BIT(1)
+#define STATUS_OVR_ERR  BIT(0)
+#define STATUS_BRK_ERR  (STATUS_BRK_DET | STATUS_FRM_ERR | \
+ STATUS_PAR_ERR | STATUS_OVR_ERR)
+
+#define TX_FIFO_SIZE32
+
+static struct mvebu3700_uart {
+unsigned int irq;
+void __iomem *regs;
+struct irqaction irqaction;
+struct vuart_info vuart;
+} mvebu3700_com = {0};
+
+#define mvebu3700_read(uart, off)   readl((uart)->regs + off)
+#define mvebu3700_write(uart, off, val) writel(val, (uart->regs) + off)
+
+static void mvebu3700_uart_interrupt(int irq, void *data,
+ struct cpu_user_regs *regs)
+{
+struct serial_port *port = data;
+struct mvebu3700_uart *uart = port->uart;
+uint32_t st = mvebu3700_read(uart, UART_STATUS_REG);
+
+if ( st & (STATUS_RX_RDY | STATUS_OVR_ERR | STATUS_FRM_ERR |
+   STATUS_BRK_DET) )
+serial_rx_interrupt(port, regs);
+
+if ( st & STATUS_TX_RDY )
+serial_tx_interrupt(port, regs);
+}
+
+static void __init mvebu3700_uart_init_preirq(struct serial_port *port)
+{
+struct mvebu3700_uart *uart = port->uart;
+uint32_t reg;
+
+reg = mvebu3700_read(uart, 

[Xen-devel] [PATCH 0/2] Add support for Marvell Armada 3700 SoC

[Amit Singh Tomar]

This patch-set enables XEN booting[1] on ESPRESSObin board based
on Marvell Armada 3700 SoC.

I would like to Thanks Andre for helping on this.

[1]https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/ESPRESSObin

Amit Singh Tomar (2):
  xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC
  xen/arm: Add Marvell ARMADA 3700 early printk support

 docs/misc/arm/early-printk.txt |   1 +
 xen/arch/arm/Rules.mk  |   1 +
 xen/arch/arm/arm64/debug-mvebu.inc |  50 +++
 xen/drivers/char/Kconfig   |   8 +
 xen/drivers/char/Makefile  |   1 +
 xen/drivers/char/mvebu-uart.c  | 296 +
 6 files changed, 357 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-mvebu.inc
 create mode 100644 xen/drivers/char/mvebu-uart.c

--
1.9.1


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

[Xen-devel] [PATCH v3 2/2] xen/arm: Add Marvell ARMADA 3700 early printk support

[Amit Singh Tomar]

Signed-off-by: Amit Singh Tomar 
---
Changes since v2:
* Addressed Andre's comments.
Changes since v1:
* Removed header file dependency.
---
 docs/misc/arm/early-printk.txt |  1 +
 xen/arch/arm/Rules.mk  |  1 +
 xen/arch/arm/arm64/debug-mvebu.inc | 50 ++
 3 files changed, 52 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-mvebu.inc

diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
index 20a8af8..f765f59 100644
--- a/docs/misc/arm/early-printk.txt
+++ b/docs/misc/arm/early-printk.txt
@@ -41,6 +41,7 @@ the name of the machine:
   - juno: printk with pl011 on Juno platform
   - lager: printk with SCIF0 on Renesas R-Car H2 processors
   - midway: printk with the pl011 on Calxeda Midway processors
+  - mvebu: printk with the MVEBU for Marvell Armada 3700 SoCs
   - omap5432: printk with UART3 on TI OMAP5432 processors
   - rcar3: printk with SCIF2 on Renesas R-Car Gen3 processors
   - seattle: printk with pl011 for AMD Seattle processor
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index b66c19f..f264592 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -36,6 +36,7 @@ EARLY_PRINTK_hikey960   := pl011,0xfff32000
 EARLY_PRINTK_juno   := pl011,0x7ff8
 EARLY_PRINTK_lager  := scif,0xe6e6
 EARLY_PRINTK_midway := pl011,0xfff36000
+EARLY_PRINTK_mvebu  := mvebu,0xd0012000
 EARLY_PRINTK_omap5432   := 8250,0x4802,2
 EARLY_PRINTK_rcar3  := scif,0xe6e88000
 EARLY_PRINTK_seattle:= pl011,0xe101
diff --git a/xen/arch/arm/arm64/debug-mvebu.inc 
b/xen/arch/arm/arm64/debug-mvebu.inc
new file mode 100644
index 000..3579ea6
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-mvebu.inc
@@ -0,0 +1,50 @@
+/*
+ * xen/arch/arm/arm64/debug-mvebu.inc
+ *
+ * MVEBU specific debug code.
+ *
+ * Copyright (c) 2018, Amit Singh Tomar .
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ */
+
+#define UART_STATUS_REG 0x0c
+#define UART_TX_REG 0x04
+
+/*
+ * MVEBU UART wait UART to be ready to transmit
+ * xb: register which contains the UART base address
+ * c: scratch register
+ */
+.macro early_uart_ready xb c
+1:
+ldrh   w\c, [\xb, #UART_STATUS_REG]  /* status register */
+tstw\c, #(1 << 11)  /* Check TXFIFO FULL bit */
+b.ne   1b/* Wait for the UART to be ready 
*/
+.endm
+
+/*
+ * MVEBU UART transmit character
+ * xb: register which contains the UART base address
+ * wt: register which contains the character to transmit
+ */
+.macro early_uart_transmit xb wt
+   strb  \wt, [\xb, #UART_TX_REG]
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
--
1.9.1


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

Re: [Xen-devel] Patches for stable

[George Dunlap]

On Thu, Apr 5, 2018 at 11:06 AM, George Dunlap  wrote:
> The fact is, that as it stands, a user could have a perfectly working
> system with Xen 4.10 and a load of PVH guests running stock Linux
> 4.15, and then upgrade to Xen 4.11 and have all those guests break for
> no apparent reason.  That's a pretty obnoxious thing to do,
> particularly as we made such a fanfare about Xen 4.10 finally having
> PVH support, and encouraging everyone to go and use it.  How are all
> of those users going to feel about Xen?

I mean, imagine a cloud provider that's managed to get a bunch of
*customers* using PVH, because it's more secure than either PV or HVM
(fewer hypercalls and no device emulation).  Then she upgrades to Xen
4.11, and suddenly all the guests break on reboot!  Worse yet, the
only way to fix it is to have the customers either boot into classic
PV mode or HVM mode in order to actually get an updated kernel!
That's a real jerk move to pull on the early adopters who are so
critical for widespread adoption and feedback.

 -George

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

Re: [Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

[George Dunlap]

On 04/05/2018 10:59 AM, Roger Pau Monné wrote:
> On Thu, Apr 05, 2018 at 10:52:09AM +0100, George Dunlap wrote:
>> On 04/05/2018 10:46 AM, Roger Pau Monné wrote:
>>> On Thu, Apr 05, 2018 at 10:40:37AM +0100, George Dunlap wrote:
 On 04/05/2018 10:34 AM, Roger Pau Monné wrote:
> On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote:
>> ... the same page with other registers which are not relevant to MSI-X. 
>> Xen
>> marks pages where PBA resides as read-only. When assigning such devices 
>> to
>> guest, device driver writes MSI-X irrelevant registers on those pages 
>> would
>> lead to an EPT violation and the guest is destroyed because no handler is
>> registered for those address range. In order to make guest capable to 
>> use such
>> kind of devices, trapping very frequent write accesses is not a good 
>> idea for
>> it would significantly impact the performance.
>>
>> This patch provides a workaround with caveat. Specifically, an option is
>> introduced to specify a list of devices. For those devices, Xen doesn't
>> control the access right to pages where PBA resides. Hence, guest device
>> driver is able to write those pages and functions well. Note that adding 
>> an
>> untrusted device to this option may endanger security of the entire 
>> system.
>>
>> Signed-off-by: Chao Gao 
>> ---
>>  docs/misc/xen-command-line.markdown | 10 +
>>  xen/arch/x86/msi.c  |  7 --
>>  xen/drivers/passthrough/pci.c   | 45 
>> +++--
>>  xen/include/asm-x86/msi.h   |  1 +
>>  4 files changed, 59 insertions(+), 4 deletions(-)
>>
>> diff --git a/docs/misc/xen-command-line.markdown 
>> b/docs/misc/xen-command-line.markdown
>> index b353352..e382513 100644
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -1423,6 +1423,16 @@ Defaults to booting secondary processors.
>>  
>>  > Default: `on`
>>  
>> +### pba\_quirk
>
> pba_write_allowed would be better, pba_quirk is too generic IMO.

 'quirk' was I think requested by Jan; and my understanding is that the
 word clearly indicates that the behavior in question is a workaround for
 hardware which is not compliant with the appropriate specification.  If
 you grep the source tree for 'quirk' you'll find a fairly large number.

 pba_shared_quirk might be slightly more descriptive.
>>>
>>> pba_write_quirk?
>>>
>>> I just think it should be slightly more descriptive than pba_quirk in
>>> case Xen has to add further PBA-related quirks in the future.
>>
>> "shared" tells you something about the quirk itself: The PBA is shared
>> across multiple devices.  "write" tells you about the work-around:
>> unsafe writes to the PBA region are allowed.
> 
> I don't think the PBA page is shared with multiple devices in any
> case. The problem here is that the PBA page contains other registers
> (from the same device as the PBA) that must be RW instead of RO.

Yes, I realized that after I'd clicked 'send'.  "Shared" still makes
sense though: the pba shares a page with registers which must be kept RO.

 -George

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

Re: [Xen-devel] Patches for stable

[George Dunlap]

On Thu, Apr 5, 2018 at 9:00 AM, Juergen Gross  wrote:
>> These are not just "patches to fix the issue", they are "patches to add
>> new features" that touch core acpi bits, right?  Support for new
>> hardware and platforms and such are not normally part of the stable
>> kernel patches at all (with the exceptions of tiny patches that add
>> device ids and quirks.)
>
> The way the patches are written are the result of requests of the
> maintainers (x86, acpi). This way they don't break layering of the
> components. I'd be happy to rewrite them for stable kernels if you
> like that better.
>
>> That's my main objection here, combined with the obvious one of "Xen
>> does not care about their users".
>
> Xen does care. PVH support in Linux is relatively new (the first working
> kernel was 4.11), Xen has full PVH guest support since Xen 4.10.
>
> For being able to replace PV mode it is mandatory for PVH to not add
> unnecessary performance overhead, as performance is the main reason for
> customers to run their guests in PV mode (yes, PV guests _are_ faster,
> especially with many vcpus).

I'm afraid I have to agree with Greg here regarding the meaning of
"supported"; and I remember expressing a similar sentiment when I
discovered that a recent Linux kernel wouldn't boot on the development
version of Xen.  Either we declare PVH in Linux 4.11-4.16 as
"supported", in which case we have to maintain backwards compatibility
and attempt not to break it; or we declare PVH in Linux 4.11-4.16 as
"tech preview" (retroactively), and Greg should feel free to ignore
these backports.

It's unfortunate that Linux 4.11 didn't follow the spec, but whose
fault is that?

The fact is, that as it stands, a user could have a perfectly working
system with Xen 4.10 and a load of PVH guests running stock Linux
4.15, and then upgrade to Xen 4.11 and have all those guests break for
no apparent reason.  That's a pretty obnoxious thing to do,
particularly as we made such a fanfare about Xen 4.10 finally having
PVH support, and encouraging everyone to go and use it.  How are all
of those users going to feel about Xen?

Aren't there flags in the binary somewhere that could tell the
toolstack / Xen whether the kernel in question needs the RSDP table in
lowmem, or whether it can be put higher?

 -George

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

Re: [Xen-devel] Problem with Xen 4.7.5

[Steven Haigh]

On Thursday, 5 April 2018 7:19:15 PM AEST Ian Jackson wrote:
> Steven Haigh writes ("Re: Problem with Xen 4.7.5"):
> > On 2018-04-05 03:22, Ian Jackson wrote:
> > > Apologies for the inconvenience.
> 
> ...
> 
> > I'm wondering if the severity of this is high enough that I should
> > withdraw the 4.7.5 packages from my repos.
> > 
> > Is this a show-stopper? Security issue? Dom0 crash?
> > 
> > I released 4.7.5 packages within an hour of the 4.7.5 release
> > announcement - so there are quite a few user systems that have already
> > grabbed them.
> 
> It's quite bad.  We don't understand the impact properly yet but it is
> at least a domU crash in some situations.
> 
> I would withdraw the packages, yes.  Sorry.

Thanks Ian, its all good - I've withdrawn them and I'll send an announcement 
to my user list to get them to downgrade etc...

-- 
Steven Haigh

 net...@crc.id.au    http://www.crc.id.au
 +61 (3) 9001 6090 0412 935 897


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

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

[kbuild test robot]

Hi Maran,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on next-20180404]
[cannot apply to tip/x86/core xen-tip/linux-next v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Maran-Wilson/KVM-x86-Allow-Qemu-KVM-to-use-PVH-entry-point/20180405-165048
config: i386-randconfig-x019-201813 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/xen/enlighten_pvh.c: In function 'xen_pvh_init':
>> arch/x86/xen/enlighten_pvh.c:23:18: error: implicit declaration of function 
>> 'xen_cpuid_base'; did you mean 'get_pid_task'? 
>> [-Werror=implicit-function-declaration]
 msr = cpuid_ebx(xen_cpuid_base() + 2);
 ^~
 get_pid_task
   cc1: some warnings being treated as errors

vim +23 arch/x86/xen/enlighten_pvh.c

15  
16  void __init xen_pvh_init(void)
17  {
18  u32 msr;
19  u64 pfn;
20  
21  xen_pvh = 1;
22  
  > 23  msr = cpuid_ebx(xen_cpuid_base() + 2);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

[Roger Pau Monné]

On Thu, Apr 05, 2018 at 10:52:09AM +0100, George Dunlap wrote:
> On 04/05/2018 10:46 AM, Roger Pau Monné wrote:
> > On Thu, Apr 05, 2018 at 10:40:37AM +0100, George Dunlap wrote:
> >> On 04/05/2018 10:34 AM, Roger Pau Monné wrote:
> >>> On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote:
>  ... the same page with other registers which are not relevant to MSI-X. 
>  Xen
>  marks pages where PBA resides as read-only. When assigning such devices 
>  to
>  guest, device driver writes MSI-X irrelevant registers on those pages 
>  would
>  lead to an EPT violation and the guest is destroyed because no handler is
>  registered for those address range. In order to make guest capable to 
>  use such
>  kind of devices, trapping very frequent write accesses is not a good 
>  idea for
>  it would significantly impact the performance.
> 
>  This patch provides a workaround with caveat. Specifically, an option is
>  introduced to specify a list of devices. For those devices, Xen doesn't
>  control the access right to pages where PBA resides. Hence, guest device
>  driver is able to write those pages and functions well. Note that adding 
>  an
>  untrusted device to this option may endanger security of the entire 
>  system.
> 
>  Signed-off-by: Chao Gao 
>  ---
>   docs/misc/xen-command-line.markdown | 10 +
>   xen/arch/x86/msi.c  |  7 --
>   xen/drivers/passthrough/pci.c   | 45 
>  +++--
>   xen/include/asm-x86/msi.h   |  1 +
>   4 files changed, 59 insertions(+), 4 deletions(-)
> 
>  diff --git a/docs/misc/xen-command-line.markdown 
>  b/docs/misc/xen-command-line.markdown
>  index b353352..e382513 100644
>  --- a/docs/misc/xen-command-line.markdown
>  +++ b/docs/misc/xen-command-line.markdown
>  @@ -1423,6 +1423,16 @@ Defaults to booting secondary processors.
>   
>   > Default: `on`
>   
>  +### pba\_quirk
> >>>
> >>> pba_write_allowed would be better, pba_quirk is too generic IMO.
> >>
> >> 'quirk' was I think requested by Jan; and my understanding is that the
> >> word clearly indicates that the behavior in question is a workaround for
> >> hardware which is not compliant with the appropriate specification.  If
> >> you grep the source tree for 'quirk' you'll find a fairly large number.
> >>
> >> pba_shared_quirk might be slightly more descriptive.
> > 
> > pba_write_quirk?
> > 
> > I just think it should be slightly more descriptive than pba_quirk in
> > case Xen has to add further PBA-related quirks in the future.
> 
> "shared" tells you something about the quirk itself: The PBA is shared
> across multiple devices.  "write" tells you about the work-around:
> unsafe writes to the PBA region are allowed.

I don't think the PBA page is shared with multiple devices in any
case. The problem here is that the PBA page contains other registers
(from the same device as the PBA) that must be RW instead of RO.

Roger.

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

Re: [Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

[George Dunlap]

On 04/05/2018 10:46 AM, Roger Pau Monné wrote:
> On Thu, Apr 05, 2018 at 10:40:37AM +0100, George Dunlap wrote:
>> On 04/05/2018 10:34 AM, Roger Pau Monné wrote:
>>> On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote:
 ... the same page with other registers which are not relevant to MSI-X. Xen
 marks pages where PBA resides as read-only. When assigning such devices to
 guest, device driver writes MSI-X irrelevant registers on those pages would
 lead to an EPT violation and the guest is destroyed because no handler is
 registered for those address range. In order to make guest capable to use 
 such
 kind of devices, trapping very frequent write accesses is not a good idea 
 for
 it would significantly impact the performance.

 This patch provides a workaround with caveat. Specifically, an option is
 introduced to specify a list of devices. For those devices, Xen doesn't
 control the access right to pages where PBA resides. Hence, guest device
 driver is able to write those pages and functions well. Note that adding an
 untrusted device to this option may endanger security of the entire system.

 Signed-off-by: Chao Gao 
 ---
  docs/misc/xen-command-line.markdown | 10 +
  xen/arch/x86/msi.c  |  7 --
  xen/drivers/passthrough/pci.c   | 45 
 +++--
  xen/include/asm-x86/msi.h   |  1 +
  4 files changed, 59 insertions(+), 4 deletions(-)

 diff --git a/docs/misc/xen-command-line.markdown 
 b/docs/misc/xen-command-line.markdown
 index b353352..e382513 100644
 --- a/docs/misc/xen-command-line.markdown
 +++ b/docs/misc/xen-command-line.markdown
 @@ -1423,6 +1423,16 @@ Defaults to booting secondary processors.
  
  > Default: `on`
  
 +### pba\_quirk
>>>
>>> pba_write_allowed would be better, pba_quirk is too generic IMO.
>>
>> 'quirk' was I think requested by Jan; and my understanding is that the
>> word clearly indicates that the behavior in question is a workaround for
>> hardware which is not compliant with the appropriate specification.  If
>> you grep the source tree for 'quirk' you'll find a fairly large number.
>>
>> pba_shared_quirk might be slightly more descriptive.
> 
> pba_write_quirk?
> 
> I just think it should be slightly more descriptive than pba_quirk in
> case Xen has to add further PBA-related quirks in the future.

"shared" tells you something about the quirk itself: The PBA is shared
across multiple devices.  "write" tells you about the work-around:
unsafe writes to the PBA region are allowed.

I think it makes more sense for the name to describe the quirk itself
rather than the work-around.  The description says what the work-around
does and why it's unsafe.

 -George

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

Re: [Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

[Roger Pau Monné]

On Thu, Apr 05, 2018 at 10:40:37AM +0100, George Dunlap wrote:
> On 04/05/2018 10:34 AM, Roger Pau Monné wrote:
> > On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote:
> >> ... the same page with other registers which are not relevant to MSI-X. Xen
> >> marks pages where PBA resides as read-only. When assigning such devices to
> >> guest, device driver writes MSI-X irrelevant registers on those pages would
> >> lead to an EPT violation and the guest is destroyed because no handler is
> >> registered for those address range. In order to make guest capable to use 
> >> such
> >> kind of devices, trapping very frequent write accesses is not a good idea 
> >> for
> >> it would significantly impact the performance.
> >>
> >> This patch provides a workaround with caveat. Specifically, an option is
> >> introduced to specify a list of devices. For those devices, Xen doesn't
> >> control the access right to pages where PBA resides. Hence, guest device
> >> driver is able to write those pages and functions well. Note that adding an
> >> untrusted device to this option may endanger security of the entire system.
> >>
> >> Signed-off-by: Chao Gao 
> >> ---
> >>  docs/misc/xen-command-line.markdown | 10 +
> >>  xen/arch/x86/msi.c  |  7 --
> >>  xen/drivers/passthrough/pci.c   | 45 
> >> +++--
> >>  xen/include/asm-x86/msi.h   |  1 +
> >>  4 files changed, 59 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/docs/misc/xen-command-line.markdown 
> >> b/docs/misc/xen-command-line.markdown
> >> index b353352..e382513 100644
> >> --- a/docs/misc/xen-command-line.markdown
> >> +++ b/docs/misc/xen-command-line.markdown
> >> @@ -1423,6 +1423,16 @@ Defaults to booting secondary processors.
> >>  
> >>  > Default: `on`
> >>  
> >> +### pba\_quirk
> > 
> > pba_write_allowed would be better, pba_quirk is too generic IMO.
> 
> 'quirk' was I think requested by Jan; and my understanding is that the
> word clearly indicates that the behavior in question is a workaround for
> hardware which is not compliant with the appropriate specification.  If
> you grep the source tree for 'quirk' you'll find a fairly large number.
> 
> pba_shared_quirk might be slightly more descriptive.

pba_write_quirk?

I just think it should be slightly more descriptive than pba_quirk in
case Xen has to add further PBA-related quirks in the future.

Roger.

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

Re: [Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

[George Dunlap]

On 04/05/2018 10:34 AM, Roger Pau Monné wrote:
> On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote:
>> ... the same page with other registers which are not relevant to MSI-X. Xen
>> marks pages where PBA resides as read-only. When assigning such devices to
>> guest, device driver writes MSI-X irrelevant registers on those pages would
>> lead to an EPT violation and the guest is destroyed because no handler is
>> registered for those address range. In order to make guest capable to use 
>> such
>> kind of devices, trapping very frequent write accesses is not a good idea for
>> it would significantly impact the performance.
>>
>> This patch provides a workaround with caveat. Specifically, an option is
>> introduced to specify a list of devices. For those devices, Xen doesn't
>> control the access right to pages where PBA resides. Hence, guest device
>> driver is able to write those pages and functions well. Note that adding an
>> untrusted device to this option may endanger security of the entire system.
>>
>> Signed-off-by: Chao Gao 
>> ---
>>  docs/misc/xen-command-line.markdown | 10 +
>>  xen/arch/x86/msi.c  |  7 --
>>  xen/drivers/passthrough/pci.c   | 45 
>> +++--
>>  xen/include/asm-x86/msi.h   |  1 +
>>  4 files changed, 59 insertions(+), 4 deletions(-)
>>
>> diff --git a/docs/misc/xen-command-line.markdown 
>> b/docs/misc/xen-command-line.markdown
>> index b353352..e382513 100644
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -1423,6 +1423,16 @@ Defaults to booting secondary processors.
>>  
>>  > Default: `on`
>>  
>> +### pba\_quirk
> 
> pba_write_allowed would be better, pba_quirk is too generic IMO.

'quirk' was I think requested by Jan; and my understanding is that the
word clearly indicates that the behavior in question is a workaround for
hardware which is not compliant with the appropriate specification.  If
you grep the source tree for 'quirk' you'll find a fairly large number.

pba_shared_quirk might be slightly more descriptive.

 -George

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

Re: [Xen-devel] [PATCH v2 07/17] arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

[Julien Grall]

Hi,

On 02/04/18 12:17, Manish Jaggi wrote:



On 04/02/2018 04:33 PM, Manish Jaggi wrote:


On 03/27/2018 03:48 PM, Marc Zyngier wrote:

On 27/03/18 10:07, Manish Jaggi wrote:

This patch is ported to xen from linux commit
b6f49035b4bf6e2709f2a5fed3107f5438c1fd02
KVM: arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

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

Signed-off-by : Manish Jaggi 
---
  xen/arch/arm/arm64/vgic-v3-sr.c | 136 


  xen/include/asm-arm/arm64/sysregs.h |   1 +
  xen/include/asm-arm/gic_v3_defs.h   |   4 ++
  3 files changed, 141 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c 
b/xen/arch/arm/arm64/vgic-v3-sr.c

index 026d64506f..e32ec01f56 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -33,6 +33,7 @@
    #define ICC_IAR1_EL1_SPURIOUS    0x3ff
  #define VGIC_MAX_SPI 1019
+#define VGIC_MIN_LPI 8192
    static int vgic_v3_bpr_min(void)
  {
@@ -482,6 +483,137 @@ static void vreg_emulate_iar(struct 
cpu_user_regs *regs, const union hsr hsr)

  vgic_v3_read_iar(regs, hsr);
  }
  +static int vgic_v3_find_active_lr(int intid, uint64_t *lr_val)
+{
+    int i;
+    unsigned int used_lrs =  gic_get_num_lrs();

This is quite a departure from the existing code. KVM always allocate
LRs sequentially, and used_lrs represents the current upper bound.

IIUC, Xen uses a function gic_find_unused_lr to find an unused LR.

xen/arch/arm/gic.c:
gic_raise_guest_irq
    gic_find_unused_lr

Here,
you seem to be looking at *all* the LRs. Is that safe?
IIUC Xen does not maintain a used_lrs, it does have an lr_mask, but 
that is static in gic.c


To do something like
+for_each_set_bit(i, lr_mask, nr_lrs)
+ {
+  u64 val = __gic_v3_get_lr(i);
+  u8 lr_prio = (val & ICH_LR_PRIORITY_MASK) >> 
ICH_LR_PRIORITY_SHIFT;

+     /* Not pending in the state? */
+ if ((val & ICH_LR_STATE) != ICH_LR_PENDING_BIT)
+ continue;


I need to do some jugglery to make lr_mask visible outside of 
xen/arch/arm/gic.c
The easiest would be to add an extern function, harder way would be to 
add it in gic_hw_operations


- vgic_v3_highest_priority_lr iterates is interested in used LR's 
which sre in Pending state.

- emulating IAR is done with interrupts disabled
- iterating over all the LRs and finding which ones are in Pending.


Just to add I was answering for using num_lrs for used_lrs, above was 
for IAR flow.

This holds the same for EOIR flow as well.

The bigger point is unless I add some jugglery to access static value 
outside gic.c

this is the only solution.

Stefano/Andre/Julien
Please suggest if there is some better way...


lr_mask is already exported. So I am not sure what you need here.

However, despite the fact the variable is living in gic.c it is only 
used by the old vGIC. Newer vGIC is based on KVM, so used_lrs would be 
fine to use.


For the old vGIC, see below.


  Are you
guaranteed not to have any stale state?


LRs are zeroed when unused and AFAICT they should always be accurate. 
Stefano can you confirm it?


So it would be ok go through all the LRs (thought with a performance hit).

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] pci: a workaround for nonstandard PCI devices whose PBA shares

[Roger Pau Monné]

On Wed, Apr 04, 2018 at 11:29:39PM +0800, Chao Gao wrote:
> ... the same page with other registers which are not relevant to MSI-X. Xen
> marks pages where PBA resides as read-only. When assigning such devices to
> guest, device driver writes MSI-X irrelevant registers on those pages would
> lead to an EPT violation and the guest is destroyed because no handler is
> registered for those address range. In order to make guest capable to use such
> kind of devices, trapping very frequent write accesses is not a good idea for
> it would significantly impact the performance.
> 
> This patch provides a workaround with caveat. Specifically, an option is
> introduced to specify a list of devices. For those devices, Xen doesn't
> control the access right to pages where PBA resides. Hence, guest device
> driver is able to write those pages and functions well. Note that adding an
> untrusted device to this option may endanger security of the entire system.
> 
> Signed-off-by: Chao Gao 
> ---
>  docs/misc/xen-command-line.markdown | 10 +
>  xen/arch/x86/msi.c  |  7 --
>  xen/drivers/passthrough/pci.c   | 45 
> +++--
>  xen/include/asm-x86/msi.h   |  1 +
>  4 files changed, 59 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index b353352..e382513 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1423,6 +1423,16 @@ Defaults to booting secondary processors.
>  
>  > Default: `on`
>  
> +### pba\_quirk

pba_write_allowed would be better, pba_quirk is too generic IMO.

> +> `= List of [:]:.
> +
> +Specify a list of SBDF of devices. When assigning devices in this list to
> +guest, reading or writing the page where MSI-X PBA resides are allowed.
> +This option provides a workaround for nonstandard PCI devices whose
> +MSI-X PBA shares the same 4K-byte page with other registers. Note that
> +adding an untrusted device to this option would undermine security of
> +the entire system.
> +
>  ### pci
>  > `= {no-}serr | {no-}perr`
>  
> diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
> index 5567990..2abf2cf 100644
> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -992,7 +992,9 @@ static int msix_capability_init(struct pci_dev *dev,
>  if ( rangeset_add_range(mmio_ro_ranges, msix->table.first,
>  msix->table.last) )
>  WARN();
> -if ( rangeset_add_range(mmio_ro_ranges, msix->pba.first,
> +
> +if ( !msix->pba_quirk_enabled &&
> + rangeset_add_range(mmio_ro_ranges, msix->pba.first,
>  msix->pba.last) )
>  WARN();

This will work fine as long as the PBA is not in the same page as the
MSI-X table. In such case you will also need changes to QEMU (see
pci_msix_write), so that writes to the memory in the same page as the
MSI-X/PBA tables are forwarded to the underlying hardware.

You should add least add something like:

if ( msix->pba_quirk_enabled &&
 msix->table.first <= msix->pba.last &&
 msix->pba.first <= msix->table.last )
{
printk("PBA write not allowed to dev %04x:%02x:%02x.%u due to MSI-X table 
overlap\n");
return -ENXIO;
}

Or similar if the QEMU side is not fixed.

Note that in order to fix the QEMU side you would probably have to add
a flag to xl 'pci' config option and pass it to both QEMU and Xen.

>  
> @@ -1139,7 +1141,8 @@ static void _pci_cleanup_msix(struct arch_msix *msix)
>  if ( rangeset_remove_range(mmio_ro_ranges, msix->table.first,
> msix->table.last) )
>  WARN();
> -if ( rangeset_remove_range(mmio_ro_ranges, msix->pba.first,
> +if ( !msix->pba_quirk_enabled &&
> + rangeset_remove_range(mmio_ro_ranges, msix->pba.first,
> msix->pba.last) )
>  WARN();
>  }
> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
> index 1db69d5..cd765ef 100644
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -184,6 +184,38 @@ static int __init parse_phantom_dev(const char *str)
>  }
>  custom_param("pci-phantom", parse_phantom_dev);
>  
> +static struct pba_quirk_dev {
> +uint32_t sbdf;
> +} pba_quirk_devs[8];

We have a sbdf type now, see 514f58.

Also, I would prefer that you use a list here. I know it's not likely
to have a huge number of devices in the system that require this
quirk, but I also see no reason to limit this to 8 (or any other
arbitrary value).

> +static unsigned int nr_pba_quirk_devs;
> +
> +static int __init parse_pba_quirk(const char *str)
> +{
> +unsigned int seg, bus, dev, func;
> +
> +for ( ; ; )
> +{
> +if ( nr_pba_quirk_devs >= ARRAY_SIZE(pba_quirk_devs) )
> +return -E2BIG;
> +
> +str = parse_pci(str, , , 

[Xen-devel] [PATCH] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE

[Paul Durrant]

My recent Xen patch series introduces a new HYPERVISOR_memory_op to
support direct priv-mapping of certain guest resources (such as ioreq
pages, used by emulators) by a tools domain, rather than having to access
such resources via the guest P2M.

This patch adds the necessary infrastructure to the privcmd driver and
Xen MMU code to support direct resource mapping.

NOTE: The adjustment in the MMU code is partially cosmetic. Xen will now
  allow a PV tools domain to map guest pages either by GFN or MFN, thus
  the term 'gfn' has been swapped for 'pfn' in the lower layers of the
  remap code.

Signed-off-by: Paul Durrant 
---
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
---
 arch/x86/xen/mmu.c |  50 -
 drivers/xen/privcmd.c  | 119 +
 include/uapi/xen/privcmd.h |  11 
 include/xen/interface/memory.h |  67 +++
 include/xen/interface/xen.h|   7 +--
 include/xen/xen-ops.h  |  24 -
 6 files changed, 260 insertions(+), 18 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index d33e7dbe3129..8453d7be415c 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -65,37 +65,42 @@ static void xen_flush_tlb_all(void)
 #define REMAP_BATCH_SIZE 16
 
 struct remap_data {
-   xen_pfn_t *mfn;
+   xen_pfn_t *pfn;
bool contiguous;
+   bool no_translate;
pgprot_t prot;
struct mmu_update *mmu_update;
 };
 
-static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
+static int remap_area_pfn_pte_fn(pte_t *ptep, pgtable_t token,
 unsigned long addr, void *data)
 {
struct remap_data *rmd = data;
-   pte_t pte = pte_mkspecial(mfn_pte(*rmd->mfn, rmd->prot));
+   pte_t pte = pte_mkspecial(mfn_pte(*rmd->pfn, rmd->prot));
 
/* If we have a contiguous range, just update the mfn itself,
   else update pointer to be "next mfn". */
if (rmd->contiguous)
-   (*rmd->mfn)++;
+   (*rmd->pfn)++;
else
-   rmd->mfn++;
+   rmd->pfn++;
 
-   rmd->mmu_update->ptr = virt_to_machine(ptep).maddr | 
MMU_NORMAL_PT_UPDATE;
+   rmd->mmu_update->ptr = virt_to_machine(ptep).maddr;
+   rmd->mmu_update->ptr |= rmd->no_translate ?
+   MMU_PT_UPDATE_NO_TRANSLATE :
+   MMU_NORMAL_PT_UPDATE;
rmd->mmu_update->val = pte_val_ma(pte);
rmd->mmu_update++;
 
return 0;
 }
 
-static int do_remap_gfn(struct vm_area_struct *vma,
+static int do_remap_pfn(struct vm_area_struct *vma,
unsigned long addr,
-   xen_pfn_t *gfn, int nr,
+   xen_pfn_t *pfn, int nr,
int *err_ptr, pgprot_t prot,
-   unsigned domid,
+   unsigned int domid,
+   bool no_translate,
struct page **pages)
 {
int err = 0;
@@ -106,11 +111,12 @@ static int do_remap_gfn(struct vm_area_struct *vma,
 
BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
 
-   rmd.mfn = gfn;
+   rmd.pfn = pfn;
rmd.prot = prot;
/* We use the err_ptr to indicate if there we are doing a contiguous
 * mapping or a discontigious mapping. */
rmd.contiguous = !err_ptr;
+   rmd.no_translate = no_translate;
 
while (nr) {
int index = 0;
@@ -121,7 +127,7 @@ static int do_remap_gfn(struct vm_area_struct *vma,
 
rmd.mmu_update = mmu_update;
err = apply_to_page_range(vma->vm_mm, addr, range,
- remap_area_mfn_pte_fn, );
+ remap_area_pfn_pte_fn, );
if (err)
goto out;
 
@@ -175,7 +181,8 @@ int xen_remap_domain_gfn_range(struct vm_area_struct *vma,
if (xen_feature(XENFEAT_auto_translated_physmap))
return -EOPNOTSUPP;
 
-   return do_remap_gfn(vma, addr, , nr, NULL, prot, domid, pages);
+   return do_remap_pfn(vma, addr, , nr, NULL, prot, domid, false,
+   pages);
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_gfn_range);
 
@@ -183,7 +190,7 @@ int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
   unsigned long addr,
   xen_pfn_t *gfn, int nr,
   int *err_ptr, pgprot_t prot,
-  unsigned domid, struct page **pages)
+  unsigned int domid, struct page **pages)
 {
if (xen_feature(XENFEAT_auto_translated_physmap))
return xen_xlate_remap_gfn_array(vma, addr, gfn, nr, err_ptr,
@@ -194,10 +201,25 @@ int 

Re: [Xen-devel] Problem with Xen 4.7.5

[Ian Jackson]

Steven Haigh writes ("Re: Problem with Xen 4.7.5"):
> On 2018-04-05 03:22, Ian Jackson wrote:
> > Apologies for the inconvenience.
...
> I'm wondering if the severity of this is high enough that I should 
> withdraw the 4.7.5 packages from my repos.
> 
> Is this a show-stopper? Security issue? Dom0 crash?
> 
> I released 4.7.5 packages within an hour of the 4.7.5 release 
> announcement - so there are quite a few user systems that have already 
> grabbed them.

It's quite bad.  We don't understand the impact properly yet but it is
at least a domU crash in some situations.

I would withdraw the packages, yes.  Sorry.

Ian.

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

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

[Julien Grall]

On 20/03/18 20:24, Brijen Raval wrote:

Hello Julien,


Hello,


As requested I am moving the conversation to email from IRC

To summarize my setup:

1. I am running a custom kernel on QEMU ARM64(without KVM) on my linux 
machine

2. I have my custom implementation of Hypervisor
3. I am trying to run the same custom kernel as guest OS on top of my 
Hypervisor


- I am able to boot my kernel to shell on QEMU
- I am able to start my guest OS
- From the logs I see that my guest OS finishes booting up, I can see 
the $sign for the shell and then it goes into idle state, but I cannot 
use the shell


To debug further I enabled tracing in QEMU and printed the exceptions to 
understand what state is my guest in


Before I paste some logs here, some more information about my system

IRQ 30 is the physical timer interrupt of my host OS running on QEMU
IRQ 27 is the virtual timer interrupt of my guest OS

I have added some extra logging in QEMU to print out the VTTBR so as to 
understand where the exception is coming from


 From 1st Attachment (GIC 1) I observe that every once in a while the 
phys timer interrupt occurs (IRQ 30) and its handled by the host VM, and 
then after about 10-20 times the virtirq 27 level changes to 1 and back 
to 0 again and again..this is how its looping currently after boot up



Adding a 2nd attachment with extra logging of traps of exceptions as 
well. It just shows 2 different IRQ exceptions taken, one with VTTBR = 0 
(IRQ30) and other with a VTTBR value of the guest (IRQ 27, since the irq 
27 level is changed to 1 just before it..



Any idea what am I missing, and why my guest OS is not handling the 
pending interrupt.


Upon receiving the IRQ 27, I do set the HCR_EL2.VI  
bit to 1 to signal the guest about a pending virual interrupt but I dont 
think thats working.


HCR_EL2.VI should not be necessary is you are using the GIC HW 
virtualization extension. Can you confirm you are using it?


If so, I would recommend to look at the content of the LRs and checking 
you effectively have IRQ 27 pending in it.




Another thing I noticed that the qemu logging, never shows anything for 
the virt_interrupt.


What do you mean by "virt_interrupt"? is it a message QEMU is supposed 
to print when injecting interrupt to the guest?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 0/7] Fix warnings found by gcc 8

[Wei Liu]

On Thu, Apr 05, 2018 at 03:50:48AM +0200, Marek Marczykowski-Górecki wrote:
> A few patches enabling build with gcc 8.
> 
> Marek Marczykowski-Górecki (7):
>   tools/libxc: fix strncpy size
>   tools/misc: fix hypothetical buffer overflow in xen-lowmemd
>   tools/blktap2: fix hypothetical buffer overflow
>   tools/blktap2: fix possible '\0' truncation
>   tools/xenpmd: fix possible '\0' truncation
>   tools/gdbsx: fix -Wstringop-truncation warning
>   tools/kdd: mute spurious gcc warning

Acked-by: Wei Liu 

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

Re: [Xen-devel] Patches for stable

[Juergen Gross]

On 05/04/18 09:14, Greg KH wrote:
> On Thu, Apr 05, 2018 at 09:02:27AM +0200, Juergen Gross wrote:
>> On 05/04/18 08:33, Greg KH wrote:
>>> On Wed, Apr 04, 2018 at 06:32:17PM +0200, Juergen Gross wrote:
 On 04/04/18 17:42, Greg KH wrote:
> On Wed, Apr 04, 2018 at 05:12:32PM +0200, Juergen Gross wrote:
>> On 04/04/18 16:46, Greg KH wrote:
>>> On Wed, Apr 04, 2018 at 04:30:30PM +0200, Juergen Gross wrote:
 On 04/04/18 16:27, Greg KH wrote:
> On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote:
>> Please add the patches:
>>
>> commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
>> commit dfc9327ab7c99bc13e12106448615efba833886b upstream
>> commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream
>>
>> to the 4.15 and 4.16 stable kernels.
>>
>> Those patches are needed to boot Linux as PVH guest on recent Xen.
>
> So a new feature?  Why is that ok for stable kernels?

 It works for kernels since at least 4.11 on Xen 4.10.
>>>
>>> Great, so what commit caused this to fail?
>>>
>>> So far, in reading those commits, it sounds like they are "make Linux
>>> work again due to changes in Xen".  That sounds like a pretty bad thing
>>> that Xen did, why do we have to fix up their mess?
>>
>> Xen did nothing bad. It was the "old" kernel implementation which relied
>> on an assumption which happened to be true by accident. Xen had to be
>> changed in order to enable grub2 to support PVH mode.
>>
>> The PVH interface specifies that the RSDP address is available via the
>> start_info structure handed over to the PVH boot entry. The Linux kernel
>> didn't look at that address, but used the legacy method scanning low
>> memory for the RSDP table. As soon as Xen moved the RSDP to a higher
>> address (which is covered by the PVH interface specification) the kernel
>> could no longer be booted.
>>
>> So it was clearly a fault of the kernel not complying to the PVH
>> specification.
>
> But it worked previously, so you can't fault Linux here :)
>
> How many other operating systems broke with this change?

 None.

 BSD did it correctly. I guess Mini-OS doesn't count, as it is mostly
 Xen-internal, but it was not hit by this change.
>>>
>>> Xen doesn't support anything other than BSD, Linux, and Mini-OS? :)
>>
>> No other OS supports PVH mode so far.
>>
> Not at all.  We have a working kernel here.  Xen changed and broke
> working Linux systems.  Now I understand the goal of wanting to also
> change Linux to work properly, but these changes are really a new
> feature addition if you read the patches.

 We have a working kernel just by luck. Would your reasoning be the same
 if the kernel would use an EFI runtime service wrong and an EFI update
 would lead to a crash?
>>>
>>> If a UEFI/BIOS update broken working systems, first we would go yell at
>>> the BIOS engineers for doing something foolish (like I am doing here...)
>>> Then we would grumble and go fix the issue in the latest kernel version
>>> and tell people to update to a new release and never buy from that
>>> vendor ever again as they obviously do not care about their users.
>>
>> Even if the kernel wasn't using the EFI interfaces correctly and just
>> worked by accident? Sorry, that's ridiculous.
>>
>>> So, I'll gladly tell everyone who hits this bug, to stop using Xen as
>>> they don't care about their users, and to work around it they have to
>>> use the 4.17 kernel release.
>>
>> The kernel is wrong here. You don't want to take the patches fixing the
>> issue.
> 
> These are not just "patches to fix the issue", they are "patches to add
> new features" that touch core acpi bits, right?  Support for new
> hardware and platforms and such are not normally part of the stable
> kernel patches at all (with the exceptions of tiny patches that add
> device ids and quirks.)

The way the patches are written are the result of requests of the
maintainers (x86, acpi). This way they don't break layering of the
components. I'd be happy to rewrite them for stable kernels if you
like that better.

> That's my main objection here, combined with the obvious one of "Xen
> does not care about their users".

Xen does care. PVH support in Linux is relatively new (the first working
kernel was 4.11), Xen has full PVH guest support since Xen 4.10.

For being able to replace PV mode it is mandatory for PVH to not add
unnecessary performance overhead, as performance is the main reason for
customers to run their guests in PV mode (yes, PV guests _are_ faster,
especially with many vcpus).

It was discovered that placing the RSDP table in low memory is bad for
performance as it adds more memory map holes than necessary. So moving
the RSDP to the same memory area as all other ACPI tables was the
right 

Re: [Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-pvhv2-amd

[Sander Eikelenboom]

On 05/04/18 09:11, Juergen Gross wrote:
> On 03/04/18 18:55, Sander Eikelenboom wrote:
>> On 03/04/18 12:29, Juergen Gross wrote:
>>> On 03/04/18 12:19, osstest service owner wrote:
 branch xen-unstable
 xenbranch xen-unstable
 job test-amd64-amd64-xl-pvhv2-amd
 testid guest-start

 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:  xen git://xenbits.xen.org/xen.git
   Bug introduced:  4a5733771e6f33918eba07b584e564a67ac1
   Bug not present: 1c2e0f9e4f263714db917eb54f8d1c2d1463ed4c
   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/118498/


   commit 4a5733771e6f33918eba07b584e564a67ac1
   Author: Juergen Gross 
   Date:   Fri Dec 1 15:14:07 2017 +0100
   
   libxl: put RSDP for PVH guest near 4GB
   
   Instead of locating the RSDP table below 1MB put it just below 4GB
   like the rest of the ACPI tables in case of PVH guests. This will
   avoid punching more holes than necessary into the memory map.
   
   Signed-off-by: Juergen Gross 
   Acked-by: Wei Liu 
   Reviewed-by: Roger Pau Monné 
>>>
>>> The corresponding Linux kernel patch just made it upstream.
>>>
>>>
>>> Juergen
>>
>> Hi Juergen,
>>
>> Are those kernel patches heading for linux-stable as well ?
> 
> Greg refuses to take them, sorry.

I noticed the conversation, it's unfortunate but reality, thanks for the effort 
anyhow.
(perhaps a lesson for the future that if one intends to get a patch in stable 
as well, 
make the commit message indicate as clearly as possible that it is a kernel 
regression, 
to hopefully prevent a discussion from happening in the first place.)

Perhaps it is something for the release notes of xen-4.11 / wiki, 
that you require a 4.17+ (or distro patched) kernel for PVH ?

--
Sander

>> I ask this, because it would be nice to be able to use PVH on Xen 4.11 
>> release with a distro kernel
>> (4.9 or 4.14 stable for instance for Debian).
> 
> I think you have to request the distributor to take them (I'll add them
> to the SUSE kernel for SLE15 / openSUSE 15).
> 
>> PVH worked fine with xen-4.11-to-be up until this commit, so the kernel 
>> patches fix this (non-kernel) regression.
> 
> It _is_ a kernel regression, as the kernel wasn't using the PVH
> interface correctly.
> 
> 
> Juergen
> 


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

Re: [Xen-devel] Patches for stable

[Greg KH]

On Thu, Apr 05, 2018 at 09:02:27AM +0200, Juergen Gross wrote:
> On 05/04/18 08:33, Greg KH wrote:
> > On Wed, Apr 04, 2018 at 06:32:17PM +0200, Juergen Gross wrote:
> >> On 04/04/18 17:42, Greg KH wrote:
> >>> On Wed, Apr 04, 2018 at 05:12:32PM +0200, Juergen Gross wrote:
>  On 04/04/18 16:46, Greg KH wrote:
> > On Wed, Apr 04, 2018 at 04:30:30PM +0200, Juergen Gross wrote:
> >> On 04/04/18 16:27, Greg KH wrote:
> >>> On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote:
>  Please add the patches:
> 
>  commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
>  commit dfc9327ab7c99bc13e12106448615efba833886b upstream
>  commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream
> 
>  to the 4.15 and 4.16 stable kernels.
> 
>  Those patches are needed to boot Linux as PVH guest on recent Xen.
> >>>
> >>> So a new feature?  Why is that ok for stable kernels?
> >>
> >> It works for kernels since at least 4.11 on Xen 4.10.
> >
> > Great, so what commit caused this to fail?
> >
> > So far, in reading those commits, it sounds like they are "make Linux
> > work again due to changes in Xen".  That sounds like a pretty bad thing
> > that Xen did, why do we have to fix up their mess?
> 
>  Xen did nothing bad. It was the "old" kernel implementation which relied
>  on an assumption which happened to be true by accident. Xen had to be
>  changed in order to enable grub2 to support PVH mode.
> 
>  The PVH interface specifies that the RSDP address is available via the
>  start_info structure handed over to the PVH boot entry. The Linux kernel
>  didn't look at that address, but used the legacy method scanning low
>  memory for the RSDP table. As soon as Xen moved the RSDP to a higher
>  address (which is covered by the PVH interface specification) the kernel
>  could no longer be booted.
> 
>  So it was clearly a fault of the kernel not complying to the PVH
>  specification.
> >>>
> >>> But it worked previously, so you can't fault Linux here :)
> >>>
> >>> How many other operating systems broke with this change?
> >>
> >> None.
> >>
> >> BSD did it correctly. I guess Mini-OS doesn't count, as it is mostly
> >> Xen-internal, but it was not hit by this change.
> > 
> > Xen doesn't support anything other than BSD, Linux, and Mini-OS? :)
> 
> No other OS supports PVH mode so far.
> 
> >>> Not at all.  We have a working kernel here.  Xen changed and broke
> >>> working Linux systems.  Now I understand the goal of wanting to also
> >>> change Linux to work properly, but these changes are really a new
> >>> feature addition if you read the patches.
> >>
> >> We have a working kernel just by luck. Would your reasoning be the same
> >> if the kernel would use an EFI runtime service wrong and an EFI update
> >> would lead to a crash?
> > 
> > If a UEFI/BIOS update broken working systems, first we would go yell at
> > the BIOS engineers for doing something foolish (like I am doing here...)
> > Then we would grumble and go fix the issue in the latest kernel version
> > and tell people to update to a new release and never buy from that
> > vendor ever again as they obviously do not care about their users.
> 
> Even if the kernel wasn't using the EFI interfaces correctly and just
> worked by accident? Sorry, that's ridiculous.
> 
> > So, I'll gladly tell everyone who hits this bug, to stop using Xen as
> > they don't care about their users, and to work around it they have to
> > use the 4.17 kernel release.
> 
> The kernel is wrong here. You don't want to take the patches fixing the
> issue.

These are not just "patches to fix the issue", they are "patches to add
new features" that touch core acpi bits, right?  Support for new
hardware and platforms and such are not normally part of the stable
kernel patches at all (with the exceptions of tiny patches that add
device ids and quirks.)

That's my main objection here, combined with the obvious one of "Xen
does not care about their users".

> That's rather sad as PVH mode was meant to replace PV in the
> future, which will remove the need for most of the paravirt ops stuff.
> You are just shifting that possibility some months further into the
> future.

So if you run in PV mode, all is fine, right?  Great, then just use 4.17
or newer for PVH, what's the issue?  Who cares about this for older
kernel versions, those are all in running systems that would not be
changing their version of Xen.

But again, I still claim that Xen doesn't care about their users by
breaking existing systems, no matter if Linux was wrong or not.  That's
just how the world is, Linux has to handle stupid userspace programs,
and Xen needs to handle stupid operating system kernels, if those
projects which to succeed over time.

Personally, I use KVM and now will strongly recommend others do the
same.

thanks,

greg k-h

Re: [Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-pvhv2-amd

[Juergen Gross]

On 03/04/18 18:55, Sander Eikelenboom wrote:
> On 03/04/18 12:29, Juergen Gross wrote:
>> On 03/04/18 12:19, osstest service owner wrote:
>>> branch xen-unstable
>>> xenbranch xen-unstable
>>> job test-amd64-amd64-xl-pvhv2-amd
>>> testid guest-start
>>>
>>> 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:  xen git://xenbits.xen.org/xen.git
>>>   Bug introduced:  4a5733771e6f33918eba07b584e564a67ac1
>>>   Bug not present: 1c2e0f9e4f263714db917eb54f8d1c2d1463ed4c
>>>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/118498/
>>>
>>>
>>>   commit 4a5733771e6f33918eba07b584e564a67ac1
>>>   Author: Juergen Gross 
>>>   Date:   Fri Dec 1 15:14:07 2017 +0100
>>>   
>>>   libxl: put RSDP for PVH guest near 4GB
>>>   
>>>   Instead of locating the RSDP table below 1MB put it just below 4GB
>>>   like the rest of the ACPI tables in case of PVH guests. This will
>>>   avoid punching more holes than necessary into the memory map.
>>>   
>>>   Signed-off-by: Juergen Gross 
>>>   Acked-by: Wei Liu 
>>>   Reviewed-by: Roger Pau Monné 
>>
>> The corresponding Linux kernel patch just made it upstream.
>>
>>
>> Juergen
> 
> Hi Juergen,
> 
> Are those kernel patches heading for linux-stable as well ?

Greg refuses to take them, sorry.

> I ask this, because it would be nice to be able to use PVH on Xen 4.11 
> release with a distro kernel
> (4.9 or 4.14 stable for instance for Debian).

I think you have to request the distributor to take them (I'll add them
to the SUSE kernel for SLE15 / openSUSE 15).

> PVH worked fine with xen-4.11-to-be up until this commit, so the kernel 
> patches fix this (non-kernel) regression.

It _is_ a kernel regression, as the kernel wasn't using the PVH
interface correctly.


Juergen

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

[Xen-devel] [xen-4.7-testing test] 121758: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  dca80abc2075a54fec58344751357021b3b5b39e
baseline version:
 xen  4bfe39fc2022b4ea6878696cda6a5594728d425d

Last test of basis   121247  2018-03-25 04:03:47 Z 

Re: [Xen-devel] Patches for stable

[Juergen Gross]

On 05/04/18 08:33, Greg KH wrote:
> On Wed, Apr 04, 2018 at 06:32:17PM +0200, Juergen Gross wrote:
>> On 04/04/18 17:42, Greg KH wrote:
>>> On Wed, Apr 04, 2018 at 05:12:32PM +0200, Juergen Gross wrote:
 On 04/04/18 16:46, Greg KH wrote:
> On Wed, Apr 04, 2018 at 04:30:30PM +0200, Juergen Gross wrote:
>> On 04/04/18 16:27, Greg KH wrote:
>>> On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote:
 Please add the patches:

 commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
 commit dfc9327ab7c99bc13e12106448615efba833886b upstream
 commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream

 to the 4.15 and 4.16 stable kernels.

 Those patches are needed to boot Linux as PVH guest on recent Xen.
>>>
>>> So a new feature?  Why is that ok for stable kernels?
>>
>> It works for kernels since at least 4.11 on Xen 4.10.
>
> Great, so what commit caused this to fail?
>
> So far, in reading those commits, it sounds like they are "make Linux
> work again due to changes in Xen".  That sounds like a pretty bad thing
> that Xen did, why do we have to fix up their mess?

 Xen did nothing bad. It was the "old" kernel implementation which relied
 on an assumption which happened to be true by accident. Xen had to be
 changed in order to enable grub2 to support PVH mode.

 The PVH interface specifies that the RSDP address is available via the
 start_info structure handed over to the PVH boot entry. The Linux kernel
 didn't look at that address, but used the legacy method scanning low
 memory for the RSDP table. As soon as Xen moved the RSDP to a higher
 address (which is covered by the PVH interface specification) the kernel
 could no longer be booted.

 So it was clearly a fault of the kernel not complying to the PVH
 specification.
>>>
>>> But it worked previously, so you can't fault Linux here :)
>>>
>>> How many other operating systems broke with this change?
>>
>> None.
>>
>> BSD did it correctly. I guess Mini-OS doesn't count, as it is mostly
>> Xen-internal, but it was not hit by this change.
> 
> Xen doesn't support anything other than BSD, Linux, and Mini-OS? :)

No other OS supports PVH mode so far.

>>> Not at all.  We have a working kernel here.  Xen changed and broke
>>> working Linux systems.  Now I understand the goal of wanting to also
>>> change Linux to work properly, but these changes are really a new
>>> feature addition if you read the patches.
>>
>> We have a working kernel just by luck. Would your reasoning be the same
>> if the kernel would use an EFI runtime service wrong and an EFI update
>> would lead to a crash?
> 
> If a UEFI/BIOS update broken working systems, first we would go yell at
> the BIOS engineers for doing something foolish (like I am doing here...)
> Then we would grumble and go fix the issue in the latest kernel version
> and tell people to update to a new release and never buy from that
> vendor ever again as they obviously do not care about their users.

Even if the kernel wasn't using the EFI interfaces correctly and just
worked by accident? Sorry, that's ridiculous.

> So, I'll gladly tell everyone who hits this bug, to stop using Xen as
> they don't care about their users, and to work around it they have to
> use the 4.17 kernel release.

The kernel is wrong here. You don't want to take the patches fixing the
issue. That's rather sad as PVH mode was meant to replace PV in the
future, which will remove the need for most of the paravirt ops stuff.
You are just shifting that possibility some months further into the
future.

I won't fight against you any longer.


Juergen

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

Re: [Xen-devel] Patches for stable

[Greg KH]

On Wed, Apr 04, 2018 at 06:32:17PM +0200, Juergen Gross wrote:
> On 04/04/18 17:42, Greg KH wrote:
> > On Wed, Apr 04, 2018 at 05:12:32PM +0200, Juergen Gross wrote:
> >> On 04/04/18 16:46, Greg KH wrote:
> >>> On Wed, Apr 04, 2018 at 04:30:30PM +0200, Juergen Gross wrote:
>  On 04/04/18 16:27, Greg KH wrote:
> > On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote:
> >> Please add the patches:
> >>
> >> commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
> >> commit dfc9327ab7c99bc13e12106448615efba833886b upstream
> >> commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream
> >>
> >> to the 4.15 and 4.16 stable kernels.
> >>
> >> Those patches are needed to boot Linux as PVH guest on recent Xen.
> >
> > So a new feature?  Why is that ok for stable kernels?
> 
>  It works for kernels since at least 4.11 on Xen 4.10.
> >>>
> >>> Great, so what commit caused this to fail?
> >>>
> >>> So far, in reading those commits, it sounds like they are "make Linux
> >>> work again due to changes in Xen".  That sounds like a pretty bad thing
> >>> that Xen did, why do we have to fix up their mess?
> >>
> >> Xen did nothing bad. It was the "old" kernel implementation which relied
> >> on an assumption which happened to be true by accident. Xen had to be
> >> changed in order to enable grub2 to support PVH mode.
> >>
> >> The PVH interface specifies that the RSDP address is available via the
> >> start_info structure handed over to the PVH boot entry. The Linux kernel
> >> didn't look at that address, but used the legacy method scanning low
> >> memory for the RSDP table. As soon as Xen moved the RSDP to a higher
> >> address (which is covered by the PVH interface specification) the kernel
> >> could no longer be booted.
> >>
> >> So it was clearly a fault of the kernel not complying to the PVH
> >> specification.
> > 
> > But it worked previously, so you can't fault Linux here :)
> > 
> > How many other operating systems broke with this change?
> 
> None.
> 
> BSD did it correctly. I guess Mini-OS doesn't count, as it is mostly
> Xen-internal, but it was not hit by this change.

Xen doesn't support anything other than BSD, Linux, and Mini-OS? :)

> > Not at all.  We have a working kernel here.  Xen changed and broke
> > working Linux systems.  Now I understand the goal of wanting to also
> > change Linux to work properly, but these changes are really a new
> > feature addition if you read the patches.
> 
> We have a working kernel just by luck. Would your reasoning be the same
> if the kernel would use an EFI runtime service wrong and an EFI update
> would lead to a crash?

If a UEFI/BIOS update broken working systems, first we would go yell at
the BIOS engineers for doing something foolish (like I am doing here...)
Then we would grumble and go fix the issue in the latest kernel version
and tell people to update to a new release and never buy from that
vendor ever again as they obviously do not care about their users.

So, I'll gladly tell everyone who hits this bug, to stop using Xen as
they don't care about their users, and to work around it they have to
use the 4.17 kernel release.

There, that was simple :)

thanks,

greg k-h

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

Re: [Xen-devel] [PATCH v4 7/7] xen/x86: use PCID feature

[Juergen Gross]

On 03/04/18 09:14, Juergen Gross wrote:
> On 29/03/18 17:37, Jan Beulich wrote:
> On 29.03.18 at 17:15,  wrote:
>>> On 29/03/18 16:19, Jan Beulich wrote:
>>> On 27.03.18 at 11:07,  wrote:
> @@ -102,7 +103,21 @@ void write_cr3_cr4(unsigned long cr3, unsigned long 
> cr4)
>  t = pre_flush();
>  
>  if ( read_cr4() & X86_CR4_PGE )
> +/*
> + * X86_CR4_PGE set means PCID being inactive.
> + * We have to purge the TLB via flipping cr4.pge.
> + */
>  write_cr4(cr4 & ~X86_CR4_PGE);
> +else if ( cpu_has_invpcid )
> +/*
> + * If we are using PCID purge the TLB via INVPCID as loading cr3
> + * will affect the current PCID only.

 s/current/new/ ?
>>>
>>> Okay.
>>>

> + * If INVPCID is not supported we don't use PCIDs so loading cr3
> + * will purge the TLB (we are in the "global pages off" branch).
> + * invpcid_flush_all_nonglobals() seems to be faster than
> + * invpcid_flush_all().
> + */
> +invpcid_flush_all_nonglobals();
>  
>  asm volatile ( "mov %0, %%cr3" : : "r" (cr3) : "memory" );

 What about the TLB entries that have been re-created between
 the INVPCID and the write of CR3? It's not obvious to me that
 leaving them around is not going to be a problem subsequently,
 the more that you write cr3 frequently with the no-flush bit set.
>>>
>>> The no-flush bit should not make any difference here. It controls only
>>> flushing of TLB-entries with the new PCID.
>>
>> Right, but in a subsequent write to CR3 you may make active again
>> what was the old PCID here. This is in particular so for PCID 0 (which
>> has dual use).
>>
 Don't you need to do a single context invalidation for the prior
 PCID (if different from the new one)?
>>>
>>> Hmm, I don't think so, as the mov to %cr3 is a serializing instruction
>>> acting as a speculation barrier. So the only TLB entries which could
>>> survive would be the ones for the few instruction bytes after the
>>> invpcid instruction until the end of the mov to %cr3. Those are harmless
>>> as they are associated with the hypervisor PCID value, so there is no
>>> risk of any data leak to a guest. Maybe a comment explaining that would
>>> be a good idea.
>>
>> Well, to be honest I don't trust in things like "speculation barrier"
>> anymore, at least not as far as things ahead of the barrier go.
>> Who knows what exactly the CPU does (and hence which TLB
>> entries it creates) between the INVPCID and the CR3 write. I
>> don't think we can blindly assume only entries for Xen mappings
>> could be created during that window.
> 
> Those speculation barriers are one of the main mitigations for Spectre.
> So either we don't think Spectre can be mitigated by using those or we
> should trust the barriers to be effective in this case, too, IMHO.
> 
> Which documented behavior of the processor are you going to trust? I
> think as long as there are no known errata in this regard we should
> assume the cpu will behave as documented. And mv to %cr3 is documented
> to be serializing nad serializing instruction are documented to be
> speculation barriers.

I have done my standard simple performance test with an extra
invpcid_flush_single_context() added in case the PCID changed in
write_cr3_cr4().

Performance impact seems to be neglectible. OTOH this isn't really
surprising as the only case where the additional flush would be needed
is the case of vcpu scheduling when PCIDs are different: either the
old or the new vcpu (not both) need to be in user mode of a XPTI domain.
Guest address space switches will always happen with PCID 0 (guest is in
kernel).

So I'm adding the additional flush to the patch. Better save than sorry.


Juergen

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

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

[osstest service owner]

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

Regressions :-(

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

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

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

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


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

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



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

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

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

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


Not pushing.


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

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

Fix linking on Debian Stretch (gcc-6)

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

Add further -no-pie checks to Rumprun build tools

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

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

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

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

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

Make the disabling of the fallthrough warning dependent on GCC version

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

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

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

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

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

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

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

Fix linking on Debian Stretch

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

Signed-off-by: Wei Liu 

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