date:20180313

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

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  3266b5bd97eaa72793df0b6e5a106c69ccc166c4
  Bug not present: 5b7d27967dabfb17c21b0d98b29153b9e3ee71e5
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/120713/


  (Revision log too long, omitted.)


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-qemut-rhel6hvm-intel.xen-boot
 --summary-out=tmp/120713.bisection-summary --basis-template=118324 
--blessings=real,real-bisect linux-linus test-amd64-i386-qemut-rhel6hvm-intel 
xen-boot
Searching for failure / basis pass:
 120441 fail [host=chardonnay1] / 118629 [host=italia0] 118598 
[host=huxelrebe0] 118586 [host=baroque1] 118576 [host=fiano1] 118566 
[host=huxelrebe1] 118556 [host=italia1] 118538 [host=elbling1] 118501 
[host=italia0] 118464 [host=chardonnay0] 118445 [host=baroque0] 118428 
[host=elbling0] 118401 [host=fiano0] 118362 [host=huxelrebe0] 118324 ok.
Failure / basis pass flights: 120441 / 118324
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 3266b5bd97eaa72793df0b6e5a106c69ccc166c4 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5c3fdee026a204a59cb392e43a313ab558de9682 
a823a5280f25ad19a751dd9a41044f556471e61a
Basis pass 5b7d27967dabfb17c21b0d98b29153b9e3ee71e5 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
e871e80c38547d9faefc6604532ba3e985e65873
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#5b7d27967dabfb17c21b0d98b29153b9e3ee71e5-3266b5bd97eaa72793df0b6e5a106c69ccc166c4
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
 
git://xenbits.xen.org/qemu-xen.git#2b033e396f4fa0981bae1213cdacd15775655a97-5c3fdee026a204a59cb392e43a313ab558de9682
 
git://xenbits.xen.org/xen.git#e871e80c38547d9faefc6604532ba3e985e65873-a823a5280f25ad19a751dd9a41044f556471e61a
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 5329 nodes in revision graph
Searching for test results:
 118112 [host=chardonnay0]
 118215 [host=fiano0]
 118250 [host=baroque0]
 118276 [host=italia0]
 118283 [host=elbling1]
 118324 pass 5b7d27967dabfb17c21b0d98b29153b9e3ee71e5 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
e871e80c38547d9faefc6604532ba3e985e65873
 118445 [host=baroque0]
 118362 [host=huxelrebe0]
 118401 [host=fiano0]
 118428 [host=elbling0]
 118464 [host=chardonnay0]
 118538 [host=elbling1]
 118501 [host=italia0]
 118556 [host=italia1]
 118566 [host=huxelrebe1]
 118576 [host=fiano1]
 118586 [host=baroque1]
 118629 [host=italia0]
 118598 [host=huxelrebe0]
 118638 fail irrelevant
 118672 fail irrelevant
 118775 fail irrelevant
 118893 fail irrelevant
 118968 fail irrelevant
 119064 fail irrelevant
 119117 fail irrelevant
 119201 fail irrelevant
 119350 fail irrelevant
 119435 fail irrelevant
 119511 fail irrelevant
 119582 fail irrelevant
 119639 fail irrelevant
 119687 fail irrelevant
 119751 fail irrelevant
 119922 fail irrelevant
 119992 fail irrelevant
 120022 fail irrelevant
 120055 fail irrelevant
 120092 fail irrelevant
 120228 fail irrelevant
 120305 fail irrelevant
 120269 fail irrelevant
 120505 pass 5b7d27967dabfb17c21b0d98b29153b9e3ee71e5 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
e871e80c38547d9faefc6604532ba3e985e65873
 120518 fail irrelevant
 120533 pass 5b7d27967dabfb17c21b0d98b29153b9e3ee71e5 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60

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

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

Regressions :-(

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

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  a7313da7f7767984172873adf645eff9bd667bda
baseline version:
 xen  eef83fd2af0d4c78afec34c199c977fc97d8a0b3

Last test of basis   120679  2018-03-13 12:06:56 Z0 days
Testing same since   120685  2018-03-13 17:01:17 Z0 days4 attempts


People who touched revisions under test:
  Doug Goldstein 
  Michael Young 
  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 a7313da7f7767984172873adf645eff9bd667bda
Author: Doug Goldstein 
Date:   Tue Mar 13 11:25:29 2018 -0500

tools/xl: fix uninitialized variable in xl_vdispl

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

Signed-off-by: Doug Goldstein 
Acked-by: Wei Liu 

commit 9f3b40e8fe083e0d6d184c105f96ad9b9617f038
Author: Michael Young 
Date:   Mon Mar 12 18:49:29 2018 +

make xen ocaml safe-strings compliant

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

Signed-off-by: Michael Young 
Reviewed-by: Christian Lindig

commit b43501451733193b265de30fd79a764363a2a473
Author: Doug Goldstein 
Date:   Mon Mar 12 23:06:51 2018 -0500

tools: detect appropriate debug optimization level

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

Signed-off-by: Doug Goldstein 
Acked-by: Wei Liu 
(qemu changes not included)

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

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

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

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-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  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  360 days
Testing same since   120360  2018-03-09 04:19:20 Z4 days4 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

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

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:  b43501451733193b265de30fd79a764363a2a473
  Bug not present: eef83fd2af0d4c78afec34c199c977fc97d8a0b3
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/120707/


  commit b43501451733193b265de30fd79a764363a2a473
  Author: Doug Goldstein 
  Date:   Mon Mar 12 23:06:51 2018 -0500
  
  tools: detect appropriate debug optimization level
  
  When building debug use -Og as the optimization level if its available,
  otherwise retain the use of -O0. -Og has been added by GCC to enable all
  optimizations that to not affect debugging while retaining full
  debugability.
  
  Signed-off-by: Doug Goldstein 
  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/120707.bisection-summary --basis-template=120679 
--blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build
Searching for failure / basis pass:
 120699 fail [host=laxton1] / 120679 ok.
Failure / basis pass flights: 120699 / 120679
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 5c3fdee026a204a59cb392e43a313ab558de9682 
a7313da7f7767984172873adf645eff9bd667bda
Basis pass 5c3fdee026a204a59cb392e43a313ab558de9682 
eef83fd2af0d4c78afec34c199c977fc97d8a0b3
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen.git#5c3fdee026a204a59cb392e43a313ab558de9682-5c3fdee026a204a59cb392e43a313ab558de9682
 
git://xenbits.xen.org/xen.git#eef83fd2af0d4c78afec34c199c977fc97d8a0b3-a7313da7f7767984172873adf645eff9bd667bda
Loaded 1001 nodes in revision graph
Searching for test results:
 120689 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
a7313da7f7767984172873adf645eff9bd667bda
 120679 pass 5c3fdee026a204a59cb392e43a313ab558de9682 
eef83fd2af0d4c78afec34c199c977fc97d8a0b3
 120687 pass 5c3fdee026a204a59cb392e43a313ab558de9682 
eef83fd2af0d4c78afec34c199c977fc97d8a0b3
 120685 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
a7313da7f7767984172873adf645eff9bd667bda
 120688 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
a7313da7f7767984172873adf645eff9bd667bda
 120693 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
b43501451733193b265de30fd79a764363a2a473
 120701 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
b43501451733193b265de30fd79a764363a2a473
 120696 pass 5c3fdee026a204a59cb392e43a313ab558de9682 
eef83fd2af0d4c78afec34c199c977fc97d8a0b3
 120699 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
a7313da7f7767984172873adf645eff9bd667bda
 120703 pass 5c3fdee026a204a59cb392e43a313ab558de9682 
eef83fd2af0d4c78afec34c199c977fc97d8a0b3
 120707 fail 5c3fdee026a204a59cb392e43a313ab558de9682 
b43501451733193b265de30fd79a764363a2a473
Searching for interesting versions
 Result found: flight 120679 (pass), for basis pass
 Result found: flight 120685 (fail), for basis failure
 Repro found: flight 120687 (pass), for basis pass
 Repro found: flight 120688 (fail), for basis failure
 0 revisions at 5c3fdee026a204a59cb392e43a313ab558de9682 
eef83fd2af0d4c78afec34c199c977fc97d8a0b3
No revisions left to test, checking graph state.
 Result found: flight 120679 (pass), for last pass
 Result found: flight 120693 (fail), for first failure
 Repro found: flight 120696 (pass), for last pass
 Repro found: flight 120701 (fail), for first failure
 Repro found: flight 120703 (pass), for last pass
 Repro found: flight 120707 (fail), for first failure

*** Found and reproduced problem changeset ***

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


  commit b43501451733193b265de30fd79a764363a2a473
  Author: Doug Goldstein 
  Date:   Mon Mar 12 23:06:51 2018 -0500
  
  tools: detect appropriate debug optimization level
  
  When building debug use -Og as the optimization level if its available,
  otherwise retain the use of -O0. -Og has been added by GCC to enable all
  optimizations that to not affect debugging while retaining full
  debugability.
  
  Signed-off-by: Doug Goldstein 
  Acked-by: Wei Liu 

Revision graph left in

Re: [Xen-devel] [PATCH] xenbaked.c: Avoid divide by zero issue on dump_stats()

2018-03-13 Thread Konrad Rzeszutek Wilk

On Tue, Mar 13, 2018 at 06:38:24PM -0700, Joe Jin wrote:
> run_time on dump_stats() maybe zero if break xenmon.py immediately after it

s/maybe/can be/
> started, then xenbaked hit divide by zero fault.

And:

"Note that run_time is computed using two values which are retrieved using 
'time'
system call which gives us resolution in seconds."

> 
> Signed-off-by: Joe Jin 
> Signed-off-by: Konrad Rzeszutek Wilk 
> Cc: Wei Liu 
> Cc: Ian Campbell 
> ---
>  tools/xenmon/xenbaked.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/xenmon/xenbaked.c b/tools/xenmon/xenbaked.c
> index 3d9e0ed900..d3f940a26b 100644
> --- a/tools/xenmon/xenbaked.c
> +++ b/tools/xenmon/xenbaked.c
> @@ -243,10 +243,12 @@ static void dump_stats(void)
>  }
>  
>  printf("processed %d total records in %d seconds (%ld per second)\n",
> -   rec_count, (int)run_time, (long)(rec_count/run_time));
> +   rec_count, (int)run_time,
> +   run_time ? (long)(rec_count/run_time) : 0L);
>  
> -printf("woke up %d times in %d seconds (%ld per second)\n", wakeups,
> -(int) run_time, (long)(wakeups/run_time));
> +printf("woke up %d times in %d seconds (%ld per second)\n",
> +   wakeups, (int) run_time,
> +   run_time ? (long)(wakeups/run_time) : 0L);
>  
>  check_gotten_sum();
>  }
> -- 
> 2.14.3 (Apple Git-98)
> 

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

[Xen-devel] [PATCH] xenbaked.c: Avoid divide by zero issue on dump_stats()

2018-03-13 Thread Joe Jin

run_time on dump_stats() maybe zero if break xenmon.py immediately after it
started, then xenbaked hit divide by zero fault.

Signed-off-by: Joe Jin 
Signed-off-by: Konrad Rzeszutek Wilk 
Cc: Wei Liu 
Cc: Ian Campbell 
---
 tools/xenmon/xenbaked.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/xenmon/xenbaked.c b/tools/xenmon/xenbaked.c
index 3d9e0ed900..d3f940a26b 100644
--- a/tools/xenmon/xenbaked.c
+++ b/tools/xenmon/xenbaked.c
@@ -243,10 +243,12 @@ static void dump_stats(void)
 }
 
 printf("processed %d total records in %d seconds (%ld per second)\n",
-   rec_count, (int)run_time, (long)(rec_count/run_time));
+   rec_count, (int)run_time,
+   run_time ? (long)(rec_count/run_time) : 0L);
 
-printf("woke up %d times in %d seconds (%ld per second)\n", wakeups,
-  (int) run_time, (long)(wakeups/run_time));
+printf("woke up %d times in %d seconds (%ld per second)\n",
+   wakeups, (int) run_time,
+   run_time ? (long)(wakeups/run_time) : 0L);
 
 check_gotten_sum();
 }
-- 
2.14.3 (Apple Git-98)


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

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

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

Regressions :-(

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

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  a7313da7f7767984172873adf645eff9bd667bda
baseline version:
 xen  eef83fd2af0d4c78afec34c199c977fc97d8a0b3

Last test of basis   120679  2018-03-13 12:06:56 Z0 days
Testing same since   120685  2018-03-13 17:01:17 Z0 days3 attempts


People who touched revisions under test:
  Doug Goldstein 
  Michael Young 
  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 a7313da7f7767984172873adf645eff9bd667bda
Author: Doug Goldstein 
Date:   Tue Mar 13 11:25:29 2018 -0500

tools/xl: fix uninitialized variable in xl_vdispl

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

Signed-off-by: Doug Goldstein 
Acked-by: Wei Liu 

commit 9f3b40e8fe083e0d6d184c105f96ad9b9617f038
Author: Michael Young 
Date:   Mon Mar 12 18:49:29 2018 +

make xen ocaml safe-strings compliant

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

Signed-off-by: Michael Young 
Reviewed-by: Christian Lindig

commit b43501451733193b265de30fd79a764363a2a473
Author: Doug Goldstein 
Date:   Mon Mar 12 23:06:51 2018 -0500

tools: detect appropriate debug optimization level

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

Signed-off-by: Doug Goldstein 
Acked-by: Wei Liu 
(qemu changes not included)

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

[Xen-devel] [xen-4.10-testing test] 120559: regressions - FAIL

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 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-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-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  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-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-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  0d2f9c89f77ad0342d38c88377ef97b3a1337c7d
baseline version:
 xen  b6a6458b13dc6f04e17620447a760ff70b1eb4c6

Last test of basis   120244  2018-03-04 20:58:36 Z9 days
Failing since120284  2018-03-06 15:09:01 Z7 days4 attempts
Testing same since   120352  2018-03-08 15:44:13 Z5 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Haozhong Zhang 
  Ian Jackson 
  Igor Druzhinin 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Lv Zheng 
  Michael Young 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau MonnÃ© 
  Ross Lagerwall 
  Sergey Dyasli 
  Wei Liu 

jobs:

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

2018-03-13 Thread Andrew Cooper

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

I'll do a proper fix tomorrow.

This bug only manifests when we service an int80, and then the next
action the vcpu undergoes (including event delivery, which has a side
effect of squashing the bug) is an exception which gets fixed up via
emulation.  Under these circumstances, we deliver the int80 a second
time on the way

Re: [Xen-devel] [PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

2018-03-13 Thread kbuild test robot

Hi Oleksandr,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.16-rc5 next-20180313]
[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/Oleksandr-Andrushchenko/drm-xen-front-Add-support-for-Xen-PV-display-frontend/20180314-014856
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/xen/xen_drm_front.c:420:29: sparse: symbol 
>> 'xen_drm_front_platform_info' was not declared. Should it be static?
--
>> drivers/gpu/drm/xen/xen_drm_front_drv.c:125:19: sparse: symbol 
>> 'xen_drm_driver' was not declared. Should it be static?

Please review and possibly fold the followup patch.

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

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

[Xen-devel] [RFC PATCH] drm/xen-front: xen_drm_front_platform_info can be static

2018-03-13 Thread kbuild test robot


Fixes: db81084f9084 ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Fengguang Wu 
---
 xen_drm_front.c |2 +-
 xen_drm_front_drv.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index dbabdf9..f421d23 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -417,7 +417,7 @@ static int xen_drm_drv_remove(struct platform_device *pdev)
return xen_drm_front_drv_remove(pdev);
 }
 
-struct platform_device_info xen_drm_front_platform_info = {
+static struct platform_device_info xen_drm_front_platform_info = {
.name = XENDISPL_DRIVER_NAME,
.id = 0,
.num_res = 0,
diff --git a/drivers/gpu/drm/xen/xen_drm_front_drv.c 
b/drivers/gpu/drm/xen/xen_drm_front_drv.c
index 3edefa2..04ee389 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_drv.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_drv.c
@@ -122,7 +122,7 @@ static const struct vm_operations_struct xen_drm_vm_ops = {
.close  = drm_gem_vm_close,
 };
 
-struct drm_driver xen_drm_driver = {
+static struct drm_driver xen_drm_driver = {
.driver_features   = DRIVER_GEM | DRIVER_MODESET |
 DRIVER_PRIME | DRIVER_ATOMIC,
.lastclose = lastclose,

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

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

2018-03-13 Thread Alexey G

On Mon, 12 Mar 2018 18:44:02 -0300
Eduardo Habkost  wrote:

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

HVM_MAX_VCPUS is 128 currently, but there is an ongoing work from Intel
to support more vcpus and >8bit APIC IDs, so this number will likely
change soon.

According to the code, using HVM_MAX_VCPUS in QEMU is a bit excessive as
the maximum number of vcpus is controlled on Xen side anyway. Currently
HVM_MAX_VCPUS is used in a one-time check for the maxcpus value (which
itself comes from libxl).
I think for future compatibility it's better to set mc->max_cpus to
HVM_MAX_VCPUS for all accel=xen HVM-supported machine types, not just
xenfv.

The '-device' approach you suggested seems more preferable than a
machine bool property, I'll try switching to it.

>Is HVM_MAX_CPUS something that needs to be enabled because of
>accel=xen or because or the xen-platform device?
>
>If it's just because of accel=xen, we could introduce a
>AccelClass::max_cpus() method (we also have KVM-imposed CPU count
>limits, currently implemented inside kvm_init()).

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

[Xen-devel] [PATCH v2 2/4] libxl: Move libxl__arch_domain_construct_memmap() earlier

From: Boris Ostrovsky 

Since hvm_start_info has now been expanded to include PVH guest's
memory map (i.e. e820) we need to know size of this map by the time we
create dom->start_info_seg in alloc_magic_pages_hvm().

To do so we have to call libxl__arch_domain_construct_memmap() earlier,
before xc_dom_build_image().

Signed-off-by: Boris Ostrovsky 
---
 tools/libxl/libxl_create.c   |  2 +-
 tools/libxl/libxl_dom.c  | 12 +---
 tools/libxl/libxl_internal.h |  1 +
 tools/libxl/libxl_x86.c  |  3 +++
 4 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index c498135..5dce3df 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -488,7 +488,7 @@ int libxl__domain_build(libxl__gc *gc,
 
 break;
 case LIBXL_DOMAIN_TYPE_PV:
-ret = libxl__build_pv(gc, domid, info, state);
+ret = libxl__build_pv(gc, domid, d_config, info, state);
 if (ret)
 goto out;
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 2e29b52..917b45e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -698,6 +698,7 @@ static int set_vnuma_info(libxl__gc *gc, uint32_t domid,
 }
 
 static int libxl__build_dom(libxl__gc *gc, uint32_t domid,
+ libxl_domain_config *d_config,
  libxl_domain_build_info *info, libxl__domain_build_state *state,
  struct xc_dom_image *dom)
 {
@@ -737,6 +738,11 @@ static int libxl__build_dom(libxl__gc *gc, uint32_t domid,
 LOGE(ERROR, "libxl__arch_domain_finalise_hw_description failed");
 goto out;
 }
+ret = libxl__arch_domain_construct_memmap(gc, d_config, domid, dom);
+if (ret != 0) {
+LOG(ERROR, "setting domain memory map failed");
+goto out;
+}
 if ( (ret = xc_dom_build_image(dom)) != 0 ) {
 LOGE(ERROR, "xc_dom_build_image failed");
 goto out;
@@ -758,7 +764,7 @@ out:
 return ret != 0 ? ERROR_FAIL : 0;
 }
 
-int libxl__build_pv(libxl__gc *gc, uint32_t domid,
+int libxl__build_pv(libxl__gc *gc, uint32_t domid, libxl_domain_config 
*d_config,
  libxl_domain_build_info *info, libxl__domain_build_state *state)
 {
 libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -847,7 +853,7 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 dom->vnode_to_pnode[i] = info->vnuma_nodes[i].pnode;
 }
 
-ret = libxl__build_dom(gc, domid, info, state, dom);
+ret = libxl__build_dom(gc, domid, d_config, info, state, dom);
 if (ret != 0)
 goto out;
 
@@ -1293,7 +1299,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 dom->vnode_to_pnode[i] = info->vnuma_nodes[i].pnode;
 }
 
-rc = libxl__build_dom(gc, domid, info, state, dom);
+rc = libxl__build_dom(gc, domid, d_config, info, state, dom);
 if (rc != 0)
 goto out;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 506687f..914df23 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1159,6 +1159,7 @@ _hidden int libxl__build_post(libxl__gc *gc, uint32_t 
domid,
char **vms_ents, char **local_ents);
 
 _hidden int libxl__build_pv(libxl__gc *gc, uint32_t domid,
+libxl_domain_config *const d_config,
  libxl_domain_build_info *info, libxl__domain_build_state *state);
 _hidden int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
   libxl_domain_config *d_config,
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index d82013f..3331cc5 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -525,6 +525,9 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 uint32_t lowmem_start = dom->device_model ? GUEST_LOW_MEM_START_DEFAULT : 
0;
 unsigned page_size = XC_DOM_PAGE_SIZE(dom);
 
+if (d_config->b_info.type == LIBXL_DOMAIN_TYPE_PV)
+return 0;
+
 /* Add all rdm entries. */
 for (i = 0; i < d_config->num_rdms; i++)
 if (d_config->rdms[i].policy != LIBXL_RDM_RESERVE_POLICY_INVALID)
-- 
1.8.3.1


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

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

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

   KVM: x86: Allow Qemu/KVM to use PVH entry point
   https://lkml.org/lkml/2018/2/28/1121

Changes since v1:
 * Made updates to code comments as suggested by Jan and Roger, including
   better definition of the memory map type field.   
 * Boris provided additional patches to populate the new fields in the
   hvm_start_info struct as Jan (and later Roger also) had requested.

 tools/libxc/include/xc_dom.h |  8 ++-
 tools/libxc/xc_dom_x86.c | 21 +-
 tools/libxl/libxl_create.c   |  2 +-
 tools/libxl/libxl_dom.c  | 12 +++-
 tools/libxl/libxl_internal.h |  1 +
 tools/libxl/libxl_x86.c  |  9 +++
 xen/include/public/arch-x86/hvm/start_info.h | 63 +-
 7 files changed, 109 insertions(+), 7 deletions(-)

Boris Ostrovsky (3):
  libxl: Move libxl__arch_domain_construct_memmap() earlier
  libxl: Store PVH guest's e820 map in xc_dom_image
  libxc: Pass e820 map to PVH guest via hvm_start_info

Maran Wilson (1):
  x86/PVHv2: Add memory map pointer to hvm_start_info struct


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

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

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

Signed-off-by: Maran Wilson 
---
 xen/include/public/arch-x86/hvm/start_info.h | 63 +++-
 1 file changed, 62 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/arch-x86/hvm/start_info.h 
b/xen/include/public/arch-x86/hvm/start_info.h
index 6484159..f8d6a1a 100644
--- a/xen/include/public/arch-x86/hvm/start_info.h
+++ b/xen/include/public/arch-x86/hvm/start_info.h
@@ -33,8 +33,9 @@
  *| magic  | Contains the magic value XEN_HVM_START_MAGIC_VALUE
  *|| ("xEn3" with the 0x80 bit of the "E" set).
  *  4 ++
- *| version| Version of this structure. Current version is 0. New
+ *| version| Version of this structure. Current version is 1. New
  *|| versions are guaranteed to be backwards-compatible.
+ *|| For PV guests only 0 allowed, for PVH 0 or 1 allowed.
  *  8 ++
  *| flags  | SIF_xxx flags.
  * 12 ++
@@ -48,6 +49,15 @@
  * 32 ++
  *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
  * 40 ++
+ *| memmap_paddr   | Physical address of the (optional) memory map. Only
+ *|| present in version 1 and newer of the structure.
+ * 48 ++
+ *| memmap_entries | Number of entries in the memory map table. Zero
+ *|| if there is no memory map being provided. Only
+ *|| present in version 1 and newer of the structure.
+ * 52 ++
+ *| reserved   | Version 1 and newer only.
+ * 56 ++
  *
  * The layout of each entry in the module structure is the following:
  *
@@ -62,10 +72,46 @@
  *| reserved   |
  * 32 ++
  *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ *  0 ++
+ *| addr   | Base address
+ *  8 ++
+ *| size   | Size of mapping in bytes
+ * 16 ++
+ *| type   | Type of mapping as defined between the hypervisor
+ *|| and guest it's starting.
+ * 20 +|
+ *| reserved   |
+ * 24 ++
+ *
  * The address and sizes are always a 64bit little endian unsigned integer.
  *
+ * For x86 implementations at least, the values used in the type field will
+ * match the Address Range Types as defined in section 15 (System Address
+ * Map Interfaces) of the ACPI Specification (http://uefi.org/specifications)
+ * where:
+ * AddressRangeMemory = 1 (E820_RAM)
+ * AddressRangeReserved = 2 (E820_RESERVED)
+ * AddressRangeACPI = 3 (E820_ACPI)
+ * AddressRangeNVS = 4 (E820_NVS)
+ * AddressRangeUnusable = 5 (E820_UNUSABLE)
+ * AddressRangeDisabled = 6 (E820_DISABLED)
+ * AddressRangePersistentMemory = 7 (E820_PMEM)
+ *
  * NB: Xen on x86 will always try to place all the data below the 4GiB
  * boundary.
+ *
+ * Version numbers of the hvm_start_info structure have evolved like this:
+ *
+ * Version 0:  Initial implementation.
+ *
+ * Version 1:  Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
+ * padding) to the end of the hvm_start_info struct. These new
+ * fields can be used to pass a memory map to the guest. The
+ * memory map is optional and so guests that understand version 1
+ * of the structure must check that memmap_entries is non-zero
+ * before trying to read the memory map.
  */
 #define XEN_HVM_START_MAGIC_VALUE 0x336ec578
 
@@ -86,6 +132,14 @@ struct hvm_start_info {
 uint64_t cmdline_paddr; /* Physical address of the command line. */
 uint64_t rsdp_paddr;/* Physical address of the RSDP ACPI data*/
 /* structure.*/
+uint64_t memmap_paddr; /* Physical address of an array of   */
+   /* hvm_memmap_table_entry. Only present in   */
+   /* version 1 and newer of the structure  */
+uint32_t memmap_entries;   /* Number of entries in the memmap table.*/
+   /* Only present in version 1 and newer of*/
+   /* the structure. Value will be zero if  */
+   /* there is no memory map being provided.*/
+uint32_t reserved; /* Must be zero for Version 1.   */
 };
 
 struct hvm_modlist_entry {
@@ -95,4 +149,11 @@ struct hvm_modlist_entry {
 uint64_t reserved;
 };
 
+struct hvm_memmap_table_entry {
+

[Xen-devel] [PATCH v2 3/4] libxl: Store PVH guest's e820 map in xc_dom_image

From: Boris Ostrovsky 

We will later copy it to hvm_start_info.

(Also remove stale comment claming that xc_dom_image.start_info_seg is
only used for HVMlite guests)

Signed-off-by: Boris Ostrovsky 
---
 tools/libxc/include/xc_dom.h | 8 +++-
 tools/libxl/libxl_x86.c  | 6 ++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 491cad8..6ef68f9 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -99,7 +99,7 @@ struct xc_dom_image {
 struct xc_dom_seg p2m_seg;
 struct xc_dom_seg pgtables_seg;
 struct xc_dom_seg devicetree_seg;
-struct xc_dom_seg start_info_seg; /* HVMlite only */
+struct xc_dom_seg start_info_seg;
 xen_pfn_t start_info_pfn;
 xen_pfn_t console_pfn;
 xen_pfn_t xenstore_pfn;
@@ -224,6 +224,12 @@ struct xc_dom_image {
 /* Extra SMBIOS structures passed to HVMLOADER */
 struct xc_hvm_firmware_module smbios_module;
 
+/* PVH guests */
+#if defined(__i386__) || defined(__x86_64__)
+struct e820entry *e820;
+unsigned int e820_entries;
+#endif
+
 xen_pfn_t vuart_gfn;
 };
 
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 3331cc5..0de278f 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -600,6 +600,12 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 goto out;
 }
 
+if (d_config->b_info.type == LIBXL_DOMAIN_TYPE_PVH) {
+dom->e820 = libxl__malloc(gc, sizeof(struct e820entry) * e820_entries);
+dom->e820_entries = e820_entries;
+memcpy(dom->e820,  e820, e820_entries * sizeof(*(dom->e820)));
+}
+
 out:
 return rc;
 }
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2] xen-pvdevice: Introduce a simplistic xen-pvdevice save state

2018-03-13 Thread Igor Druzhinin

This should help to avoid problems with accessing the device after
migration/resume without PV drivers by migrating its PCI configuration
space state. Without an explicitly defined state record it resets
every time a VM migrates which confuses the OS and makes every
access to xen-pvdevice MMIO region to fail. PV tools enable some
logic to save and restore PCI configuration state from within the VM
every time it migrates which basically hides the issue.

Older systems will acquire the new record when migrated which should
not change their state for worse.

Signed-off-by: Igor Druzhinin 
Reviewed-by: Paul Durrant 
---
v2: add more concrete info
---
 hw/i386/xen/xen_pvdevice.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/hw/i386/xen/xen_pvdevice.c b/hw/i386/xen/xen_pvdevice.c
index f748823..a146f18 100644
--- a/hw/i386/xen/xen_pvdevice.c
+++ b/hw/i386/xen/xen_pvdevice.c
@@ -71,6 +71,16 @@ static const MemoryRegionOps xen_pv_mmio_ops = {
 .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
+static const VMStateDescription vmstate_xen_pvdevice = {
+.name = "xen-pvdevice",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_PCI_DEVICE(parent_obj, XenPVDevice),
+VMSTATE_END_OF_LIST()
+}
+};
+
 static void xen_pv_realize(PCIDevice *pci_dev, Error **errp)
 {
 XenPVDevice *d = XEN_PV_DEVICE(pci_dev);
@@ -120,6 +130,7 @@ static void xen_pv_class_init(ObjectClass *klass, void 
*data)
 k->class_id = PCI_CLASS_SYSTEM_OTHER;
 dc->desc = "Xen PV Device";
 dc->props = xen_pv_props;
+dc->vmsd = _xen_pvdevice;
 }
 
 static const TypeInfo xen_pv_type_info = {
-- 
2.7.4


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

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

2018-03-13 Thread Andrew Cooper

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

Can you try this patch?

diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index bf41563..ef6dfaf 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -367,10 +367,8 @@ UNLIKELY_END(msi_check)
 mov   %cl, TRAPBOUNCE_flags(%rdx)
 
 cmpb  $0, DOMAIN_is_32bit_pv(%rax)
-    jne   compat_int80_direct_trap
-
-    call  create_bounce_frame
-    jmp   test_all_events
+    jne   compat_post_handle_exception
+    jmp   .Lbounce_exception
 
 int80_slow_path:
 /*


The event injection code for PV guests is completely undocumented and
twisted, and depends on a couple of well placed clobbers of specific
metadata.

~Andrew

___
Xen-devel mailing list

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

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

Regressions :-(

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

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  a7313da7f7767984172873adf645eff9bd667bda
baseline version:
 xen  eef83fd2af0d4c78afec34c199c977fc97d8a0b3

Last test of basis   120679  2018-03-13 12:06:56 Z0 days
Testing same since   120685  2018-03-13 17:01:17 Z0 days2 attempts


People who touched revisions under test:
  Doug Goldstein 
  Michael Young 
  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 a7313da7f7767984172873adf645eff9bd667bda
Author: Doug Goldstein 
Date:   Tue Mar 13 11:25:29 2018 -0500

tools/xl: fix uninitialized variable in xl_vdispl

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

Signed-off-by: Doug Goldstein 
Acked-by: Wei Liu 

commit 9f3b40e8fe083e0d6d184c105f96ad9b9617f038
Author: Michael Young 
Date:   Mon Mar 12 18:49:29 2018 +

make xen ocaml safe-strings compliant

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

Signed-off-by: Michael Young 
Reviewed-by: Christian Lindig

commit b43501451733193b265de30fd79a764363a2a473
Author: Doug Goldstein 
Date:   Mon Mar 12 23:06:51 2018 -0500

tools: detect appropriate debug optimization level

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

Signed-off-by: Doug Goldstein 
Acked-by: Wei Liu 
(qemu changes not included)

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

[Xen-devel] [xen-4.8-testing test] 120544: regressions - FAIL

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 120116
 build-armhf   6 xen-buildfail REGR. vs. 120116

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 120391 pass 
in 120544
 test-xtf-amd64-amd64-2   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 120391
 test-xtf-amd64-amd64-3   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 120391
 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-installfail pass in 120391
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail pass in 120391

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 120391 REGR. vs. 
120116

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail in 120391 like 120116
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 120391 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 120391 never 
pass
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 120391 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 120391 never pass
 test-armhf-armhf-xl 13 migrate-support-check fail in 120391 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 120391 never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 120391 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 120391 
never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 120391 never 
pass
 test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 120391 never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 120391 never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 120391 
never pass
 test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 120391 never 
pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 120391 never 
pass
 test-armhf-armhf-libvirt13 migrate-support-check fail in 120391 never pass
 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 120391 never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 120391 never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 120391 never 
pass
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 120391 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 120391 never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 120116
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 120116
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 120116
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 120116
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 120116
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 120116
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 120116
 test-xtf-amd64-amd64-1   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-3   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-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13

[Xen-devel] [PATCH] [v3] xen: remove pre-xen3 fallback handlers

2018-03-13 Thread Arnd Bergmann

The legacy hypercall handlers were originally added with
a comment explaining that "copying the argument structures in
HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local
variable is sufficiently safe" and only made sure to not write
past the end of the argument structure, the checks in linux/string.h
disagree with that, when link-time optimizations are used:

In function 'memcpy',
inlined from 'pirq_query_unmask' at drivers/xen/fallback.c:53:2,
inlined from '__startup_pirq' at drivers/xen/events/events_base.c:529:2,
inlined from 'restore_pirqs' at drivers/xen/events/events_base.c:1439:3,
inlined from 'xen_irq_resume' at drivers/xen/events/events_base.c:1581:2:
include/linux/string.h:350:3: error: call to '__read_overflow2' declared with 
attribute error: detected read beyond size of object passed as 2nd parameter
   __read_overflow2();
   ^

Further research turned out that only Xen 3.0.2 or earlier required the
fallback at all, while all versions in use today don't need it.
As far as I can tell, it is not even possible to run a mainline kernel
on those old Xen releases, at the time when they were in use, only
a patched kernel was supported anyway.

Fixes: cf47a83fb06e ("xen/hypercall: fix hypercall fallback code for very old 
hypervisors")
Signed-off-by: Arnd Bergmann 
---
[v2] use a table lookup instead of a switch/case statement, after
multiple suggestions.
[v3] remove that file completely
---
 arch/x86/include/asm/xen/hypercall.h | 13 +-
 drivers/xen/Makefile |  1 -
 drivers/xen/fallback.c   | 81 
 3 files changed, 2 insertions(+), 93 deletions(-)
 delete mode 100644 drivers/xen/fallback.c

diff --git a/arch/x86/include/asm/xen/hypercall.h 
b/arch/x86/include/asm/xen/hypercall.h
index bfd882617613..dcf9353a662a 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -365,15 +365,11 @@ HYPERVISOR_update_va_mapping(unsigned long va, pte_t 
new_val,
return _hypercall4(int, update_va_mapping, va,
   new_val.pte, new_val.pte >> 32, flags);
 }
-extern int __must_check xen_event_channel_op_compat(int, void *);
 
 static inline int
 HYPERVISOR_event_channel_op(int cmd, void *arg)
 {
-   int rc = _hypercall2(int, event_channel_op, cmd, arg);
-   if (unlikely(rc == -ENOSYS))
-   rc = xen_event_channel_op_compat(cmd, arg);
-   return rc;
+   return _hypercall2(int, event_channel_op, cmd, arg);
 }
 
 static inline int
@@ -388,15 +384,10 @@ HYPERVISOR_console_io(int cmd, int count, char *str)
return _hypercall3(int, console_io, cmd, count, str);
 }
 
-extern int __must_check xen_physdev_op_compat(int, void *);
-
 static inline int
 HYPERVISOR_physdev_op(int cmd, void *arg)
 {
-   int rc = _hypercall2(int, physdev_op, cmd, arg);
-   if (unlikely(rc == -ENOSYS))
-   rc = xen_physdev_op_compat(cmd, arg);
-   return rc;
+   return _hypercall2(int, physdev_op, cmd, arg);
 }
 
 static inline int
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 451e833f5931..ea2485069e19 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,6 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_HOTPLUG_CPU)  += cpu_hotplug.o
-obj-$(CONFIG_X86)  += fallback.o
 obj-y  += grant-table.o features.o balloon.o manage.o preempt.o time.o
 obj-y  += events/
 obj-y  += xenbus/
diff --git a/drivers/xen/fallback.c b/drivers/xen/fallback.c
deleted file mode 100644
index b04fb64c5a91..
--- a/drivers/xen/fallback.c
+++ /dev/null
@@ -1,81 +0,0 @@
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-int xen_event_channel_op_compat(int cmd, void *arg)
-{
-   struct evtchn_op op;
-   int rc;
-
-   op.cmd = cmd;
-   memcpy(, arg, sizeof(op.u));
-   rc = _hypercall1(int, event_channel_op_compat, );
-
-   switch (cmd) {
-   case EVTCHNOP_close:
-   case EVTCHNOP_send:
-   case EVTCHNOP_bind_vcpu:
-   case EVTCHNOP_unmask:
-   /* no output */
-   break;
-
-#define COPY_BACK(eop) \
-   case EVTCHNOP_##eop: \
-   memcpy(arg, , sizeof(op.u.eop)); \
-   break
-
-   COPY_BACK(bind_interdomain);
-   COPY_BACK(bind_virq);
-   COPY_BACK(bind_pirq);
-   COPY_BACK(status);
-   COPY_BACK(alloc_unbound);
-   COPY_BACK(bind_ipi);
-#undef COPY_BACK
-
-   default:
-   WARN_ON(rc != -ENOSYS);
-   break;
-   }
-
-   return rc;
-}
-EXPORT_SYMBOL_GPL(xen_event_channel_op_compat);
-
-int xen_physdev_op_compat(int cmd, void *arg)
-{
-   struct physdev_op op;
-   int rc;
-
-   op.cmd = cmd;
-   memcpy(, arg, sizeof(op.u));
-   rc = _hypercall1(int, physdev_op_compat, );
-
-   switch (cmd) {
-   case PHYSDEVOP_IRQ_UNMASK_NOTIFY:
-   case

[Xen-devel] [PATCH v2 19/27] kvm: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible. The new __ASM_MOVABS macro is used to
get the address of a symbol on both 32 and 64-bit with PIE support.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/kvm_host.h | 6 --
 arch/x86/kernel/kvm.c   | 6 --
 arch/x86/kvm/svm.c  | 4 ++--
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index b605a5b6a30c..7bd6ba79e778 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1380,9 +1380,11 @@ asmlinkage void kvm_spurious_fault(void);
".pushsection .fixup, \"ax\" \n" \
"667: \n\t" \
cleanup_insn "\n\t"   \
-   "cmpb $0, kvm_rebooting \n\t" \
+   "cmpb $0, kvm_rebooting" __ASM_SEL(,(%%rip)) " \n\t" \
"jne 668b \n\t"   \
-   __ASM_SIZE(push) " $666b \n\t"\
+   __ASM_SIZE(push) "%%" _ASM_AX " \n\t"   \
+   _ASM_MOVABS " $666b, %%" _ASM_AX "\n\t" \
+   "xchg %%" _ASM_AX ", (%%" _ASM_SP ") \n\t"  \
"call kvm_spurious_fault \n\t"\
".popsection \n\t" \
_ASM_EXTABLE(666b, 667b)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index bc1a27280c4b..5e4dd958ea95 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -711,8 +711,10 @@ asm(
 ".global __raw_callee_save___kvm_vcpu_is_preempted;"
 ".type __raw_callee_save___kvm_vcpu_is_preempted, @function;"
 "__raw_callee_save___kvm_vcpu_is_preempted:"
-"movq  __per_cpu_offset(,%rdi,8), %rax;"
-"cmpb  $0, " __stringify(KVM_STEAL_TIME_preempted) "+steal_time(%rax);"
+"leaq  __per_cpu_offset(%rip), %rax;"
+"movq  (%rax,%rdi,8), %rax;"
+"addq  " __stringify(KVM_STEAL_TIME_preempted) "+steal_time(%rip), %rax;"
+"cmpb  $0, (%rax);"
 "setne %al;"
 "ret;"
 ".popsection");
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index be9c839e2c89..6835a2ce02e5 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -626,12 +626,12 @@ static u32 svm_msrpm_offset(u32 msr)
 
 static inline void clgi(void)
 {
-   asm volatile (__ex(SVM_CLGI));
+   asm volatile (__ex(SVM_CLGI) : :);
 }
 
 static inline void stgi(void)
 {
-   asm volatile (__ex(SVM_STGI));
+   asm volatile (__ex(SVM_STGI) : :);
 }
 
 static inline void invlpga(unsigned long addr, u32 asid)
-- 
2.16.2.660.g709887971b-goog


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

[Xen-devel] [PATCH v2 20/27] x86: Support global stack cookie

Add an off-by-default configuration option to use a global stack cookie
instead of the default TLS. This configuration option will only be used
with PIE binaries.

For kernel stack cookie, the compiler uses the mcmodel=kernel to switch
between the fs segment to gs segment. A PIE binary does not use
mcmodel=kernel because it can be relocated anywhere, therefore the
compiler will default to the fs segment register. This is fixed on the
latest version of gcc.

If the segment selector is available, it will be automatically added. If
the automatic configuration was selected, a warning is written and the
global variable stack cookie is used. If a specific stack mode was
selected (regular or strong) and the compiler does not support selecting
the segment register, an error is emitted.

Signed-off-by: Thomas Garnier 
---
 arch/x86/Kconfig  | 12 
 arch/x86/Makefile |  9 +
 arch/x86/entry/entry_32.S |  3 ++-
 arch/x86/entry/entry_64.S |  3 ++-
 arch/x86/include/asm/processor.h  |  3 ++-
 arch/x86/include/asm/stackprotector.h | 19 ++-
 arch/x86/kernel/asm-offsets.c |  3 ++-
 arch/x86/kernel/asm-offsets_32.c  |  3 ++-
 arch/x86/kernel/asm-offsets_64.c  |  3 ++-
 arch/x86/kernel/cpu/common.c  |  3 ++-
 arch/x86/kernel/head_32.S |  3 ++-
 arch/x86/kernel/process.c |  5 +
 12 files changed, 56 insertions(+), 13 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a0a777ce4c7c..0cb1ae187c3e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2236,6 +2236,18 @@ config RANDOMIZE_MEMORY_PHYSICAL_PADDING
 
   If unsure, leave at the default value.
 
+config X86_GLOBAL_STACKPROTECTOR
+   bool "Stack cookie using a global variable"
+   depends on CC_STACKPROTECTOR_AUTO
+   default n
+   ---help---
+  This option turns on the "stack-protector" GCC feature using a global
+  variable instead of a segment register. It is useful when the
+  compiler does not support custom segment registers when building a
+  position independent (PIE) binary.
+
+  If unsure, say N
+
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 498c1b812300..16dafc551f3b 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -142,6 +142,15 @@ else
 KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time)
 endif
 
+ifdef CONFIG_X86_GLOBAL_STACKPROTECTOR
+ifeq ($(call cc-option, -mstack-protector-guard=global),)
+$(error Cannot use CONFIG_X86_GLOBAL_STACKPROTECTOR: \
+-mstack-protector-guard=global not supported \
+by compiler)
+endif
+KBUILD_CFLAGS += -mstack-protector-guard=global
+endif
+
 ifdef CONFIG_X86_X32
x32_ld_ok := $(call try-run,\
/bin/echo -e '1: .quad 1b' | \
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index bef8e2b202a8..b7d5bc710ae7 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -239,7 +239,8 @@ ENTRY(__switch_to_asm)
movl%esp, TASK_threadsp(%eax)
movlTASK_threadsp(%edx), %esp
 
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+   !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
movlTASK_stack_canary(%edx), %ebx
movl%ebx, PER_CPU_VAR(stack_canary)+stack_canary_offset
 #endif
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index d34794368e20..fbf2b63b4e78 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -356,7 +356,8 @@ ENTRY(__switch_to_asm)
movq%rsp, TASK_threadsp(%rdi)
movqTASK_threadsp(%rsi), %rsp
 
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+   !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
movqTASK_stack_canary(%rsi), %rbx
movq%rbx, PER_CPU_VAR(irq_stack_union + stack_canary_offset)
 #endif
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 1b9488b1018a..f11284481597 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -411,7 +411,8 @@ DECLARE_PER_CPU(char *, irq_stack_ptr);
 DECLARE_PER_CPU(unsigned int, irq_count);
 extern asmlinkage void ignore_sysret(void);
 #else  /* X86_64 */
-#ifdef CONFIG_CC_STACKPROTECTOR
+#if defined(CONFIG_CC_STACKPROTECTOR) && \
+   !defined(CONFIG_X86_GLOBAL_STACKPROTECTOR)
 /*
  * Make sure stack canary segment base is cached-aligned:
  *   "For Intel Atom processors, avoid non zero segment base address
diff --git a/arch/x86/include/asm/stackprotector.h 
b/arch/x86/include/asm/stackprotector.h
index 371b3a4af000..5063f57d99f5 100644
--- a/arch/x86/include/asm/stackprotector.h
+++

[Xen-devel] [PATCH v2 24/27] x86/mm: Make the x86 GOT read-only

The GOT is changed during early boot when relocations are applied. Make
it read-only directly. This table exists only for PIE binary.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 include/asm-generic/vmlinux.lds.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 1ab0e520d6fc..89398d042f78 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -295,6 +295,17 @@
VMLINUX_SYMBOL(__end_ro_after_init) = .;
 #endif
 
+#ifdef CONFIG_X86_PIE
+#define RO_GOT_X86 \
+   .got: AT(ADDR(.got) - LOAD_OFFSET) {\
+   VMLINUX_SYMBOL(__start_got) = .;\
+   *(.got);\
+   VMLINUX_SYMBOL(__end_got) = .;  \
+   }
+#else
+#define RO_GOT_X86
+#endif
+
 /*
  * Read only Data
  */
@@ -351,6 +362,7 @@
VMLINUX_SYMBOL(__end_builtin_fw) = .;   \
}   \
\
+   RO_GOT_X86  \
TRACEDATA   \
\
/* Kernel symbol table: Normal symbols */   \
-- 
2.16.2.660.g709887971b-goog


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

[Xen-devel] [PATCH v2 26/27] x86/relocs: Add option to generate 64-bit relocations

The x86 relocation tool generates a list of 32-bit signed integers. There
was no need to use 64-bit integers because all addresses where above the 2G
top of the memory.

This change add a large-reloc option to generate 64-bit unsigned integers.
It can be used when the kernel plan to go below the top 2G and 32-bit
integers are not enough.

Signed-off-by: Thomas Garnier 
---
 arch/x86/tools/relocs.c| 60 +++---
 arch/x86/tools/relocs.h|  4 +--
 arch/x86/tools/relocs_common.c | 15 ++---
 3 files changed, 60 insertions(+), 19 deletions(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 29283ad3950f..a29eaac6 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -13,8 +13,14 @@
 
 static Elf_Ehdr ehdr;
 
+#if ELF_BITS == 64
+typedef uint64_t rel_off_t;
+#else
+typedef uint32_t rel_off_t;
+#endif
+
 struct relocs {
-   uint32_t*offset;
+   rel_off_t   *offset;
unsigned long   count;
unsigned long   size;
 };
@@ -685,7 +691,7 @@ static void print_absolute_relocs(void)
printf("\n");
 }
 
-static void add_reloc(struct relocs *r, uint32_t offset)
+static void add_reloc(struct relocs *r, rel_off_t offset)
 {
if (r->count == r->size) {
unsigned long newsize = r->size + 5;
@@ -1061,26 +1067,48 @@ static void sort_relocs(struct relocs *r)
qsort(r->offset, r->count, sizeof(r->offset[0]), cmp_relocs);
 }
 
-static int write32(uint32_t v, FILE *f)
+static int write32(rel_off_t rel, FILE *f)
 {
-   unsigned char buf[4];
+   unsigned char buf[sizeof(uint32_t)];
+   uint32_t v = (uint32_t)rel;
 
put_unaligned_le32(v, buf);
-   return fwrite(buf, 1, 4, f) == 4 ? 0 : -1;
+   return fwrite(buf, 1, sizeof(buf), f) == sizeof(buf) ? 0 : -1;
 }
 
-static int write32_as_text(uint32_t v, FILE *f)
+static int write32_as_text(rel_off_t rel, FILE *f)
 {
+   uint32_t v = (uint32_t)rel;
return fprintf(f, "\t.long 0x%08"PRIx32"\n", v) > 0 ? 0 : -1;
 }
 
-static void emit_relocs(int as_text, int use_real_mode)
+static int write64(rel_off_t rel, FILE *f)
+{
+   unsigned char buf[sizeof(uint64_t)];
+   uint64_t v = (uint64_t)rel;
+
+   put_unaligned_le64(v, buf);
+   return fwrite(buf, 1, sizeof(buf), f) == sizeof(buf) ? 0 : -1;
+}
+
+static int write64_as_text(rel_off_t rel, FILE *f)
+{
+   uint64_t v = (uint64_t)rel;
+   return fprintf(f, "\t.quad 0x%016"PRIx64"\n", v) > 0 ? 0 : -1;
+}
+
+static void emit_relocs(int as_text, int use_real_mode, int use_large_reloc)
 {
int i;
-   int (*write_reloc)(uint32_t, FILE *) = write32;
+   int (*write_reloc)(rel_off_t, FILE *);
int (*do_reloc)(struct section *sec, Elf_Rel *rel, Elf_Sym *sym,
const char *symname);
 
+   if (use_large_reloc)
+   write_reloc = write64;
+   else
+   write_reloc = write32;
+
 #if ELF_BITS == 64
if (!use_real_mode)
do_reloc = do_reloc64;
@@ -1091,6 +1119,9 @@ static void emit_relocs(int as_text, int use_real_mode)
do_reloc = do_reloc32;
else
do_reloc = do_reloc_real;
+
+   /* Large relocations only for 64-bit */
+   use_large_reloc = 0;
 #endif
 
/* Collect up the relocations */
@@ -1114,8 +1145,13 @@ static void emit_relocs(int as_text, int use_real_mode)
 * gas will like.
 */
printf(".section \".data.reloc\",\"a\"\n");
-   printf(".balign 4\n");
-   write_reloc = write32_as_text;
+   if (use_large_reloc) {
+   printf(".balign 8\n");
+   write_reloc = write64_as_text;
+   } else {
+   printf(".balign 4\n");
+   write_reloc = write32_as_text;
+   }
}
 
if (use_real_mode) {
@@ -1183,7 +1219,7 @@ static void print_reloc_info(void)
 
 void process(FILE *fp, int use_real_mode, int as_text,
 int show_absolute_syms, int show_absolute_relocs,
-int show_reloc_info)
+int show_reloc_info, int use_large_reloc)
 {
regex_init(use_real_mode);
read_ehdr(fp);
@@ -1206,5 +1242,5 @@ void process(FILE *fp, int use_real_mode, int as_text,
print_reloc_info();
return;
}
-   emit_relocs(as_text, use_real_mode);
+   emit_relocs(as_text, use_real_mode, use_large_reloc);
 }
diff --git a/arch/x86/tools/relocs.h b/arch/x86/tools/relocs.h
index 43c83c0fd22c..3d401da59df7 100644
--- a/arch/x86/tools/relocs.h
+++ b/arch/x86/tools/relocs.h
@@ -31,8 +31,8 @@ enum symtype {
 
 void process_32(FILE *fp, int use_real_mode, int as_text,
int show_absolute_syms, int show_absolute_relocs,
-   int show_reloc_info);
+   int show_reloc_info, int use_large_reloc);

[Xen-devel] [PATCH v2 18/27] xen: Adapt assembly for PIE support

Change the assembly code to use the new _ASM_MOVABS macro which get a
symbol reference while being PIE compatible. Adapt the relocation tool
to ignore 32-bit Xen code.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/tools/relocs.c | 16 +++-
 arch/x86/xen/xen-head.S | 11 ++-
 arch/x86/xen/xen-pvh.S  | 13 +
 3 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index a35cc337f883..29283ad3950f 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -832,6 +832,16 @@ static int is_percpu_sym(ElfW(Sym) *sym, const char 
*symname)
strncmp(symname, "init_per_cpu_", 13);
 }
 
+/*
+ * Check if the 32-bit relocation is within the xenpvh 32-bit code.
+ * If so, ignores it.
+ */
+static int is_in_xenpvh_assembly(ElfW(Addr) offset)
+{
+   ElfW(Sym) *sym = sym_lookup("pvh_start_xen");
+   return sym && (offset >= sym->st_value) &&
+   (offset < (sym->st_value + sym->st_size));
+}
 
 static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym,
  const char *symname)
@@ -895,8 +905,12 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, 
ElfW(Sym) *sym,
 * the relocations are processed.
 * Make sure that the offset will fit.
 */
-   if (r_type != R_X86_64_64 && (int32_t)offset != (int64_t)offset)
+   if (r_type != R_X86_64_64 &&
+   (int32_t)offset != (int64_t)offset) {
+   if (is_in_xenpvh_assembly(offset))
+   break;
die("Relocation offset doesn't fit in 32 bits\n");
+   }
 
if (r_type == R_X86_64_64)
add_reloc(, offset);
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 96f26e026783..210568e63c84 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -28,14 +28,15 @@ ENTRY(startup_xen)
 
/* Clear .bss */
xor %eax,%eax
-   mov $__bss_start, %_ASM_DI
-   mov $__bss_stop, %_ASM_CX
+   _ASM_MOVABS $__bss_start, %_ASM_DI
+   _ASM_MOVABS $__bss_stop, %_ASM_CX
sub %_ASM_DI, %_ASM_CX
shr $__ASM_SEL(2, 3), %_ASM_CX
rep __ASM_SIZE(stos)
 
-   mov %_ASM_SI, xen_start_info
-   mov $init_thread_union+THREAD_SIZE, %_ASM_SP
+   _ASM_MOVABS $xen_start_info, %_ASM_AX
+   _ASM_MOV %_ASM_SI, (%_ASM_AX)
+   _ASM_MOVABS $init_thread_union+THREAD_SIZE, %_ASM_SP
 
 #ifdef CONFIG_X86_64
/* Set up %gs.
@@ -46,7 +47,7 @@ ENTRY(startup_xen)
 * init data section till per cpu areas are set up.
 */
movl$MSR_GS_BASE,%ecx
-   movq$INIT_PER_CPU_VAR(irq_stack_union),%rax
+   movabsq $INIT_PER_CPU_VAR(irq_stack_union),%rax
cdq
wrmsr
 #endif
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
index e1a5fbeae08d..43e234c7c2de 100644
--- a/arch/x86/xen/xen-pvh.S
+++ b/arch/x86/xen/xen-pvh.S
@@ -101,8 +101,8 @@ ENTRY(pvh_start_xen)
call xen_prepare_pvh
 
/* startup_64 expects boot_params in %rsi. */
-   mov $_pa(pvh_bootparams), %rsi
-   mov $_pa(startup_64), %rax
+   movabs $_pa(pvh_bootparams), %rsi
+   movabs $_pa(startup_64), %rax
jmp *%rax
 
 #else /* CONFIG_X86_64 */
@@ -137,10 +137,15 @@ END(pvh_start_xen)
 
.section ".init.data","aw"
.balign 8
+   /*
+* Use a quad for _pa(gdt_start) because PIE does not understand a
+* long is enough. The resulting value will still be in the lower long
+* part.
+*/
 gdt:
.word gdt_end - gdt_start
-   .long _pa(gdt_start)
-   .word 0
+   .quad _pa(gdt_start)
+   .balign 8
 gdt_start:
.quad 0x/* NULL descriptor */
.quad 0x/* reserved */
-- 
2.16.2.660.g709887971b-goog


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

[Xen-devel] [PATCH v2 27/27] x86/kaslr: Add option to extend KASLR range from 1GB to 3GB

Add a new CONFIG_RANDOMIZE_BASE_LARGE option to benefit from PIE
support. It increases the KASLR range from 1GB to 3GB. The new range
stars at 0x just above the EFI memory region. This
option is off by default.

The boot code is adapted to create the appropriate page table spanning
three PUD pages.

The relocation table uses 64-bit integers generated with the updated
relocation tool with the large-reloc option.

Signed-off-by: Thomas Garnier 
---
 arch/x86/Kconfig | 21 +
 arch/x86/boot/compressed/Makefile|  5 +
 arch/x86/boot/compressed/misc.c  | 10 +-
 arch/x86/include/asm/page_64_types.h |  9 +
 arch/x86/kernel/head64.c | 15 ---
 arch/x86/kernel/head_64.S| 11 ++-
 6 files changed, 66 insertions(+), 5 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4b1615e661d6..7ea69cb0153f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2260,6 +2260,27 @@ config X86_PIE
select DYNAMIC_MODULE_BASE
select MODULE_REL_CRCS if MODVERSIONS
 
+config RANDOMIZE_BASE_LARGE
+   bool "Increase the randomization range of the kernel image"
+   depends on X86_64 && RANDOMIZE_BASE
+   select X86_PIE
+   select X86_MODULE_PLTS if MODULES
+   default n
+   ---help---
+ Build the kernel as a Position Independent Executable (PIE) and
+ increase the available randomization range from 1GB to 3GB.
+
+ This option impacts performance on kernel CPU intensive workloads up
+ to 10% due to PIE generated code. Impact on user-mode processes and
+ typical usage would be significantly less (0.50% when you build the
+ kernel).
+
+ The kernel and modules will generate slightly more assembly (1 to 2%
+ increase on the .text sections). The vmlinux binary will be
+ significantly smaller due to less relocations.
+
+ If unsure say N
+
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/boot/compressed/Makefile 
b/arch/x86/boot/compressed/Makefile
index 1f734cd98fd3..fb72f53defd0 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -116,7 +116,12 @@ $(obj)/vmlinux.bin: vmlinux FORCE
 
 targets += $(patsubst $(obj)/%,%,$(vmlinux-objs-y)) vmlinux.bin.all 
vmlinux.relocs
 
+# Large randomization require bigger relocation table
+ifeq ($(CONFIG_RANDOMIZE_BASE_LARGE),y)
+CMD_RELOCS = arch/x86/tools/relocs --large-reloc
+else
 CMD_RELOCS = arch/x86/tools/relocs
+endif
 quiet_cmd_relocs = RELOCS  $@
   cmd_relocs = $(CMD_RELOCS) $< > $@;$(CMD_RELOCS) --abs-relocs $<
 $(obj)/vmlinux.relocs: vmlinux FORCE
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index b50c42455e25..746a968690d5 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -170,10 +170,18 @@ void __puthex(unsigned long value)
 }
 
 #if CONFIG_X86_NEED_RELOCS
+
+/* Large randomization go lower than -2G and use large relocation table */
+#ifdef CONFIG_RANDOMIZE_BASE_LARGE
+typedef long rel_t;
+#else
+typedef int rel_t;
+#endif
+
 static void handle_relocations(void *output, unsigned long output_len,
   unsigned long virt_addr)
 {
-   int *reloc;
+   rel_t *reloc;
unsigned long delta, map, ptr;
unsigned long min_addr = (unsigned long)output;
unsigned long max_addr = min_addr + (VO___bss_start - VO__text);
diff --git a/arch/x86/include/asm/page_64_types.h 
b/arch/x86/include/asm/page_64_types.h
index 2c5a966dc222..85ea681421d2 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -46,7 +46,11 @@
 #define __PAGE_OFFSET   __PAGE_OFFSET_BASE_L4
 #endif /* CONFIG_DYNAMIC_MEMORY_LAYOUT */
 
+#ifdef CONFIG_RANDOMIZE_BASE_LARGE
+#define __START_KERNEL_map _AC(0x, UL)
+#else
 #define __START_KERNEL_map _AC(0x8000, UL)
+#endif /* CONFIG_RANDOMIZE_BASE_LARGE */
 
 /* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */
 
@@ -64,9 +68,14 @@
  * 512MiB by default, leaving 1.5GiB for modules once the page tables
  * are fully set up. If kernel ASLR is configured, it can extend the
  * kernel page table mapping, reducing the size of the modules area.
+ * On PIE, we relocate the binary 2G lower so add this extra space.
  */
 #if defined(CONFIG_RANDOMIZE_BASE)
+#ifdef CONFIG_RANDOMIZE_BASE_LARGE
+#define KERNEL_IMAGE_SIZE  (_AC(3, UL) * 1024 * 1024 * 1024)
+#else
 #define KERNEL_IMAGE_SIZE  (1024 * 1024 * 1024)
+#endif
 #else
 #define KERNEL_IMAGE_SIZE  (512 * 1024 * 1024)
 #endif
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index ea4c498369d8..577b47381ba2 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -63,6 +63,7 @@ EXPORT_SYMBOL(vmemmap_base);

[Xen-devel] [PATCH v2 25/27] x86/pie: Add option to build the kernel as PIE

Add the CONFIG_X86_PIE option which builds the kernel as a Position
Independent Executable (PIE). The kernel is currently build with the
mcmodel=kernel option which forces it to stay on the top 2G of the
virtual address space. With PIE, the kernel will be able to move below
the current limit.

The --emit-relocs linker option was kept instead of using -pie to limit
the impact on mapped sections. Any incompatible relocation will be
catch by the arch/x86/tools/relocs binary at compile time.

If segment based stack cookies are enabled, try to use the compiler
option to select the segment register. If not available, automatically
enabled global stack cookie in auto mode. Otherwise, recommend
compiler update or global stack cookie option.

Performance/Size impact:

Size of vmlinux (Default configuration):
 File size:
 - PIE disabled: +0.18%
 - PIE enabled: -1.977% (less relocations)
 .text section:
 - PIE disabled: same
 - PIE enabled: same

Size of vmlinux (Ubuntu configuration):
 File size:
 - PIE disabled: +0.21%
 - PIE enabled: +10%
 .text section:
 - PIE disabled: same
 - PIE enabled: +0.001%

The size increase is mainly due to not having access to the 32-bit signed
relocation that can be used with mcmodel=kernel. A small part is due to reduced
optimization for PIE code. This bug [1] was opened with gcc to provide a better
code generation for kernel PIE.

Hackbench (50% and 1600% on thread/process for pipe/sockets):
 - PIE disabled: no significant change (avg -/+ 0.5% on latest test).
 - PIE enabled: between -1% to +1% in average (default and Ubuntu config).

Kernbench (average of 10 Half and Optimal runs):
 Elapsed Time:
 - PIE disabled: no significant change (avg -0.5%)
 - PIE enabled: average -0.5% to +0.5%
 System Time:
 - PIE disabled: no significant change (avg -0.1%)
 - PIE enabled: average -0.4% to +0.4%.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303

Signed-off-by: Thomas Garnier 

merge pie
---
 arch/x86/Kconfig  |  8 
 arch/x86/Makefile | 45 -
 2 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index df4134fd3247..4b1615e661d6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2252,6 +2252,14 @@ config X86_GLOBAL_STACKPROTECTOR
 
   If unsure, say N
 
+config X86_PIE
+   bool
+   depends on X86_64
+   select DEFAULT_HIDDEN
+   select WEAK_PROVIDE_HIDDEN
+   select DYNAMIC_MODULE_BASE
+   select MODULE_REL_CRCS if MODVERSIONS
+
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index f24d200c0d9d..ab0cf88c7059 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -61,6 +61,8 @@ endif
 KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
 KBUILD_CFLAGS += $(call cc-option,-mno-avx,)
 
+stackglobal := $(call cc-option-yn, -mstack-protector-guard=global)
+
 ifeq ($(CONFIG_X86_32),y)
 BITS := 32
 UTS_MACHINE := i386
@@ -136,7 +138,48 @@ else
 
 KBUILD_CFLAGS += -mno-red-zone
 ifdef CONFIG_X86_PIE
+KBUILD_CFLAGS += -fPIE
 KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/x86/kernel/module.lds
+
+# Relax relocation in both CFLAGS and LDFLAGS to support older 
compilers
+KBUILD_CFLAGS += $(call cc-option,-Wa$(comma)-mrelax-relocations=no)
+LDFLAGS_vmlinux += $(call ld-option,--no-relax)
+KBUILD_LDFLAGS_MODULE += $(call ld-option,--no-relax)
+
+# Stack validation is not yet support due to self-referenced switches
+ifdef CONFIG_STACK_VALIDATION
+$(warning CONFIG_STACK_VALIDATION is not yet supported for x86_64 pie \
+   build.)
+SKIP_STACK_VALIDATION := 1
+export SKIP_STACK_VALIDATION
+endif
+
+ifndef CONFIG_CC_STACKPROTECTOR_NONE
+ifndef CONFIG_X86_GLOBAL_STACKPROTECTOR
+stackseg-flag := -mstack-protector-guard-reg=%gs
+ifeq ($(call cc-option-yn,$(stackseg-flag)),n)
+# Try to enable global stack cookie if possible
+ifeq ($(stackglobal), y)
+$(warning Cannot use CONFIG_CC_STACKPROTECTOR_* while \
+building a position independent kernel. \
+Default to global stack protector \
+(CONFIG_X86_GLOBAL_STACKPROTECTOR).)
+CONFIG_X86_GLOBAL_STACKPROTECTOR := y
+KBUILD_CFLAGS += -DCONFIG_X86_GLOBAL_STACKPROTECTOR
+KBUILD_AFLAGS += -DCONFIG_X86_GLOBAL_STACKPROTECTOR
+else
+$(error echo Cannot use \
+CONFIG_CC_STACKPROTECTOR_(REGULAR|STRONG|AUTO) 
\
+while building a position independent binary. \
+Update your compiler or use \
+

[Xen-devel] [PATCH v2 21/27] x86/ftrace: Adapt function tracing for PIE support

When using -fPIE/PIC with function tracing, the compiler generates a
call through the GOT (call *__fentry__@GOTPCREL). This instruction
takes 6 bytes instead of 5 on the usual relative call.

If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte nop
so ftrace can handle the previous 5-bytes as before.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/ftrace.h   |  6 +++--
 arch/x86/include/asm/sections.h |  4 
 arch/x86/kernel/ftrace.c| 42 +++--
 3 files changed, 48 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index 09ad88572746..61fa02d81b95 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -25,9 +25,11 @@ extern void __fentry__(void);
 static inline unsigned long ftrace_call_adjust(unsigned long addr)
 {
/*
-* addr is the address of the mcount call instruction.
-* recordmcount does the necessary offset calculation.
+* addr is the address of the mcount call instruction. PIE has always a
+* byte added to the start of the function.
 */
+   if (IS_ENABLED(CONFIG_X86_PIE))
+   addr -= 1;
return addr;
 }
 
diff --git a/arch/x86/include/asm/sections.h b/arch/x86/include/asm/sections.h
index d6baf23782bc..cad292f62eed 100644
--- a/arch/x86/include/asm/sections.h
+++ b/arch/x86/include/asm/sections.h
@@ -12,4 +12,8 @@ extern struct exception_table_entry __stop___ex_table[];
 extern char __end_rodata_hpage_align[];
 #endif
 
+#if defined(CONFIG_X86_PIE)
+extern char __start_got[], __end_got[];
+#endif
+
 #endif /* _ASM_X86_SECTIONS_H */
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 01ebcb6f263e..21bde498f1a9 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -102,7 +102,7 @@ static const unsigned char *ftrace_nop_replace(void)
 
 static int
 ftrace_modify_code_direct(unsigned long ip, unsigned const char *old_code,
-  unsigned const char *new_code)
+ unsigned const char *new_code)
 {
unsigned char replaced[MCOUNT_INSN_SIZE];
 
@@ -135,6 +135,44 @@ ftrace_modify_code_direct(unsigned long ip, unsigned const 
char *old_code,
return 0;
 }
 
+/* Bytes before call GOT offset */
+const unsigned char got_call_preinsn[] = { 0xff, 0x15 };
+
+static int
+ftrace_modify_initial_code(unsigned long ip, unsigned const char *old_code,
+  unsigned const char *new_code)
+{
+   unsigned char replaced[MCOUNT_INSN_SIZE + 1];
+
+   ftrace_expected = old_code;
+
+   /*
+* If PIE is not enabled or no GOT call was found, default to the
+* original approach to code modification.
+*/
+   if (!IS_ENABLED(CONFIG_X86_PIE)
+   || probe_kernel_read(replaced, (void *)ip, sizeof(replaced))
+   || memcmp(replaced, got_call_preinsn, sizeof(got_call_preinsn)))
+   return ftrace_modify_code_direct(ip, old_code, new_code);
+
+   /*
+* Build a nop slide with a 5-byte nop and 1-byte nop to keep the ftrace
+* hooking algorithm working with the expected 5 bytes instruction.
+*/
+   memcpy(replaced, new_code, MCOUNT_INSN_SIZE);
+   replaced[MCOUNT_INSN_SIZE] = ideal_nops[1][0];
+
+   ip = text_ip_addr(ip);
+
+   if (probe_kernel_write((void *)ip, replaced, sizeof(replaced)))
+   return -EPERM;
+
+   sync_core();
+
+   return 0;
+
+}
+
 int ftrace_make_nop(struct module *mod,
struct dyn_ftrace *rec, unsigned long addr)
 {
@@ -153,7 +191,7 @@ int ftrace_make_nop(struct module *mod,
 * just modify the code directly.
 */
if (addr == MCOUNT_ADDR)
-   return ftrace_modify_code_direct(rec->ip, old, new);
+   return ftrace_modify_initial_code(rec->ip, old, new);
 
ftrace_expected = NULL;
 
-- 
2.16.2.660.g709887971b-goog


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

[Xen-devel] [PATCH v2 22/27] x86/modules: Add option to start module section after kernel

Add an option so the module section is just after the mapped kernel. It
will ensure position independent modules are always at the right
distance from the kernel and do not require mcmodule=large. It also
optimize the available size for modules by getting rid of the empty
space on kernel randomization range.

Signed-off-by: Thomas Garnier 
---
 Documentation/x86/x86_64/mm.txt | 3 +++
 arch/x86/Kconfig| 4 
 arch/x86/include/asm/pgtable_64_types.h | 6 ++
 arch/x86/kernel/head64.c| 5 -
 arch/x86/mm/dump_pagetables.c   | 3 ++-
 5 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index ea91cb61a602..ec1dfe4c3cfe 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -77,3 +77,6 @@ Their order is preserved but their base will be offset early 
at boot time.
 Be very careful vs. KASLR when changing anything here. The KASLR address
 range must not overlap with anything except the KASAN shadow area, which is
 correct as KASAN disables KASLR.
+
+If CONFIG_DYNAMIC_MODULE_BASE is enabled, the module section follows the end of
+the mapped kernel.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0cb1ae187c3e..df4134fd3247 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2236,6 +2236,10 @@ config RANDOMIZE_MEMORY_PHYSICAL_PADDING
 
   If unsure, leave at the default value.
 
+# Module section starts just after the end of the kernel module
+config DYNAMIC_MODULE_BASE
+   bool
+
 config X86_GLOBAL_STACKPROTECTOR
bool "Stack cookie using a global variable"
depends on CC_STACKPROTECTOR_AUTO
diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h
index d5c21a382475..d4d3b21d5b3d 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -7,6 +7,7 @@
 #ifndef __ASSEMBLY__
 #include 
 #include 
+#include 
 
 /*
  * These are used to make use of C type-checking..
@@ -126,7 +127,12 @@ extern unsigned int ptrs_per_p4d;
 
 #define VMALLOC_END(VMALLOC_START + (VMALLOC_SIZE_TB << 40) - 1)
 
+#ifdef CONFIG_DYNAMIC_MODULE_BASE
+#define MODULES_VADDR  ALIGN(((unsigned long)_end + PAGE_SIZE), 
PMD_SIZE)
+#else
 #define MODULES_VADDR  (__START_KERNEL_map + KERNEL_IMAGE_SIZE)
+#endif
+
 /* The module sections ends with the start of the fixmap */
 #define MODULES_END_AC(0xff00, UL)
 #define MODULES_LEN(MODULES_END - MODULES_VADDR)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 2fe60e661227..ea4c498369d8 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -384,12 +384,15 @@ asmlinkage __visible void __init x86_64_start_kernel(char 
* real_mode_data)
 * Build-time sanity checks on the kernel image and module
 * area mappings. (these are purely build-time and produce no code)
 */
+#ifndef CONFIG_DYNAMIC_MODULE_BASE
BUILD_BUG_ON(MODULES_VADDR < __START_KERNEL_map);
BUILD_BUG_ON(MODULES_VADDR - __START_KERNEL_map < KERNEL_IMAGE_SIZE);
-   BUILD_BUG_ON(MODULES_LEN + KERNEL_IMAGE_SIZE > 2*PUD_SIZE);
+   BUILD_BUG_ON(!IS_ENABLED(CONFIG_RANDOMIZE_BASE_LARGE) &&
+MODULES_LEN + KERNEL_IMAGE_SIZE > 2*PUD_SIZE);
BUILD_BUG_ON((__START_KERNEL_map & ~PMD_MASK) != 0);
BUILD_BUG_ON((MODULES_VADDR & ~PMD_MASK) != 0);
BUILD_BUG_ON(!(MODULES_VADDR > __START_KERNEL));
+#endif
MAYBE_BUILD_BUG_ON(!(((MODULES_END - 1) & PGDIR_MASK) ==
(__START_KERNEL & PGDIR_MASK)));
BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) <= MODULES_END);
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 62a7e9f65dec..6f0b1fa2a71a 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -104,7 +104,7 @@ static struct addr_marker address_markers[] = {
[EFI_END_NR]= { EFI_VA_END, "EFI Runtime Services" 
},
 #endif
[HIGH_KERNEL_NR]= { __START_KERNEL_map, "High Kernel Mapping" },
-   [MODULES_VADDR_NR]  = { MODULES_VADDR,  "Modules" },
+   [MODULES_VADDR_NR]  = { 0/*MODULES_VADDR*/, "Modules" },
[MODULES_END_NR]= { MODULES_END,"End Modules" },
[FIXADDR_START_NR]  = { FIXADDR_START,  "Fixmap Area" },
[END_OF_SPACE_NR]   = { -1, NULL }
@@ -599,6 +599,7 @@ static int __init pt_dump_init(void)
address_markers[KASAN_SHADOW_START_NR].start_address = 
KASAN_SHADOW_START;
address_markers[KASAN_SHADOW_END_NR].start_address = KASAN_SHADOW_END;
 #endif
+   address_markers[MODULES_VADDR_NR].start_address = MODULES_VADDR;
 #endif
 #ifdef CONFIG_X86_32
address_markers[VMALLOC_START_NR].start_address = VMALLOC_START;
--

[Xen-devel] [PATCH v2 11/27] x86/power/64: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/power/hibernate_asm_64.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/power/hibernate_asm_64.S 
b/arch/x86/power/hibernate_asm_64.S
index ce8da3a0412c..6fdd7bbc3c33 100644
--- a/arch/x86/power/hibernate_asm_64.S
+++ b/arch/x86/power/hibernate_asm_64.S
@@ -24,7 +24,7 @@
 #include 
 
 ENTRY(swsusp_arch_suspend)
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movq%rsp, pt_regs_sp(%rax)
movq%rbp, pt_regs_bp(%rax)
movq%rsi, pt_regs_si(%rax)
@@ -115,7 +115,7 @@ ENTRY(restore_registers)
movq%rax, %cr4;  # turn PGE back on
 
/* We don't restore %rax, it must be 0 anyway */
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movqpt_regs_sp(%rax), %rsp
movqpt_regs_bp(%rax), %rbp
movqpt_regs_si(%rax), %rsi
-- 
2.16.2.660.g709887971b-goog


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

[Xen-devel] [PATCH v2 13/27] x86/boot/64: Build head64.c as mcmodel large when PIE is enabled

The __startup_64 function assumes all symbols have relocated addresses
instead of the current boot virtual address. PIE generated code favor
relative addresses making all virtual and physical address math incorrect.
If PIE is enabled, build head64.c as mcmodel large instead to ensure absolute
references on all memory access. Add a global __force_order variable required
when using a large model with read_cr* functions.

To build head64.c as mcmodel=large, disable the retpoline gcc flags.
This code is used at early boot and removed later, it doesn't need
retpoline mitigation.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/Makefile | 6 ++
 arch/x86/kernel/head64.c | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 29786c87e864..1ff6be34de66 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -22,6 +22,12 @@ CFLAGS_REMOVE_early_printk.o = -pg
 CFLAGS_REMOVE_head64.o = -pg
 endif
 
+ifdef CONFIG_X86_PIE
+# Remove PIE and retpoline flags that are incompatible with mcmodel=large
+CFLAGS_REMOVE_head64.o += -fPIE -mindirect-branch=thunk-extern 
-mindirect-branch-register
+CFLAGS_head64.o = -mcmodel=large
+endif
+
 KASAN_SANITIZE_head$(BITS).o   := n
 KASAN_SANITIZE_dumpstack.o := n
 KASAN_SANITIZE_dumpstack_$(BITS).o := n
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 0c855deee165..2fe60e661227 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -64,6 +64,9 @@ EXPORT_SYMBOL(vmemmap_base);
 
 #define __head __section(.head.text)
 
+/* Required for read_cr3 when building as PIE */
+unsigned long __force_order;
+
 static void __head *fixup_pointer(void *ptr, unsigned long physaddr)
 {
return ptr - (void *)_text + (void *)physaddr;
-- 
2.16.2.660.g709887971b-goog


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

[Xen-devel] [PATCH v2 17/27] x86/relocs: Handle PIE relocations

Change the relocation tool to correctly handle relocations generated by
-fPIE option:

 - Add relocation for each entry of the .got section given the linker does not
   generate R_X86_64_GLOB_DAT on a simple link.
 - Ignore R_X86_64_GOTPCREL.

Signed-off-by: Thomas Garnier 
---
 arch/x86/tools/relocs.c | 93 -
 1 file changed, 92 insertions(+), 1 deletion(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 220e97841e49..a35cc337f883 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -32,6 +32,7 @@ struct section {
Elf_Sym*symtab;
Elf_Rel*reltab;
char   *strtab;
+   Elf_Addr   *got;
 };
 static struct section *secs;
 
@@ -293,6 +294,35 @@ static Elf_Sym *sym_lookup(const char *symname)
return 0;
 }
 
+static Elf_Sym *sym_lookup_addr(Elf_Addr addr, const char **name)
+{
+   int i;
+   for (i = 0; i < ehdr.e_shnum; i++) {
+   struct section *sec = [i];
+   long nsyms;
+   Elf_Sym *symtab;
+   Elf_Sym *sym;
+
+   if (sec->shdr.sh_type != SHT_SYMTAB)
+   continue;
+
+   nsyms = sec->shdr.sh_size/sizeof(Elf_Sym);
+   symtab = sec->symtab;
+
+   for (sym = symtab; --nsyms >= 0; sym++) {
+   if (sym->st_value == addr) {
+   if (name) {
+   *name = sym_name(sec->link->strtab,
+sym);
+   }
+   return sym;
+   }
+   }
+   }
+   return 0;
+}
+
+
 #if BYTE_ORDER == LITTLE_ENDIAN
 #define le16_to_cpu(val) (val)
 #define le32_to_cpu(val) (val)
@@ -513,6 +543,33 @@ static void read_relocs(FILE *fp)
}
 }
 
+static void read_got(FILE *fp)
+{
+   int i;
+   for (i = 0; i < ehdr.e_shnum; i++) {
+   struct section *sec = [i];
+   sec->got = NULL;
+   if (sec->shdr.sh_type != SHT_PROGBITS ||
+   strcmp(sec_name(i), ".got")) {
+   continue;
+   }
+   sec->got = malloc(sec->shdr.sh_size);
+   if (!sec->got) {
+   die("malloc of %d bytes for got failed\n",
+   sec->shdr.sh_size);
+   }
+   if (fseek(fp, sec->shdr.sh_offset, SEEK_SET) < 0) {
+   die("Seek to %d failed: %s\n",
+   sec->shdr.sh_offset, strerror(errno));
+   }
+   if (fread(sec->got, 1, sec->shdr.sh_size, fp)
+   != sec->shdr.sh_size) {
+   die("Cannot read got: %s\n",
+   strerror(errno));
+   }
+   }
+}
+
 
 static void print_absolute_symbols(void)
 {
@@ -643,6 +700,32 @@ static void add_reloc(struct relocs *r, uint32_t offset)
r->offset[r->count++] = offset;
 }
 
+/*
+ * The linker does not generate relocations for the GOT for the kernel.
+ * If a GOT is found, simulate the relocations that should have been included.
+ */
+static void walk_got_table(int (*process)(struct section *sec, Elf_Rel *rel,
+ Elf_Sym *sym, const char *symname),
+  struct section *sec)
+{
+   int i;
+   Elf_Addr entry;
+   Elf_Sym *sym;
+   const char *symname;
+   Elf_Rel rel;
+
+   for (i = 0; i < sec->shdr.sh_size/sizeof(Elf_Addr); i++) {
+   entry = sec->got[i];
+   sym = sym_lookup_addr(entry, );
+   if (!sym)
+   die("Could not found got symbol for entry %d\n", i);
+   rel.r_offset = sec->shdr.sh_addr + i * sizeof(Elf_Addr);
+   rel.r_info = ELF_BITS == 64 ? R_X86_64_GLOB_DAT
+: R_386_GLOB_DAT;
+   process(sec, , sym, symname);
+   }
+}
+
 static void walk_relocs(int (*process)(struct section *sec, Elf_Rel *rel,
Elf_Sym *sym, const char *symname))
 {
@@ -656,6 +739,8 @@ static void walk_relocs(int (*process)(struct section *sec, 
Elf_Rel *rel,
struct section *sec = [i];
 
if (sec->shdr.sh_type != SHT_REL_TYPE) {
+   if (sec->got)
+   walk_got_table(process, sec);
continue;
}
sec_symtab  = sec->link;
@@ -765,6 +850,7 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, 
ElfW(Sym) *sym,
offset += per_cpu_load_addr;
 
switch (r_type) {
+   case R_X86_64_GOTPCREL:
case R_X86_64_NONE:
/* NONE can be ignored. */
break;
@@ -809,7 +895,7 @@ static int do_reloc64(struct section *sec, Elf_Rel

[Xen-devel] [PATCH v2 10/27] x86/boot/64: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Early at boot, the kernel is mapped at a temporary address while preparing
the page table. To know the changes needed for the page table with KASLR,
the boot code calculate the difference between the expected address of the
kernel and the one chosen by KASLR. It does not work with PIE because all
symbols in code are relatives. Instead of getting the future relocated
virtual address, you will get the current temporary mapping. The solution
is using global variables that will be relocated as expected.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/head_64.S | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 48385c1074a5..48652f3ec46a 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -89,8 +89,9 @@ startup_64:
popq%rsi
 
/* Form the CR3 value being sure to include the CR3 modifier */
-   addq$(early_top_pgt - __START_KERNEL_map), %rax
+   addq_early_top_pgt_offset(%rip), %rax
jmp 1f
+
 ENTRY(secondary_startup_64)
UNWIND_HINT_EMPTY
/*
@@ -119,7 +120,7 @@ ENTRY(secondary_startup_64)
popq%rsi
 
/* Form the CR3 value being sure to include the CR3 modifier */
-   addq$(init_top_pgt - __START_KERNEL_map), %rax
+   addq_init_top_offset(%rip), %rax
 1:
 
/* Enable PAE mode, PGE and LA57 */
@@ -137,7 +138,7 @@ ENTRY(secondary_startup_64)
movq%rax, %cr3
 
/* Ensure I am executing from virtual addresses */
-   movq$1f, %rax
+   movabs  $1f, %rax
ANNOTATE_RETPOLINE_SAFE
jmp *%rax
 1:
@@ -234,11 +235,12 @@ ENTRY(secondary_startup_64)
 *  REX.W + FF /5 JMP m16:64 Jump far, absolute indirect,
 *  address given in m16:64.
 */
-   pushq   $.Lafter_lret   # put return address on stack for unwinder
+   leaq.Lafter_lret(%rip), %rax
+   pushq   %rax# put return address on stack for unwinder
xorq%rbp, %rbp  # clear frame pointer
-   movqinitial_code(%rip), %rax
+   leaqinitial_code(%rip), %rax
pushq   $__KERNEL_CS# set correct cs
-   pushq   %rax# target address in negative space
+   pushq   (%rax)  # target address in negative space
lretq
 .Lafter_lret:
 END(secondary_startup_64)
@@ -342,6 +344,18 @@ END(early_idt_handler_common)
 GLOBAL(early_recursion_flag)
.long 0
 
+   /*
+* Position Independent Code takes only relative references in code
+* meaning a global variable address is relative to RIP and not its
+* future virtual address. Global variables can be used instead as they
+* are still relocated on the expected kernel mapping address.
+*/
+   .align 8
+_early_top_pgt_offset:
+   .quad early_top_pgt - __START_KERNEL_map
+_init_top_offset:
+   .quad init_top_pgt - __START_KERNEL_map
+
 #define NEXT_PAGE(name) \
.balign PAGE_SIZE; \
 GLOBAL(name)
-- 
2.16.2.660.g709887971b-goog


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

[Xen-devel] [PATCH v2 09/27] x86/acpi: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/acpi/wakeup_64.S | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
index 50b8ed0317a3..472659c0f811 100644
--- a/arch/x86/kernel/acpi/wakeup_64.S
+++ b/arch/x86/kernel/acpi/wakeup_64.S
@@ -14,7 +14,7 @@
 * Hooray, we are in Long 64-bit mode (but still running in low memory)
 */
 ENTRY(wakeup_long64)
-   movqsaved_magic, %rax
+   movqsaved_magic(%rip), %rax
movq$0x123456789abcdef0, %rdx
cmpq%rdx, %rax
jne bogus_64_magic
@@ -25,14 +25,14 @@ ENTRY(wakeup_long64)
movw%ax, %es
movw%ax, %fs
movw%ax, %gs
-   movqsaved_rsp, %rsp
+   movqsaved_rsp(%rip), %rsp
 
-   movqsaved_rbx, %rbx
-   movqsaved_rdi, %rdi
-   movqsaved_rsi, %rsi
-   movqsaved_rbp, %rbp
+   movqsaved_rbx(%rip), %rbx
+   movqsaved_rdi(%rip), %rdi
+   movqsaved_rsi(%rip), %rsi
+   movqsaved_rbp(%rip), %rbp
 
-   movqsaved_rip, %rax
+   movqsaved_rip(%rip), %rax
jmp *%rax
 ENDPROC(wakeup_long64)
 
@@ -45,7 +45,7 @@ ENTRY(do_suspend_lowlevel)
xorl%eax, %eax
callsave_processor_state
 
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movq%rsp, pt_regs_sp(%rax)
movq%rbp, pt_regs_bp(%rax)
movq%rsi, pt_regs_si(%rax)
@@ -64,13 +64,14 @@ ENTRY(do_suspend_lowlevel)
pushfq
popqpt_regs_flags(%rax)
 
-   movq$.Lresume_point, saved_rip(%rip)
+   leaq.Lresume_point(%rip), %rax
+   movq%rax, saved_rip(%rip)
 
-   movq%rsp, saved_rsp
-   movq%rbp, saved_rbp
-   movq%rbx, saved_rbx
-   movq%rdi, saved_rdi
-   movq%rsi, saved_rsi
+   movq%rsp, saved_rsp(%rip)
+   movq%rbp, saved_rbp(%rip)
+   movq%rbx, saved_rbx(%rip)
+   movq%rdi, saved_rdi(%rip)
+   movq%rsi, saved_rsi(%rip)
 
addq$8, %rsp
movl$3, %edi
@@ -82,7 +83,7 @@ ENTRY(do_suspend_lowlevel)
.align 4
 .Lresume_point:
/* We don't restore %rax, it must be 0 anyway */
-   movq$saved_context, %rax
+   leaqsaved_context(%rip), %rax
movqsaved_context_cr4(%rax), %rbx
movq%rbx, %cr4
movqsaved_context_cr3(%rax), %rbx
-- 
2.16.2.660.g709887971b-goog


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

[Xen-devel] [PATCH v2 12/27] x86/paravirt: Adapt assembly for PIE support

if PIE is enabled, switch the paravirt assembly constraints to be
compatible. The %c/i constrains generate smaller code so is kept by
default.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/paravirt_types.h | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 180bc0bff0fb..140747a98d94 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -337,9 +337,17 @@ extern struct pv_lock_ops pv_lock_ops;
 #define PARAVIRT_PATCH(x)  \
(offsetof(struct paravirt_patch_template, x) / sizeof(void *))
 
+#ifdef CONFIG_X86_PIE
+#define paravirt_opptr_call "a"
+#define paravirt_opptr_type "p"
+#else
+#define paravirt_opptr_call "c"
+#define paravirt_opptr_type "i"
+#endif
+
 #define paravirt_type(op)  \
[paravirt_typenum] "i" (PARAVIRT_PATCH(op)),\
-   [paravirt_opptr] "i" (&(op))
+   [paravirt_opptr] paravirt_opptr_type (&(op))
 #define paravirt_clobber(clobber)  \
[paravirt_clobber] "i" (clobber)
 
@@ -395,7 +403,7 @@ int paravirt_disable_iospace(void);
  */
 #define PARAVIRT_CALL  \
ANNOTATE_RETPOLINE_SAFE \
-   "call *%c[paravirt_opptr];"
+   "call *%" paravirt_opptr_call "[paravirt_opptr];"
 
 /*
  * These macros are intended to wrap calls through one of the paravirt
-- 
2.16.2.660.g709887971b-goog


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

[Xen-devel] [PATCH v2 06/27] x86/entry/64: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/entry/entry_64.S| 16 ++--
 arch/x86/kernel/relocate_kernel_64.S |  8 +++-
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index bd53c57617e6..c53123468364 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -191,7 +191,7 @@ ENTRY(entry_SYSCALL_64_trampoline)
 * spill RDI and restore it in a second-stage trampoline.
 */
pushq   %rdi
-   movq$entry_SYSCALL_64_stage2, %rdi
+   movabsq $entry_SYSCALL_64_stage2, %rdi
JMP_NOSPEC %rdi
 END(entry_SYSCALL_64_trampoline)
 
@@ -1275,7 +1275,8 @@ ENTRY(error_entry)
movl%ecx, %eax  /* zero extend */
cmpq%rax, RIP+8(%rsp)
je  .Lbstep_iret
-   cmpq$.Lgs_change, RIP+8(%rsp)
+   leaq.Lgs_change(%rip), %rcx
+   cmpq%rcx, RIP+8(%rsp)
jne .Lerror_entry_done
 
/*
@@ -1480,10 +1481,10 @@ ENTRY(nmi)
 * resume the outer NMI.
 */
 
-   movq$repeat_nmi, %rdx
+   leaqrepeat_nmi(%rip), %rdx
cmpq8(%rsp), %rdx
ja  1f
-   movq$end_repeat_nmi, %rdx
+   leaqend_repeat_nmi(%rip), %rdx
cmpq8(%rsp), %rdx
ja  nested_nmi_out
 1:
@@ -1537,7 +1538,8 @@ nested_nmi:
pushq   %rdx
pushfq
pushq   $__KERNEL_CS
-   pushq   $repeat_nmi
+   leaqrepeat_nmi(%rip), %rdx
+   pushq   %rdx
 
/* Put stack back */
addq$(6*8), %rsp
@@ -1576,7 +1578,9 @@ first_nmi:
addq$8, (%rsp)  /* Fix up RSP */
pushfq  /* RFLAGS */
pushq   $__KERNEL_CS/* CS */
-   pushq   $1f /* RIP */
+   pushq   %rax/* Support Position Independent Code */
+   leaq1f(%rip), %rax  /* RIP */
+   xchgq   %rax, (%rsp)/* Restore RAX, put 1f */
iretq   /* continues at repeat_nmi below */
UNWIND_HINT_IRET_REGS
 1:
diff --git a/arch/x86/kernel/relocate_kernel_64.S 
b/arch/x86/kernel/relocate_kernel_64.S
index a7227dfe1a2b..0c0fc259a4e2 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -208,11 +208,9 @@ identity_mapped:
movq%rax, %cr3
lea PAGE_SIZE(%r8), %rsp
callswap_pages
-   jmp *virtual_mapped_addr(%rip)
-
-   /* Absolute value for PIE support */
-virtual_mapped_addr:
-   .quad virtual_mapped
+   movabsq $virtual_mapped, %rax
+   pushq   %rax
+   ret
 
 virtual_mapped:
movqRSP(%r8), %rsp
-- 
2.16.2.660.g709887971b-goog


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

[Xen-devel] [PATCH v2 03/27] x86: Use symbol name in jump table for PIE support

Replace the %c constraint with %P. The %c is incompatible with PIE
because it implies an immediate value whereas %P reference a symbol.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/jump_label.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/jump_label.h 
b/arch/x86/include/asm/jump_label.h
index 8c0de4282659..dfdcdc39604a 100644
--- a/arch/x86/include/asm/jump_label.h
+++ b/arch/x86/include/asm/jump_label.h
@@ -37,9 +37,9 @@ static __always_inline bool arch_static_branch(struct 
static_key *key, bool bran
".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
".pushsection __jump_table,  \"aw\" \n\t"
_ASM_ALIGN "\n\t"
-   _ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
+   _ASM_PTR "1b, %l[l_yes], %P0 \n\t"
".popsection \n\t"
-   : :  "i" (key), "i" (branch) : : l_yes);
+   : :  "X" (&((char *)key)[branch]) : : l_yes);
 
return false;
 l_yes:
@@ -53,9 +53,9 @@ static __always_inline bool arch_static_branch_jump(struct 
static_key *key, bool
"2:\n\t"
".pushsection __jump_table,  \"aw\" \n\t"
_ASM_ALIGN "\n\t"
-   _ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
+   _ASM_PTR "1b, %l[l_yes], %P0 \n\t"
".popsection \n\t"
-   : :  "i" (key), "i" (branch) : : l_yes);
+   : :  "X" (&((char *)key)[branch]) : : l_yes);
 
return false;
 l_yes:
-- 
2.16.2.660.g709887971b-goog


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

[Xen-devel] [PATCH v2 16/27] compiler: Option to add PROVIDE_HIDDEN replacement for weak symbols

Provide an option to have a PROVIDE_HIDDEN (linker script) entry for
each weak symbol. This option solve an error in x86_64 where the linker
optimizes pie generate code to be non-pie because --emit-relocs was used
instead of -pie (to reduce dynamic relocations).

Signed-off-by: Thomas Garnier 
---
 init/Kconfig|  7 +++
 scripts/link-vmlinux.sh | 14 ++
 2 files changed, 21 insertions(+)

diff --git a/init/Kconfig b/init/Kconfig
index c924babc6d47..fe9f9ada4db0 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1927,6 +1927,13 @@ config ASN1
  inform it as to what tags are to be expected in a stream and what
  functions to call on what tags.
 
+config WEAK_PROVIDE_HIDDEN
+   bool
+   help
+ Generate linker script PROVIDE_HIDDEN entries for all weak symbols. It
+ allows to prevent non-pie code being replaced by the linker if the
+ emit-relocs option is used instead of pie (useful for x86_64 pie).
+
 source "kernel/Kconfig.locks"
 
 config ARCH_HAS_SYNC_CORE_BEFORE_USERMODE
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 08ca08e9105c..c015f5142ecf 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -146,6 +146,17 @@ kallsyms()
${CC} ${aflags} -c -o ${2} ${afile}
 }
 
+gen_weak_provide_hidden()
+{
+if [ -n "${CONFIG_WEAK_PROVIDE_HIDDEN}" ]; then
+local pattern="s/^\s\+ w \(\w\+\)$/PROVIDE_HIDDEN(\1 = .);/gp"
+echo -e "SECTIONS {\n. = _end;" > .tmp_vmlinux_hiddenld
+${NM} ${1} | sed -n "${pattern}" >> .tmp_vmlinux_hiddenld
+echo "}" >> .tmp_vmlinux_hiddenld
+LDFLAGS_vmlinux="${LDFLAGS_vmlinux} -T .tmp_vmlinux_hiddenld"
+fi
+}
+
 # Create map file with all symbols from ${1}
 # See mksymap for additional details
 mksysmap()
@@ -230,6 +241,9 @@ modpost_link vmlinux.o
 # modpost vmlinux.o to check for section mismatches
 ${MAKE} -f "${srctree}/scripts/Makefile.modpost" vmlinux.o
 
+# Generate weak linker script
+gen_weak_provide_hidden vmlinux.o
+
 kallsymso=""
 kallsyms_vmlinux=""
 if [ -n "${CONFIG_KALLSYMS}" ]; then
-- 
2.16.2.660.g709887971b-goog


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

[Xen-devel] [PATCH v2 07/27] x86: pm-trace - Adapt assembly for PIE support

Change assembly to use the new _ASM_MOVABS macro instead of _ASM_MOV for
the assembly to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/pm-trace.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/pm-trace.h b/arch/x86/include/asm/pm-trace.h
index bfa32aa428e5..972070806ce9 100644
--- a/arch/x86/include/asm/pm-trace.h
+++ b/arch/x86/include/asm/pm-trace.h
@@ -8,7 +8,7 @@
 do {   \
if (pm_trace_enabled) { \
const void *tracedata;  \
-   asm volatile(_ASM_MOV " $1f,%0\n"   \
+   asm volatile(_ASM_MOVABS " $1f,%0\n"\
 ".section .tracedata,\"a\"\n"  \
 "1:\t.word %c1\n\t"\
 _ASM_PTR " %c2\n"  \
-- 
2.16.2.660.g709887971b-goog


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

[Xen-devel] [PATCH v2 15/27] compiler: Option to default to hidden symbols

Provide an option to default visibility to hidden except for key
symbols. This option is disabled by default and will be used by x86_64
PIE support to remove errors between compilation units.

The default visibility is also enabled for external symbols that are
compared as they maybe equals (start/end of sections). In this case,
older versions of GCC will remove the comparison if the symbols are
hidden. This issue exists at least on gcc 4.9 and before.

Signed-off-by: Thomas Garnier 
---
 arch/x86/boot/boot.h |  2 +-
 arch/x86/include/asm/setup.h |  2 +-
 arch/x86/kernel/cpu/microcode/core.c |  4 ++--
 drivers/base/firmware_class.c|  4 ++--
 include/asm-generic/sections.h   |  6 ++
 include/linux/compiler.h |  7 +++
 init/Kconfig |  7 +++
 kernel/kallsyms.c| 16 
 kernel/trace/trace.h |  4 ++--
 lib/dynamic_debug.c  |  4 ++--
 10 files changed, 38 insertions(+), 18 deletions(-)

diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/boot.h
index ef5a9cc66fb8..d726c35bdd96 100644
--- a/arch/x86/boot/boot.h
+++ b/arch/x86/boot/boot.h
@@ -193,7 +193,7 @@ static inline bool memcmp_gs(const void *s1, addr_t s2, 
size_t len)
 }
 
 /* Heap -- available for dynamic lists. */
-extern char _end[];
+extern char _end[] __default_visibility;
 extern char *HEAP;
 extern char *heap_end;
 #define RESET_HEAP() ((void *)( HEAP = _end ))
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 3108e297d87d..dfba64fe1c7e 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -70,7 +70,7 @@ static inline void x86_ce4100_early_setup(void) { }
  * This is set up by the setup-routine at boot-time
  */
 extern struct boot_params boot_params;
-extern char _text[];
+extern char _text[] __default_visibility;
 
 static inline bool kaslr_enabled(void)
 {
diff --git a/arch/x86/kernel/cpu/microcode/core.c 
b/arch/x86/kernel/cpu/microcode/core.c
index aa1b9a422f2b..ed5675db6e82 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -141,8 +141,8 @@ static bool __init check_loader_disabled_bsp(void)
return *res;
 }
 
-extern struct builtin_fw __start_builtin_fw[];
-extern struct builtin_fw __end_builtin_fw[];
+extern struct builtin_fw __start_builtin_fw[] __default_visibility;
+extern struct builtin_fw __end_builtin_fw[] __default_visibility;
 
 bool get_builtin_firmware(struct cpio_data *cd, const char *name)
 {
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 7dd36ace6152..939a1952d0ab 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -136,8 +136,8 @@ static struct firmware_cache fw_cache;
 
 #ifdef CONFIG_FW_LOADER
 
-extern struct builtin_fw __start_builtin_fw[];
-extern struct builtin_fw __end_builtin_fw[];
+extern struct builtin_fw __start_builtin_fw[] __default_visibility;
+extern struct builtin_fw __end_builtin_fw[] __default_visibility;
 
 static void fw_copy_to_prealloc_buf(struct firmware *fw,
void *buf, size_t size)
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index 849cd8eb5ca0..0a0e23405ddd 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -32,6 +32,9 @@
  * __softirqentry_text_start, __softirqentry_text_end
  * __start_opd, __end_opd
  */
+#ifdef CONFIG_DEFAULT_HIDDEN
+#pragma GCC visibility push(default)
+#endif
 extern char _text[], _stext[], _etext[];
 extern char _data[], _sdata[], _edata[];
 extern char __bss_start[], __bss_stop[];
@@ -49,6 +52,9 @@ extern char __start_once[], __end_once[];
 
 /* Start and end of .ctors section - used for constructor calls. */
 extern char __ctors_start[], __ctors_end[];
+#ifdef CONFIG_DEFAULT_HIDDEN
+#pragma GCC visibility pop
+#endif
 
 /* Start and end of .opd section - used for function descriptors. */
 extern char __start_opd[], __end_opd[];
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index ab4711c63601..a9ac84e37af9 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -278,6 +278,13 @@ unsigned long read_word_at_a_time(const void *addr)
__u.__val;  \
 })
 
+#ifdef CONFIG_DEFAULT_HIDDEN
+#pragma GCC visibility push(hidden)
+#define __default_visibility  __attribute__((visibility ("default")))
+#else
+#define __default_visibility
+#endif
+
 #endif /* __KERNEL__ */
 
 #endif /* __ASSEMBLY__ */
diff --git a/init/Kconfig b/init/Kconfig
index acc9087546ac..c924babc6d47 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1667,6 +1667,13 @@ config PROFILING
 config TRACEPOINTS
bool
 
+#
+# Default to hidden visibility for all symbols.
+# Useful for Position Independent Code to reduce global references.
+#
+config DEFAULT_HIDDEN
+   bool
+
 source "arch/Kconfig"

[Xen-devel] [PATCH v2 05/27] x86: relocate_kernel - Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/kernel/relocate_kernel_64.S | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/relocate_kernel_64.S 
b/arch/x86/kernel/relocate_kernel_64.S
index 11eda21eb697..a7227dfe1a2b 100644
--- a/arch/x86/kernel/relocate_kernel_64.S
+++ b/arch/x86/kernel/relocate_kernel_64.S
@@ -208,9 +208,11 @@ identity_mapped:
movq%rax, %cr3
lea PAGE_SIZE(%r8), %rsp
callswap_pages
-   movq$virtual_mapped, %rax
-   pushq   %rax
-   ret
+   jmp *virtual_mapped_addr(%rip)
+
+   /* Absolute value for PIE support */
+virtual_mapped_addr:
+   .quad virtual_mapped
 
 virtual_mapped:
movqRSP(%r8), %rsp
-- 
2.16.2.660.g709887971b-goog


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

[Xen-devel] [PATCH v2 01/27] x86/crypto: Adapt assembly for PIE support

Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/crypto/aes-x86_64-asm_64.S  | 45 +
 arch/x86/crypto/aesni-intel_asm.S|  8 +-
 arch/x86/crypto/aesni-intel_avx-x86_64.S |  6 +-
 arch/x86/crypto/camellia-aesni-avx-asm_64.S  | 42 -
 arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 44 -
 arch/x86/crypto/camellia-x86_64-asm_64.S |  8 +-
 arch/x86/crypto/cast5-avx-x86_64-asm_64.S| 50 +-
 arch/x86/crypto/cast6-avx-x86_64-asm_64.S| 44 +
 arch/x86/crypto/des3_ede-asm_64.S| 96 +---
 arch/x86/crypto/ghash-clmulni-intel_asm.S|  4 +-
 arch/x86/crypto/glue_helper-asm-avx.S|  4 +-
 arch/x86/crypto/glue_helper-asm-avx2.S   |  6 +-
 arch/x86/crypto/sha256-avx2-asm.S| 23 +++--
 13 files changed, 221 insertions(+), 159 deletions(-)

diff --git a/arch/x86/crypto/aes-x86_64-asm_64.S 
b/arch/x86/crypto/aes-x86_64-asm_64.S
index 8739cf7795de..86fa068e5e81 100644
--- a/arch/x86/crypto/aes-x86_64-asm_64.S
+++ b/arch/x86/crypto/aes-x86_64-asm_64.S
@@ -48,8 +48,12 @@
 #define R10%r10
 #define R11%r11
 
+/* Hold global for PIE suport */
+#define RBASE  %r12
+
 #define prologue(FUNC,KEY,B128,B192,r1,r2,r5,r6,r7,r8,r9,r10,r11) \
ENTRY(FUNC);\
+   pushq   RBASE;  \
movqr1,r2;  \
leaqKEY+48(r8),r9;  \
movqr10,r11;\
@@ -74,54 +78,63 @@
movlr6 ## E,4(r9);  \
movlr7 ## E,8(r9);  \
movlr8 ## E,12(r9); \
+   popqRBASE;  \
ret;\
ENDPROC(FUNC);
 
+#define round_mov(tab_off, reg_i, reg_o) \
+   leaqtab_off(%rip), RBASE; \
+   movl(RBASE,reg_i,4), reg_o;
+
+#define round_xor(tab_off, reg_i, reg_o) \
+   leaqtab_off(%rip), RBASE; \
+   xorl(RBASE,reg_i,4), reg_o;
+
 #define round(TAB,OFFSET,r1,r2,r3,r4,r5,r6,r7,r8,ra,rb,rc,rd) \
movzbl  r2 ## H,r5 ## E;\
movzbl  r2 ## L,r6 ## E;\
-   movlTAB+1024(,r5,4),r5 ## E;\
+   round_mov(TAB+1024, r5, r5 ## E)\
movwr4 ## X,r2 ## X;\
-   movlTAB(,r6,4),r6 ## E; \
+   round_mov(TAB, r6, r6 ## E) \
roll$16,r2 ## E;\
shrl$16,r4 ## E;\
movzbl  r4 ## L,r7 ## E;\
movzbl  r4 ## H,r4 ## E;\
xorlOFFSET(r8),ra ## E; \
xorlOFFSET+4(r8),rb ## E;   \
-   xorlTAB+3072(,r4,4),r5 ## E;\
-   xorlTAB+2048(,r7,4),r6 ## E;\
+   round_xor(TAB+3072, r4, r5 ## E)\
+   round_xor(TAB+2048, r7, r6 ## E)\
movzbl  r1 ## L,r7 ## E;\
movzbl  r1 ## H,r4 ## E;\
-   movlTAB+1024(,r4,4),r4 ## E;\
+   round_mov(TAB+1024, r4, r4 ## E)\
movwr3 ## X,r1 ## X;\
roll$16,r1 ## E;\
shrl$16,r3 ## E;\
-   xorlTAB(,r7,4),r5 ## E; \
+   round_xor(TAB, r7, r5 ## E) \
movzbl  r3 ## L,r7 ## E;\
movzbl  r3 ## H,r3 ## E;\
-   xorlTAB+3072(,r3,4),r4 ## E;\
-   xorlTAB+2048(,r7,4),r5 ## E;\
+   round_xor(TAB+3072, r3, r4 ## E)\
+   round_xor(TAB+2048, r7, r5 ## E)\
movzbl  r1 ## L,r7 ## E;\
movzbl  r1 ## H,r3 ## E;\
shrl$16,r1 ## E;\
-   xorlTAB+3072(,r3,4),r6 ## E;\
-   movlTAB+2048(,r7,4),r3 ## E;\
+   round_xor(TAB+3072, r3, r6 ## E)\
+   round_mov(TAB+2048, r7, r3 ## E)\
movzbl  r1 ## L,r7 ## E;\
movzbl  r1 ## H,r1 ## E;\
-   xorlTAB+1024(,r1,4),r6 ## E;\
-   xorlTAB(,r7,4),r3 ## E; \
+   round_xor(TAB+1024, r1, r6 ## E)\
+   round_xor(TAB, r7, r3 ## E) \
movzbl  r2 ## H,r1 ## E;\
movzbl  r2 ## L,r7 ## E;\
shrl$16,r2 ## E;\
-   xorlTAB+3072(,r1,4),r3 ## E;\
-   xorlTAB+2048(,r7,4),r4 ## E;\
+   round_xor(TAB+3072, r1, r3 ## E)\
+   round_xor(TAB+2048, r7, r4 ## E)\
movzbl  r2 ## H,r1 ## E;\
movzbl  r2 ## L,r2 ## E;\
xorlOFFSET+8(r8),rc ## E;   \
xorlOFFSET+12(r8),rd ## E;  \
-   xorlTAB+1024(,r1,4),r3 ## E;\
-   xorlTAB(,r2,4),r4 ## E;
+   round_xor(TAB+1024, r1, r3 ## E)\
+   round_xor(TAB, r2, r4 ## E)
 
 #define move_regs(r1,r2,r3,r4) \
movlr3 ## E,r1 ## E;\
diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index e762ef417562..4df029aa5fc1 100644

[Xen-devel] [PATCH v2 00/27] x86: PIE support and option to extend KASLR randomization

Changes:
 - patch v2:
   - Adapt patch to work post KPTI and compiler changes
   - Redo all performance testing with latest configs and compilers
   - Simplify mov macro on PIE (MOVABS now)
   - Reduce GOT footprint
 - patch v1:
   - Simplify ftrace implementation.
   - Use gcc mstack-protector-guard-reg=%gs with PIE when possible.
 - rfc v3:
   - Use --emit-relocs instead of -pie to reduce dynamic relocation space on
 mapped memory. It also simplifies the relocation process.
   - Move the start the module section next to the kernel. Remove the need for
 -mcmodel=large on modules. Extends module space from 1 to 2G maximum.
   - Support for XEN PVH as 32-bit relocations can be ignored with
 --emit-relocs.
   - Support for GOT relocations previously done automatically with -pie.
   - Remove need for dynamic PLT in modules.
   - Support dymamic GOT for modules.
 - rfc v2:
   - Add support for global stack cookie while compiler default to fs without
 mcmodel=kernel
   - Change patch 7 to correctly jump out of the identity mapping on kexec load
 preserve.

These patches make the changes necessary to build the kernel as Position
Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
the top 2G of the virtual address space. It allows to optionally extend the
KASLR randomization range from 1G to 3G.

Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler
changes, PIE support and KASLR in general. Thanks to Roland McGrath on his
feedback for using -pie versus --emit-relocs and details on compiler code
generation.

The patches:
 - 1-3, 5-13, 18-19: Change in assembly code to be PIE compliant.
 - 4: Add a new _ASM_GET_PTR macro to fetch a symbol address generically.
 - 14: Adapt percpu design to work correctly when PIE is enabled.
 - 15: Provide an option to default visibility to hidden except for key symbols.
   It removes errors between compilation units.
 - 16: Add PROVIDE_HIDDEN replacement on the linker script for weak symbols to
   reduce GOT footprint.
 - 17: Adapt relocation tool to handle PIE binary correctly.
 - 20: Add support for global cookie.
 - 21: Support ftrace with PIE (used on Ubuntu config).
 - 22: Add option to move the module section just after the kernel.
 - 23: Adapt module loading to support PIE with dynamic GOT.
 - 24: Make the GOT read-only.
 - 25: Add the CONFIG_X86_PIE option (off by default).
 - 26: Adapt relocation tool to generate a 64-bit relocation table.
 - 27: Add the CONFIG_RANDOMIZE_BASE_LARGE option to increase relocation range
   from 1G to 3G (off by default).

Performance/Size impact:

Size of vmlinux (Default configuration):
 File size:
 - PIE disabled: +0.18%
 - PIE enabled: -1.977% (less relocations)
 .text section:
 - PIE disabled: same
 - PIE enabled: same

Size of vmlinux (Ubuntu configuration):
 File size:
 - PIE disabled: +0.21%
 - PIE enabled: +10%
 .text section:
 - PIE disabled: same
 - PIE enabled: +0.001%

The size increase is mainly due to not having access to the 32-bit signed
relocation that can be used with mcmodel=kernel. A small part is due to reduced
optimization for PIE code. This bug [1] was opened with gcc to provide a better
code generation for kernel PIE.

Hackbench (50% and 1600% on thread/process for pipe/sockets):
 - PIE disabled: no significant change (avg -/+ 0.5% on latest test).
 - PIE enabled: between -1% to +1% in average (default and Ubuntu config).

Kernbench (average of 10 Half and Optimal runs):
 Elapsed Time:
 - PIE disabled: no significant change (avg -0.5%)
 - PIE enabled: average -0.5% to +0.5%
 System Time:
 - PIE disabled: no significant change (avg -0.1%)
 - PIE enabled: average -0.4% to +0.4%.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303

diffstat:
 Documentation/x86/x86_64/mm.txt  |3 
 arch/x86/Kconfig |   45 ++
 arch/x86/Makefile|   58 
 arch/x86/boot/boot.h |2 
 arch/x86/boot/compressed/Makefile|5 
 arch/x86/boot/compressed/misc.c  |   10 +
 arch/x86/crypto/aes-x86_64-asm_64.S  |   45 --
 arch/x86/crypto/aesni-intel_asm.S|8 -
 arch/x86/crypto/aesni-intel_avx-x86_64.S |6 
 arch/x86/crypto/camellia-aesni-avx-asm_64.S  |   42 +++---
 arch/x86/crypto/camellia-aesni-avx2-asm_64.S |   44 +++---
 arch/x86/crypto/camellia-x86_64-asm_64.S |8 -
 arch/x86/crypto/cast5-avx-x86_64-asm_64.S|   50 ---
 arch/x86/crypto/cast6-avx-x86_64-asm_64.S|   44 +++---
 arch/x86/crypto/des3_ede-asm_64.S|   96 +-
 arch/x86/crypto/ghash-clmulni-intel_asm.S|4 
 arch/x86/crypto/glue_helper-asm-avx.S|4 
 arch/x86/crypto/glue_helper-asm-avx2.S   |6 
 arch/x86/crypto/sha256-avx2-asm.S|   23 ++-
 arch/x86/entry/calling.h |2 
 arch/x86/entry/entry_32.S|3

[Xen-devel] [PATCH v2 04/27] x86: Add macro to get symbol address for PIE support

Add a new _ASM_MOVABS macro to fetch a symbol address. It will be used
to replace "_ASM_MOV $, %dst" code construct that are not compatible
with PIE.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/asm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
index 386a6900e206..653d8b82f015 100644
--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -30,6 +30,7 @@
 #define _ASM_ALIGN __ASM_SEL(.balign 4, .balign 8)
 
 #define _ASM_MOV   __ASM_SIZE(mov)
+#define _ASM_MOVABS__ASM_SEL(movl, movabsq)
 #define _ASM_INC   __ASM_SIZE(inc)
 #define _ASM_DEC   __ASM_SIZE(dec)
 #define _ASM_ADD   __ASM_SIZE(add)
-- 
2.16.2.660.g709887971b-goog


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

[Xen-devel] [PATCH v2 02/27] x86: Use symbol name on bug table for PIE support

Replace the %c constraint with %P. The %c is incompatible with PIE
because it implies an immediate value whereas %P reference a symbol.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier 
---
 arch/x86/include/asm/bug.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index 6804d6642767..3d690a4abf50 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -35,7 +35,7 @@ do {  
\
asm volatile("1:\t" ins "\n"\
 ".pushsection __bug_table,\"aw\"\n"\
 "2:\t" __BUG_REL(1b) "\t# bug_entry::bug_addr\n"   \
-"\t"  __BUG_REL(%c0) "\t# bug_entry::file\n"   \
+"\t"  __BUG_REL(%P0) "\t# bug_entry::file\n"   \
 "\t.word %c1""\t# bug_entry::line\n"   \
 "\t.word %c2""\t# bug_entry::flags\n"  \
 "\t.org 2b+%c3\n"  \
-- 
2.16.2.660.g709887971b-goog


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

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

2018-03-13 Thread Tamas K Lengyel

On Tue, Mar 13, 2018 at 1:47 AM, Jan Beulich  wrote:
 On 12.03.18 at 16:00,  wrote:
>> Patch ping. Jan, I would like to touch base once more to see if we can
>> get this patch included in 4.11. The patch as-is correctly tells the
>> difference between buffers provided by both an EFI shell or by the
>> firmware as an EFI_LOAD_OPTION.
>
> Well, I've stated my opinion before, and I'm intending to provide a
> replacement patch along the outline I had provided, but I didn't get
> around to actually do so yet.
>

Thanks for the update. I would be happy to wait for your patch to
rebase this on top of in still needed.

Tamas

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

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

2018-03-13 Thread Lars Kurth

Hi all,

Please find attached the agenda

We don’t have any design and problem related items this meeting. This means
that we will only cover discussions specific to some series, some may contain
design related discussion though. Note that the meeting will probably not be
very interesting for people whose series are not on the agenda. Feel free to
join and observe the meeting, but it’s also OK to drop out. You can give me
feedback about the meeting format (see AOB at the end)

For series on the agenda: we will only discuss your series if the poster of the
series is on the call when we get to it. For each series, I will call out the
owner: if the owner is not there, I will move to the next one.

Intel has sent me an updated list based on their priorities. I pushed items
which have no issues down the priority list. Also, I tried to order based on
priority and vendor.

Agenda
Quick round the table: name, company
Series for 4.11
Other Series with Issues
Other Series with no Technical Issues which had no review
Other Series - Progressing or Waiting (we will probably not get to these) -
just there for reference
AOB: feedback on format

Detailed agenda at
https://docs.google.com/document/d/1n7HAu5IbuRt5aJbQKt5X470kv2Ubvk5P2mG0vp6rKfU/edit?usp=sharing
(I am planning to edit this as we go during the meeting) and as PDF
I set it, such that everyone can edit

Regards
Lars

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

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

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

Regressions :-(

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

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  a7313da7f7767984172873adf645eff9bd667bda
baseline version:
 xen  eef83fd2af0d4c78afec34c199c977fc97d8a0b3

Last test of basis   120679  2018-03-13 12:06:56 Z0 days
Testing same since   120685  2018-03-13 17:01:17 Z0 days1 attempts


People who touched revisions under test:
  Doug Goldstein 
  Michael Young 
  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 a7313da7f7767984172873adf645eff9bd667bda
Author: Doug Goldstein 
Date:   Tue Mar 13 11:25:29 2018 -0500

tools/xl: fix uninitialized variable in xl_vdispl

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

Signed-off-by: Doug Goldstein 
Acked-by: Wei Liu 

commit 9f3b40e8fe083e0d6d184c105f96ad9b9617f038
Author: Michael Young 
Date:   Mon Mar 12 18:49:29 2018 +

make xen ocaml safe-strings compliant

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

Signed-off-by: Michael Young 
Reviewed-by: Christian Lindig

commit b43501451733193b265de30fd79a764363a2a473
Author: Doug Goldstein 
Date:   Mon Mar 12 23:06:51 2018 -0500

tools: detect appropriate debug optimization level

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

Signed-off-by: Doug Goldstein 
Acked-by: Wei Liu 
(qemu changes not included)

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

[Xen-devel] [PATCH v5 1/2] libxl: Implement the handler to handle unrecoverable AER errors

2018-03-13 Thread Venu Busireddy

Implement the callback function to handle unrecoverable AER errors, and
also the public APIs that can be used to register/unregister the handler.
When an AER error occurs, the handler will forcibly remove the erring
PCIe device from the guest.

Signed-off-by: Venu Busireddy 
---
 tools/libxl/libxl.h  |   7 +++
 tools/libxl/libxl_event.h|   7 +++
 tools/libxl/libxl_internal.h |   8 +++
 tools/libxl/libxl_pci.c  | 123 +++
 4 files changed, 145 insertions(+)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index eca0ea2c50..99a3c8ae1f 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1120,6 +1120,13 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
const libxl_mac *src);
  */
 #define LIBXL_HAVE_PV_SHIM 1
 
+/* LIBXL_HAVE_AER_EVENTS_HANDLER
+ *
+ * If this is defined, libxl has the library functions called
+ * libxl_reg_aer_events_handler and libxl_unreg_aer_events_handler.
+ */
+#define LIBXL_HAVE_AER_EVENTS_HANDLER 1
+
 typedef char **libxl_string_list;
 void libxl_string_list_dispose(libxl_string_list *sl);
 int libxl_string_list_length(const libxl_string_list *sl);
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 1ea789e231..63c29ae800 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -184,6 +184,13 @@ void libxl_evdisable_domain_death(libxl_ctx *ctx, 
libxl_evgen_domain_death*);
* may generate only a DEATH event.
*/
 
+typedef struct libxl__aer_watch libxl_aer_watch;
+int libxl_reg_aer_events_handler(libxl_ctx *, uint32_t);
+  /*
+   * Registers a handler to handle the occurrence of unrecoverable AER errors.
+   */
+void libxl_unreg_aer_events_handler(libxl_ctx *, uint32_t);
+
 typedef struct libxl__evgen_disk_eject libxl_evgen_disk_eject;
 int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t domid, const char *vdev,
 libxl_ev_user, libxl_evgen_disk_eject **evgen_out);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 506687fbe9..7972490050 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -356,6 +356,14 @@ struct libxl__ev_child {
 LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
 };
 
+/*
+ * Structure used for AER event handling.
+ */
+struct libxl__aer_watch {
+uint32_t domid;
+libxl__ev_xswatch watch;
+struct libxl__aer_watch *next;
+};
 
 /*
  * evgen structures, which are the state we use for generating
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4755a0c93c..c121c9f8cc 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1686,6 +1686,129 @@ static int libxl_device_pci_compare(libxl_device_pci 
*d1,
 return COMPARE_PCI(d1, d2);
 }
 
+static void aer_backend_watch_callback(libxl__egc *egc,
+   libxl__ev_xswatch *watch,
+   const char *watch_path,
+   const char *event_path)
+{
+EGC_GC;
+libxl_aer_watch *aer_ws = CONTAINER_OF(watch, *aer_ws, watch);
+int rc;
+uint32_t dom, bus, dev, fn;
+uint32_t domid = aer_ws->domid;
+char *p, *path;
+const char *aerFailedSBDF;
+libxl_device_pci pcidev;
+
+/* Extract the backend directory. */
+path = libxl__strdup(gc, event_path);
+p = strrchr(path, '/');
+if ((p == NULL) || (strcmp(p, "/aerFailedSBDF") != 0))
+return;
+/* Truncate the string so it points to the backend directory. */
+*p = '\0';
+
+/* Fetch the value of the failed PCI device. */
+rc = libxl__xs_read_checked(gc, XBT_NULL,
+GCSPRINTF("%s/aerFailedSBDF", path), );
+if (rc || !aerFailedSBDF)
+return;
+LOGD(ERROR, domid, " aerFailedSBDF = %s", aerFailedSBDF);
+sscanf(aerFailedSBDF, "%x:%x:%x.%x", , , , );
+
+libxl_device_pci_init();
+pcidev_struct_fill(, dom, bus, dev, fn, 0);
+/* Forcibly remove the device from the guest */
+rc = libxl__device_pci_remove_common(gc, domid, , 1);
+if (rc)
+LOGD(ERROR, domid, " libxl__device_pci_remove_common() failed, rc=x%x",
+(unsigned int)rc);
+
+return;
+}
+
+static libxl_aer_watch *manage_aer_ws_list(libxl_aer_watch *in, uint32_t domid)
+{
+static libxl_aer_watch *aer_ws = NULL;
+libxl_aer_watch *iter, *prev = NULL;
+
+if (in) {
+if (aer_ws)
+in->next = aer_ws;
+iter = aer_ws = in;
+} else {
+iter = aer_ws;
+while (iter) {
+if (iter->domid == domid) {
+if (prev)
+prev->next = iter->next;
+else
+aer_ws = iter->next;
+break;
+}
+prev = iter;
+iter = iter->next;
+}
+}
+return iter;
+}
+
+static void store_aer_ws(libxl_aer_watch *aer_ws)
+{
+manage_aer_ws_list(aer_ws, 0);
+return;
+}
+

[Xen-devel] [PATCH v5 2/2] xl: Register the AER event handler that handles AER errors

2018-03-13 Thread Venu Busireddy

When a guest is created, register the AER event handler to handle the
AER errors. When an AER error occurs, the handler will forcibly remove
the erring PCIe device from the guest.

Signed-off-by: Venu Busireddy 
Signed-off-by: Wim Ten Have 
---
 tools/libxl/libxl_create.c | 11 +--
 tools/libxl/libxl_domain.c |  1 +
 tools/xl/xl_vmcontrol.c| 14 +-
 3 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index c498135246..2d247da5f0 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1663,7 +1663,7 @@ static int do_domain_create(libxl_ctx *ctx, 
libxl_domain_config *d_config,
 {
 AO_CREATE(ctx, 0, ao_how);
 libxl__app_domain_create_state *cdcs;
-int rc;
+int rc, ao_rc;
 
 GCNEW(cdcs);
 cdcs->dcs.ao = ao;
@@ -1698,7 +1698,14 @@ static int do_domain_create(libxl_ctx *ctx, 
libxl_domain_config *d_config,
 
 initiate_domain_create(egc, >dcs);
 
-return AO_INPROGRESS;
+ao_rc = AO_INPROGRESS;
+rc = libxl_reg_aer_events_handler(ctx, *domid);
+if (rc) {
+/* Log the error, and move on... */
+LOGD(ERROR, *domid,
+"libxl_reg_aer_events_handler() failed, rc = %d", rc);
+}
+return ao_rc;
 
  out_err:
 return AO_CREATE_FAIL(rc);
diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 13b1c73d40..b8fb5e0349 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -906,6 +906,7 @@ void libxl__domain_destroy(libxl__egc *egc, 
libxl__domain_destroy_state *dds)
 STATE_AO_GC(dds->ao);
 uint32_t stubdomid = libxl_get_stubdom_id(CTX, dds->domid);
 
+libxl_unreg_aer_events_handler(CTX, dds->domid);
 if (stubdomid) {
 dds->stubdom.ao = ao;
 dds->stubdom.domid = stubdomid;
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
index 89c2b25ded..5bf415fa6e 100644
--- a/tools/xl/xl_vmcontrol.c
+++ b/tools/xl/xl_vmcontrol.c
@@ -945,8 +945,11 @@ start:
 libxl_domain_unpause(ctx, domid);
 
 ret = domid; /* caller gets success in parent */
-if (!daemonize && !monitor)
+if (!daemonize && !monitor) {
+/* Unregister aer events handler before returning/exiting */
+libxl_unreg_aer_events_handler(ctx, domid);
 goto out;
+}
 
 if (dom_info->vnc)
 autoconnect_vncviewer(domid, vncautopass);
@@ -958,9 +961,17 @@ start:
 ret = do_daemonize(name, NULL);
 free(name);
 if (ret) {
+/* Unregister aer events handler before returning/exiting */
+libxl_unreg_aer_events_handler(ctx, domid);
 ret = (ret == 1) ? domid : ret;
 goto out;
 }
+/* Child has new ctx. Re-register the events handler in child's ctx */
+ret = libxl_reg_aer_events_handler(ctx, domid);
+if (ret) {
+/* Log the error, and move on... */
+LOG("libxl_reg_aer_events_handler() failed, ret = %d", ret);
+}
 need_daemon = 0;
 }
 LOG("Waiting for domain %s (domid %u) to die [pid %ld]",
@@ -1059,6 +1070,7 @@ start:
 
 case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
 LOG("Domain %u has been destroyed.", domid);
+libxl_unreg_aer_events_handler(ctx, domid);
 libxl_event_free(ctx, event);
 ret = 0;
 goto out;

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

[Xen-devel] [PATCH v5 0/2] Containing AER unrecoverable errors

2018-03-13 Thread Venu Busireddy

This patch set is part of a set of patches that together allow containment
of unrecoverable AER errors from PCIe devices assigned to guests in
passthrough mode. The containment is achieved by forcibly removing the
erring PCIe device from the guest.

The original xen-pciback patch corresponding to this patch set is:
https://lists.xen.org/archives/html/xen-devel/2017-06/msg03274.html.
It will be reposted after this patch set is accepted.

Changes in v5:
  * v4 worked only in the case of guests created using 'xl' command.
Enhanced the fix to work for guests created using libvirt too.

Changes in v4:
  * Made the following changes suggested by Wei Liu.
- Combine multiple LIBXL_HAVE_* definitions into one.
- Use libxl__calloc() instead of malloc().

Changes in v3:
  * Made the following changes suggested by Wei Liu.
- Added LIBXL_HAVE macros to libxl.h.
- Don't hard-code dom0's domid to 0. Instead, use libxl__get_domid().
- Corrected comments.
  * Made the following changes based on comments from Ian Jackson.
- Got rid of the global variable aer_watch.
- Added documentation (comments in code) for the new API calls.
- Removed the unnecessary writes to xenstore.

Changes in v2:
  - Instead of killing the guest and hiding the device, forcibly remove
the device from the guest.

Venu Busireddy (2):
  libxl: Implement the handler to handle unrecoverable AER errors
  xl: Register the AER event handler that handles AER errors

 tools/libxl/libxl.h  |   7 +++
 tools/libxl/libxl_create.c   |  11 +++-
 tools/libxl/libxl_domain.c   |   1 +
 tools/libxl/libxl_event.h|   7 +++
 tools/libxl/libxl_internal.h |   8 +++
 tools/libxl/libxl_pci.c  | 123 +++
 tools/xl/xl_vmcontrol.c  |  14 -
 7 files changed, 168 insertions(+), 3 deletions(-)


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

Re: [Xen-devel] Modifying domain creation interface

2018-03-13 Thread Juergen Gross

On 13/03/18 17:08, Wei Liu wrote:
> On Wed, Feb 21, 2018 at 03:08:23PM +0100, Juergen Gross wrote:
>> Creating a new domain currently is a sequence of hypercalls with many of
>> those being mandatory and needed in a specific sequence. Its has been
>> discussed before to build a new interface for domain creation with _all_
>> the mandatory information passed to the hypervisor in one hypercall.
>>
>> I'd like to suggest to extend this idea even more: instead of passing
>> the mandatory data only we could even add some optional data in a
>> generic way. Instead of extending the binary interface each time a new
>> configurable parameter is added for domains we could use a text based
>> interface for that purpose, similar to the boot parameters of the
>> hypervisor or the kernel. So instead adding e.g. a new flag for
>> switching the Meltdown mitigation on or off for a specific domain (this
>> example is the reason I thought of the new interface) to
>> xen_domctl_createdomain.flags we could pass a string "xpti=off" to the
>> hypervisor in the domain create hypercall parameters. Passing an array
>> of strings plus the number of array elements would allow to extend the
>> interface without having to change any header file.
>>
>> It would even be possible to have something like:
>>
>> domain_params=[ "xpti=off", "param_xy=foo" ]
>>
>> in the xl config file of a domain allowing to specify new parameters
>> without having to modify xl/libxl. This would allow backports of
>> security patches which need some per-domain configuration aid (some
>> SUSE customers already asked for a way to switch Meltdown mitigation
>> on a per-domain basis in old versions).
>>
> 
> This is yet another way to configure a domain. What is your thought
> going forward? I certainly don't want to have more than one way to
> configure some aspects of a domain.

The hypervisor should accept only one way of configuration for each
parameter: either the traditional one (e.g. max. numbers of vcpus) or
the new textual interface (e.g. "xpti=...").

Same for the tools: in case xl knows about a textual parameter it
shouldn't accept it in the "domain_params=[..." form.

> Say, we want to introduce parameter foo, do we support foo=bar in
> domain_params only? Do we allow foo=bar as top-level option?

This would depend on each parameter I guess.

> A problem I can see is that it would make it harder for toolstack to
> reject incompatible options during migration -- it can't know until it
> actually tries to (re)create the guest with the same parameters. But
> what we have today isn't perfect either.

Right.

>> Security is a point to be looked at, of course. OTOH it should be quite
>> easy to use a fuzzer for proving the parser to be secure, as the parser
>> can be constructed to be testable in user environment (like e.g. the
>> x86 instruction emulator).
>>
> 
> One way to deal with that is to say we trust the configuration file
> completely so bugs in parser won't be security issues.

I was thinking of the parser in the hypervisor. It shouldn't crash the
system.


Juergen

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

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


On 3/13/2018 10:16 AM, Roger Pau Monné wrote:

On Tue, Mar 13, 2018 at 09:55:20AM -0700, Maran Wilson wrote:

On 3/13/2018 9:34 AM, Jan Beulich wrote:

On 13.03.18 at 17:20,  wrote:

On 3/13/2018 3:50 AM, Roger Pau Monné wrote:

On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote:

@@ -62,10 +72,34 @@
 *| reserved   |
 * 32 ++
 *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ *  0 ++
+ *| addr   | Base address
+ *  8 ++
+ *| size   | Size of mapping in bytes
+ * 16 ++
+ *| type   | Type of mapping as defined between the hypervisor
+ *|| and guest it's starting. E820_TYPE_xxx, for example.

This needs a link to the expected type values (or a reference). Or you
need to spell out the relation between the values and the memory types.

This field was discussed a good deal in v2 of the linux patches. I had
originally defined this to be a specific type field, matching the
x86/Linux definition for e820 memory mapping types. But Jan Beulich
successfully argued that we should keep the definition of this
particular interface agnostic to architecture and OS and not limit the
field to specific values. I believe the central idea behind Jan's
argument was to keep the interface x86-agnostic as well as preserving
the option to add additional memory mapping types in the future without
them being sanctioned by whoever maintains E820 type assignments.

That's why I changed the comment wording to what it is now. Basically
spelling out the fact that this field simply needs to be agreed upon
between the producer and the consumer since a hypervisor should
generally know what type of guest it is starting. And I mentioned
e820_type_xxx as the *example* of one such implementation, since that is
the most obvious use case and the e820 types are part of the ACPI
standard (and thus easy to find/reference).

But Roger makes a valid remark here. Statements like
"E820_TYPE_xxx, for example" are simply to vague for a stable public
interface.

How about "For example, E820 types like E820_RAM, E820_ACPI, etc as defined
in xen/include/asm-x86/e820.h of the Xen tree" ?

No, it needs to be in a public header, e820.h is private to Xen.

I would recommend that you list the types in this header, specifying
that the 'type' values are arch-specific, and that this is the x86
specific interface.


Can I provide that list in a comment block? Or are you saying you want 
me to create new #define values in this header file to enumerate the 
possible range of "type" values for x86 guests?


I'd prefer to avoid the latter since I would be redefining values that 
most certainly are already defined in every source tree where this 
header file is likely to show up. But if folks feel it is necessary, 
I'll add the symbols here.



You likely also want to reference the section of
the ACPI spec where those types are defined, so that the reader can
figure out it's exact meaning.


Sure, I can add that. I'm thinking something like:

   For x86 guests, please see "Address Range Types" as defined in 
section 15 (System Address Map Interfaces) of the ACPI Specification 
(http://uefi.org/specifications)


Thanks,
-Maran



Thanks, Roger.

___
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] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

2018-03-13 Thread Juergen Gross

On 13/03/18 18:51, Boris Ostrovsky wrote:
> 
> 
> On 03/13/2018 01:27 AM, Juergen Gross wrote:
>> On 12/03/18 20:26, Sander Eikelenboom wrote:
>>> Hi Juergen,
>>>
>>> I don't know by which tree those patches should arrive at Linus,
>>> so i can't check if they fell through the cracks somewhere, but 4.16-rc5
>>> hasn't got them yet.
>>
>> They are queued for 4.17 in:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/boot
> 
> 
> I may not be looking at the right place but I don't see it there:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tree/arch/x86/xen/enlighten_pvh.c?h=x86/boot

Aah, seems as if Ingo has merged the patches into x86/mm and x86/boot
has been re-inited again. Look at:

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tree/arch/x86/xen/enlighten_pvh.c?h=x86/mm


Juergen

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

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

On Wed, Mar 14, 2018 at 03:58:17AM +1000, Alexey G wrote:
> On Tue, 13 Mar 2018 17:26:04 +
> Wei Liu  wrote:
> 
> >On Tue, Mar 13, 2018 at 04:33:48AM +1000, Alexey Gerasimenko wrote:
> >> This adds a new function get_pc_machine_type() which allows to
> >> determine the emulated chipset type. Supported return values:
> >> 
> >> - MACHINE_TYPE_I440
> >> - MACHINE_TYPE_Q35
> >> - MACHINE_TYPE_UNKNOWN, results in the error message being printed
> >>   followed by calling BUG() in hvmloader.
> >> 
> >> Signed-off-by: Alexey Gerasimenko 
> >> ---
> >>  tools/firmware/hvmloader/pci_regs.h |  5 
> >>  tools/firmware/hvmloader/util.c | 47
> >> +
> >> tools/firmware/hvmloader/util.h |  8 +++ 3 files changed, 60
> >> insertions(+)
> >> 
> >> diff --git a/tools/firmware/hvmloader/pci_regs.h
> >> b/tools/firmware/hvmloader/pci_regs.h index 7bf2d873ab..ba498b840e
> >> 100644 --- a/tools/firmware/hvmloader/pci_regs.h
> >> +++ b/tools/firmware/hvmloader/pci_regs.h
> >> @@ -107,6 +107,11 @@
> >>  
> >>  #define PCI_INTEL_OPREGION 0xfc /* 4 bits */
> >>  
> >> +#define PCI_VENDOR_ID_INTEL  0x8086
> >> +#define PCI_DEVICE_ID_INTEL_824410x1237
> >> +#define PCI_DEVICE_ID_INTEL_Q35_MCH  0x29c0
> >> +
> >> +  
> >
> >Too many blank lines.
> 
> Will fix.
> 
> >> @@ -735,6 +736,52 @@ void __bug(char *file, int line)
> >>  crash();
> >>  }
> >>  
> >> +/* only Intel platforms are emulated currently */
> >> +if (vendor_id == PCI_VENDOR_ID_INTEL)  
> >
> >Coding style.
> >
> >Ditto.
> 
> Will fix.
> 
> >And this patch should be folded into its user, unless the patch that
> >uses it is very big on its own.
> 
> Hmm, looks like I overfollowed the recommendation about making atomic
> patches for easier review. There are multiple users of these function,
> it was made in a separate patch just because of this. In the next
> version I'll merge it with some of the patches which use this function
> then.

It really depends. It will take some back-and-forth to find the right
balance. I can't say I'm very consistent on this either.

If you think leaving it in a separate patch is better, I won't object.

Wei.

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

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

2018-03-13 Thread Boris Ostrovsky




On 03/13/2018 01:27 AM, Juergen Gross wrote:

On 12/03/18 20:26, Sander Eikelenboom wrote:

Hi Juergen,

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


They are queued for 4.17 in:

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



I may not be looking at the right place but I don't see it there:

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tree/arch/x86/xen/enlighten_pvh.c?h=x86/boot

-boris

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

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

2018-03-13 Thread Alexey G

On Tue, 13 Mar 2018 17:26:04 +
Wei Liu  wrote:

>On Tue, Mar 13, 2018 at 04:33:48AM +1000, Alexey Gerasimenko wrote:
>> This adds a new function get_pc_machine_type() which allows to
>> determine the emulated chipset type. Supported return values:
>> 
>> - MACHINE_TYPE_I440
>> - MACHINE_TYPE_Q35
>> - MACHINE_TYPE_UNKNOWN, results in the error message being printed
>>   followed by calling BUG() in hvmloader.
>> 
>> Signed-off-by: Alexey Gerasimenko 
>> ---
>>  tools/firmware/hvmloader/pci_regs.h |  5 
>>  tools/firmware/hvmloader/util.c | 47
>> +
>> tools/firmware/hvmloader/util.h |  8 +++ 3 files changed, 60
>> insertions(+)
>> 
>> diff --git a/tools/firmware/hvmloader/pci_regs.h
>> b/tools/firmware/hvmloader/pci_regs.h index 7bf2d873ab..ba498b840e
>> 100644 --- a/tools/firmware/hvmloader/pci_regs.h
>> +++ b/tools/firmware/hvmloader/pci_regs.h
>> @@ -107,6 +107,11 @@
>>  
>>  #define PCI_INTEL_OPREGION 0xfc /* 4 bits */
>>  
>> +#define PCI_VENDOR_ID_INTEL  0x8086
>> +#define PCI_DEVICE_ID_INTEL_824410x1237
>> +#define PCI_DEVICE_ID_INTEL_Q35_MCH  0x29c0
>> +
>> +  
>
>Too many blank lines.

Will fix.

>> @@ -735,6 +736,52 @@ void __bug(char *file, int line)
>>  crash();
>>  }
>>  
>> +/* only Intel platforms are emulated currently */
>> +if (vendor_id == PCI_VENDOR_ID_INTEL)  
>
>Coding style.
>
>Ditto.

Will fix.

>And this patch should be folded into its user, unless the patch that
>uses it is very big on its own.

Hmm, looks like I overfollowed the recommendation about making atomic
patches for easier review. There are multiple users of these function,
it was made in a separate patch just because of this. In the next
version I'll merge it with some of the patches which use this function
then.

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

Re: [Xen-devel] [PATCH 1/2] libxl: Add a version check of QEMU for QMP commands

2018-03-13 Thread Anthony PERARD

On Tue, Mar 13, 2018 at 05:40:08PM +, Wei Liu wrote:
> On Tue, Mar 13, 2018 at 11:13:17AM +, Anthony PERARD wrote:
> > On connection to QEMU via QMP, the version of QEMU is provided, store it
> > for later use.
> > 
> > Add a function qmp_qemu_check_version that can be used to check if QEMU
> > is new enough for certain fonctionnality. This will be used in a moment.
> > 
> > As it's a static function, it is commented out until first use, which is
> > in the next patch.
> > 
> > Signed-off-by: Anthony PERARD 
> > ---
> >  tools/libxl/libxl_qmp.c | 31 ++-
> >  1 file changed, 30 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> > index eab993aca9..b1c6598cf7 100644
> > --- a/tools/libxl/libxl_qmp.c
> > +++ b/tools/libxl/libxl_qmp.c
> > @@ -75,6 +75,11 @@ struct libxl__qmp_handler {
> >  
> >  int last_id_used;
> >  LIBXL_STAILQ_HEAD(callback_list, callback_id_pair) callback_list;
> > +struct {
> > +int major;
> > +int minor;
> > +int micro;
> > +} version;
> >  };
> >  
> >  static int qmp_send(libxl__qmp_handler *qmp,
> > @@ -296,9 +301,22 @@ static int qmp_handle_response(libxl__gc *gc, 
> > libxl__qmp_handler *qmp,
> >  LOGD(DEBUG, qmp->domid, "message type: %s", 
> > libxl__qmp_message_type_to_string(type));
> >  
> >  switch (type) {
> > -case LIBXL__QMP_MESSAGE_TYPE_QMP:
> > +case LIBXL__QMP_MESSAGE_TYPE_QMP: {
> > +const libxl__json_object *o;
> > +o = libxl__json_map_get("QMP", resp, JSON_MAP);
> > +o = libxl__json_map_get("version", o, JSON_MAP);
> > +o = libxl__json_map_get("qemu", o, JSON_MAP);
> > +qmp->version.major = libxl__json_object_get_integer(
> > +libxl__json_map_get("major", o, JSON_INTEGER));
> > +qmp->version.minor = libxl__json_object_get_integer(
> > +libxl__json_map_get("minor", o, JSON_INTEGER));
> > +qmp->version.micro = libxl__json_object_get_integer(
> > +libxl__json_map_get("micro", o, JSON_INTEGER));
> > +LOGD(DEBUG, qmp->domid, "QEMU version: %d.%d.%d",
> > + qmp->version.major, qmp->version.minor, qmp->version.micro);
> >  /* On the greeting message from the server, enable QMP 
> > capabilities */
> >  return enable_qmp_capabilities(qmp);
> > +}
> 
> Are those fields available in QMP in all the versions we care about?

I don't care if the field is available or not, the result would be a
QEMU version -1.-1.-1 This is why I did not do any check here to find
out if a particular value exist.  But the version field is part of the
QMP protocol, so it should be there.

Also yes, the field is available in all QEMU version we care about, e.i.
QEMU 2.11 and later. That information is not usefull for older version
of QEMU.

> If so, 
> 
> Acked-by: Wei Liu 

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v10] x86/altp2m: support for setting restrictions for an array of pages

On Wed, Dec 13, 2017 at 04:22:20PM +0200, Petre Pircalabu wrote:
>  /** 
>   * Mem paging operations.
> diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
> index 07fcd18..0f792b5 100644
> --- a/tools/libxc/xc_altp2m.c
> +++ b/tools/libxc/xc_altp2m.c
> @@ -213,3 +213,44 @@ int xc_altp2m_change_gfn(xc_interface *handle, uint32_t 
> domid,
>  return rc;
>  }
>  
> +int xc_altp2m_set_mem_access_multi(xc_interface *xch, uint32_t domid,
> +   uint16_t view_id, uint8_t *access,
> +   uint64_t *pages, uint32_t nr)
> +{
> +int rc;
> +
> +DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
> +DECLARE_HYPERCALL_BOUNCE(access, nr * sizeof(*access),
> + XC_HYPERCALL_BUFFER_BOUNCE_IN);
> +DECLARE_HYPERCALL_BOUNCE(pages, nr * sizeof(*pages),
> + XC_HYPERCALL_BUFFER_BOUNCE_IN);
> +
> +arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
> +if ( arg == NULL )
> +return -1;
> +
> +arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
> +arg->cmd = HVMOP_altp2m_set_mem_access_multi;
> +arg->domain = domid;
> +arg->u.set_mem_access_multi.view = view_id;
> +arg->u.set_mem_access_multi.nr = nr;
> +
> +if ( xc_hypercall_bounce_pre(xch, pages) ||
> + xc_hypercall_bounce_pre(xch, access) )
> +{
> +PERROR("Could not bounce memory for 
> HVMOP_altp2m_set_mem_access_multi");
> +return -1;
> +}
> +
> +set_xen_guest_handle(arg->u.set_mem_access_multi.pfn_list, pages);
> +set_xen_guest_handle(arg->u.set_mem_access_multi.access_list, access);
> +
> +rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
> +   HYPERCALL_BUFFER_AS_ARG(arg));

Tabs here.

With this fixed, libxc bits:

Acked-by: Wei Liu 


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

Re: [Xen-devel] [PATCH 2/2] libxl_qmp: Tell QEMU about live migration or snapshot

On Tue, Mar 13, 2018 at 11:13:18AM +, Anthony PERARD wrote:
> Since version 2.10, QEMU will lock the disk images so a second QEMU
> instance will not try to open it. This would prevent live migration from
> working correctly. A new parameter as been added to the QMP command
> "xen-save-devices-state" in QEMU version 2.11 which allow to unlock the
> disk image for a live migration, but also keep it locked for a snapshot.
> 
> QEMU commit: 5d6c599fe1d69a1bf8c5c4d3c58be2b31cd625ad
> "migration, xen: Fix block image lock issue on live migration"
> 
> The extra "live" parameter can only be use if QEMU knows about it, so
> only add it if qemu is recent enough.
> 
> The struct libxl__domain_suspend_state as now knowledge if the suspend
> is part of a live migration.
> 
> Signed-off-by: Anthony PERARD 

Acked-by: Wei Liu 

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

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

2018-03-13 Thread Roger Pau Monné

On Tue, Mar 13, 2018 at 09:55:20AM -0700, Maran Wilson wrote:
> On 3/13/2018 9:34 AM, Jan Beulich wrote:
> > > > > On 13.03.18 at 17:20,  wrote:
> > > On 3/13/2018 3:50 AM, Roger Pau Monné wrote:
> > > > On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote:
> > > > > @@ -62,10 +72,34 @@
> > > > > *| reserved   |
> > > > > * 32 ++
> > > > > *
> > > > > + * The layout of each entry in the memory map table is as follows:
> > > > > + *
> > > > > + *  0 ++
> > > > > + *| addr   | Base address
> > > > > + *  8 ++
> > > > > + *| size   | Size of mapping in bytes
> > > > > + * 16 ++
> > > > > + *| type   | Type of mapping as defined between the 
> > > > > hypervisor
> > > > > + *|| and guest it's starting. E820_TYPE_xxx, for 
> > > > > example.
> > > > This needs a link to the expected type values (or a reference). Or you
> > > > need to spell out the relation between the values and the memory types.
> > > This field was discussed a good deal in v2 of the linux patches. I had
> > > originally defined this to be a specific type field, matching the
> > > x86/Linux definition for e820 memory mapping types. But Jan Beulich
> > > successfully argued that we should keep the definition of this
> > > particular interface agnostic to architecture and OS and not limit the
> > > field to specific values. I believe the central idea behind Jan's
> > > argument was to keep the interface x86-agnostic as well as preserving
> > > the option to add additional memory mapping types in the future without
> > > them being sanctioned by whoever maintains E820 type assignments.
> > > 
> > > That's why I changed the comment wording to what it is now. Basically
> > > spelling out the fact that this field simply needs to be agreed upon
> > > between the producer and the consumer since a hypervisor should
> > > generally know what type of guest it is starting. And I mentioned
> > > e820_type_xxx as the *example* of one such implementation, since that is
> > > the most obvious use case and the e820 types are part of the ACPI
> > > standard (and thus easy to find/reference).
> > But Roger makes a valid remark here. Statements like
> > "E820_TYPE_xxx, for example" are simply to vague for a stable public
> > interface.
> 
> How about "For example, E820 types like E820_RAM, E820_ACPI, etc as defined
> in xen/include/asm-x86/e820.h of the Xen tree" ?

No, it needs to be in a public header, e820.h is private to Xen.

I would recommend that you list the types in this header, specifying
that the 'type' values are arch-specific, and that this is the x86
specific interface. You likely also want to reference the section of
the ACPI spec where those types are defined, so that the reader can
figure out it's exact meaning.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 39/57] ARM: new VGIC: Add ACTIVE registers handlers


Hi,

On 13/03/18 17:34, Andre Przywara wrote:

On 13/03/18 17:14, Julien Grall wrote:

On 13/03/18 17:02, Andre Przywara wrote:

On 08/03/18 15:39, Julien Grall wrote:

On 05/03/18 16:03, Andre Przywara wrote:

I can't see how a knowledgeable admin will be able to know that IRQ 2 is
active with just the register value.


Well, I was assuming that a really knowledgeable admin would somehow
forward the error message either to the ML or at least to $search_engine.
...


Surely, but it does not mean the message should be clueless for the 
developer. I would rather no spent 10 min to try to find out what's 
going on where reading logs...





Does that sound OK?


I would still prefer the one per IRQ and using printk(XENLOG_G_*).


I really don't think one per IRQ is too useful. A developer however can
easily deal with "IRQ45, value: 0x00802000" from a log. And can deduce
from there that it's about IRQ45 and IRQ55. Following the example above
you would either see one "IRQ32, value: 0x" or "IRQ 45, value:
0x2000".


I still can't see how the developer would know the IRQ55 is active or 
not. That's the whole purpose of the per IRQ.



That looks like a good compromise between readability (having the IRQ
number for admins) and brevity.


You may save 10 characters on the logs, you likely going to waste 10 min 
of the developer to understand what that messages really mean.




I changed it now to output:
%pv: vGICD: clearing active state not supported (IRQ%u, value: 0x%08lx)


I don't much care about the spam, see why above.


Having them on the console between Dom0 messages is really scary, but
not helpful if it's *more* than one. Since it's a known limitation of
the VGIC emulation, not a real "error" in that sense.


It is the same as having any Xen messages interleaved with Dom0 
messages. If the user is not happy with that, then it can divert Dom0 
console to another UART.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/2] libxl: Add a version check of QEMU for QMP commands

On Tue, Mar 13, 2018 at 11:13:17AM +, Anthony PERARD wrote:
> On connection to QEMU via QMP, the version of QEMU is provided, store it
> for later use.
> 
> Add a function qmp_qemu_check_version that can be used to check if QEMU
> is new enough for certain fonctionnality. This will be used in a moment.
> 
> As it's a static function, it is commented out until first use, which is
> in the next patch.
> 
> Signed-off-by: Anthony PERARD 
> ---
>  tools/libxl/libxl_qmp.c | 31 ++-
>  1 file changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index eab993aca9..b1c6598cf7 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -75,6 +75,11 @@ struct libxl__qmp_handler {
>  
>  int last_id_used;
>  LIBXL_STAILQ_HEAD(callback_list, callback_id_pair) callback_list;
> +struct {
> +int major;
> +int minor;
> +int micro;
> +} version;
>  };
>  
>  static int qmp_send(libxl__qmp_handler *qmp,
> @@ -296,9 +301,22 @@ static int qmp_handle_response(libxl__gc *gc, 
> libxl__qmp_handler *qmp,
>  LOGD(DEBUG, qmp->domid, "message type: %s", 
> libxl__qmp_message_type_to_string(type));
>  
>  switch (type) {
> -case LIBXL__QMP_MESSAGE_TYPE_QMP:
> +case LIBXL__QMP_MESSAGE_TYPE_QMP: {
> +const libxl__json_object *o;
> +o = libxl__json_map_get("QMP", resp, JSON_MAP);
> +o = libxl__json_map_get("version", o, JSON_MAP);
> +o = libxl__json_map_get("qemu", o, JSON_MAP);
> +qmp->version.major = libxl__json_object_get_integer(
> +libxl__json_map_get("major", o, JSON_INTEGER));
> +qmp->version.minor = libxl__json_object_get_integer(
> +libxl__json_map_get("minor", o, JSON_INTEGER));
> +qmp->version.micro = libxl__json_object_get_integer(
> +libxl__json_map_get("micro", o, JSON_INTEGER));
> +LOGD(DEBUG, qmp->domid, "QEMU version: %d.%d.%d",
> + qmp->version.major, qmp->version.minor, qmp->version.micro);
>  /* On the greeting message from the server, enable QMP capabilities 
> */
>  return enable_qmp_capabilities(qmp);
> +}

Are those fields available in QMP in all the versions we care about?

If so, 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 39/57] ARM: new VGIC: Add ACTIVE registers handlers

2018-03-13 Thread Andre Przywara

Hi,

On 13/03/18 17:14, Julien Grall wrote:
> Hi Andre,
> 
> On 13/03/18 17:02, Andre Przywara wrote:
>> On 08/03/18 15:39, Julien Grall wrote:
>>> On 05/03/18 16:03, Andre Przywara wrote:
 +/*
 + * We don't actually support clearing the active state of an IRQ
 (yet).
 + * However there is a chance that most guests use this for
 initialization.
 + * We check whether this MMIO access would actually affect any active
 IRQ,
 + * and only print our warning in this case. So clearing already
 non-active
 + * IRQs would not be moaned about in the logs.
 + */
 +void vgic_mmio_write_cactive(struct vcpu *vcpu,
 + paddr_t addr, unsigned int len,
 + unsigned long val)
 +{
 +    uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
 +    unsigned int i;
 +    bool bail_out = false;
 +
 +    for_each_set_bit( i, , len * 8 )
 +    {
 +    struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid
 + i);
 +
 +    /*
 + * If we know that the IRQ is active or we can't be sure about
 + * it (because it is currently in a CPU), log the not properly
 + * emulated MMIO access.
 + */
 +    if ( irq->active || irq->vcpu )
 +    {
 +    gdprintk(XENLOG_ERR,
 + "%pv: vGICD: IRQ%d: clearing active state not
 supported\n",
>>>
>>> s/%d/%u/
>>>
 + vcpu, irq->intid);
>>>
>>> gdprintk will always print the vCPU. Thought it is the current which
>>> might be different from vcpu (mostly in the re-dist case).
>>
>> Ah, thanks. I always get confused about what which version of *printk
>> does.
>>
>>> So I would use dprintk(XENLOG_G_ERR, "%pv: ..."). I would even be tempt
>>> to use printk() so we can spot potential issue on non-debug build.
>>
>> Well, in the true spirit of Xen paranoia ;-) I wanted to avoid a guest
>> spamming the console.
> 
> The guests messages are rate limited.

Ah ...

>> And in the end there is nothing a administrator
>> could really do about it. In my experience those messages tend to really
>> scare users ("I could boot Dom0 but I see those error messages ").
> 
> Xen message are not only here for the administrator, they are also here
> to help for the developer to get log to dissect.

Sure, see below ...

> I think that particular message should be printed in non-debug build
> because if the interrupt was active and can't clear it. Then something
> will go wrong later on.

Fair enough, if it's rate limited ...

 +    bail_out = true;
>>>
>>> I admit the bailout is a bit weird here. You would only print the
>>> warning for the first activated IRQ and give the impression it is fine
>>> for the rest. So maybe you want to drop IRQ%d?
>>
>> For the above reasons I wanted to keep them concise, so that we see that
>> the issue has happened, but avoid getting tons of error messages about
>> the same problem (as this may affect up to 32 IRQs).
>> But for debugging it might be good to know which IRQ was affected. I see
>> two use cases for a guest:
>> - (De-)activating a single IRQ: we get one message and know which IRQ it
>> was, so an admin can chase this down to a certain device (driver).
>> - (De-)activating *every* IRQ in this range (~0): we still get one
>> message per 32 IRQs, but can see whether it covers SPIs only (IRQ>=32)
>> and which ones.
>>
>> So what about a compromise: I use dprintk(XENLOG_G_ERR, "%pv ...), print
>> the (first) IRQ and the *value* to be written. So a knowledgeable admin
>> can tell whether it's a single IRQ or a "clear/set-all" case. That
>> should also give enough info for debugging, but keeps it short.
> 
> I can't see how a knowledgeable admin will be able to know that IRQ 2 is
> active with just the register value.

Well, I was assuming that a really knowledgeable admin would somehow
forward the error message either to the ML or at least to $search_engine.
...

>> Does that sound OK?
> 
> I would still prefer the one per IRQ and using printk(XENLOG_G_*).

I really don't think one per IRQ is too useful. A developer however can
easily deal with "IRQ45, value: 0x00802000" from a log. And can deduce
from there that it's about IRQ45 and IRQ55. Following the example above
you would either see one "IRQ32, value: 0x" or "IRQ 45, value:
0x2000".
That looks like a good compromise between readability (having the IRQ
number for admins) and brevity.

I changed it now to output:
%pv: vGICD: clearing active state not supported (IRQ%u, value: 0x%08lx)

> I don't much care about the spam, see why above.

Having them on the console between Dom0 messages is really scary, but
not helpful if it's *more* than one. Since it's a known limitation of
the VGIC emulation, not a real "error" in that sense.

Cheers,
Andre.

___
Xen-devel mailing list

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

2018-03-13 Thread Anthony PERARD

On Tue, Mar 13, 2018 at 05:25:50PM +, Wei Liu wrote:
> Cc Anthony
> 
> IIRC there are changes needed on QEMU side?

Yes, there are actually QEMU patches in the patch series. I'm CCed on
them.

> Do we need to wait until that lands?

That's depends. I don't have an answer.

-- 
Anthony PERARD

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

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

On 03/13/2018 06:31 PM, Takashi Iwai wrote:

On Tue, 13 Mar 2018 12:49:00 +0100,
Oleksandr Andrushchenko wrote:

So, I tried to make a POC to stress the protocol changes and see
what implementation of the HW parameter negotiation would look like.

Please find protocol changes at [1]:
- add XENSND_OP_HW_PARAM_QUERY request to read/update
configuration space for the parameter given: request passes
desired parameter interval and the response to this request
returns min/max interval for the parameter to be used.
Parameters supported by this request:
- frame rate
- sample rate
- number of channels
- buffer size
- period size
- add minimum buffer size to XenStore configuration

From the previous changes to the protocol which I posted earlier I see
that XENSND_OP_HW_PARAM_SET is not really needed - removed.

The implementation in the PV frontend driver is at [2].

Takashi, could you please take a look at the above if it meets your
expectations
so I can move forward?

This looks almost good through a quick glance.
But the mixture of SNDRV_PCM_HW_PARAM_PERIOD_SIZE and
SNDRV_PCM_HW_PARAM_BUFFER_BYTES are likely confusing.
The *_SIZE means in frames unit while *_BYTES means in bytes.
You should align both PERIOD_ and BUFFER_ to the same units,
i.e. either use SNDRV_PCM_HW_PARAM_PERIOD_BYTES and *_BUFFER_BYTES,
or SNDRV_PCM_HW_PARAM_PERIOD_SIZE and *_BUFFER_SIZE.

You are correct, fixed this at [1]

Also, a slightly remaining concern is the use-case where hw_params is
called multiple times. An application may call hw_free and hw_params
freely, or even hw_params calls multiple times, in order to change the
parameter.

If the backend needs to resolve some dependency between parameters
(e.g. the available period size depends on the sample rate), the
backend has to remember the previously passed parameters.

So, instead of passing a single parameter, you may extend the protocol
always to pass the full (five) parameters, too.

OTOH, this can be considered to be a minor case, and the backend
(e.g. PA) can likely support every possible combinations, so maybe a
simpler code may be a better solution in the end.

Yes, let's have it step by step.
If you are ok with what we have at the moment then, after I implement both
backend and frontend changes and confirm that protocol works,
I will send v3 of the series (protocol changes).

Still there some questions:
1. Do we really need min buffer value as configuration [2]? I see no way
it can be used,
for instance at [3], we only have snd_pcm_hardware.buffer_bytes_max, but
not min.

So, I feel I can drop that

2. Can I assume that min buffer size == period size and add such a
constraint

in the frontend driver?

3. On backend side (ALSA), with current changes in the protocol I will
call something like
int snd_pcm_hw_params_set_channels_minmax(snd_pcm_t *pcm,
snd_pcm_hw_params_t *params, unsigned int *min, unsigned int *max)

instead of

int snd_pcm_hw_params_set_channels(snd_pcm_t *pcm, snd_pcm_hw_params_t
*params, unsigned int val)

while servicing XENSND_OP_HW_PARAM_QUERY.XENSND_OP_HW_PARAM_CHANNELS.
Does this make sense?

thanks,

Takashi

Thank you,
Oleksandr
[1]
https://github.com/andr2000/linux/commit/03e74fb23cf5baa2e252cd1e62fa9506decbca7e
[2]
https://github.com/andr2000/linux/blob/tiwai_sound_for_next_pv_snd_upstream_v2/include/xen/interface/io/sndif.h#L253

[3] https://elixir.bootlin.com/linux/latest/source/include/sound/pcm.h#L53

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

Re: [Xen-devel] [PATCH] xl/libxl: add pvcalls support

2018-03-13 Thread Stefano Stabellini

On Tue, 13 Mar 2018, George Dunlap wrote:
> On Tue, Mar 13, 2018 at 2:13 PM, Wei Liu  wrote:
> > On Tue, Feb 27, 2018 at 01:28:08PM -0800, Stefano Stabellini wrote:
> >> Add pvcalls support to libxl and xl. Create the appropriate pvcalls
> >> entries in xenstore.
> >>
> >> Signed-off-by: Stefano Stabellini 
> >
> > The code looks fine.
> >
> > I only want to have a second opinion on
> >
> >> @@ -829,6 +835,7 @@ libxl_domain_config = Struct("domain_config", [
> >>  ("vkbs", Array(libxl_device_vkb, "num_vkbs")),
> >>  ("vtpms", Array(libxl_device_vtpm, "num_vtpms")),
> >>  ("p9s", Array(libxl_device_p9, "num_p9s")),
> >> +("pvcallss", Array(libxl_device_pvcalls, "num_pvcallss")),
> >
> > this...
> >
> > I think the two s'es look a bit strange. But I don't have a better idea.
> 
> That does look a bit Gollum-like, my preciou.  Call individual
> connections a "pvcalldev", and then have it "pvcalldevs" and
> "num_pvcalldevs"?
> 
> Alternately, only allow a single pvcall connection?

Unfortunately neither can be done without rearchitecting/changing the
idl and libxl (I tried). Given that pvcallss remains only "internal", I
opted for the easy route.

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

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

On Tue, Mar 13, 2018 at 04:33:49AM +1000, Alexey Gerasimenko wrote:
> In order to turn on ACPI for OS, we need to write a chipset-specific value
> to SMI_CMD register (sort of imitation of the APM->ACPI switch on real
> systems). Modify acpi_enable_sci() function to support both i440 and Q35
> emulation.
> 
> Signed-off-by: Alexey Gerasimenko 
> ---
>  tools/firmware/hvmloader/hvmloader.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/hvmloader.c 
> b/tools/firmware/hvmloader/hvmloader.c
> index f603f68ded..070698440e 100644
> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -257,9 +257,16 @@ static const struct bios_config *detect_bios(void)
>  static void acpi_enable_sci(void)
>  {
>  uint8_t pm1a_cnt_val;
> +uint8_t acpi_enable_val;
>  
> -#define PIIX4_SMI_CMD_IOPORT 0xb2
> +#define SMI_CMD_IOPORT   0xb2
>  #define PIIX4_ACPI_ENABLE0xf1
> +#define ICH9_ACPI_ENABLE 0x02
> +
> +if (get_pc_machine_type() == MACHINE_TYPE_Q35)

Coding style.

And the previous patch can be folded into this one.

Wei.

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

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

Cc Anthony

IIRC there are changes needed on QEMU side? Do we need to wait until
that lands?

Wei.

On Tue, Mar 13, 2018 at 04:33:53AM +1000, Alexey Gerasimenko wrote:
> Provide a new domain config option to select the emulated machine type,
> device_model_machine. It has following possible values:
> - "i440" - i440 emulation (default)
> - "q35" - emulate a Q35 machine. By default, the storage interface is AHCI.
> 
> Note that omitting device_model_machine parameter means i440 system
> by default, so the default behavior doesn't change for existing domain
> config files.
> 
> Setting device_model_machine to "q35" sends '-machine q35,accel=xen'
> argument to QEMU. Unlike i440, there no separate machine type
> to enable/disable Xen platform device, it is controlled via a machine
> property only. See 'libxl: Xen Platform device support for Q35' patch for
> a detailed description.
> 
> Signed-off-by: Alexey Gerasimenko 
> ---
>  tools/libxl/libxl_dm.c  | 16 ++--
>  tools/libxl/libxl_types.idl |  7 +++
>  tools/xl/xl_parse.c | 14 ++
>  3 files changed, 31 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index a3cddce8b7..7b531050c7 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -1443,13 +1443,17 @@ static int 
> libxl__build_device_model_args_new(libxl__gc *gc,
>  flexarray_append(dm_args, b_info->extra_pv[i]);
>  break;
>  case LIBXL_DOMAIN_TYPE_HVM:
> -if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
> -/* Switching here to the machine "pc" which does not add
> - * the xen-platform device instead of the default "xenfv" 
> machine.
> - */
> -machinearg = libxl__strdup(gc, "pc,accel=xen");
> +if (b_info->device_model_machine == LIBXL_DEVICE_MODEL_MACHINE_Q35) {
> +machinearg = libxl__sprintf(gc, "q35,accel=xen");
>  } else {
> -machinearg = libxl__strdup(gc, "xenfv");
> +if (!libxl_defbool_val(b_info->u.hvm.xen_platform_pci)) {
> +/* Switching here to the machine "pc" which does not add
> + * the xen-platform device instead of the default "xenfv" 
> machine.
> + */
> +machinearg = libxl__strdup(gc, "pc,accel=xen");
> +} else {
> +machinearg = libxl__strdup(gc, "xenfv");
> +}
>  }
>  if (b_info->u.hvm.mmio_hole_memkb) {
>  uint64_t max_ram_below_4g = (1ULL << 32) -
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 35038120ca..f3ef3cbdde 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -101,6 +101,12 @@ libxl_device_model_version = 
> Enumeration("device_model_version", [
>  (2, "QEMU_XEN"), # Upstream based qemu-xen device model
>  ])
>  
> +libxl_device_model_machine = Enumeration("device_model_machine", [
> +(0, "UNKNOWN"),
> +(1, "I440"),
> +(2, "Q35"),
> +])
> +
>  libxl_console_type = Enumeration("console_type", [
>  (0, "UNKNOWN"),
>  (1, "SERIAL"),
> @@ -491,6 +497,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>  ("device_model_ssid_label", string),
>  # device_model_user is not ready for use yet
>  ("device_model_user", string),
> +("device_model_machine", libxl_device_model_machine),
>  
>  # extra parameters pass directly to qemu, NULL terminated
>  ("extra",libxl_string_list),
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index f6842540ca..a7506a426b 100644
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -2110,6 +2110,20 @@ skip_usbdev:
>  xlu_cfg_replace_string(config, "device_model_user",
> _info->device_model_user, 0);
>  
> +if (!xlu_cfg_get_string (config, "device_model_machine", , 0)) {
> +if (!strcmp(buf, "i440")) {
> +b_info->device_model_machine = LIBXL_DEVICE_MODEL_MACHINE_I440;
> +} else if (!strcmp(buf, "q35")) {
> +b_info->device_model_machine = LIBXL_DEVICE_MODEL_MACHINE_Q35;
> +} else {
> +fprintf(stderr,
> +"Unknown device_model_machine \"%s\" specified\n", buf);
> +exit(1);
> +}
> +} else {
> +b_info->device_model_machine = LIBXL_DEVICE_MODEL_MACHINE_UNKNOWN;
> +}
> +
>  #define parse_extra_args(type)\
>  e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
>  _info->extra##type, 0);\
> -- 
> 2.11.0
> 

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

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

On Tue, Mar 13, 2018 at 04:33:48AM +1000, Alexey Gerasimenko wrote:
> This adds a new function get_pc_machine_type() which allows to determine
> the emulated chipset type. Supported return values:
> 
> - MACHINE_TYPE_I440
> - MACHINE_TYPE_Q35
> - MACHINE_TYPE_UNKNOWN, results in the error message being printed
>   followed by calling BUG() in hvmloader.
> 
> Signed-off-by: Alexey Gerasimenko 
> ---
>  tools/firmware/hvmloader/pci_regs.h |  5 
>  tools/firmware/hvmloader/util.c | 47 
> +
>  tools/firmware/hvmloader/util.h |  8 +++
>  3 files changed, 60 insertions(+)
> 
> diff --git a/tools/firmware/hvmloader/pci_regs.h 
> b/tools/firmware/hvmloader/pci_regs.h
> index 7bf2d873ab..ba498b840e 100644
> --- a/tools/firmware/hvmloader/pci_regs.h
> +++ b/tools/firmware/hvmloader/pci_regs.h
> @@ -107,6 +107,11 @@
>  
>  #define PCI_INTEL_OPREGION 0xfc /* 4 bits */
>  
> +#define PCI_VENDOR_ID_INTEL  0x8086
> +#define PCI_DEVICE_ID_INTEL_824410x1237
> +#define PCI_DEVICE_ID_INTEL_Q35_MCH  0x29c0
> +
> +

Too many blank lines.

>  #endif /* __HVMLOADER_PCI_REGS_H__ */
>  
>  /*
> diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
> index 0c3f2d24cd..5739a87628 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -22,6 +22,7 @@
>  #include "hypercall.h"
>  #include "ctype.h"
>  #include "vnuma.h"
> +#include "pci_regs.h"
>  #include 
>  #include 
>  #include 
> @@ -735,6 +736,52 @@ void __bug(char *file, int line)
>  crash();
>  }
>  
> +
> +static int machine_type = MACHINE_TYPE_UNDEFINED;
> +
> +int get_pc_machine_type(void)
> +{
> +uint16_t vendor_id;
> +uint16_t device_id;
> +
> +if (machine_type != MACHINE_TYPE_UNDEFINED)
> +return machine_type;
> +
> +machine_type = MACHINE_TYPE_UNKNOWN;
> +
> +vendor_id = pci_readw(0, PCI_VENDOR_ID);
> +device_id = pci_readw(0, PCI_DEVICE_ID);
> +
> +/* only Intel platforms are emulated currently */
> +if (vendor_id == PCI_VENDOR_ID_INTEL)

Coding style.

> +{
> +switch (device_id)

Ditto.

And this patch should be folded into its user, unless the patch that
uses it is very big on its own.

Wei.

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

Re: [Xen-devel] [PATCH 39/57] ARM: new VGIC: Add ACTIVE registers handlers




On 13/03/18 17:14, Julien Grall wrote:

On 13/03/18 17:02, Andre Przywara wrote:

On 08/03/18 15:39, Julien Grall wrote:

On 05/03/18 16:03, Andre Przywara wrote:
I admit the bailout is a bit weird here. You would only print the
warning for the first activated IRQ and give the impression it is fine
for the rest. So maybe you want to drop IRQ%d?


For the above reasons I wanted to keep them concise, so that we see that
the issue has happened, but avoid getting tons of error messages about
the same problem (as this may affect up to 32 IRQs).
But for debugging it might be good to know which IRQ was affected. I see
two use cases for a guest:
- (De-)activating a single IRQ: we get one message and know which IRQ it
was, so an admin can chase this down to a certain device (driver).
- (De-)activating *every* IRQ in this range (~0): we still get one
message per 32 IRQs, but can see whether it covers SPIs only (IRQ>=32)
and which ones.

So what about a compromise: I use dprintk(XENLOG_G_ERR, "%pv ...), print
the (first) IRQ and the *value* to be written. So a knowledgeable admin
can tell whether it's a single IRQ or a "clear/set-all" case. That
should also give enough info for debugging, but keeps it short.


I can't see how a knowledgeable admin will be able to know that IRQ 2 is 
active with just the register value.




Does that sound OK?


I would still prefer the one per IRQ and using printk(XENLOG_G_*). I  > don't 
much care about the spam, see why above.


XENLOG_G_DEBUG is a good candidate actually.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 39/57] ARM: new VGIC: Add ACTIVE registers handlers


Hi Andre,

On 13/03/18 17:02, Andre Przywara wrote:

On 08/03/18 15:39, Julien Grall wrote:

On 05/03/18 16:03, Andre Przywara wrote:

+/*
+ * We don't actually support clearing the active state of an IRQ (yet).
+ * However there is a chance that most guests use this for
initialization.
+ * We check whether this MMIO access would actually affect any active
IRQ,
+ * and only print our warning in this case. So clearing already
non-active
+ * IRQs would not be moaned about in the logs.
+ */
+void vgic_mmio_write_cactive(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len,
+ unsigned long val)
+{
+    uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+    unsigned int i;
+    bool bail_out = false;
+
+    for_each_set_bit( i, , len * 8 )
+    {
+    struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid
+ i);
+
+    /*
+ * If we know that the IRQ is active or we can't be sure about
+ * it (because it is currently in a CPU), log the not properly
+ * emulated MMIO access.
+ */
+    if ( irq->active || irq->vcpu )
+    {
+    gdprintk(XENLOG_ERR,
+ "%pv: vGICD: IRQ%d: clearing active state not
supported\n",


s/%d/%u/


+ vcpu, irq->intid);


gdprintk will always print the vCPU. Thought it is the current which
might be different from vcpu (mostly in the re-dist case).


Ah, thanks. I always get confused about what which version of *printk does.


So I would use dprintk(XENLOG_G_ERR, "%pv: ..."). I would even be tempt
to use printk() so we can spot potential issue on non-debug build.


Well, in the true spirit of Xen paranoia ;-) I wanted to avoid a guest
spamming the console.


The guests messages are rate limited.


And in the end there is nothing a administrator
could really do about it. In my experience those messages tend to really
scare users ("I could boot Dom0 but I see those error messages ").


Xen message are not only here for the administrator, they are also here 
to help for the developer to get log to dissect.


I think that particular message should be printed in non-debug build 
because if the interrupt was active and can't clear it. Then something

will go wrong later on.




+    bail_out = true;


I admit the bailout is a bit weird here. You would only print the
warning for the first activated IRQ and give the impression it is fine
for the rest. So maybe you want to drop IRQ%d?


For the above reasons I wanted to keep them concise, so that we see that
the issue has happened, but avoid getting tons of error messages about
the same problem (as this may affect up to 32 IRQs).
But for debugging it might be good to know which IRQ was affected. I see
two use cases for a guest:
- (De-)activating a single IRQ: we get one message and know which IRQ it
was, so an admin can chase this down to a certain device (driver).
- (De-)activating *every* IRQ in this range (~0): we still get one
message per 32 IRQs, but can see whether it covers SPIs only (IRQ>=32)
and which ones.

So what about a compromise: I use dprintk(XENLOG_G_ERR, "%pv ...), print
the (first) IRQ and the *value* to be written. So a knowledgeable admin
can tell whether it's a single IRQ or a "clear/set-all" case. That
should also give enough info for debugging, but keeps it short.


I can't see how a knowledgeable admin will be able to know that IRQ 2 is 
active with just the register value.




Does that sound OK?


I would still prefer the one per IRQ and using printk(XENLOG_G_*). I 
don't much care about the spam, see why above.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4] new config option vtsc_tolerance_khz to avoid TSC emulation

On Fri, Mar 09, 2018 at 03:10:39PM +0100, Olaf Hering wrote:
> Add an option to control when vTSC emulation will be activated for a
> domU with tsc_mode=default. Without such option each TSC access from
> domU will be emulated, which causes a significant perfomance drop for
> workloads that make use of rdtsc.
> 
> Add a new domctl XEN_DOMCTL_set_vtsc_tolerance_khz to adjust the
> tolerance value of a running domU that is supposed to be migrated.
> 
> One option to avoid the TSC option is to run domUs with tsc_mode=native.
> This has the drawback that migrating a domU from a "2.3GHz" class host
> to a "2.4GHz" class host may change the rate at wich the TSC counter
> increases, the domU may not be prepared for that.
> 
> With this option the host admin can decide how a domU should behave when
> it is migrated across systems of the same class. Since there is always
> some jitter when Xen calibrates the cpu_khz value, all hosts of the same
> class will most likely have slightly different values. As a result vTSC
> emulation is unavoidable. Data collected during the incident which
> triggered this change showed a jitter of up to 200 KHz across systems of
> the same class.
> 
> A new utility is added which allows to adjust the vtsc_tolerance_khz
> value for running domUs. This is useful to avoid emulation for domUs
> that are already running and which can not be restarted.
> 
> The ordering of records sent during migration is important. The value of
> vtsc_tolerance_khz must be known by the receiving host before
> configuring TSC, because this is the place where the decision of vTSC
> emulation is made. Therefore the existing write_tsc_info function is
> modified to enforce that ordering.

There were questions on previous patches as to why this approach is
better than what we already have. Are those comments addressed?

Wei.

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

Re: [Xen-devel] [PATCH 39/57] ARM: new VGIC: Add ACTIVE registers handlers

2018-03-13 Thread Andre Przywara

Hi,

On 08/03/18 15:39, Julien Grall wrote:
> Hi Andre,
> 
> On 05/03/18 16:03, Andre Przywara wrote:
>> The active register handlers are shared between the v2 and v3 emulation,
>> so their implementation goes into vgic-mmio.c, to be easily referenced
>> from the v3 emulation as well later.
>> Since activation/deactivation of an interrupt may happen entirely in the
>> guest without it ever exiting, we need some extra logic to properly track
>> the active state.
>> For clearing the active state, we would basically have to halt the guest
>> to make sure this is properly propagated into the respective VCPUs.
>> This is not yet implemented in Xen.
>> Fortunately this feature is mostly used to reset a just in initialised
>> GIC, so chances are we are tasked to clear bits that are already zero.
>> Add some simple check to avoid a pointless warning in this case.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>> Changelog RFC ... v1:
>> - remove premature "proper ACTIVE" handler stub
>> - avoid unnecessary warnings on NO-OP register writes
>> - extend comments
>>
>>   xen/arch/arm/vgic/vgic-mmio-v2.c |   4 +-
>>   xen/arch/arm/vgic/vgic-mmio.c    | 103
>> +++
>>   xen/arch/arm/vgic/vgic-mmio.h    |  11 +
>>   3 files changed, 116 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c
>> b/xen/arch/arm/vgic/vgic-mmio-v2.c
>> index efdd73301d..c93455fbb2 100644
>> --- a/xen/arch/arm/vgic/vgic-mmio-v2.c
>> +++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
>> @@ -92,10 +92,10 @@ static const struct vgic_register_region
>> vgic_v2_dist_registers[] = {
>>   vgic_mmio_read_pending, vgic_mmio_write_cpending, 1,
>>   VGIC_ACCESS_32bit),
>>   REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISACTIVER,
>> -    vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
>> +    vgic_mmio_read_active, vgic_mmio_write_sactive, 1,
>>   VGIC_ACCESS_32bit),
>>   REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICACTIVER,
>> -    vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
>> +    vgic_mmio_read_active, vgic_mmio_write_cactive, 1,
>>   VGIC_ACCESS_32bit),
>>   REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_IPRIORITYR,
>>   vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
>> diff --git a/xen/arch/arm/vgic/vgic-mmio.c
>> b/xen/arch/arm/vgic/vgic-mmio.c
>> index 2e939d5e39..c44d67082f 100644
>> --- a/xen/arch/arm/vgic/vgic-mmio.c
>> +++ b/xen/arch/arm/vgic/vgic-mmio.c
>> @@ -281,6 +281,109 @@ void vgic_mmio_write_cpending(struct vcpu *vcpu,
>>   }
>>   }
>>   +/*
>> + * The actual active bit for a virtual IRQ is held in the LR. Our shadow
>> + * copy in struct vgic_irq is only synced when needed and may not be
>> + * up-to-date all of the time.
>> + * Returning the actual active state is quite costly (stopping all
>> + * VCPUs processing any affected vIRQs), so we use a simple
>> implementation
>> + * to get the best possible answer.
>> + */
>> +unsigned long vgic_mmio_read_active(struct vcpu *vcpu,
>> +    paddr_t addr, unsigned int len)
>> +{
>> +    uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
>> +    uint32_t value = 0;
>> +    unsigned int i;
>> +
>> +    /* Loop over all IRQs affected by this read */
>> +    for ( i = 0; i < len * 8; i++ )
>> +    {
>> +    struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid
>> + i);
>> +
>> +    if ( irq->active )
>> +    value |= (1U << i);
>> +
>> +    vgic_put_irq(vcpu->domain, irq);
>> +    }
>> +
>> +    return value;
>> +}
>> +
>> +/*
>> + * We don't actually support clearing the active state of an IRQ (yet).
>> + * However there is a chance that most guests use this for
>> initialization.
>> + * We check whether this MMIO access would actually affect any active
>> IRQ,
>> + * and only print our warning in this case. So clearing already
>> non-active
>> + * IRQs would not be moaned about in the logs.
>> + */
>> +void vgic_mmio_write_cactive(struct vcpu *vcpu,
>> + paddr_t addr, unsigned int len,
>> + unsigned long val)
>> +{
>> +    uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
>> +    unsigned int i;
>> +    bool bail_out = false;
>> +
>> +    for_each_set_bit( i, , len * 8 )
>> +    {
>> +    struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid
>> + i);
>> +
>> +    /*
>> + * If we know that the IRQ is active or we can't be sure about
>> + * it (because it is currently in a CPU), log the not properly
>> + * emulated MMIO access.
>> + */
>> +    if ( irq->active || irq->vcpu )
>> +    {
>> +    gdprintk(XENLOG_ERR,
>> + "%pv: vGICD: IRQ%d: clearing active state not
>> supported\n",
> 
> s/%d/%u/
> 
>> + vcpu, irq->intid);
> 
> gdprintk will always print the vCPU. Thought it is the current which
> might be different from vcpu (mostly in the re-dist case).

Ah, thanks. I

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


On 3/13/2018 9:34 AM, Jan Beulich wrote:

On 13.03.18 at 17:20,  wrote:

On 3/13/2018 3:50 AM, Roger Pau Monné wrote:

On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote:

@@ -62,10 +72,34 @@
*| reserved   |
* 32 ++
*
+ * The layout of each entry in the memory map table is as follows:
+ *
+ *  0 ++
+ *| addr   | Base address
+ *  8 ++
+ *| size   | Size of mapping in bytes
+ * 16 ++
+ *| type   | Type of mapping as defined between the hypervisor
+ *|| and guest it's starting. E820_TYPE_xxx, for example.

This needs a link to the expected type values (or a reference). Or you
need to spell out the relation between the values and the memory types.

This field was discussed a good deal in v2 of the linux patches. I had
originally defined this to be a specific type field, matching the
x86/Linux definition for e820 memory mapping types. But Jan Beulich
successfully argued that we should keep the definition of this
particular interface agnostic to architecture and OS and not limit the
field to specific values. I believe the central idea behind Jan's
argument was to keep the interface x86-agnostic as well as preserving
the option to add additional memory mapping types in the future without
them being sanctioned by whoever maintains E820 type assignments.

That's why I changed the comment wording to what it is now. Basically
spelling out the fact that this field simply needs to be agreed upon
between the producer and the consumer since a hypervisor should
generally know what type of guest it is starting. And I mentioned
e820_type_xxx as the *example* of one such implementation, since that is
the most obvious use case and the e820 types are part of the ACPI
standard (and thus easy to find/reference).

But Roger makes a valid remark here. Statements like
"E820_TYPE_xxx, for example" are simply to vague for a stable public
interface.


How about "For example, E820 types like E820_RAM, E820_ACPI, etc as 
defined in xen/include/asm-x86/e820.h of the Xen tree" ?


Thanks,
-Maran



Jan



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

Re: [Xen-devel] [PATCH v10] x86/altp2m: support for setting restrictions for an array of pages

>>> On 13.12.17 at 15:22,  wrote:
> From: Razvan Cojocaru 
> 
> For the default EPT view we have xc_set_mem_access_multi(), which
> is able to set an array of pages to an array of access rights with
> a single hypercall. However, this functionality was lacking for the
> altp2m subsystem, which could only set page restrictions for one
> page at a time. This patch addresses the gap.
> 
> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
> hence with the original altp2m design, where domains are allowed - with the
> proper altp2m access rights - to alter these settings), in the absence of an
> official position on the issue from the original altp2m designers.

I've just stumbled across this 3 months old patch. All my comments
code wise have been addressed, so I'm not going to object to this
going in. However, the permissions issue alluded to above is what
makes me refrain from giving an ack for it; it'll need Andrew's or
George's ack (plus a tool stack maintainer's) to go in. (Please
remember that it's generally the submitter of a patch to ping people
for missing acks.)

Jan

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

Re: [Xen-devel] [PATCH] xl: remove apic option for PVH guests

On Tue, Mar 13, 2018 at 02:23:15PM +, Roger Pau Monné wrote:
> On Mon, Mar 05, 2018 at 11:36:58AM +, Ian Jackson wrote:
> > Roger Pau Monne writes ("[PATCH] xl: remove apic option for PVH guests"):
> > > XSA-256 forces the local APIC to always be enabled for PVH guests, so
> > > ignore any apic option for PVH guests. Update the documentation
> > > accordingly.
> > ...
> > > diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> > > index f6842540ca..8b999825d2 100644
> > > --- a/tools/xl/xl_parse.c
> > > +++ b/tools/xl/xl_parse.c
> > > @@ -1208,7 +1208,6 @@ void parse_config_data(const char *config_source,
> > >  }
> > >  
> > >  xlu_cfg_get_defbool(config, "nestedhvm", _info->nested_hvm, 0);
> > > -xlu_cfg_get_defbool(config, "apic", _info->apic, 0);
> > 
> > Is this hunk not in a path also used by HVM ?
> 
> Yes, this hunk is moved to a HVM-specific section a little bit below:
> 
> @@ -1243,6 +1242,7 @@ void parse_config_data(const char *config_source,
>  xlu_cfg_get_defbool(config, "nx", _info->u.hvm.nx, 0);
>  xlu_cfg_get_defbool(config, "hpet", _info->u.hvm.hpet, 0);
>  xlu_cfg_get_defbool(config, "vpt_align", _info->u.hvm.vpt_align, 
> 0);
> +xlu_cfg_get_defbool(config, "apic", _info->apic, 0);
> 
>  switch (xlu_cfg_get_list(config, "viridian",
>   , _viridian, 1))
> 
> So it's only set for HVM, which AFAICT should be fine.
> 

I tried to apply this patch to staging but it failed.

Wei.

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

Re: [Xen-devel] Modifying domain creation interface

On Wed, Feb 21, 2018 at 03:08:23PM +0100, Juergen Gross wrote:
> Creating a new domain currently is a sequence of hypercalls with many of
> those being mandatory and needed in a specific sequence. Its has been
> discussed before to build a new interface for domain creation with _all_
> the mandatory information passed to the hypervisor in one hypercall.
> 
> I'd like to suggest to extend this idea even more: instead of passing
> the mandatory data only we could even add some optional data in a
> generic way. Instead of extending the binary interface each time a new
> configurable parameter is added for domains we could use a text based
> interface for that purpose, similar to the boot parameters of the
> hypervisor or the kernel. So instead adding e.g. a new flag for
> switching the Meltdown mitigation on or off for a specific domain (this
> example is the reason I thought of the new interface) to
> xen_domctl_createdomain.flags we could pass a string "xpti=off" to the
> hypervisor in the domain create hypercall parameters. Passing an array
> of strings plus the number of array elements would allow to extend the
> interface without having to change any header file.
> 
> It would even be possible to have something like:
> 
> domain_params=[ "xpti=off", "param_xy=foo" ]
> 
> in the xl config file of a domain allowing to specify new parameters
> without having to modify xl/libxl. This would allow backports of
> security patches which need some per-domain configuration aid (some
> SUSE customers already asked for a way to switch Meltdown mitigation
> on a per-domain basis in old versions).
> 

This is yet another way to configure a domain. What is your thought
going forward? I certainly don't want to have more than one way to
configure some aspects of a domain.

Say, we want to introduce parameter foo, do we support foo=bar in
domain_params only? Do we allow foo=bar as top-level option?

A problem I can see is that it would make it harder for toolstack to
reject incompatible options during migration -- it can't know until it
actually tries to (re)create the guest with the same parameters. But
what we have today isn't perfect either.

> Security is a point to be looked at, of course. OTOH it should be quite
> easy to use a fuzzer for proving the parser to be secure, as the parser
> can be constructed to be testable in user environment (like e.g. the
> x86 instruction emulator).
> 

One way to deal with that is to say we trust the configuration file
completely so bugs in parser won't be security issues.

Wei.

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

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

>>> On 13.03.18 at 17:20,  wrote:
> On 3/13/2018 3:50 AM, Roger Pau Monné wrote:
>> On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote:
>>> @@ -62,10 +72,34 @@
>>>*| reserved   |
>>>* 32 ++
>>>*
>>> + * The layout of each entry in the memory map table is as follows:
>>> + *
>>> + *  0 ++
>>> + *| addr   | Base address
>>> + *  8 ++
>>> + *| size   | Size of mapping in bytes
>>> + * 16 ++
>>> + *| type   | Type of mapping as defined between the hypervisor
>>> + *|| and guest it's starting. E820_TYPE_xxx, for 
>>> example.
>> This needs a link to the expected type values (or a reference). Or you
>> need to spell out the relation between the values and the memory types.
> 
> This field was discussed a good deal in v2 of the linux patches. I had 
> originally defined this to be a specific type field, matching the 
> x86/Linux definition for e820 memory mapping types. But Jan Beulich 
> successfully argued that we should keep the definition of this 
> particular interface agnostic to architecture and OS and not limit the 
> field to specific values. I believe the central idea behind Jan's 
> argument was to keep the interface x86-agnostic as well as preserving 
> the option to add additional memory mapping types in the future without 
> them being sanctioned by whoever maintains E820 type assignments.
> 
> That's why I changed the comment wording to what it is now. Basically 
> spelling out the fact that this field simply needs to be agreed upon 
> between the producer and the consumer since a hypervisor should 
> generally know what type of guest it is starting. And I mentioned 
> e820_type_xxx as the *example* of one such implementation, since that is 
> the most obvious use case and the e820 types are part of the ACPI 
> standard (and thus easy to find/reference).

But Roger makes a valid remark here. Statements like
"E820_TYPE_xxx, for example" are simply to vague for a stable public
interface.

Jan

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

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

On Tue, Mar 13, 2018 at 11:25:29AM -0500, Doug Goldstein wrote:
> The code added in 7a48622a78a0b452e8afa55b8442c958abd226a7 could use rc
> uninitialized in main_vdisplattach().
> 
> Signed-off-by: Doug Goldstein 

Acked-by: Wei Liu 

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

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

2018-03-13 Thread Takashi Iwai

On Tue, 13 Mar 2018 12:49:00 +0100,
Oleksandr Andrushchenko wrote:
> 
> So, I tried to make a POC to stress the protocol changes and see
> what implementation of the HW parameter negotiation would look like.
> 
> Please find protocol changes at [1]:
> - add XENSND_OP_HW_PARAM_QUERY request to read/update
>    configuration space for the parameter given: request passes
>    desired parameter interval and the response to this request
>    returns min/max interval for the parameter to be used.
>    Parameters supported by this request:
>  - frame rate
>  - sample rate
>  - number of channels
>  - buffer size
>  - period size
>  - add minimum buffer size to XenStore configuration
> 
> From the previous changes to the protocol which I posted earlier I see
> that XENSND_OP_HW_PARAM_SET is not really needed - removed.
> 
> The implementation in the PV frontend driver is at [2].
> 
> Takashi, could you please take a look at the above if it meets your
> expectations
> so I can move forward?

This looks almost good through a quick glance.
But the mixture of SNDRV_PCM_HW_PARAM_PERIOD_SIZE and
SNDRV_PCM_HW_PARAM_BUFFER_BYTES are likely confusing.
The *_SIZE means in frames unit while *_BYTES means in bytes.
You should align both PERIOD_ and BUFFER_ to the same units,
i.e. either use SNDRV_PCM_HW_PARAM_PERIOD_BYTES and *_BUFFER_BYTES,
or SNDRV_PCM_HW_PARAM_PERIOD_SIZE and *_BUFFER_SIZE.

Also, a slightly remaining concern is the use-case where hw_params is
called multiple times.  An application may call hw_free and hw_params
freely, or even hw_params calls multiple times, in order to change the
parameter.

If the backend needs to resolve some dependency between parameters
(e.g. the available period size depends on the sample rate), the
backend has to remember the previously passed parameters.

So, instead of passing a single parameter, you may extend the protocol
always to pass the full (five) parameters, too.

OTOH, this can be considered to be a minor case, and the backend
(e.g. PA) can likely support every possible combinations, so maybe a
simpler code may be a better solution in the end.

thanks,

Takashi

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

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


On 3/13/2018 3:50 AM, Roger Pau Monné wrote:

On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote:

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

I would also like to see Xen modified to make use of this new
memmap_paddr feature. See bootlate_hvm in tools/libxc/xc_dom_x86.c, it
should be quite trivial to add the memmap to the hvm_start_info
crafted there.


Yes, that is being worked on as we speak. Should have a new set of 
patches out shortly.



Signed-off-by: Maran Wilson 
---
  xen/include/public/arch-x86/hvm/start_info.h | 51 +++-
  1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/arch-x86/hvm/start_info.h 
b/xen/include/public/arch-x86/hvm/start_info.h
index 6484159..ae8dac8 100644
--- a/xen/include/public/arch-x86/hvm/start_info.h
+++ b/xen/include/public/arch-x86/hvm/start_info.h
@@ -33,8 +33,9 @@
   *| magic  | Contains the magic value XEN_HVM_START_MAGIC_VALUE
   *|| ("xEn3" with the 0x80 bit of the "E" set).
   *  4 ++
- *| version| Version of this structure. Current version is 0. New
+ *| version| Version of this structure. Current version is 1. New
   *|| versions are guaranteed to be backwards-compatible.
+ *|| For PV guests only 0 allowed, for PVH 0 or 1 allowed.
   *  8 ++
   *| flags  | SIF_xxx flags.
   * 12 ++
@@ -48,6 +49,15 @@
   * 32 ++
   *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
   * 40 ++
+ *| memmap_paddr   | Physical address of the (optional) memory map. Only
+ *|| present in version 1 and newer of the structure.
+ * 48 ++
+ *| memmap_entries | Number of entries in the memory map table. Only
+ *|| present in version 1 and newer of the structure.
+ *|| Zero if there is no memory map being provided.

Can you place the "present in version 1 and newer" at the end of the
text block?


Sure, I'll do that.


IMHO setting memmap_paddr to 0 should be the way to signal that
there's no memory map (like it's done for rsdp_paddr), and then the
value of _entries is irrelevant. At which point the "Zero if there is
no memory map being provided" is wrong.


+ * 52 ++
+ *| reserved   | Version 1 and newer only.
+ * 56 ++
   *
   * The layout of each entry in the module structure is the following:
   *
@@ -62,10 +72,34 @@
   *| reserved   |
   * 32 ++
   *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ *  0 ++
+ *| addr   | Base address
+ *  8 ++
+ *| size   | Size of mapping in bytes
+ * 16 ++
+ *| type   | Type of mapping as defined between the hypervisor
+ *|| and guest it's starting. E820_TYPE_xxx, for example.

This needs a link to the expected type values (or a reference). Or you
need to spell out the relation between the values and the memory types.


This field was discussed a good deal in v2 of the linux patches. I had 
originally defined this to be a specific type field, matching the 
x86/Linux definition for e820 memory mapping types. But Jan Beulich 
successfully argued that we should keep the definition of this 
particular interface agnostic to architecture and OS and not limit the 
field to specific values. I believe the central idea behind Jan's 
argument was to keep the interface x86-agnostic as well as preserving 
the option to add additional memory mapping types in the future without 
them being sanctioned by whoever maintains E820 type assignments.


That's why I changed the comment wording to what it is now. Basically 
spelling out the fact that this field simply needs to be agreed upon 
between the producer and the consumer since a hypervisor should 
generally know what type of guest it is starting. And I mentioned 
e820_type_xxx as the *example* of one such implementation, since that is 
the most obvious use case and the e820 types are part of the ACPI 
standard (and thus easy to find/reference).



+ * 20 +|
+ *| reserved   |
+ * 24 ++
+ *
   * The address and sizes are always a 64bit little endian unsigned integer.
   *
   * NB: Xen on x86 will always try to place all the data below the 4GiB
   * boundary.
+ *
+ * Version numbers of the hvm_start_info structure have evolved like this:
+ *
+ * Version 0:
+ *
+ * Version 1:  Added the memmap_paddr/memmap_entries fields (plus 4 bytes of
+ * padding) to the end of

Re: [Xen-devel] [PATCH v2 1/5] x86/hvm: Handle viridian MSRs via the new guest_{rd, wr}msr() infrastructure

>>> On 13.03.18 at 16:47,  wrote:
> On 13/03/18 15:20, Jan Beulich wrote:
> On 07.03.18 at 19:58,  wrote:
>>> @@ -175,11 +177,26 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr, 
> uint64_t *val)
>>> _MSR_MISC_FEATURES_CPUID_FAULTING;
>>>  break;
>>>  
>>> +case MSR_HYPERVISOR_START ... MSR_HYPERVISOR_START + NR_VIRIDIAN_MSRS 
>>> - 
> 
>>> 1:
>>> +if ( is_viridian_domain(d) )
>>> +{
>>> +ret = guest_rdmsr_viridian(v, msr, val);
>>> +goto out;
>>> +}
>>> +
>>> +/* Fallthrough. */
>>>  default:
>>>  return X86EMUL_UNHANDLEABLE;
>>>  }
>>>  
>>> -return X86EMUL_OKAY;
>>> + out:
>> I've noticed this only in the context of patch 4, but why is this label
>> and yet another unnecessary "goto" here? That "goto" could simply
>> be "break" afaics.
> 
> Ah - that is for changes which I haven't posted yet.
> 
> When we get onto MSRs which might be in the load/save lists, or may be
> stashed in the VMCB/VMCS rather than in real hardware, we need to call
> back into arch specific code when an update is completed.

But I don't think this requires a goto here, does it? If that future
code structure really can't get away without, so be it (then). But
please let's evaluate that at the time you have that code ready.

Jan


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

[Xen-devel] [PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

From: Oleksandr Andrushchenko 

Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
Xen guest domain configuration options [3].

Driver limitations:
 1. Only primary plane without additional properties is supported.
 2. Only one video mode supported which resolution is configured via XenStore.
 3. All CRTCs operate at fixed frequency of 60Hz.

1. Implement Xen bus state machine for the frontend driver according to
the state diagram and recovery flow from display para-virtualized
protocol: xen/interface/io/displif.h.

2. Read configuration values from Xen store according
to xen/interface/io/displif.h protocol:
  - read connector(s) configuration
  - read buffer allocation mode (backend/frontend)

3. Handle Xen event channels:
  - create for all configured connectors and publish
corresponding ring references and event channels in Xen store,
so backend can connect
  - implement event channels interrupt handlers
  - create and destroy event channels with respect to Xen bus state

4. Implement shared buffer handling according to the
para-virtualized display device protocol at xen/interface/io/displif.h:
  - handle page directories according to displif protocol:
- allocate and share page directories
- grant references to the required set of pages for the
  page directory
  - allocate xen balllooned pages via Xen balloon driver
with alloc_xenballooned_pages/free_xenballooned_pages
  - grant references to the required set of pages for the
shared buffer itself
  - implement pages map/unmap for the buffers allocated by the
backend (gnttab_map_refs/gnttab_unmap_refs)

5. Implement kernel modesetiing/connector handling using
DRM simple KMS helper pipeline:

- implement KMS part of the driver with the help of DRM
  simple pipepline helper which is possible due to the fact
  that the para-virtualized driver only supports a single
  (primary) plane:
  - initialize connectors according to XenStore configuration
  - handle frame done events from the backend
  - create and destroy frame buffers and propagate those
to the backend
  - propagate set/reset mode configuration to the backend on display
enable/disable callbacks
  - send page flip request to the backend and implement logic for
reporting backend IO errors on prepare fb callback

- implement virtual connector handling:
  - support only pixel formats suitable for single plane modes
  - make sure the connector is always connected
  - support a single video mode as per para-virtualized driver
configuration

6. Implement GEM handling depending on driver mode of operation:
depending on the requirements for the para-virtualized environment, namely
requirements dictated by the accompanying DRM/(v)GPU drivers running in both
host and guest environments, number of operating modes of para-virtualized
display driver are supported:
 - display buffers can be allocated by either frontend driver or backend
 - display buffers can be allocated to be contiguous in memory or not

Note! Frontend driver itself has no dependency on contiguous memory for
its operation.

6.1. Buffers allocated by the frontend driver.

The below modes of operation are configured at compile-time via
frontend driver's kernel configuration.

6.1.1. Front driver configured to use GEM CMA helpers
 This use-case is useful when used with accompanying DRM/vGPU driver in
 guest domain which was designed to only work with contiguous buffers,
 e.g. DRM driver based on GEM CMA helpers: such drivers can only import
 contiguous PRIME buffers, thus requiring frontend driver to provide
 such. In order to implement this mode of operation para-virtualized
 frontend driver can be configured to use GEM CMA helpers.

6.1.2. Front driver doesn't use GEM CMA
 If accompanying drivers can cope with non-contiguous memory then, to
 lower pressure on CMA subsystem of the kernel, driver can allocate
 buffers from system memory.

Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
may require IOMMU support on the platform, so accompanying DRM/vGPU
hardware can still reach display buffer memory while importing PRIME
buffers from the frontend driver.

6.2. Buffers allocated by the backend

This mode of operation is run-time configured via guest domain configuration
through XenStore entries.

For systems which do not provide IOMMU support, but having specific
requirements for display buffers it is possible to allocate such buffers
at backend side and share those with the frontend.
For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting
physically contiguous memory, this allows implementing zero-copying
use-cases.

Note, while using this scenario the following should be

[Xen-devel] [PATCH RESEND v2 0/2] drm/xen-front: Add support for Xen PV display frontend

From: Oleksandr Andrushchenko 

Hello!

Resending with all the patches squashed on Daniel's request.

This patch series adds support for Xen [1] para-virtualized
frontend display driver. It implements the protocol from
include/xen/interface/io/displif.h [2].
Accompanying backend [3] is implemented as a user-space application
and its helper library [4], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via 
Xen guest domain configuration options [5].

***
* Driver limitations
***
 1. Configuration options 1.1 (contiguous display buffers) and 2 (backend
allocated buffers) below are not supported at the same time.

 2. Only primary plane without additional properties is supported.

 3. Only one video mode supported which resolution is configured via XenStore.

 4. All CRTCs operate at fixed frequency of 60Hz.

***
* Driver modes of operation in terms of display buffers used
***
 Depending on the requirements for the para-virtualized environment, namely
 requirements dictated by the accompanying DRM/(v)GPU drivers running in both
 host and guest environments, number of operating modes of para-virtualized
 display driver are supported:
  - display buffers can be allocated by either frontend driver or backend
  - display buffers can be allocated to be contiguous in memory or not

 Note! Frontend driver itself has no dependency on contiguous memory for
   its operation.

***
* 1. Buffers allocated by the frontend driver.
***

 The below modes of operation are configured at compile-time via
 frontend driver's kernel configuration.

 1.1. Front driver configured to use GEM CMA helpers
  This use-case is useful when used with accompanying DRM/vGPU driver in
  guest domain which was designed to only work with contiguous buffers,
  e.g. DRM driver based on GEM CMA helpers: such drivers can only import
  contiguous PRIME buffers, thus requiring frontend driver to provide
  such. In order to implement this mode of operation para-virtualized
  frontend driver can be configured to use GEM CMA helpers.

 1.2. Front driver doesn't use GEM CMA
  If accompanying drivers can cope with non-contiguous memory then, to
  lower pressure on CMA subsystem of the kernel, driver can allocate
  buffers from system memory.

 Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
   may require IOMMU support on the platform, so accompanying DRM/vGPU
   hardware can still reach display buffer memory while importing PRIME
   buffers from the frontend driver.

***
* 2. Buffers allocated by the backend
***

 This mode of operation is run-time configured via guest domain configuration
 through XenStore entries.

 For systems which do not provide IOMMU support, but having specific
 requirements for display buffers it is possible to allocate such buffers
 at backend side and share those with the frontend.
 For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting
 physically contiguous memory, this allows implementing zero-copying
 use-cases.


I would like to thank at least, but not at last the following
people/communities who helped this driver to happen ;)

1. My team at EPAM for continuous support
2. Xen community for answering tons of questions on different
modes of operation of the driver with respect to virtualized
environment.
3. Rob Clark for "GEM allocation for para-virtualized DRM driver" [6]
4. Maarten Lankhorst for "Atomic driver and old remove FB behavior" [7]
5. Ville Syrjälä for "Questions on page flips and atomic modeset" [8]


Changes since v1:
***
- use SPDX license identifier, set license to GPLv2 OR MIT
- changed midlayers to direct function calls, removed:
  - front_ops
  - gem_ops
- renamed xenbus_driver callbacks to align with exisitng PV drivers
- re-worked backend error handling with connector hotplug uevents
- removed vblank handling so user-space doesn't have an impression
  we really support that
- directly use front's mode_set in display enable/disable
- removed BUG_ON, error handling implemented
- moved driver documentation into Documentation/gpu
- other comments from Xen community addressed (Boris and Juergen)
- squashed Xen and DRM patches for better interrconnection

[Xen-devel] [PATCH RESEND v2 2/2] drm/xen-front: Provide kernel documentation

From: Oleksandr Andrushchenko 

Provide kernel documentation for the Xen para-virtualized
frontend DRM driver.

Signed-off-by: Oleksandr Andrushchenko 
---
 Documentation/gpu/index.rst |  1 +
 Documentation/gpu/xen-front.rst | 77 +
 2 files changed, 78 insertions(+)
 create mode 100644 Documentation/gpu/xen-front.rst

diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index c36586dad29d..e31684af0a20 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -20,6 +20,7 @@ Linux GPU Driver Developer's Guide
vga-switcheroo
vgaarbiter
bridge/dw-hdmi
+   xen-front
todo
 
 .. only::  subproject and html
diff --git a/Documentation/gpu/xen-front.rst b/Documentation/gpu/xen-front.rst
new file mode 100644
index ..6ac0b75373c4
--- /dev/null
+++ b/Documentation/gpu/xen-front.rst
@@ -0,0 +1,77 @@
+
+Xen para-virtualized frontend driver
+
+This frontend driver implements Xen para-virtualized display
+according to the display protocol described at
+include/xen/interface/io/displif.h
+
+Driver modes of operation in terms of display buffers used
+==
+
+Depending on the requirements for the para-virtualized environment, namely
+requirements dictated by the accompanying DRM/(v)GPU drivers running in both
+host and guest environments, number of operating modes of para-virtualized
+display driver are supported:
+
+- display buffers can be allocated by either frontend driver or backend
+- display buffers can be allocated to be contiguous in memory or not
+
+Note! Frontend driver itself has no dependency on contiguous memory for
+its operation.
+
+Buffers allocated by the frontend driver
+
+
+The below modes of operation are configured at compile-time via
+frontend driver's kernel configuration:
+
+With GEM CMA helpers
+
+ This use-case is useful when used with accompanying DRM/vGPU driver in
+ guest domain which was designed to only work with contiguous buffers,
+ e.g. DRM driver based on GEM CMA helpers: such drivers can only import
+ contiguous PRIME buffers, thus requiring frontend driver to provide
+ such. In order to implement this mode of operation para-virtualized
+ frontend driver can be configured to use GEM CMA helpers.
+
+Without GEM CMA helpers
+~~~
+ If accompanying drivers can cope with non-contiguous memory then, to
+ lower pressure on CMA subsystem of the kernel, driver can allocate
+ buffers from system memory.
+
+ Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
+ may require IOMMU support on the platform, so accompanying DRM/vGPU
+ hardware can still reach display buffer memory while importing PRIME
+ buffers from the frontend driver.
+
+Buffers allocated by the backend
+
+
+This mode of operation is run-time configured via guest domain configuration
+through XenStore entries.
+
+For systems which do not provide IOMMU support, but having specific
+requirements for display buffers it is possible to allocate such buffers
+at backend side and share those with the frontend.
+For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting
+physically contiguous memory, this allows implementing zero-copying
+use-cases.
+
+Note, while using this scenario the following should be considered:
+
+#. If guest domain dies then pages/grants received from the backend
+   cannot be claimed back
+
+#. Misbehaving guest may send too many requests to the
+   backend exhausting its grant references and memory
+   (consider this from security POV).
+
+Driver limitations
+==
+
+#. Only primary plane without additional properties is supported.
+
+#. Only one video mode per connector supported which is configured via 
XenStore.
+
+#. All CRTCs operate at fixed frequency of 60Hz.
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v6 7/9] x86/mm: provide put_page_type_ptpg{, _preemptible}

>>> On 13.02.18 at 21:04,  wrote:
> @@ -2736,8 +2744,8 @@ int put_old_guest_table(struct vcpu *v)
>  if ( !v->arch.old_guest_table )
>  return 0;
>  
> -switch ( rc = _put_page_type(v->arch.old_guest_table, true,
> - v->arch.old_guest_ptpg) )
> +switch ( rc = put_page_type_ptpg_preemptible(v->arch.old_guest_table,
> + v->arch.old_guest_ptpg) )

Having looked briefly at patch 8, it looks like this - PV only
afaict - function is the only thing not being moved there, and
hence the only reason to have the helpers you introduce here.
Part of your problem is that a fair part of e.g. _put_page_type()
is PV-only, and hence would perhaps want moving or #ifdef-ing.

Jan

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

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

2018-03-13 Thread Doug Goldstein

On 3/13/18 10:38 AM, George Dunlap wrote:
> On 03/13/2018 03:31 AM, Doug Goldstein wrote:
>> Add a basic README explaining the containers and how people can use them
>> to locally test with if they see an error in CI and want to reproduce it
>> locally.
>>
>> Signed-off-by: Doug Goldstein 
>> ---
>>  extras/testing/README.md | 29 +
>>  1 file changed, 29 insertions(+)
>>  create mode 100644 extras/testing/README.md
>>
>> diff --git a/extras/testing/README.md b/extras/testing/README.md
>> new file mode 100644
>> index 000..0908a66
>> --- /dev/null
>> +++ b/extras/testing/README.md
>> @@ -0,0 +1,29 @@
>> +Docker Containers
>> +=
>> +
>> +These Docker containers should make it possible to build Xen in
>> +any of the available environments on any system that supports
>> +running Docker. They are organized by distro and tagged with
>> +the version of that distro. They are available from the GitLab
>> +Container Registry under the Xen project at:
>> +
>> +registry.gitlab.com/cardoe/xen/DISTRO:VERSION
> 
> If we were to check something like this into the upstream tree, it would
> be better if this were some sort of official Xen account (of which I'd
> be happy for you to be the maintainer).  Is that possible?

Yep. I mentioned in the cover letter that if people gave me a +1 I'd
move it over to the "xen-project" tenant. I've already registered it to
reserve it for us to move forward with this if we so decide.

> 
> Other than that, this looks really good.  As you say, having FreeBSD
> would be a good thing to add, and with my CentOS hat on, I'd like to add
> a hook to build the CentOS Virt SIG packages against master as well (so
> that I could get early notification of issues).

Totally agree. I ultimately want to have every environment that's
supported / used run through this loop. I'm just going to need some help
enumerating them all out.


-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH v6 7/9] x86/mm: provide put_page_type_ptpg{, _preemptible}

>>> On 13.02.18 at 21:04,  wrote:
> And replace open-coded _put_page_type where the parent table parameter
> is not null.
> 
> This is in preparation for code movement in which various
> put_page_from_lNe will be moved to pv/mm.c.

I dislike both the proliferation of new functions here and, as
indicated before, them being non-static when they're used in
just a single source file. By this point in the series I have to
admit I'm not convinced of the direction all this is taking.

Jan

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

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




On 12/03/18 17:33, Amit Tomer wrote:

Hi,


Hi,




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


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

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


earlycon=xenboot enables the early console for the hardware domain only. 
What I meant is having earlyprintk for Xen (see CONFIG_EARLY_PRINTK). 
This is used for low-level debug when booting the hypervisor.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v6 6/9] x86/mm: export set_tlbflush_timestamp

>>> On 13.02.18 at 21:04,  wrote:
> The function will skip stamping the page when the page is used as page
> table in shadow mode. Since it is called both in PV code and common
> code we need to export it.

Again I think there's some prerequisite analysis necessary: Is this
functionality actually needed at all for HVM guests? What we use
the time stamp for is to know whether, at a given later time, there
may still be TLB entries around for this page. With HVM guests'
pages not managed the PV way, I'm not convinced there is any
case where we'd need to worry about such TLB flushes.

Jan

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

Re: [Xen-devel] [PATCH v2 1/5] x86/hvm: Handle viridian MSRs via the new guest_{rd, wr}msr() infrastructure

2018-03-13 Thread Andrew Cooper

On 13/03/18 15:20, Jan Beulich wrote:
 On 07.03.18 at 19:58,  wrote:
>> @@ -175,11 +177,26 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr, 
>> uint64_t *val)
>> _MSR_MISC_FEATURES_CPUID_FAULTING;
>>  break;
>>  
>> +case MSR_HYPERVISOR_START ... MSR_HYPERVISOR_START + NR_VIRIDIAN_MSRS - 
>> 1:
>> +if ( is_viridian_domain(d) )
>> +{
>> +ret = guest_rdmsr_viridian(v, msr, val);
>> +goto out;
>> +}
>> +
>> +/* Fallthrough. */
>>  default:
>>  return X86EMUL_UNHANDLEABLE;
>>  }
>>  
>> -return X86EMUL_OKAY;
>> + out:
> I've noticed this only in the context of patch 4, but why is this label
> and yet another unnecessary "goto" here? That "goto" could simply
> be "break" afaics.

Ah - that is for changes which I haven't posted yet.

When we get onto MSRs which might be in the load/save lists, or may be
stashed in the VMCB/VMCS rather than in real hardware, we need to call
back into arch specific code when an update is completed.

~Andrew

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

Re: [Xen-devel] [PATCH v6 5/9] x86/mm: factor out pv_dec_linear_pt

>>> On 13.02.18 at 21:04,  wrote:
> Linear page table is a PV only feature. The functions used to handle
> that will be moved.

But the functions dealing with linear page tables are all helpers to
PV-only functions. Why does any of this need to become non-
static or factored out? It should all be moved in one go.

> @@ -70,6 +72,9 @@ static inline int pv_put_final_page_type(struct page_info 
> *page,
>   struct page_info *ptpg)
>  { ASSERT_UNREACHABLE(); return -EINVAL; }
>  
> +static inline void pv_dec_linear_pt(struct page_info *ptpg, struct page_info 
> *page,
> +unsigned long type) {}

Along those lines, if such a placeholder was indeed necessary, it
should gain ASSERT_UNREACHABLE() I think.

Jan

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

Re: [Xen-devel] [PATCH v6 4/9] x86/mm: add pv prefix to _put_final_page_type

>>> On 13.02.18 at 21:04,  wrote:
> ... so that it is clear it is PV only and can be moved later.

Same comment as on patch 1, plus - why does it need to become
non-static?

Jan


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

Re: [Xen-devel] [PATCH 51/57] ARM: new VGIC: Add preliminary stub implementation

2018-03-13 Thread Andre Przywara

Hi,

On 09/03/18 18:18, Julien Grall wrote:
> Hi Andre,
> 
> On 05/03/18 16:04, Andre Przywara wrote:
>> The ARM arch code requires an interrupt controller emulation to implement
>> vgic_clear_pending_irqs(), although it is suspected that it is actually
>> not necessary. Go with a stub for now to make the linker happy.
> 
> The implementation of that function is fundamentally wrong on the
> current vGIC for a few reasons:
> - lr_mask is reset but the LRs are not. This means when we context
> switch back, the LR might still be written and injecting unexpected
> interrupt (whoops).
> - both lists (inflight and pending) are cleared which means that a
> physical interrupt pending on that vCPU is lost forever (stay active in
> the physical so never going to fire again).
> 
> Furthermore, I don't think that Xen business to reset the GIC on cpu_on.
> If anything should be done, then is it on CPU_off to migrate the current
> interrupts to another vCPU. But IIRC the OS is responsible for that.
> 
> So I would kill that function. Any opinions?

So I guess given that the patch is pretty small, we are good with
keeping that for now, and solve this together with the old VGIC later.

Cheers,
Andre.

>>
>> Signed-off-by: Andre Przywara 
>> ---
>> Changelog RFC ... v1:
>> - split off from former patch, otherwise unchanged
>>
>>   xen/arch/arm/vgic/vgic.c | 8 
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
>> index 5e767927c0..5d84a4d81a 100644
>> --- a/xen/arch/arm/vgic/vgic.c
>> +++ b/xen/arch/arm/vgic/vgic.c
>> @@ -790,6 +790,14 @@ void gic_dump_vgic_info(struct vcpu *v)
>>   spin_unlock_irqrestore(>arch.vgic.ap_list_lock, flags);
>>   }
>>   +void vgic_clear_pending_irqs(struct vcpu *v)
>> +{
>> +    /*
>> + * TODO: It is unclear whether we really need this, so we might
>> instead
>> + * remove it on the caller site.
>> + */
>> +}
>> +
>>   /**
>>    * arch_move_irqs() - migrate the physical affinity of hardware
>> mapped vIRQs
>>    * @v:  the vCPU, already assigned to the new pCPU
>>
> 
> Cheers,
> 

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

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