[Xen-devel] [seabios test] 119338: regressions - FAIL

[osstest service owner]

flight 119338 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119338/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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

version targeted for testing:
 seabios  af0daeb2687ad2595482b8a71b02a082a5672ceb
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z  104 days
Failing since115733  2017-11-10 17:19:59 Z   97 days  124 attempts
Testing same since   119258  2018-02-15 09:12:54 Z0 days2 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Nikolay Nikolov 
  Paul Menzel 
  Stefan Berger 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel 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 af0daeb2687ad2595482b8a71b02a082a5672ceb
Author: Nikolay Nikolov 
Date:   Sat Feb 10 13:52:17 2018 +0200

floppy: Send 4 sense interrupt commands during controller initialization

During initialization, real floppy controllers need 4 sense interrupt 
commands
to clear the interrupt status (this represents the transition from "not 
ready"
to "ready" for each of the four virtual floppy drives), instead of just one.

This is described in detail in section 7.4 - Drive Polling of the Intel 
82077AA
datasheet.

Signed-off-by: Nikolay Nikolov 

commit 2611db472c0f0bad4987c20990a45c175342fc22
Author: Nikolay Nikolov 
Date:   Sat Feb 10 13:52:16 2018 +0200

floppy: Wait for the floppy motor to reach a stable speed, after starting

When starting up the 

[Xen-devel] [libvirt test] 119237: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw 11 guest-start  fail REGR. vs. 119049

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

version targeted for testing:
 libvirt  d70d07eef8001b55a5f6b18a2065da2b528d3679
baseline version:
 libvirt  554a5edcb46ff972fed45b851d70823b923fec6a

Last test of basis   119049  2018-02-13 04:20:05 Z3 days
Failing since119148  2018-02-14 04:23:35 Z2 days2 attempts
Testing same since   119237  2018-02-15 04:25:30 Z1 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Bjoern Walk 
  Jiri Denemark 
  Michal Privoznik 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



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

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

Explanation of these reports, and of osstest in general, is at

Re: [Xen-devel] Slow HVM boot time, was "HVM boot time optimization"

[Alexey G]

On Thu, 15 Feb 2018 17:02:35 +0100
Yessine Daoud  wrote:

> Hello,
>
>I tried to debug the issue and this what I found:
>the HVM boot takes some time at the following section
>(qemu/pc-bios/optionrom/linuxboot.S)
>/* Load kernel and initrd */
>read_fw_blob_addr32_edi(FW_CFG_INITRD) (ramdisk about 3M takes ~~7.s)
>read_fw_blob_addr32(FW_CFG_KERNEL) (vmlinuz about 7M takes ~~15.s)
>read_fw_blob_addr32(FW_CFG_CMDLINE)
>
>#define read_fw_blob_addr32(var) \
>read_fw var ## _ADDR; \
>mov %eax, %edi; \
>read_fw_blob_pre(var); \
>/* old as(1) doesn't like this insn so emit the bytes instead: \
>addr32 rep insb (%dx), %es:(%edi); \
>*/ \
>.dc.b 0x67,0xf3,0x6c
>
>#define read_fw_blob_addr32_edi(var) \
>read_fw_blob_pre(var); \
>/* old as(1) doesn't like this insn so emit the bytes instead: \
>addr32 rep insb (%dx), %es:(%edi); \
>*/ \
>.dc.b 0x67,0xf3,0x6c
>
>Any idea how to speed the  I/O read ?
>Thanks.

Hmm, looks like it does rep insb with every I/O iteration emulated
individually for some reason, hence its so slow. Normally it should be
emulated on a buffer basis. There might be a bug somewhere which cause
string I/O to be handled by every iteration.

You may try to collect QEMU trace logs using 
device_model_args = ["-trace", "events="]
Where the events file should contain lines like this:
xen_ioreq_server_create
xen_ioreq_server_destroy
xen_ioreq_server_state
xen_map_portio_range
xen_unmap_portio_range
cpu_ioreq_pio
cpu_ioreq_pio_read_reg
cpu_ioreq_pio_write_reg
handle_ioreq
handle_ioreq_read
handle_ioreq_write

The resulting log file in /var/log/xen might be large (may even require
to specify XEN_QEMU_CONSOLE_LIMIT=0) but will show how the string I/O
with port 510h is processed. This should narrow the issue.

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

[Xen-devel] [xen-unstable test] 119217: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 15 guest-saverestore.2 fail REGR. 
vs. 118698
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
118698
 build-armhf-pvops 5 host-build-prep  fail REGR. vs. 118698

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

version targeted for testing:
 xen  27196d4cc917d91b5b5daee50173565139ca9c9d
baseline version:
 xen  c93014ad3aa6aa88dfa5e96f66e8adb561483b8d

Last test of basis   118698  2018-02-08 19:23:11 Z7 days
Failing since118802  2018-02-10 00:36:18 Z6 days7 attempts
Testing same since   119217  2018-02-14 22:45:36 Z1 days1 attempts


People who touched revisions under test:
  Acked-by: Razvan Cojocaru 
  Alexandru Isaila 
  Andre Przywara 
  Andrew Cooper 
  Daniel De Graaf 
  George Dunlap 
  Haozhong Zhang 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Julien Grall 
  Kevin Tian 
  Paul Semel 
  Roger Pau Monne 
  Roger Pau Monné 
  Sameer Goel 
  Simon Gaiser 

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-freebsd10-amd64

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-amd64
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:  61f14c015f5be9151ba25e638d349f4d40cb7cd4
  Bug not present: 0a4b6e2f80aad46fb55a5cf7b1664c0aef030ee0
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/119349/


  (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-freebsd10-amd64.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-freebsd10-amd64.xen-boot
 --summary-out=tmp/119349.bisection-summary --basis-template=118324 
--blessings=real,real-bisect linux-linus test-amd64-i386-freebsd10-amd64 
xen-boot
Searching for failure / basis pass:
 119201 fail [host=italia0] / 118629 [host=rimava0] 118598 [host=chardonnay1] 
118586 [host=elbling0] 118576 [host=pinot1] 118566 [host=elbling1] 118556 
[host=huxelrebe1] 118538 [host=baroque1] 118501 [host=fiano1] 118464 
[host=chardonnay0] 118445 ok.
Failure / basis pass flights: 119201 / 118445
(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 61f14c015f5be9151ba25e638d349f4d40cb7cd4 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
Basis pass 0a4b6e2f80aad46fb55a5cf7b1664c0aef030ee0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
4c7e478d597b0346eef3a256cfd6794ac778b608
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#0a4b6e2f80aad46fb55a5cf7b1664c0aef030ee0-61f14c015f5be9151ba25e638d349f4d40cb7cd4
 
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-2b033e396f4fa0981bae1213cdacd15775655a97
 
git://xenbits.xen.org/xen.git#4c7e478d597b0346eef3a256cfd6794ac778b608-c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 1002 nodes in revision graph
Searching for test results:
 118445 pass 0a4b6e2f80aad46fb55a5cf7b1664c0aef030ee0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
4c7e478d597b0346eef3a256cfd6794ac778b608
 118362 [host=fiano0]
 118401 [host=italia1]
 118428 [host=baroque0]
 118464 [host=chardonnay0]
 118538 [host=baroque1]
 118501 [host=fiano1]
 118556 [host=huxelrebe1]
 118566 [host=elbling1]
 118576 [host=pinot1]
 118586 [host=elbling0]
 118629 [host=rimava0]
 118598 [host=chardonnay1]
 118638 fail irrelevant
 118672 fail irrelevant
 118775 fail irrelevant
 118893 fail irrelevant
 118968 fail irrelevant
 119064 fail irrelevant
 119117 fail 61f14c015f5be9151ba25e638d349f4d40cb7cd4 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
 119271 pass 0a4b6e2f80aad46fb55a5cf7b1664c0aef030ee0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
4c7e478d597b0346eef3a256cfd6794ac778b608
 119283 fail 61f14c015f5be9151ba25e638d349f4d40cb7cd4 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
 119288 pass 0a4b6e2f80aad46fb55a5cf7b1664c0aef030ee0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
00268cc91270c7b0aa3a1906bf7e7702db9c61c1
 119298 blocked 0a4b6e2f80aad46fb55a5cf7b1664c0aef030ee0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with Linus' tree

[Stefano Stabellini]

On Fri, 16 Feb 2018, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the xen-tip tree got a conflict in:
> 
>   drivers/xen/pvcalls-front.c
> 
> between commit:
> 
>   a9a08845e9ac ("vfs: do bulk POLL* -> EPOLL* replacement")
> 
> from Linus' tree and commit:
> 
>   1e7dbff356e5 ("pvcalls-front: introduce a per sock_mapping refcount")
> 
> from the xen-tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Hi Stephen,

it looks good.

Cheers,

Stefano


> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/xen/pvcalls-front.c
> index 753d9cb437d0,ca5b77309c7d..
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@@ -963,20 -942,13 +942,13 @@@ __poll_t pvcalls_front_poll(struct fil
>   {
>   struct pvcalls_bedata *bedata;
>   struct sock_mapping *map;
>  -int ret;
>  +__poll_t ret;
>   
> - pvcalls_enter();
> - if (!pvcalls_front_dev) {
> - pvcalls_exit();
> + map = pvcalls_enter_sock(sock);
> + if (IS_ERR(map))
>  -return POLLNVAL;
>  +return EPOLLNVAL;
> - }
>   bedata = dev_get_drvdata(_front_dev->dev);
>   
> - map = (struct sock_mapping *) sock->sk->sk_send_head;
> - if (!map) {
> - pvcalls_exit();
> - return EPOLLNVAL;
> - }
>   if (map->active_socket)
>   ret = pvcalls_front_poll_active(file, bedata, map, wait);
>   else
> 

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

[Xen-devel] [xen-4.7-testing bisection] complete build-i386

[osstest service owner]

branch xen-4.7-testing
xenbranch xen-4.7-testing
job build-i386
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:  aac4cbe3644738d485d38bd551046d63c00cc670
  Bug not present: 68420b47d9b813ca48891b604fab379d40aa594e
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/119353/


  commit aac4cbe3644738d485d38bd551046d63c00cc670
  Author: Jan Beulich 
  Date:   Wed Feb 14 12:06:22 2018 +0100
  
  x86: fix build with older tool chain
  
  Signed-off-by: Jan Beulich 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.7-testing/build-i386.xen-build 
--summary-out=tmp/119353.bisection-summary --basis-template=118721 
--blessings=real,real-bisect xen-4.7-testing build-i386 xen-build
Searching for failure / basis pass:
 119182 fail [host=huxelrebe0] / 118721 [host=chardonnay1] 118664 ok.
Failure / basis pass flights: 119182 / 118664
(tree with no url: minios)
(tree in basispass but not in latest: ovmf)
(tree in basispass but not in latest: qemu)
(tree in basispass but not in latest: seabios)
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 02659364349730f82977bd20331d4fa374648fa5 
aac4cbe3644738d485d38bd551046d63c00cc670
Basis pass 02659364349730f82977bd20331d4fa374648fa5 
f50ea840b9a860927c7aca5fa64eb34e14f17164
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen.git#02659364349730f82977bd20331d4fa374648fa5-02659364349730f82977bd20331d4fa374648fa5
 
git://xenbits.xen.org/xen.git#f50ea840b9a860927c7aca5fa64eb34e14f17164-aac4cbe3644738d485d38bd551046d63c00cc670
Loaded 1002 nodes in revision graph
Searching for test results:
 118664 pass 02659364349730f82977bd20331d4fa374648fa5 
f50ea840b9a860927c7aca5fa64eb34e14f17164
 118721 [host=chardonnay1]
 119182 fail 02659364349730f82977bd20331d4fa374648fa5 
aac4cbe3644738d485d38bd551046d63c00cc670
 119329 pass 02659364349730f82977bd20331d4fa374648fa5 
f50ea840b9a860927c7aca5fa64eb34e14f17164
 119330 fail 02659364349730f82977bd20331d4fa374648fa5 
aac4cbe3644738d485d38bd551046d63c00cc670
 119331 pass 02659364349730f82977bd20331d4fa374648fa5 
f9616884e16b8028c257c8b01fb12daff7fe3454
 119334 pass 02659364349730f82977bd20331d4fa374648fa5 
84d47acc05af516d813f1952e853c4ca2be2adba
 119335 pass 02659364349730f82977bd20331d4fa374648fa5 
327a7836744ca8d7e1cfc6dc476d51d7c63f68ea
 119336 pass 02659364349730f82977bd20331d4fa374648fa5 
e09548d28a1cffafc0fa5ed9f97ac58514491ab8
 119341 pass 02659364349730f82977bd20331d4fa374648fa5 
68420b47d9b813ca48891b604fab379d40aa594e
 119342 fail 02659364349730f82977bd20331d4fa374648fa5 
aac4cbe3644738d485d38bd551046d63c00cc670
 119344 pass 02659364349730f82977bd20331d4fa374648fa5 
68420b47d9b813ca48891b604fab379d40aa594e
 119346 fail 02659364349730f82977bd20331d4fa374648fa5 
aac4cbe3644738d485d38bd551046d63c00cc670
 119347 pass 02659364349730f82977bd20331d4fa374648fa5 
68420b47d9b813ca48891b604fab379d40aa594e
 119353 fail 02659364349730f82977bd20331d4fa374648fa5 
aac4cbe3644738d485d38bd551046d63c00cc670
Searching for interesting versions
 Result found: flight 118664 (pass), for basis pass
 Result found: flight 119182 (fail), for basis failure
 Repro found: flight 119329 (pass), for basis pass
 Repro found: flight 119330 (fail), for basis failure
 0 revisions at 02659364349730f82977bd20331d4fa374648fa5 
68420b47d9b813ca48891b604fab379d40aa594e
No revisions left to test, checking graph state.
 Result found: flight 119341 (pass), for last pass
 Result found: flight 119342 (fail), for first failure
 Repro found: flight 119344 (pass), for last pass
 Repro found: flight 119346 (fail), for first failure
 Repro found: flight 119347 (pass), for last pass
 Repro found: flight 119353 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  aac4cbe3644738d485d38bd551046d63c00cc670
  Bug not present: 68420b47d9b813ca48891b604fab379d40aa594e
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/119353/


  commit aac4cbe3644738d485d38bd551046d63c00cc670
  Author: Jan Beulich 
  Date:   Wed Feb 14 12:06:22 2018 +0100
  
  x86: fix build with older tool chain
  
  Signed-off-by: Jan Beulich 

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

119353: tolerable ALL FAIL

flight 119353 xen-4.7-testing real-bisect [real]

[Xen-devel] linux-next: manual merge of the xen-tip tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  drivers/xen/pvcalls-front.c

between commit:

  a9a08845e9ac ("vfs: do bulk POLL* -> EPOLL* replacement")

from Linus' tree and commit:

  1e7dbff356e5 ("pvcalls-front: introduce a per sock_mapping refcount")

from the xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/xen/pvcalls-front.c
index 753d9cb437d0,ca5b77309c7d..
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@@ -963,20 -942,13 +942,13 @@@ __poll_t pvcalls_front_poll(struct fil
  {
struct pvcalls_bedata *bedata;
struct sock_mapping *map;
 -  int ret;
 +  __poll_t ret;
  
-   pvcalls_enter();
-   if (!pvcalls_front_dev) {
-   pvcalls_exit();
+   map = pvcalls_enter_sock(sock);
+   if (IS_ERR(map))
 -  return POLLNVAL;
 +  return EPOLLNVAL;
-   }
bedata = dev_get_drvdata(_front_dev->dev);
  
-   map = (struct sock_mapping *) sock->sk->sk_send_head;
-   if (!map) {
-   pvcalls_exit();
-   return EPOLLNVAL;
-   }
if (map->active_socket)
ret = pvcalls_front_poll_active(file, bedata, map, wait);
else


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

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-saverestore  fail pass in 119117

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail in 119117 like 118324
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118324
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 

[Xen-devel] [PATCH 0/4] unsafe big.LITTLE support

[Stefano Stabellini]

Hi all,

This series changes the initialization of two virtual registers to make
sure they match the value of the underlying physical cpu.

It also disables cpus different from the boot cpu, unless a newly
introduced command line option is specified. In that case, it explains
how to setup the system to avoid corruptions, which involves manually
specifying the cpu affinity of all domains, because the scheduler still
lacks big.LITTLE support.

Cheers,

Stefano


Julien Grall (1):
  xen/arm: Park CPUs with a MIDR different from the boot CPU.

Stefano Stabellini (3):
  xen/arm: read ACTLR on the pcpu where the vcpu will run
  xen/arm: set vpidr on the pcpu where the vcpu will run
  xen/arm: update the docs about heterogeneous computing

 docs/misc/xen-command-line.markdown | 18 ++
 xen/arch/arm/domain.c   | 23 ++-
 xen/arch/arm/smpboot.c  | 27 +++
 3 files changed, 63 insertions(+), 5 deletions(-)

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

[Xen-devel] [PATCH 3/4] xen/arm: set vpidr on the pcpu where the vcpu will run

[Stefano Stabellini]

On big.LITTLE systems not all cores have the same midr. Instead of
initializing the vpidr to the boot cpu midr, set it to the value of the
midr of the pcpu where the vcpu will run.

This way, assuming that the vcpu has been created with the right pcpu
affinity, the guest will be able to read the right vpidr value, matching
the one of the physical cpu.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/domain.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 532e824..280125f 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -315,6 +315,22 @@ static void schedule_tail(struct vcpu *prev)
 static void continue_new_vcpu(struct vcpu *prev)
 {
 current->arch.actlr = READ_SYSREG32(ACTLR_EL1);
+/*
+ * Default the virtual ID to match the physical.
+ *
+ * In case the big.LITTLE systems, a guest should be created with
+ * cpu affinity set so that all vcpus run on the same kind of pcpus.
+ * Warn if it is not the case.
+ */
+if ( !current->domain->arch.vpidr )
+current->domain->arch.vpidr = current_cpu_data.midr.bits;
+else if ( current->domain->arch.vpidr != current_cpu_data.midr.bits )
+{
+gdprintk(XENLOG_WARNING,
+ "WARNING: possible corruptions! d%uv%u is running on a pcpu 
with different midr (%x) from the others (%x)\n",
+ current->domain->domain_id, current->vcpu_id,
+ current_cpu_data.midr.bits, current->domain->arch.vpidr);
+}
 
 schedule_tail(prev);
 
@@ -596,9 +612,6 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 if ( (d->shared_info = alloc_xenheap_pages(0, 0)) == NULL )
 goto fail;
 
-/* Default the virtual ID to match the physical */
-d->arch.vpidr = boot_cpu_data.midr.bits;
-
 clear_page(d->shared_info);
 share_xen_page_with_guest(
 virt_to_page(d->shared_info), d, XENSHARE_writable);
-- 
1.9.1


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

[Xen-devel] [PATCH 4/4] xen/arm: update the docs about heterogeneous computing

[Stefano Stabellini]

Update the documentation of the hmp-unsafe option to explain how to use
it safely, together with the right cpu affinity setting, on big.LITTLE
systems.

Also update the warning message to point users to the docs.

Signed-off-by: Stefano Stabellini 
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com

---
 docs/misc/xen-command-line.markdown | 10 +-
 xen/arch/arm/smpboot.c  |  9 +
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 2184cb9..a1ebeea 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1007,7 +1007,15 @@ Control Xens use of the APEI Hardware Error Source 
Table, should one be found.
 
 Say yes at your own risk if you want to enable heterogenous computing
 (such as big.LITTLE). This may result to an unstable and insecure
-platform. When the option is disabled (default), CPUs that are not
+platform, unless you manually specify the cpu affinity of all domains so
+that all vcpus are scheduled on the same class of pcpus (big or LITTLE
+but not both). vcpu migration between big cores and LITTLE cores is not
+supported. Thus, if the first 4 pcpus are big and the last 4 are LITTLE,
+all domains need to have either cpus = "0-3" or cpus = "4-7" in their VM
+config. Moreover, dom0_vcpus_pin needs to be passed on the Xen command
+line.
+
+When the hmp-unsafe option is disabled (default), CPUs that are not
 identical to the boot CPU will be parked and not used by Xen.
 
 ### hpetbroadcast
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 7ea4e41..20c1b4a 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -265,7 +265,7 @@ void __init smp_init_cpus(void)
 
 if ( opt_hmp_unsafe )
 warning_add("WARNING: HMP COMPUTING HAS BEEN ENABLED.\n"
-"It has implications on the security and stability of the 
system.\n");
+"Make sure to pass dom0_vcpus_pin, and specify the cpu 
affinity of all domains.\n");
 }
 
 int __init
@@ -306,13 +306,14 @@ void start_secondary(unsigned long boot_phys_offset,
 /*
  * Currently Xen assumes the platform has only one kind of CPUs.
  * This assumption does not hold on big.LITTLE platform and may
- * result to instability and insecure platform. Better to park them
- * for now.
+ * result to instability and insecure platform (unless cpu affinity
+ * is manually specified for all domains). Better to park them for
+ * now.
  */
 if ( !opt_hmp_unsafe &&
  current_cpu_data.midr.bits != boot_cpu_data.midr.bits )
 {
-printk(XENLOG_ERR "CPU%u MIDR (0x%x) does not match boot CPU MIDR 
(0x%x).\n",
+printk(XENLOG_ERR "CPU%u MIDR (0x%x) does not match boot CPU MIDR 
(0x%x), disable cpu. See hmp-unsafe.\n",
smp_processor_id(), current_cpu_data.midr.bits,
boot_cpu_data.midr.bits);
 stop_cpu();
-- 
1.9.1


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

[Xen-devel] [PATCH 2/4] xen/arm: read ACTLR on the pcpu where the vcpu will run

[Stefano Stabellini]

On big.LITTLE systems not all cores have the same ACTLR. Instead of
reading ACTLR and setting v->arch.actlr in vcpu_initialise, which is run
always on pcpu 0, do it later on the same pcpu where the vcpu will run.

This way, assuming that the vcpu has been created with the right pcpu
affinity, the guest will be able to read the right ACTLR value, matching
the one of the physical cpu.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/domain.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index a010443..532e824 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -314,6 +314,8 @@ static void schedule_tail(struct vcpu *prev)
 
 static void continue_new_vcpu(struct vcpu *prev)
 {
+current->arch.actlr = READ_SYSREG32(ACTLR_EL1);
+
 schedule_tail(prev);
 
 if ( is_idle_vcpu(current) )
@@ -540,8 +542,6 @@ int vcpu_initialise(struct vcpu *v)
 
 v->arch.vmpidr = MPIDR_SMP | vcpuid_to_vaffinity(v->vcpu_id);
 
-v->arch.actlr = READ_SYSREG32(ACTLR_EL1);
-
 v->arch.hcr_el2 = get_default_hcr_flags();
 
 processor_vcpu_initialise(v);
-- 
1.9.1


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

[Xen-devel] [PATCH 1/4] xen/arm: Park CPUs with a MIDR different from the boot CPU.

[Stefano Stabellini]

From: Julien Grall 

From: Julien Grall 

Xen does not properly support big.LITTLE platform. All vCPUs of a guest
will always have the MIDR of the boot CPU (see arch_domain_create).
At best the guest may see unreliable performance (vCPU switching between
big and LITTLE), at worst the guest will become unreliable or insecure.

This is becoming more apparent with branch predictor hardening in Linux
because they target a specific kind of CPUs and may not work on other
CPUs.

For the time being, park any CPUs with a MDIR different from the boot
CPU. This will be revisited in the future once Xen gains understanding
of big.LITTLE.

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

Signed-off-by: Julien Grall 
Reviewed-by: Oleksandr Tyshchenkko 
Reviewed-by: Stefano Stabellini 
Acked-by: Jan Beulich 
---
 docs/misc/xen-command-line.markdown | 10 ++
 xen/arch/arm/smpboot.c  | 26 ++
 2 files changed, 36 insertions(+)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 8317639..2184cb9 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1000,6 +1000,16 @@ supported only when compiled with XSM on x86.
 
 Control Xens use of the APEI Hardware Error Source Table, should one be found.
 
+### hmp-unsafe (arm)
+> `= `
+
+> Default : `false`
+
+Say yes at your own risk if you want to enable heterogenous computing
+(such as big.LITTLE). This may result to an unstable and insecure
+platform. When the option is disabled (default), CPUs that are not
+identical to the boot CPU will be parked and not used by Xen.
+
 ### hpetbroadcast
 > `= `
 
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 1255185..7ea4e41 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -69,6 +70,13 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
 /* representing HT and core siblings of each logical CPU */
 DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
 
+/*
+ * By default non-boot CPUs not identical to the boot CPU will be
+ * parked.
+ */
+static bool __read_mostly opt_hmp_unsafe = false;
+boolean_param("hmp-unsafe", opt_hmp_unsafe);
+
 static void setup_cpu_sibling_map(int cpu)
 {
 if ( !zalloc_cpumask_var(_cpu(cpu_sibling_mask, cpu)) ||
@@ -255,6 +263,9 @@ void __init smp_init_cpus(void)
 else
 acpi_smp_init_cpus();
 
+if ( opt_hmp_unsafe )
+warning_add("WARNING: HMP COMPUTING HAS BEEN ENABLED.\n"
+"It has implications on the security and stability of the 
system.\n");
 }
 
 int __init
@@ -292,6 +303,21 @@ void start_secondary(unsigned long boot_phys_offset,
 
 init_traps();
 
+/*
+ * Currently Xen assumes the platform has only one kind of CPUs.
+ * This assumption does not hold on big.LITTLE platform and may
+ * result to instability and insecure platform. Better to park them
+ * for now.
+ */
+if ( !opt_hmp_unsafe &&
+ current_cpu_data.midr.bits != boot_cpu_data.midr.bits )
+{
+printk(XENLOG_ERR "CPU%u MIDR (0x%x) does not match boot CPU MIDR 
(0x%x).\n",
+   smp_processor_id(), current_cpu_data.midr.bits,
+   boot_cpu_data.midr.bits);
+stop_cpu();
+}
+
 mmu_init_secondary_cpu();
 
 gic_init_secondary_cpu();
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v3] xen/arm: Park CPUs with a MIDR different from the boot CPU.

[Stefano Stabellini]

On Thu, 15 Feb 2018, Julien Grall wrote:
> Xen does not properly support big.LITTLE platform. All vCPUs of a guest
> will always have the MIDR of the boot CPU (see arch_domain_create).
> At best the guest may see unreliable performance (vCPU switching between
> big and LITTLE), at worst the guest will become unreliable or insecure.
> 
> This is becoming more apparent with branch predictor hardening in Linux
> because they target a specific kind of CPUs and may not work on other
> CPUs.
> 
> For the time being, park any CPUs with a MDIR different from the boot
> CPU. This will be revisited in the future once Xen gains understanding
> of big.LITTLE.
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00826.html
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Oleksandr Tyshchenkko 
> Acked-by: Jan Beulich 

Hi Julien,

This patch is fine. As discussed, I have a couple of patches that make
big.LITTLE a bit more usable, provided that the right cpu affinity is
specified for all domains.

I am going to take this patch as is, and add it at the beginning of my
little series. I'll update the warning and the docs in a separate patch.


> ---
> 
> We probably want to backport this as part of XSA-254. Using big.LITTLE
> on Xen has never been supported but we didn't make it clearly. This is
> becoming more apparent with code targeting specific CPUs.
> 
> Oleksandr, FIY, I've kept your reviewed-by despite changing the command line
> option.
> 
> Changes in v3:
> - Rename hmp_unsafe to hmp-unsafe.
> - Add Jan's acked-by
> - Add Oleksandr's reviewed-by
> 
> Changes in v2:
> - Add a command line option to override the default behavior.
> ---
>  docs/misc/xen-command-line.markdown | 10 ++
>  xen/arch/arm/smpboot.c  | 26 ++
>  2 files changed, 36 insertions(+)
> 
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index 79feba6bcd..7bd009f858 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1000,6 +1000,16 @@ supported only when compiled with XSM on x86.
>  
>  Control Xens use of the APEI Hardware Error Source Table, should one be 
> found.
>  
> +### hmp-unsafe (arm)
> +> `= `
> +
> +> Default : `false`
> +
> +Say yes at your own risk if you want to enable heterogenous computing
> +(such as big.LITTLE). This may result to an unstable and insecure
> +platform. When the option is disabled (default), CPUs that are not
> +identical to the boot CPU will be parked and not used by Xen.
> +
>  ### hpetbroadcast
>  > `= `
>  
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index 1255185a9c..7ea4e41866 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -69,6 +70,13 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, 
> cpu_sibling_mask);
>  /* representing HT and core siblings of each logical CPU */
>  DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
>  
> +/*
> + * By default non-boot CPUs not identical to the boot CPU will be
> + * parked.
> + */
> +static bool __read_mostly opt_hmp_unsafe = false;
> +boolean_param("hmp-unsafe", opt_hmp_unsafe);
> +
>  static void setup_cpu_sibling_map(int cpu)
>  {
>  if ( !zalloc_cpumask_var(_cpu(cpu_sibling_mask, cpu)) ||
> @@ -255,6 +263,9 @@ void __init smp_init_cpus(void)
>  else
>  acpi_smp_init_cpus();
>  
> +if ( opt_hmp_unsafe )
> +warning_add("WARNING: HMP COMPUTING HAS BEEN ENABLED.\n"
> +"It has implications on the security and stability of 
> the system.\n");
>  }
>  
>  int __init
> @@ -292,6 +303,21 @@ void start_secondary(unsigned long boot_phys_offset,
>  
>  init_traps();
>  
> +/*
> + * Currently Xen assumes the platform has only one kind of CPUs.
> + * This assumption does not hold on big.LITTLE platform and may
> + * result to instability and insecure platform. Better to park them
> + * for now.
> + */
> +if ( !opt_hmp_unsafe &&
> + current_cpu_data.midr.bits != boot_cpu_data.midr.bits )
> +{
> +printk(XENLOG_ERR "CPU%u MIDR (0x%x) does not match boot CPU MIDR 
> (0x%x).\n",
> +   smp_processor_id(), current_cpu_data.midr.bits,
> +   boot_cpu_data.midr.bits);
> +stop_cpu();
> +}
> +
>  mmu_init_secondary_cpu();
>  
>  gic_init_secondary_cpu();
> -- 
> 2.11.0
> 

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

[Xen-devel] [seabios test] 119258: regressions - FAIL

[osstest service owner]

flight 119258 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119258/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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

version targeted for testing:
 seabios  af0daeb2687ad2595482b8a71b02a082a5672ceb
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z  104 days
Failing since115733  2017-11-10 17:19:59 Z   97 days  123 attempts
Testing same since   119258  2018-02-15 09:12:54 Z0 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Nikolay Nikolov 
  Paul Menzel 
  Stefan Berger 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel 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 af0daeb2687ad2595482b8a71b02a082a5672ceb
Author: Nikolay Nikolov 
Date:   Sat Feb 10 13:52:17 2018 +0200

floppy: Send 4 sense interrupt commands during controller initialization

During initialization, real floppy controllers need 4 sense interrupt 
commands
to clear the interrupt status (this represents the transition from "not 
ready"
to "ready" for each of the four virtual floppy drives), instead of just one.

This is described in detail in section 7.4 - Drive Polling of the Intel 
82077AA
datasheet.

Signed-off-by: Nikolay Nikolov 

commit 2611db472c0f0bad4987c20990a45c175342fc22
Author: Nikolay Nikolov 
Date:   Sat Feb 10 13:52:16 2018 +0200

floppy: Wait for the floppy motor to reach a stable speed, after starting

When starting up the 

[Xen-devel] Minutes of the Xen ARM community call Tuesday 13th February 5PM UTC

[Stefano Stabellini]

Hi all,

These are the minutes of the meeting we had earlier this week. Thank you
all for attending!

Cheers,

Stefano


Attendees: Stefano Stabellini, Julien Grall (ARM), Artem Mygaiev (EPAM),
Mirela Simonovic (Aggios), Davorin Mista (Aggios), Christopher Clark,
Andrii Anisov (EPAM), Rich Persaud, Nicole Chalhoub, Anthony Toubeau,
Volodymyr Babchuk (EPAM), Oleksander (EPAM), Kristophor (DornerWorks).


= GPU virtualization =

Artem: Coprocessor framework is used for virtualization, on top of it
there is a component based on Imagination Technology guidelines. PV
drivers are too slow. EPAM used a different way. The implementation with
Imagination Technology doesn't completely switch GPU context. Instead,
we signal the GPU to switch domain. The firmware is doing most of the
work. There are limits by the GPU for number of contexts (number of VMs
that can have a vGPU). Also RAM could be a limitation. Most GPUs have
their own MMU, and securing those is difficult. Only 300LOC for the
Imagination Technology specific driver. Almost nothing Imagination
specific in the hypervisor -- the solution relies heavily on the generic
coprocessor framework.  EPAM will submit it to xeb-devel again soon.

Question by Artem: is there interest to virtualize Mali?
ACTION Julien: I'll make introductions


= Suspend/Resume Demo =

Mirela: Xen suspend/resume on Xilinx MPSoC
1.8W = 1.5 (aarch64 cores) + 0.3 (low power domain)

Create 1 more Linux DomU: power consumption goes to 2W temporarily, then
back to normal because it is idle.
Suspend the domU linux -> no change, it was already idle.
Load a bare metal guest: power consumpion increases because it is idle
looping. Small differece, about 0.1W. Suspend it and goes back to
normal.
Dom0 suspends, then Xen suspends.
Any interrupt can wake up the whole system.
0.035W consumption after suspend.
PSCI based suspend.

ACTION Stefano Send link to suspend/resume design doc to Artem.
See below. [1]


= AGL Whitepaper =
Artem: please review the whitepaper, most of the content is already
there.
Everybody agrees that Xen Project should publish its own whitepaper.

Certifications are mostly not about the code. Artem about to share an
analysis done by third parties on certification gaps. Then, we'll
organize another call.
ACTION Artem: send out the gap analysis


[1] https://marc.info/?l=xen-devel=151396462523580

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  548224fe4256ea02669f106fe8b3297a22e6b4ad
baseline version:
 xtf  a08df2278be1a8d5b677f0ba78e13ca20ae141f8

Last test of basis   119006  2018-02-12 15:15:50 Z3 days
Testing same since   119280  2018-02-15 14:20:58 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xtf.git
   a08df22..548224f  548224fe4256ea02669f106fe8b3297a22e6b4ad -> 
xen-tested-master

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

[Xen-devel] [xen-4.7-testing bisection] complete build-i386-xsm

[osstest service owner]

branch xen-4.7-testing
xenbranch xen-4.7-testing
job build-i386-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:  aac4cbe3644738d485d38bd551046d63c00cc670
  Bug not present: 68420b47d9b813ca48891b604fab379d40aa594e
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/119302/


  commit aac4cbe3644738d485d38bd551046d63c00cc670
  Author: Jan Beulich 
  Date:   Wed Feb 14 12:06:22 2018 +0100
  
  x86: fix build with older tool chain
  
  Signed-off-by: Jan Beulich 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.7-testing/build-i386-xsm.xen-build 
--summary-out=tmp/119302.bisection-summary --basis-template=118721 
--blessings=real,real-bisect xen-4.7-testing build-i386-xsm xen-build
Searching for failure / basis pass:
 119182 fail [host=huxelrebe0] / 118721 [host=huxelrebe1] 118664 [host=italia0] 
118337 [host=elbling1] 118245 [host=huxelrebe1] 118221 [host=huxelrebe1] 117937 
[host=italia0] 117873 [host=chardonnay0] 117705 [host=huxelrebe1] 117289 
[host=huxelrebe1] 117241 [host=baroque1] 117195 [host=huxelrebe1] 117141 
[host=baroque1] 117115 [host=baroque1] 116665 [host=rimava1] 116623 
[host=chardonnay1] 116506 ok.
Failure / basis pass flights: 119182 / 116506
(tree with no url: minios)
(tree in basispass but not in latest: ovmf)
(tree in basispass but not in latest: qemu)
(tree in basispass but not in latest: seabios)
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 02659364349730f82977bd20331d4fa374648fa5 
aac4cbe3644738d485d38bd551046d63c00cc670
Basis pass c21d63ec23de80b267cd34f887b229b3763ffc47 
bcc9e245aafbdae44c761053c898bedb3582cc4d
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen.git#c21d63ec23de80b267cd34f887b229b3763ffc47-02659364349730f82977bd20331d4fa374648fa5
 
git://xenbits.xen.org/xen.git#bcc9e245aafbdae44c761053c898bedb3582cc4d-aac4cbe3644738d485d38bd551046d63c00cc670
From git://cache:9419/git://xenbits.xen.org/xen
   422588e885..5e6984c50b  smoke  -> origin/smoke
Loaded 3011 nodes in revision graph
Searching for test results:
 116455 [host=chardonnay1]
 116485 [host=nobling0]
 116506 pass c21d63ec23de80b267cd34f887b229b3763ffc47 
bcc9e245aafbdae44c761053c898bedb3582cc4d
 116665 [host=rimava1]
 116623 [host=chardonnay1]
 117179 [host=huxelrebe1]
 117115 [host=baroque1]
 117186 [host=baroque1]
 117141 [host=baroque1]
 117195 [host=huxelrebe1]
 117241 [host=baroque1]
 117289 [host=huxelrebe1]
 117705 [host=huxelrebe1]
 117873 [host=chardonnay0]
 117937 [host=italia0]
 118221 [host=huxelrebe1]
 118245 [host=huxelrebe1]
 118337 [host=elbling1]
 118664 [host=italia0]
 118721 [host=huxelrebe1]
 119182 fail 02659364349730f82977bd20331d4fa374648fa5 
aac4cbe3644738d485d38bd551046d63c00cc670
 119282 pass 02659364349730f82977bd20331d4fa374648fa5 
e09548d28a1cffafc0fa5ed9f97ac58514491ab8
 119269 pass 02659364349730f82977bd20331d4fa374648fa5 
c3f8df3df224eeac0e78533644010ed096de7a34
 119291 fail 02659364349730f82977bd20331d4fa374648fa5 
aac4cbe3644738d485d38bd551046d63c00cc670
 119275 pass 02659364349730f82977bd20331d4fa374648fa5 
c947e1e23d1db17da0dd211b9410f311248b6c13
 119284 pass 02659364349730f82977bd20331d4fa374648fa5 
68420b47d9b813ca48891b604fab379d40aa594e
 119250 pass c21d63ec23de80b267cd34f887b229b3763ffc47 
bcc9e245aafbdae44c761053c898bedb3582cc4d
 119276 pass 02659364349730f82977bd20331d4fa374648fa5 
4a38ec26bafde70f2af36d7bc2bec7f218145982
 119266 fail 02659364349730f82977bd20331d4fa374648fa5 
aac4cbe3644738d485d38bd551046d63c00cc670
 119268 pass 02659364349730f82977bd20331d4fa374648fa5 
624abdcf2d30ae48e0653fb511b4c90d3ccdd2af
 119287 pass 02659364349730f82977bd20331d4fa374648fa5 
68420b47d9b813ca48891b604fab379d40aa594e
 119286 fail 02659364349730f82977bd20331d4fa374648fa5 
aac4cbe3644738d485d38bd551046d63c00cc670
 119277 pass 02659364349730f82977bd20331d4fa374648fa5 
be261bd97f7b4fc76db7c11bb3366974f5635a04
 119297 pass 02659364349730f82977bd20331d4fa374648fa5 
68420b47d9b813ca48891b604fab379d40aa594e
 119302 fail 02659364349730f82977bd20331d4fa374648fa5 
aac4cbe3644738d485d38bd551046d63c00cc670
Searching for interesting versions
 Result found: flight 116506 (pass), for basis pass
 Result found: flight 119182 (fail), for basis failure
 Repro found: flight 119250 (pass), for basis pass
 Repro found: flight 119266 (fail), for basis failure
 0 revisions at 02659364349730f82977bd20331d4fa374648fa5 
68420b47d9b813ca48891b604fab379d40aa594e
No revisions left to test, checking graph 

Re: [Xen-devel] [PATCH] vmx/hap: optimize CR4 trapping

[Razvan Cojocaru]

On 02/15/2018 08:57 PM, Andrew Cooper wrote:
> On 15/02/18 16:25, Roger Pau Monne wrote:
>> There a bunch of bits in CR4 that should be allowed to be set directly
>> by the guest without requiring Xen intervention, currently this is
>> already done by passing through guest writes into the CR4 used when
>> running in non-root mode, but taking an expensive vmexit in order to
>> do so.
>>
>> xenalyze reports the following when running a PV guest in shim mode:
>>
>>  CR_ACCESS 3885950  6.41s 17.04%  3957 cyc { 2361| 3378| 7920}
>>cr4  3885940  6.41s 17.04%  3957 cyc { 2361| 3378| 7920}
>>cr31  0.00s  0.00%  3480 cyc { 3480| 3480| 3480}
>>  *[  0]1  0.00s  0.00%  3480 cyc { 3480| 3480| 3480}
>>cr07  0.00s  0.00%  7112 cyc { 3248| 5960|17480}
>>clts2  0.00s  0.00%  4588 cyc { 3456| 5720| 5720}
>>
>> After this change this turns into:
>>
>>  CR_ACCESS  12  0.00s  0.00%  9972 cyc { 3680|11024|24032}
>>cr42  0.00s  0.00% 17528 cyc {11024|24032|24032}
>>cr31  0.00s  0.00%  3680 cyc { 3680| 3680| 3680}
>>  *[  0]1  0.00s  0.00%  3680 cyc { 3680| 3680| 3680}
>>cr07  0.00s  0.00%  9209 cyc { 4184| 7848|17488}
>>clts2  0.00s  0.00%  8232 cyc { 5352|2|2}
>>
>> Note that this optimized trapping is currently only applied to guests
>> running with HAP on Intel hardware. If using shadow paging more CR4
>> bits need to be unconditionally trapped, which makes this approach
>> unlikely to yield any important performance improvements.
>>
>> Reported-by: Andrew Cooper 
>> Signed-off-by: Roger Pau Monné 
>> ---
>> Cc: Jun Nakajima 
>> Cc: Kevin Tian 
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>> Cc: Razvan Cojocaru 
>> Cc: Tamas K Lengyel 
>> ---
>>  xen/arch/x86/hvm/vmx/vmx.c  | 41 +
>>  xen/arch/x86/hvm/vmx/vvmx.c |  5 -
>>  xen/arch/x86/monitor.c  |  5 +++--
>>  3 files changed, 48 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index d35cf55982..9747b2a398 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -1684,6 +1684,35 @@ static void vmx_update_guest_cr(struct vcpu *v, 
>> unsigned int cr)
>>  }
>>  
>>  __vmwrite(GUEST_CR4, v->arch.hvm_vcpu.hw_cr[4]);
>> +
>> +if ( (v->domain->arch.monitor.write_ctrlreg_enabled &
>> +  monitor_ctrlreg_bitmask(VM_EVENT_X86_CR4)) ||
>> + !paging_mode_hap(v->domain) )
>> +/*
>> + * If requested by introspection or running in shadow mode trap 
>> all
>> + * accesses to CR4.
> 
> The monitor write_ctrlreg_onchangeonly feature was purposefully
> introduced to avoid sending PGE updates to the introspection agent.  It
> would be ideal to include that in the mask calculation so introspection
> cases don't vmexit for PGE changes.
> 
> Also, AMD has similar capabilities, and (as of today) has gained CR
> monitoring.

I believe the patch Andrew is referring to is this one:

https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=59aad28cfac09640e2272f1e87951406233c3192

We added that specifically so that no PGE-only exits end up needing
(pointless) processing by the introspection agent.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH V4] x86/hvm: fix domain crash when CR3 has the noflush bit set

[Razvan Cojocaru]

On 02/15/2018 06:50 PM, Jan Beulich wrote:
 On 09.02.18 at 12:01,  wrote:
>> @@ -563,13 +563,19 @@ void svm_update_guest_cr(struct vcpu *v, unsigned int 
>> cr)
>>  case 3:
>>  vmcb_set_cr3(vmcb, v->arch.hvm_vcpu.hw_cr[3]);
>>  if ( !nestedhvm_enabled(v->domain) )
>> -hvm_asid_flush_vcpu(v);
>> +{
>> +if ( !(flags & HVM_UPDATE_GUEST_CR3_NO_FLUSH) )
>> +hvm_asid_flush_vcpu(v);
>> +}
>>  else if ( nestedhvm_vmswitch_in_progress(v) )
>>  ; /* CR3 switches during VMRUN/VMEXIT do not flush the TLB. */
>>  else
>> -hvm_asid_flush_vcpu_asid(
>> -nestedhvm_vcpu_in_guestmode(v)
>> -? _nestedhvm(v).nv_n2asid : >arch.hvm_vcpu.n1asid);
>> +{
>> +if ( !(flags & HVM_UPDATE_GUEST_CR3_NO_FLUSH) )
> 
> Any reason you didn't make this an "else if()", reducing code churn?

I just thought it reads easier, but I don't feel strongly about it.
I'll change it.

>> --- a/xen/include/asm-x86/hvm/hvm.h
>> +++ b/xen/include/asm-x86/hvm/hvm.h
>> @@ -80,6 +80,9 @@ enum hvm_intblk {
>>  #define HVM_EVENT_VECTOR_UNSET(-1)
>>  #define HVM_EVENT_VECTOR_UPDATING (-2)
>>  
>> +/* update_guest_cr() flags. */
>> +#define HVM_UPDATE_GUEST_CR3_NO_FLUSH 0x0001
> 
> I'd prefer if the naming was consistent with X86_CR3_NOFLUSH
> (i.e. have or don't have an underscore between NO and FLUSH in
> both cases).

Of course. I'll change it.

>> --- a/xen/include/asm-x86/x86-defns.h
>> +++ b/xen/include/asm-x86/x86-defns.h
>> @@ -43,6 +43,11 @@
>>  #define X86_CR0_PG  0x8000 /* Paging   (RW) 
>> */
>>  
>>  /*
>> + * Intel CPU flags in CR3
>> + */
>> +#define X86_CR3_NOFLUSH0x8000
> 
> Please add the ULL suffix, so the insn emulator could eventually
> use this without breaking the 32-bit test harness build.

Will change it (to _AC(...)) (as suggested by both you and Andrew).


Thanks,
Razvan

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  5e6984c50bc7147398474fea0e6b8dc7364b91b5
baseline version:
 xen  422588e88511d17984544c0f017a927de3315290

Last test of basis   119270  2018-02-15 12:01:24 Z0 days
Testing same since   119295  2018-02-15 17:01:04 Z0 days1 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andrew Cooper 
  Tamas K Lengyel 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   422588e885..5e6984c50b  5e6984c50bc7147398474fea0e6b8dc7364b91b5 -> smoke

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

Re: [Xen-devel] [PATCH] vmx/hap: optimize CR4 trapping

[Andrew Cooper]

On 15/02/18 16:25, Roger Pau Monne wrote:
> There a bunch of bits in CR4 that should be allowed to be set directly
> by the guest without requiring Xen intervention, currently this is
> already done by passing through guest writes into the CR4 used when
> running in non-root mode, but taking an expensive vmexit in order to
> do so.
>
> xenalyze reports the following when running a PV guest in shim mode:
>
>  CR_ACCESS 3885950  6.41s 17.04%  3957 cyc { 2361| 3378| 7920}
>cr4  3885940  6.41s 17.04%  3957 cyc { 2361| 3378| 7920}
>cr31  0.00s  0.00%  3480 cyc { 3480| 3480| 3480}
>  *[  0]1  0.00s  0.00%  3480 cyc { 3480| 3480| 3480}
>cr07  0.00s  0.00%  7112 cyc { 3248| 5960|17480}
>clts2  0.00s  0.00%  4588 cyc { 3456| 5720| 5720}
>
> After this change this turns into:
>
>  CR_ACCESS  12  0.00s  0.00%  9972 cyc { 3680|11024|24032}
>cr42  0.00s  0.00% 17528 cyc {11024|24032|24032}
>cr31  0.00s  0.00%  3680 cyc { 3680| 3680| 3680}
>  *[  0]1  0.00s  0.00%  3680 cyc { 3680| 3680| 3680}
>cr07  0.00s  0.00%  9209 cyc { 4184| 7848|17488}
>clts2  0.00s  0.00%  8232 cyc { 5352|2|2}
>
> Note that this optimized trapping is currently only applied to guests
> running with HAP on Intel hardware. If using shadow paging more CR4
> bits need to be unconditionally trapped, which makes this approach
> unlikely to yield any important performance improvements.
>
> Reported-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Jun Nakajima 
> Cc: Kevin Tian 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Razvan Cojocaru 
> Cc: Tamas K Lengyel 
> ---
>  xen/arch/x86/hvm/vmx/vmx.c  | 41 +
>  xen/arch/x86/hvm/vmx/vvmx.c |  5 -
>  xen/arch/x86/monitor.c  |  5 +++--
>  3 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index d35cf55982..9747b2a398 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1684,6 +1684,35 @@ static void vmx_update_guest_cr(struct vcpu *v, 
> unsigned int cr)
>  }
>  
>  __vmwrite(GUEST_CR4, v->arch.hvm_vcpu.hw_cr[4]);
> +
> +if ( (v->domain->arch.monitor.write_ctrlreg_enabled &
> +  monitor_ctrlreg_bitmask(VM_EVENT_X86_CR4)) ||
> + !paging_mode_hap(v->domain) )
> +/*
> + * If requested by introspection or running in shadow mode trap 
> all
> + * accesses to CR4.

The monitor write_ctrlreg_onchangeonly feature was purposefully
introduced to avoid sending PGE updates to the introspection agent.  It
would be ideal to include that in the mask calculation so introspection
cases don't vmexit for PGE changes.

Also, AMD has similar capabilities, and (as of today) has gained CR
monitoring.

> + *
> + * NB: shadow path has not been optimized because it requires
> + * unconditionally trapping more CR4 bits, at which point the
> + * performance benefit of doing this is quite dubious.
> + */
> +__vmwrite(CR4_GUEST_HOST_MASK, ~0UL);

It would be better to stash the calculated mask, rather than reading it
back in the vmexit handler.

~Andrew

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

Re: [Xen-devel] [PATCH v3 0/2] pvcalls-front improvements

[Juergen Gross]

On 14/02/18 19:26, Stefano Stabellini wrote:
> Hi all,
> 
> this small series introduces a per socket refcount to increase the
> efficiency on socket release operations, and makes releasing passive
> sockets safe.
> 
> Cheers,
> 
> Stefano
> 
> 
> Changes in v3:
> - remove pointless initializers
> - reorder pvcalls_enter_sock
> 
> Changes in v2:
> - add acked-by
> - fix check in pvcalls_enter_soc
> - fix code style
> - nicer checks in pvcalls_front_release
> 
> 
> Stefano Stabellini (2):
>   pvcalls-front: introduce a per sock_mapping refcount
>   pvcalls-front: wait for other operations to return when release passive 
> sockets

Both patches committed to xen/tip.git for-linus-4.16


Juergen

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

Re: [Xen-devel] PVH Dom0 ACPI tables

[Jan Beulich]

>>> On 15.02.18 at 17:59,  wrote:
> On Thu, Feb 15, 2018 at 03:05:03AM -0700, Jan Beulich wrote:
>> >>> On 14.02.18 at 11:30,  wrote:
>> > Tables related to devices in use by Xen (or not available to Dom0)
>> > 
>> > HPET, DMAR, IVRS, WAET, CSRT, BOOT, MADT,
>> 
>> Why WAET, CSRT, and BOOT? I can't find Xen using any of these.
> 
> WAET contains information about devices not available to Dom0 (RTC and
> ACPI PM timer).
> 
> CSRT is more of a grey area, it contains information about interrupt
> controllers and timers, and those devices are likely not available to
> Dom0.
> 
> BOOT contains an offset into the CMOS, which is not available to Dom0.

CMOS and RTC are usable by Dom0, aren't they?

Jan


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

Re: [Xen-devel] PVH Dom0 ACPI tables

[Roger Pau Monné]

On Thu, Feb 15, 2018 at 03:05:03AM -0700, Jan Beulich wrote:
> >>> On 14.02.18 at 11:30,  wrote:
> > Hello,
> > 
> > After the comments on the ACPI whitelisting patch for PVH Dom0 I've
> > decided to post the list of ACPI tables that I've used to create the
> > current whitelist, together with other tables that I've not yet added.
> > 
> > Allowed tables
> > 
> > DSDT*, FACP*, FACS*, PSDT*, SSDT*, SBST*, ASF, MCFG*, SLIC*, MSDM*,
> > UEFI, WDAT*, BGRT, FPDT*, S3PT*, IBFT.
> > 
> > * Already whitelisted.
> > 
> > Tables that might need mappings
> > 
> > BERT, MCHI, SPCR, SPMI, TCPA, WDDT, WDRT, PCCT, WPBT
> 
> You have BERT here, but none of ERST, EINJ, or HEST above.
> Albeit ERST and HEST are in use by Xen, so may need to go on
> the list further down instead.

Hm, right I've missed those. So ERST and HEST are in used by Xen and
should go below (or to a new category, since it's not a device but a
table itself that's being used by Xen).

EINJ doesn't look safe to pass through to Dom0, since Injection
actions contain Register Regions that could contain Dom0 GFNs.

> > Tables that could point to devices being used by Xen
> > 
> > DBG2, DBGP
> > 
> > Tables related to devices in use by Xen (or not available to Dom0)
> > 
> > HPET, DMAR, IVRS, WAET, CSRT, BOOT, MADT,
> 
> Why WAET, CSRT, and BOOT? I can't find Xen using any of these.

WAET contains information about devices not available to Dom0 (RTC and
ACPI PM timer).

CSRT is more of a grey area, it contains information about interrupt
controllers and timers, and those devices are likely not available to
Dom0.

BOOT contains an offset into the CMOS, which is not available to Dom0.

> 
> > System topology related
> > 
> > SLIT, SRAT, MPST, PMTT, RASF*
> > 
> > * Not sure allowing Dom0 to activate 'patrol scrub' is safe.
> > 
> > ARM only
> > 
> > IORT, GTDT, STAO
> 
> I didn't think STAO is ARM-specific.

Right, it also shouldn't be present when booting on bare metal.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH] x86/PV: avoid indirect call/thunk in I/O emulation

[Andrew Cooper]

On 15/02/18 16:03, Jan Beulich wrote:
> The stub is within reach from the .text section, so there's no point
> using an indirect call here. This has the added benefit of there no
> longer being two sufficiently different approaches, breaking one of
> which people may not even notice.
>
> Signed-off-by: Jan Beulich 

Wow - after all effort I've spent changing (and breaking) this, it
hadn't even occurred to me that a plain jmp was fine.

>
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -73,55 +73,42 @@ void (*pv_post_outb_hook)(unsigned int p
>  
>  typedef void io_emul_stub_t(struct cpu_user_regs *);
>  
> -void __x86_indirect_thunk_rcx(void);
> -
>  static io_emul_stub_t *io_emul_stub_setup(struct priv_op_ctxt *ctxt, u8 
> opcode,
>unsigned int port, unsigned int 
> bytes)
>  {
>  struct stubs *this_stubs = _cpu(stubs);
>  unsigned long stub_va = this_stubs->addr + STUB_BUF_SIZE / 2;
> +signed long disp;

I'm not in favour of sprinkling 'signed' all over the code base.

long is already unambiguous, and a far more common construct to encounter. 

>  bool use_quirk_stub = false;
>  
>  if ( !ctxt->io_emul_stub )
>  ctxt->io_emul_stub =
>  map_domain_page(_mfn(this_stubs->mfn)) + (stub_va & ~PAGE_MASK);
>  
> -/* movq $host_to_guest_gpr_switch,%rcx */
> -ctxt->io_emul_stub[0] = 0x48;
> -ctxt->io_emul_stub[1] = 0xb9;
> -*(void **)>io_emul_stub[2] = (void *)host_to_guest_gpr_switch;
> -
> -#ifdef CONFIG_INDIRECT_THUNK
> -/* callq __x86_indirect_thunk_rcx */
> -ctxt->io_emul_stub[10] = 0xe8;
> -*(int32_t *)>io_emul_stub[11] =
> -(long)__x86_indirect_thunk_rcx - (stub_va + 11 + 4);
> -#else
> -/* callq *%rcx */
> -ctxt->io_emul_stub[10] = 0xff;
> -ctxt->io_emul_stub[11] = 0xd1;
> -/* TODO: untangle ideal_nops from init/livepatch Kconfig options. */
> -memcpy(>io_emul_stub[12], "\x0f\x1f\x00", 3); /* P6_NOP3 */
> -#endif
> +/* call host_to_guest_gpr_switch */
> +ctxt->io_emul_stub[0] = 0xe8;
> +disp = (long)host_to_guest_gpr_switch - (stub_va + 1 + 4);

The 1 in the middle here only aids clarity in the context above, where
it was part of a direct assignment to offset 11 in io_emul_stub[].

It is marginal, but in this case, I think stub_va + 5 would be slightly
clearer, as call opcode is obviously at 0, and the length of a call
instruction is 5.

~Andrew

> +BUG_ON((int32_t)disp != disp);
> +*(int32_t *)>io_emul_stub[1] = disp;
>  
>  if ( unlikely(ioemul_handle_quirk) )
> -use_quirk_stub = ioemul_handle_quirk(opcode, >io_emul_stub[15],
> +use_quirk_stub = ioemul_handle_quirk(opcode, >io_emul_stub[5],
>   ctxt->ctxt.regs);
>  
>  if ( !use_quirk_stub )
>  {
>  /* data16 or nop */
> -ctxt->io_emul_stub[15] = (bytes != 2) ? 0x90 : 0x66;
> +ctxt->io_emul_stub[5] = (bytes != 2) ? 0x90 : 0x66;
>  /*  */
> -ctxt->io_emul_stub[16] = opcode;
> +ctxt->io_emul_stub[6] = opcode;
>  /* imm8 or nop */
> -ctxt->io_emul_stub[17] = !(opcode & 8) ? port : 0x90;
> +ctxt->io_emul_stub[7] = !(opcode & 8) ? port : 0x90;
>  /* ret (jumps to guest_to_host_gpr_switch) */
> -ctxt->io_emul_stub[18] = 0xc3;
> +ctxt->io_emul_stub[8] = 0xc3;
>  }
>  
> -BUILD_BUG_ON(STUB_BUF_SIZE / 2 < MAX(19, /* Default emul stub */
> - 15 + IOEMUL_QUIRK_STUB_BYTES));
> +BUILD_BUG_ON(STUB_BUF_SIZE / 2 < MAX(9, /* Default emul stub */
> + 5 + IOEMUL_QUIRK_STUB_BYTES));
>  
>  /* Handy function-typed pointer to the stub. */
>  return (void *)stub_va;
>
>
>


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

Re: [Xen-devel] [PATCH V4] x86/hvm: fix domain crash when CR3 has the noflush bit set

[Jan Beulich]

>>> On 09.02.18 at 12:01,  wrote:
> @@ -563,13 +563,19 @@ void svm_update_guest_cr(struct vcpu *v, unsigned int 
> cr)
>  case 3:
>  vmcb_set_cr3(vmcb, v->arch.hvm_vcpu.hw_cr[3]);
>  if ( !nestedhvm_enabled(v->domain) )
> -hvm_asid_flush_vcpu(v);
> +{
> +if ( !(flags & HVM_UPDATE_GUEST_CR3_NO_FLUSH) )
> +hvm_asid_flush_vcpu(v);
> +}
>  else if ( nestedhvm_vmswitch_in_progress(v) )
>  ; /* CR3 switches during VMRUN/VMEXIT do not flush the TLB. */
>  else
> -hvm_asid_flush_vcpu_asid(
> -nestedhvm_vcpu_in_guestmode(v)
> -? _nestedhvm(v).nv_n2asid : >arch.hvm_vcpu.n1asid);
> +{
> +if ( !(flags & HVM_UPDATE_GUEST_CR3_NO_FLUSH) )

Any reason you didn't make this an "else if()", reducing code churn?

> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -80,6 +80,9 @@ enum hvm_intblk {
>  #define HVM_EVENT_VECTOR_UNSET(-1)
>  #define HVM_EVENT_VECTOR_UPDATING (-2)
>  
> +/* update_guest_cr() flags. */
> +#define HVM_UPDATE_GUEST_CR3_NO_FLUSH 0x0001

I'd prefer if the naming was consistent with X86_CR3_NOFLUSH
(i.e. have or don't have an underscore between NO and FLUSH in
both cases).

> --- a/xen/include/asm-x86/x86-defns.h
> +++ b/xen/include/asm-x86/x86-defns.h
> @@ -43,6 +43,11 @@
>  #define X86_CR0_PG  0x8000 /* Paging   (RW) 
> */
>  
>  /*
> + * Intel CPU flags in CR3
> + */
> +#define X86_CR3_NOFLUSH0x8000

Please add the ULL suffix, so the insn emulator could eventually
use this without breaking the 32-bit test harness build.

Jan


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

[Xen-devel] [PATCH] vmx/hap: optimize CR4 trapping

[Roger Pau Monne]

There a bunch of bits in CR4 that should be allowed to be set directly
by the guest without requiring Xen intervention, currently this is
already done by passing through guest writes into the CR4 used when
running in non-root mode, but taking an expensive vmexit in order to
do so.

xenalyze reports the following when running a PV guest in shim mode:

 CR_ACCESS 3885950  6.41s 17.04%  3957 cyc { 2361| 3378| 7920}
   cr4  3885940  6.41s 17.04%  3957 cyc { 2361| 3378| 7920}
   cr31  0.00s  0.00%  3480 cyc { 3480| 3480| 3480}
 *[  0]1  0.00s  0.00%  3480 cyc { 3480| 3480| 3480}
   cr07  0.00s  0.00%  7112 cyc { 3248| 5960|17480}
   clts2  0.00s  0.00%  4588 cyc { 3456| 5720| 5720}

After this change this turns into:

 CR_ACCESS  12  0.00s  0.00%  9972 cyc { 3680|11024|24032}
   cr42  0.00s  0.00% 17528 cyc {11024|24032|24032}
   cr31  0.00s  0.00%  3680 cyc { 3680| 3680| 3680}
 *[  0]1  0.00s  0.00%  3680 cyc { 3680| 3680| 3680}
   cr07  0.00s  0.00%  9209 cyc { 4184| 7848|17488}
   clts2  0.00s  0.00%  8232 cyc { 5352|2|2}

Note that this optimized trapping is currently only applied to guests
running with HAP on Intel hardware. If using shadow paging more CR4
bits need to be unconditionally trapped, which makes this approach
unlikely to yield any important performance improvements.

Reported-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
---
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Razvan Cojocaru 
Cc: Tamas K Lengyel 
---
 xen/arch/x86/hvm/vmx/vmx.c  | 41 +
 xen/arch/x86/hvm/vmx/vvmx.c |  5 -
 xen/arch/x86/monitor.c  |  5 +++--
 3 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index d35cf55982..9747b2a398 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1684,6 +1684,35 @@ static void vmx_update_guest_cr(struct vcpu *v, unsigned 
int cr)
 }
 
 __vmwrite(GUEST_CR4, v->arch.hvm_vcpu.hw_cr[4]);
+
+if ( (v->domain->arch.monitor.write_ctrlreg_enabled &
+  monitor_ctrlreg_bitmask(VM_EVENT_X86_CR4)) ||
+ !paging_mode_hap(v->domain) )
+/*
+ * If requested by introspection or running in shadow mode trap all
+ * accesses to CR4.
+ *
+ * NB: shadow path has not been optimized because it requires
+ * unconditionally trapping more CR4 bits, at which point the
+ * performance benefit of doing this is quite dubious.
+ */
+__vmwrite(CR4_GUEST_HOST_MASK, ~0UL);
+else
+{
+uint64_t mask = HVM_CR4_HOST_MASK | X86_CR4_PKE |
+~hvm_cr4_guest_valid_bits(v, 0);
+
+/*
+ * Update CR4 host mask to only trap when the guest tries to set
+ * bits that are controlled by the hypervisor.
+ */
+mask |= v->arch.hvm_vmx.vmx_realmode ? X86_CR4_VME : 0;
+mask |= !hvm_paging_enabled(v) ? (X86_CR4_PSE | X86_CR4_SMEP |
+  X86_CR4_SMAP)
+   : 0;
+__vmwrite(CR4_GUEST_HOST_MASK, mask);
+}
+
 break;
 
 case 2:
@@ -3512,6 +3541,18 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 
 if ( paging_mode_hap(v->domain) )
 {
+uint64_t cr4, mask;
+
+/*
+ * Xen allows the guest to modify some CR4 bits directly, update cached
+ * values to match.
+ */
+__vmread(GUEST_CR4, );
+__vmread(CR4_GUEST_HOST_MASK, );
+v->arch.hvm_vcpu.hw_cr[4] = cr4;
+v->arch.hvm_vcpu.guest_cr[4] &= mask;
+v->arch.hvm_vcpu.guest_cr[4] |= cr4 & ~mask;
+
 __vmread(GUEST_CR3, >arch.hvm_vcpu.hw_cr[3]);
 if ( vmx_unrestricted_guest(v) || hvm_paging_enabled(v) )
 v->arch.hvm_vcpu.guest_cr[3] = v->arch.hvm_vcpu.hw_cr[3];
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index dfe97b9705..65f2629118 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1043,7 +1043,7 @@ static void load_shadow_guest_state(struct vcpu *v)
 {
 struct nestedvcpu *nvcpu = _nestedhvm(v);
 u32 control;
-u64 cr_gh_mask, cr_read_shadow;
+uint64_t cr_gh_mask, cr_mask, cr_read_shadow;
 int rc;
 
 static const u16 vmentry_fields[] = {
@@ -1100,6 +1100,9 @@ static void load_shadow_guest_state(struct vcpu *v)
 cr_read_shadow = (get_vvmcs(v, GUEST_CR4) & ~cr_gh_mask) |
  (get_vvmcs(v, CR4_READ_SHADOW) & cr_gh_mask);
 

[Xen-devel] [linux-arm-xen test] 119195: tolerable all pass - PUSHED

[osstest service owner]

flight 119195 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119195/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 116992
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 116992
 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-rtds 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass

version targeted for testing:
 linux50484ee133c2219a26fd98b39770187221b5e0bc
baseline version:
 linuxf829c1350f1b61684b919704970e84536971f62d

Last test of basis   116992  2017-12-08 15:36:32 Z   69 days
Testing same since   119195  2018-02-14 15:21:44 Z1 days1 attempts


6122 people touched revisions under test,
not listing them all

jobs:
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-arm64  pass
 build-armhf  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-arm64-pvopspass
 build-armhf-pvopspass
 test-arm64-arm64-xl  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-arm64-arm64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  pass
 test-armhf-armhf-xl-arndale  pass
 test-arm64-arm64-xl-credit2  pass
 test-armhf-armhf-xl-credit2  pass
 test-armhf-armhf-xl-cubietruck   pass
 test-arm64-arm64-examine 

[Xen-devel] [PATCH] x86/PV: avoid indirect call/thunk in I/O emulation

[Jan Beulich]

The stub is within reach from the .text section, so there's no point
using an indirect call here. This has the added benefit of there no
longer being two sufficiently different approaches, breaking one of
which people may not even notice.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -73,55 +73,42 @@ void (*pv_post_outb_hook)(unsigned int p
 
 typedef void io_emul_stub_t(struct cpu_user_regs *);
 
-void __x86_indirect_thunk_rcx(void);
-
 static io_emul_stub_t *io_emul_stub_setup(struct priv_op_ctxt *ctxt, u8 opcode,
   unsigned int port, unsigned int 
bytes)
 {
 struct stubs *this_stubs = _cpu(stubs);
 unsigned long stub_va = this_stubs->addr + STUB_BUF_SIZE / 2;
+signed long disp;
 bool use_quirk_stub = false;
 
 if ( !ctxt->io_emul_stub )
 ctxt->io_emul_stub =
 map_domain_page(_mfn(this_stubs->mfn)) + (stub_va & ~PAGE_MASK);
 
-/* movq $host_to_guest_gpr_switch,%rcx */
-ctxt->io_emul_stub[0] = 0x48;
-ctxt->io_emul_stub[1] = 0xb9;
-*(void **)>io_emul_stub[2] = (void *)host_to_guest_gpr_switch;
-
-#ifdef CONFIG_INDIRECT_THUNK
-/* callq __x86_indirect_thunk_rcx */
-ctxt->io_emul_stub[10] = 0xe8;
-*(int32_t *)>io_emul_stub[11] =
-(long)__x86_indirect_thunk_rcx - (stub_va + 11 + 4);
-#else
-/* callq *%rcx */
-ctxt->io_emul_stub[10] = 0xff;
-ctxt->io_emul_stub[11] = 0xd1;
-/* TODO: untangle ideal_nops from init/livepatch Kconfig options. */
-memcpy(>io_emul_stub[12], "\x0f\x1f\x00", 3); /* P6_NOP3 */
-#endif
+/* call host_to_guest_gpr_switch */
+ctxt->io_emul_stub[0] = 0xe8;
+disp = (long)host_to_guest_gpr_switch - (stub_va + 1 + 4);
+BUG_ON((int32_t)disp != disp);
+*(int32_t *)>io_emul_stub[1] = disp;
 
 if ( unlikely(ioemul_handle_quirk) )
-use_quirk_stub = ioemul_handle_quirk(opcode, >io_emul_stub[15],
+use_quirk_stub = ioemul_handle_quirk(opcode, >io_emul_stub[5],
  ctxt->ctxt.regs);
 
 if ( !use_quirk_stub )
 {
 /* data16 or nop */
-ctxt->io_emul_stub[15] = (bytes != 2) ? 0x90 : 0x66;
+ctxt->io_emul_stub[5] = (bytes != 2) ? 0x90 : 0x66;
 /*  */
-ctxt->io_emul_stub[16] = opcode;
+ctxt->io_emul_stub[6] = opcode;
 /* imm8 or nop */
-ctxt->io_emul_stub[17] = !(opcode & 8) ? port : 0x90;
+ctxt->io_emul_stub[7] = !(opcode & 8) ? port : 0x90;
 /* ret (jumps to guest_to_host_gpr_switch) */
-ctxt->io_emul_stub[18] = 0xc3;
+ctxt->io_emul_stub[8] = 0xc3;
 }
 
-BUILD_BUG_ON(STUB_BUF_SIZE / 2 < MAX(19, /* Default emul stub */
- 15 + IOEMUL_QUIRK_STUB_BYTES));
+BUILD_BUG_ON(STUB_BUF_SIZE / 2 < MAX(9, /* Default emul stub */
+ 5 + IOEMUL_QUIRK_STUB_BYTES));
 
 /* Handy function-typed pointer to the stub. */
 return (void *)stub_va;




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

Re: [Xen-devel] Slow HVM boot time, was "HVM boot time optimization"

[Yessine Daoud]

 Hello,

I tried to debug the issue and this what I found:
the HVM boot takes some time at the following section
(qemu/pc-bios/optionrom/linuxboot.S)
/* Load kernel and initrd */
read_fw_blob_addr32_edi(FW_CFG_INITRD) (ramdisk about 3M takes ~~7.s)
read_fw_blob_addr32(FW_CFG_KERNEL) (vmlinuz about 7M takes ~~15.s)
read_fw_blob_addr32(FW_CFG_CMDLINE)

#define read_fw_blob_addr32(var) \
read_fw var ## _ADDR; \
mov %eax, %edi; \
read_fw_blob_pre(var); \
/* old as(1) doesn't like this insn so emit the bytes instead: \
addr32 rep insb (%dx), %es:(%edi); \
*/ \
.dc.b 0x67,0xf3,0x6c

#define read_fw_blob_addr32_edi(var) \
read_fw_blob_pre(var); \
/* old as(1) doesn't like this insn so emit the bytes instead: \
addr32 rep insb (%dx), %es:(%edi); \
*/ \
.dc.b 0x67,0xf3,0x6c

Any idea how to speed the  I/O read ?
Thanks.


ᐧ

2018-02-12 15:42 GMT+01:00 Wei Liu :

> On Mon, Feb 12, 2018 at 09:27:25AM +0100, Yessine Daoud wrote:
> >  Hello,
> >
> > Thank you for your quick response.
> > Any hints how can I "fix" this "issue"? *Any workaround?
> >
>
> Honestly I have no idea why it is slow unless there is more logging
> available.
>
> Wei.
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC 0/4] Use INVPCID to flush global mappings

[Juergen Gross]

On 15/02/18 13:10, Wei Liu wrote:
> I wrote these patches sometime ago to explore PCID and INVPCID. I haven't
> thought through whether how to use both in Xen yet. But seeing Juergen laid 
> out
> his thought on PCID and INVPCID I think some of the patches can be useful.
> 
> I had done some benchmark on the speed in one of my older branch by inserting
> some trace points before and after the flush. It showed that twiddling CR4.PGE
> is 3 to 5 times slower than invpcid.
> 
> This series is in incomplete -- obviously we have CR4.PGE twiddling in a few
> other places. But if you think it is beneficial I can try to convert those
> places as well.

I just did a little experiment by replacing the %cr4 based TLB flush in
Jan's XPTI patches by invpcid, on top of my last XPTI speedup patch (no
fancy ALTERNATIVE, just a plain replacement).

Doing a parallel build of the hypervisor in dom0 showed following data:

real  user  sys
xpti=no 61.2 167.7 71.9
xpti=yes   112.1 170.1141.8
 + my speedup  103.0 171.2131.2
  + invpcid 99.0 170.2122.0

So system time reduction due to invpcid is quite nice.


Juergen

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

[Xen-devel] [PATCH v3] xen/arm: Park CPUs with a MIDR different from the boot CPU.

[Julien Grall]

Xen does not properly support big.LITTLE platform. All vCPUs of a guest
will always have the MIDR of the boot CPU (see arch_domain_create).
At best the guest may see unreliable performance (vCPU switching between
big and LITTLE), at worst the guest will become unreliable or insecure.

This is becoming more apparent with branch predictor hardening in Linux
because they target a specific kind of CPUs and may not work on other
CPUs.

For the time being, park any CPUs with a MDIR different from the boot
CPU. This will be revisited in the future once Xen gains understanding
of big.LITTLE.

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

Signed-off-by: Julien Grall 
Reviewed-by: Oleksandr Tyshchenkko 
Acked-by: Jan Beulich 

---

We probably want to backport this as part of XSA-254. Using big.LITTLE
on Xen has never been supported but we didn't make it clearly. This is
becoming more apparent with code targeting specific CPUs.

Oleksandr, FIY, I've kept your reviewed-by despite changing the command line
option.

Changes in v3:
- Rename hmp_unsafe to hmp-unsafe.
- Add Jan's acked-by
- Add Oleksandr's reviewed-by

Changes in v2:
- Add a command line option to override the default behavior.
---
 docs/misc/xen-command-line.markdown | 10 ++
 xen/arch/arm/smpboot.c  | 26 ++
 2 files changed, 36 insertions(+)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 79feba6bcd..7bd009f858 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1000,6 +1000,16 @@ supported only when compiled with XSM on x86.
 
 Control Xens use of the APEI Hardware Error Source Table, should one be found.
 
+### hmp-unsafe (arm)
+> `= `
+
+> Default : `false`
+
+Say yes at your own risk if you want to enable heterogenous computing
+(such as big.LITTLE). This may result to an unstable and insecure
+platform. When the option is disabled (default), CPUs that are not
+identical to the boot CPU will be parked and not used by Xen.
+
 ### hpetbroadcast
 > `= `
 
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 1255185a9c..7ea4e41866 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -69,6 +70,13 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_mask);
 /* representing HT and core siblings of each logical CPU */
 DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
 
+/*
+ * By default non-boot CPUs not identical to the boot CPU will be
+ * parked.
+ */
+static bool __read_mostly opt_hmp_unsafe = false;
+boolean_param("hmp-unsafe", opt_hmp_unsafe);
+
 static void setup_cpu_sibling_map(int cpu)
 {
 if ( !zalloc_cpumask_var(_cpu(cpu_sibling_mask, cpu)) ||
@@ -255,6 +263,9 @@ void __init smp_init_cpus(void)
 else
 acpi_smp_init_cpus();
 
+if ( opt_hmp_unsafe )
+warning_add("WARNING: HMP COMPUTING HAS BEEN ENABLED.\n"
+"It has implications on the security and stability of the 
system.\n");
 }
 
 int __init
@@ -292,6 +303,21 @@ void start_secondary(unsigned long boot_phys_offset,
 
 init_traps();
 
+/*
+ * Currently Xen assumes the platform has only one kind of CPUs.
+ * This assumption does not hold on big.LITTLE platform and may
+ * result to instability and insecure platform. Better to park them
+ * for now.
+ */
+if ( !opt_hmp_unsafe &&
+ current_cpu_data.midr.bits != boot_cpu_data.midr.bits )
+{
+printk(XENLOG_ERR "CPU%u MIDR (0x%x) does not match boot CPU MIDR 
(0x%x).\n",
+   smp_processor_id(), current_cpu_data.midr.bits,
+   boot_cpu_data.midr.bits);
+stop_cpu();
+}
+
 mmu_init_secondary_cpu();
 
 gic_init_secondary_cpu();
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v3 10/17] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Volodymyr Babchuk]

Julien,

On 15.02.18 17:02, Julien Grall wrote:

Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.

Signed-off-by: Julien Grall 

Reviewed-by: Volodymyr Babchuk 


---
 Changes in v3:
 - Add the missing call to smc #0.

 Changes in v2:
 - Patch added
---
  xen/arch/arm/arm64/bpi.S| 13 +
  xen/arch/arm/cpuerrata.c| 32 +++-
  xen/include/asm-arm/smccc.h |  1 +
  3 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
index 4b7f1dc21f..981fb83a88 100644
--- a/xen/arch/arm/arm64/bpi.S
+++ b/xen/arch/arm/arm64/bpi.S
@@ -16,6 +16,8 @@
   * along with this program.  If not, see .
   */
  
+#include 

+
  .macro ventry target
  .rept 31
  nop
@@ -81,6 +83,17 @@ ENTRY(__psci_hyp_bp_inval_start)
  add sp, sp, #(8 * 18)
  ENTRY(__psci_hyp_bp_inval_end)
  
+ENTRY(__smccc_workaround_1_smc_start)

+sub sp, sp, #(8 * 4)
+stp x2, x3, [sp, #(8 * 0)]
+stp x0, x1, [sp, #(8 * 2)]
+mov w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
+smc #0
+ldp x2, x3, [sp, #(8 * 0)]
+ldp x0, x1, [sp, #(8 * 2)]
+add sp, sp, #(8 * 4)
+ENTRY(__smccc_workaround_1_smc_end)
+
  /*
   * Local variables:
   * mode: ASM
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 8d5f8d372a..dec9074422 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -147,6 +147,34 @@ install_bp_hardening_vec(const struct arm_cpu_capabilities 
*entry,
  return ret;
  }
  
+extern char __smccc_workaround_1_smc_start[], __smccc_workaround_1_smc_end[];

+
+static bool
+check_smccc_arch_workaround_1(const struct arm_cpu_capabilities *entry)
+{
+struct arm_smccc_res res;
+
+/*
+ * Enable callbacks are called on every CPU based on the
+ * capabilities. So double-check whether the CPU matches the
+ * entry.
+ */
+if ( !entry->matches(entry) )
+return false;
+
+if ( smccc_ver < SMCCC_VERSION(1, 1) )
+return false;
+
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+  ARM_SMCCC_ARCH_WORKAROUND_1_FID, );
+if ( res.a0 != ARM_SMCCC_SUCCESS )
+return false;
+
+return install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
+__smccc_workaround_1_smc_end,
+"call ARM_SMCCC_ARCH_WORKAROUND_1");
+}
+
  extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
  
  static int enable_psci_bp_hardening(void *data)

@@ -154,12 +182,14 @@ static int enable_psci_bp_hardening(void *data)
  bool ret = true;
  static bool warned = false;
  
+if ( check_smccc_arch_workaround_1(data) )

+return 0;
  /*
   * The mitigation is using PSCI version function to invalidate the
   * branch predictor. This function is only available with PSCI 0.2
   * and later.
   */
-if ( psci_ver >= PSCI_VERSION(0, 2) )
+else if ( psci_ver >= PSCI_VERSION(0, 2) )
  ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
 __psci_hyp_bp_inval_end,
 "call PSCI get version");
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 154772b728..8342cc33fe 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -261,6 +261,7 @@ struct arm_smccc_res {
  /* SMCCC error codes */
  #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
  #define ARM_SMCCC_NOT_SUPPORTED (-1)
+#define ARM_SMCCC_SUCCESS   (0)
  
  /* SMCCC function identifier range which is reserved for existing APIs */

  #define ARM_SMCCC_RESERVED_RANGE_START  0x0



--
Volodymyr Babchuk

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

Re: [Xen-devel] [PATCH v3 02/17] xen/arm: vsmc: Implement SMCCC 1.1

[Volodymyr Babchuk]

Hi Julien,

On 15.02.18 17:02, Julien Grall wrote:

The new SMC Calling Convention (v1.1) allows for a reduced overhead when
calling into the firmware, and provides a new feature discovery
mechanism. See "Firmware interfaces for mitigating CVE-2017-5715"
ARM DEN 00070A.

Signed-off-by: Julien Grall 

Reviewed-by: Volodymyr Babchuk 



---
 Changes in v3:
 - Use ARM_SMCCC_NOT_SUPPORTED rather than hardcoded return

 Changes in v2:
 - Add a humand readable name for the specification
---
  xen/arch/arm/vpsci.c|  1 +
  xen/arch/arm/vsmc.c | 23 +++
  xen/include/asm-arm/smccc.h | 18 +-
  3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index e82b62db1a..19ee7caeb4 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -212,6 +212,7 @@ static int32_t do_psci_1_0_features(uint32_t psci_func_id)
  case PSCI_0_2_FN32_SYSTEM_OFF:
  case PSCI_0_2_FN32_SYSTEM_RESET:
  case PSCI_1_0_FN32_PSCI_FEATURES:
+case ARM_SMCCC_VERSION_FID:
  return 0;
  default:
  return PSCI_NOT_SUPPORTED;
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 3d3bd95fee..7ec492741b 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -81,6 +81,26 @@ static bool fill_function_call_count(struct cpu_user_regs 
*regs, uint32_t cnt)
  return true;
  }
  
+/* SMCCC interface for ARM Architecture */

+static bool handle_arch(struct cpu_user_regs *regs)
+{
+uint32_t fid = (uint32_t)get_user_reg(regs, 0);
+
+switch ( fid )
+{
+case ARM_SMCCC_VERSION_FID:
+set_user_reg(regs, 0, ARM_SMCCC_VERSION_1_1);
+return true;
+
+case ARM_SMCCC_ARCH_FEATURES_FID:
+/* Nothing supported yet */
+set_user_reg(regs, 0, ARM_SMCCC_NOT_SUPPORTED);
+return true;
+}
+
+return false;
+}
+
  /* SMCCC interface for hypervisor. Tell about itself. */
  static bool handle_hypervisor(struct cpu_user_regs *regs)
  {
@@ -188,6 +208,9 @@ static bool vsmccc_handle_call(struct cpu_user_regs *regs)
  {
  switch ( smccc_get_owner(funcid) )
  {
+case ARM_SMCCC_OWNER_ARCH:
+handled = handle_arch(regs);
+break;
  case ARM_SMCCC_OWNER_HYPERVISOR:
  handled = handle_hypervisor(regs);
  break;
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 62b3a8cdf5..629cc5150b 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -16,6 +16,9 @@
  #ifndef __ASM_ARM_SMCCC_H__
  #define __ASM_ARM_SMCCC_H__
  
+#define ARM_SMCCC_VERSION_1_0   0x1

+#define ARM_SMCCC_VERSION_1_1   0x10001
+
  /*
   * This file provides common defines for ARM SMC Calling Convention as
   * specified in
@@ -100,8 +103,21 @@ static inline uint32_t smccc_get_owner(register_t funcid)
 ARM_SMCCC_OWNER_##owner, \
 0xFF03)
  
-/* Only one error code defined in SMCCC */

+#define ARM_SMCCC_VERSION_FID   \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+   ARM_SMCCC_CONV_32,   \
+   ARM_SMCCC_OWNER_ARCH,\
+   0x0) \
+
+#define ARM_SMCCC_ARCH_FEATURES_FID \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+   ARM_SMCCC_CONV_32,   \
+   ARM_SMCCC_OWNER_ARCH,\
+   0x1)
+
+/* SMCCC error codes */
  #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
+#define ARM_SMCCC_NOT_SUPPORTED (-1)
  
  /* SMCCC function identifier range which is reserved for existing APIs */

  #define ARM_SMCCC_RESERVED_RANGE_START  0x0



--
Volodymyr Babchuk

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

Re: [Xen-devel] [PATCH v2] xen/arm: Park CPUs with a MIDR different from the boot CPU.

[Julien Grall]

Hi Jan,

On 15/02/18 09:03, Jan Beulich wrote:

On 14.02.18 at 15:17,  wrote:

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1000,6 +1000,16 @@ supported only when compiled with XSM on x86.
  
  Control Xens use of the APEI Hardware Error Source Table, should one be found.
  
+### hmp_unsafe (arm)


Could I talk you into using hmp-unsafe instead? As said elsewhere,
dashes (as being easier to type) should be preferred over underscores
(which make option strings needlessly resemble identifier names). 


I don't mind on the naming. I will update it.


Other
than that the doc addition is
Acked-by: Jan Beulich 
if that's needed in the first place.


I have CCed you because docs falls under "THE REST". Not sure what is 
the policy here thought. Anyway, thank you for the acked.


Cheers,



Jan



--
Julien Grall

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

[Xen-devel] [PATCH v3 09/17] xen/arm: smccc: Implement SMCCC v1.1 inline primitive

[Julien Grall]

One of the major improvement of SMCCC v1.1 is that it only clobbers the
first 4 registers, both on 32 and 64bit. This means that it becomes very
easy to provide an inline version of the SMC call primitive, and avoid
performing a function call to stash the registers that woudl otherwise
be clobbered by SMCCC v1.0.

This patch has been adapted to Xen from Linux commit f2d3b2e8759a. The
changes mades are:
- Using Xen coding style
- Remove HVC as not used by Xen
- Add arm_smccc_res structure

 Reviewed-by: Robin Murphy 
 Tested-by: Ard Biesheuvel 
 Signed-off-by: Marc Zyngier 
 Signed-off-by: Catalin Marinas 

Signed-off-by: Julien Grall 

---

Note that the patch is in arm64/for-next/core and should be merged
in master soon.

Changes in v2:
- Patch added
---
 xen/include/asm-arm/smccc.h | 119 
 1 file changed, 119 insertions(+)

diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index bc067892c7..154772b728 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -78,6 +78,125 @@ static inline uint32_t smccc_get_owner(register_t funcid)
 return (funcid >> ARM_SMCCC_OWNER_SHIFT) & ARM_SMCCC_OWNER_MASK;
 }
 
+/*
+ * struct arm_smccc_res - Result from SMC call
+ * @a0 - @a3 result values from registers 0 to 3
+ */
+struct arm_smccc_res {
+unsigned long a0;
+unsigned long a1;
+unsigned long a2;
+unsigned long a3;
+};
+
+/* SMCCC v1.1 implementation madness follows */
+#define ___count_args(_0, _1, _2, _3, _4, _5, _6, _7, _8, x, ...) x
+
+#define __count_args(...)   \
+___count_args(__VA_ARGS__, 7, 6, 5, 4, 3, 2, 1, 0)
+
+#define __constraint_write_0\
+"+r" (r0), "=" (r1), "=" (r2), "=" (r3)
+#define __constraint_write_1\
+"+r" (r0), "+r" (r1), "=" (r2), "=" (r3)
+#define __constraint_write_2\
+"+r" (r0), "+r" (r1), "+r" (r2), "=" (r3)
+#define __constraint_write_3\
+"+r" (r0), "+r" (r1), "+r" (r2), "+r" (r3)
+#define __constraint_write_4__constraint_write_3
+#define __constraint_write_5__constraint_write_4
+#define __constraint_write_6__constraint_write_5
+#define __constraint_write_7__constraint_write_6
+
+#define __constraint_read_0
+#define __constraint_read_1
+#define __constraint_read_2
+#define __constraint_read_3
+#define __constraint_read_4 "r" (r4)
+#define __constraint_read_5 __constraint_read_4, "r" (r5)
+#define __constraint_read_6 __constraint_read_5, "r" (r6)
+#define __constraint_read_7 __constraint_read_6, "r" (r7)
+
+#define __declare_arg_0(a0, res)\
+struct arm_smccc_res*___res = res;  \
+register uin32_tr0 asm("r0") = a0;  \
+register unsigned long  r1 asm("r1");   \
+register unsigned long  r2 asm("r2");   \
+register unsigned long  r3 asm("r3")
+
+#define __declare_arg_1(a0, a1, res)\
+struct arm_smccc_res*___res = res;  \
+register uint32_t   r0 asm("r0") = a0;  \
+register typeof(a1) r1 asm("r1") = a1;  \
+register unsigned long  r2 asm("r2");   \
+register unsigned long  r3 asm("r3")
+
+#define __declare_arg_2(a0, a1, a2, res)\
+struct arm_smccc_res*___res = res; \
+register u32r0 asm("r0") = a0;  \
+register typeof(a1) r1 asm("r1") = a1;  \
+register typeof(a2) r2 asm("r2") = a2;  \
+register unsigned long  r3 asm("r3")
+
+#define __declare_arg_3(a0, a1, a2, a3, res)\
+struct arm_smccc_res*___res = res;  \
+register u32r0 asm("r0") = a0;  \
+register typeof(a1) r1 asm("r1") = a1;  \
+register typeof(a2) r2 asm("r2") = a2;  \
+register typeof(a3) r3 asm("r3") = a3
+
+#define __declare_arg_4(a0, a1, a2, a3, a4, res)\
+__declare_arg_3(a0, a1, a2, a3, res);   \
+register typeof(a4) r4 asm("r4") = a4
+
+#define __declare_arg_5(a0, a1, a2, a3, a4, a5, res)\
+__declare_arg_4(a0, a1, a2, a3, a4, res);   \
+register typeof(a5) r5 asm("r5") = a5
+
+#define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res)\
+__declare_arg_5(a0, a1, a2, a3, a4, a5, res);   \
+register typeof(a6) r6 asm("r6") = a6
+
+#define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res)\
+__declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res);   \
+register typeof(a7) r7 asm("r7") = a7
+
+#define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__)
+#define __declare_args(count, ...)  ___declare_args(count, __VA_ARGS__)
+
+#define 

[Xen-devel] [PATCH v3 13/17] xen/arm: psci: Consolidate PSCI version print

[Julien Grall]

Xen is printing the same way the PSCI version for 0.1, 0.2 and later.
The only different is the former is hardcoded.

Furthermore PSCI is now used for other things than SMP bring up. So only
print the PSCI version in psci_init.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

---
Changes in v3:
- Add Volodymyr's reviewed-by

Changes in v2:
- Patch added
---
 xen/arch/arm/psci.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index bc7b2260e8..7a8cf54e6d 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -136,8 +136,6 @@ int __init psci_init_0_1(void)
 
 psci_ver = PSCI_VERSION(0, 1);
 
-printk(XENLOG_INFO "Using PSCI-0.1 for SMP bringup\n");
-
 return 0;
 }
 
@@ -183,9 +181,6 @@ int __init psci_init_0_2(void)
 
 psci_cpu_on_nr = PSCI_0_2_FN_NATIVE(CPU_ON);
 
-printk(XENLOG_INFO "Using PSCI-%u.%u for SMP bringup\n",
-   PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver));
-
 return 0;
 }
 
@@ -205,6 +200,9 @@ int __init psci_init(void)
 
 psci_init_smccc();
 
+printk(XENLOG_INFO "Using PSCI v%u.%u\n",
+   PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver));
+
 return 0;
 }
 
-- 
2.11.0


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

[Xen-devel] [PATCH v3 03/17] xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Julien Grall]

SMCCC 1.1 offers firmware-based CPU workarounds. In particular,
SMCCC_ARCH_WORKAROUND_1 provides BP hardening for variant 2 of XSA-254
(CVE-2017-5715).

If the hypervisor has some mitigation for this issue, report that we
deal with it using SMCCC_ARCH_WORKAROUND_1, as we apply the hypervisor
workaround on every guest exit.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

---
Changes in v3:
- Fix minor conflict during rebase

Changes in v2:
- Add Volodymyr's reviewed-by
---
 xen/arch/arm/vsmc.c | 22 --
 xen/include/asm-arm/smccc.h |  6 ++
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 7ec492741b..40a80d5760 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -93,8 +94,25 @@ static bool handle_arch(struct cpu_user_regs *regs)
 return true;
 
 case ARM_SMCCC_ARCH_FEATURES_FID:
-/* Nothing supported yet */
-set_user_reg(regs, 0, ARM_SMCCC_NOT_SUPPORTED);
+{
+uint32_t arch_func_id = get_user_reg(regs, 1);
+int ret = ARM_SMCCC_NOT_SUPPORTED;
+
+switch ( arch_func_id )
+{
+case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
+if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
+ret = 0;
+break;
+}
+
+set_user_reg(regs, 0, ret);
+
+return true;
+}
+
+case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
+/* No return value */
 return true;
 }
 
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 629cc5150b..2951caa49d 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -115,6 +115,12 @@ static inline uint32_t smccc_get_owner(register_t funcid)
ARM_SMCCC_OWNER_ARCH,\
0x1)
 
+#define ARM_SMCCC_ARCH_WORKAROUND_1_FID \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+  ARM_SMCCC_CONV_32,\
+  ARM_SMCCC_OWNER_ARCH, \
+  0x8000)
+
 /* SMCCC error codes */
 #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
 #define ARM_SMCCC_NOT_SUPPORTED (-1)
-- 
2.11.0


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

[Xen-devel] [PATCH v3 05/17] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1

[Julien Grall]

The function SMCCC_ARCH_WORKAROUND_1 will be called by the guest for
hardening the branch predictor. So we want the handling to be as fast as
possible.

As the mitigation is applied on every guest exit, we can check for the
call before saving all the context and return very early.

For now, only provide a fast path for HVC64 call. Because the code rely
on 2 registers, x0 and x1 are saved in advance.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

---
guest_sync only handle 64-bit guest, so I have only implemented the
64-bit side for now. We can discuss whether it is useful to
implement it for 32-bit guests.

We could also consider to implement the fast path for SMC64,
althought a guest should always use HVC.

Changes in v2:
- Add Volodymyr's reviewed-by
---
 xen/arch/arm/arm64/entry.S  | 56 +++--
 xen/include/asm-arm/processor.h |  2 ++
 2 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
index 6d99e46f0f..67f96d518f 100644
--- a/xen/arch/arm/arm64/entry.S
+++ b/xen/arch/arm/arm64/entry.S
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -90,8 +91,12 @@ lr  .reqx30 /* link register */
 .endm
 /*
  * Save state on entry to hypervisor, restore on exit
+ *
+ * save_x0_x1: Does the macro needs to save x0/x1 (default 1). If 0,
+ * we rely on the on x0/x1 to have been saved at the correct position on
+ * the stack before.
  */
-.macro  entry, hyp, compat
+.macro  entry, hyp, compat, save_x0_x1=1
 sub sp, sp, #(UREGS_SPSR_el1 - UREGS_LR) /* CPSR, PC, SP, LR */
 pushx28, x29
 pushx26, x27
@@ -107,7 +112,16 @@ lr  .reqx30 /* link register */
 pushx6, x7
 pushx4, x5
 pushx2, x3
+/*
+ * The caller may already have saved x0/x1 on the stack at the
+ * correct address and corrupt them with another value. Only
+ * save them if save_x0_x1 == 1.
+ */
+.if \save_x0_x1 == 1
 pushx0, x1
+.else
+sub sp, sp, #16
+.endif
 
 .if \hyp == 1/* Hypervisor mode */
 
@@ -200,7 +214,45 @@ hyp_irq:
 exithyp=1
 
 guest_sync:
-entry   hyp=0, compat=0
+/*
+ * Save x0, x1 in advance
+ */
+stp x0, x1, [sp, #-(UREGS_kernel_sizeof - UREGS_X0)]
+
+/*
+ * x1 is used because x0 may contain the function identifier.
+ * This avoids to restore x0 from the stack.
+ */
+mrs x1, esr_el2
+lsr x1, x1, #HSR_EC_SHIFT   /* x1 = ESR_EL2.EC */
+cmp x1, #HSR_EC_HVC64
+b.ne1f  /* Not a HVC skip fastpath. */
+
+mrs x1, esr_el2
+and x1, x1, #0x /* Check the immediate [0:16] 
*/
+cbnzx1, 1f  /* should be 0 for HVC #0 */
+
+/*
+ * Fastest path possible for ARM_SMCCC_ARCH_WORKAROUND_1.
+ * The workaround has already been applied on the exception
+ * entry from the guest, so let's quickly get back to the guest.
+ */
+eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
+cbnzw0, 1f
+
+/*
+ * Clobber both x0 and x1 to prevent leakage. Note that thanks
+ * the eor, x0 = 0.
+ */
+mov x1, x0
+eret
+
+1:
+/*
+ * x0/x1 may have been scratch by the fast path above, so avoid
+ * to save them.
+ */
+entry   hyp=0, compat=0, save_x0_x1=0
 /*
  * The vSError will be checked while SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT
  * is not set. If a vSError took place, the initial exception will be
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index c0f79d0093..222a02dd99 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -306,6 +306,8 @@
 #define HDCR_TPM(_AC(1,U)<<6)   /* Trap Performance Monitors 
accesses */
 #define HDCR_TPMCR  (_AC(1,U)<<5)   /* Trap PMCR accesses */
 
+#define HSR_EC_SHIFT26
+
 #define HSR_EC_UNKNOWN  0x00
 #define HSR_EC_WFI_WFE  0x01
 #define HSR_EC_CP15_32  0x03
-- 
2.11.0


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

[Xen-devel] [PATCH v3 17/17] xen/arm: vpsci: Rework the logic to start AArch32 vCPU in Thumb mode

[Julien Grall]

32-bit domain is able to select the instruction (ARM vs Thumb) to use
when boot a new vCPU via CPU_ON. This is indicated via bit[0] of the
entry point address (see "T32 support" in PSCI v1.1 DEN0022D). bit[0]
must be cleared when setting the PC.

At the moment, Xen is setting the CPSR.T but never clear bit[0]. Clear
it to match the specification.

At the same time, slighlty rework the code to make clear thumb is only for
32-bit domain. Lastly, take the opportunity to switch is_thumb from int
to bool.

Signed-off-by: Julien Grall 

---
Changes in v3:
- Patch added
---
 xen/arch/arm/vpsci.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 1729f7071e..9f4e5b8844 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -28,7 +28,7 @@ static int do_common_cpu_on(register_t target_cpu, register_t 
entry_point,
 struct domain *d = current->domain;
 struct vcpu_guest_context *ctxt;
 int rc;
-int is_thumb = entry_point & 1;
+bool is_thumb = entry_point & 1;
 register_t vcpuid;
 
 vcpuid = vaffinity_to_vcpuid(target_cpu);
@@ -62,6 +62,13 @@ static int do_common_cpu_on(register_t target_cpu, 
register_t entry_point,
 if ( is_32bit_domain(d) )
 {
 ctxt->user_regs.cpsr = PSR_GUEST32_INIT;
+/* Start the VCPU with THUMB set if it's requested by the kernel */
+if ( is_thumb )
+{
+ctxt->user_regs.cpsr |= PSR_THUMB;
+ctxt->user_regs.pc64 &= ~(u64)1;
+}
+
 ctxt->user_regs.r0_usr = context_id;
 }
 #ifdef CONFIG_ARM_64
@@ -71,10 +78,6 @@ static int do_common_cpu_on(register_t target_cpu, 
register_t entry_point,
 ctxt->user_regs.x0 = context_id;
 }
 #endif
-
-/* Start the VCPU with THUMB set if it's requested by the kernel */
-if ( is_thumb )
-ctxt->user_regs.cpsr |= PSR_THUMB;
 ctxt->flags = VGCF_online;
 
 domain_lock(d);
-- 
2.11.0


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

[Xen-devel] [PATCH v3 06/17] xen/arm64: Print a per-CPU message with the BP hardening method used

[Julien Grall]

This will make easier to know whether BP hardening has been enabled for
a CPU and which method is used.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babcuk 

---
Changes in v3:
- Add Volodymyr's reviewed-by

Changes in v2:
- Patch added
---
 xen/arch/arm/cpuerrata.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index c243521ed4..8d5f8d372a 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -79,7 +79,8 @@ static bool copy_hyp_vect_bpi(unsigned int slot, const char 
*hyp_vec_start,
 static bool __maybe_unused
 install_bp_hardening_vec(const struct arm_cpu_capabilities *entry,
  const char *hyp_vec_start,
- const char *hyp_vec_end)
+ const char *hyp_vec_end,
+ const char *desc)
 {
 static int last_slot = -1;
 static DEFINE_SPINLOCK(bp_lock);
@@ -94,6 +95,9 @@ install_bp_hardening_vec(const struct arm_cpu_capabilities 
*entry,
 if ( !entry->matches(entry) )
 return true;
 
+printk(XENLOG_INFO "CPU%u will %s on exception entry\n",
+   smp_processor_id(), desc);
+
 /*
  * No need to install hardened vector when the processor has
  * ID_AA64PRF0_EL1.CSV2 set.
@@ -157,7 +161,8 @@ static int enable_psci_bp_hardening(void *data)
  */
 if ( psci_ver >= PSCI_VERSION(0, 2) )
 ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
-   __psci_hyp_bp_inval_end);
+   __psci_hyp_bp_inval_end,
+   "call PSCI get version");
 else if ( !warned )
 {
 ASSERT(system_state < SYS_STATE_active);
-- 
2.11.0


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

[Xen-devel] [PATCH v3 12/17] xen/arm: vpsci: Remove parameter 'ver' from do_common_cpu

[Julien Grall]

Currently, the behavior of do_common_cpu will slightly change depending
on the PSCI version passed in parameter. Looking at the code, more the
specific 0.2 behavior could move out of the function or adapted for 0.1:

- x0/r0 can be updated on PSCI 0.1 because general purpose registers
are undefined upon CPU on.
- PSCI 0.1 does not defined PSCI_ALREADY_ON. However, it would be
safer to bail out if the CPU is already on.

Based on this, the parameter 'ver' is removed and do_psci_cpu_on
(implementation for PSCI 0.1) is adapted to avoid returning
PSCI_ALREADY_ON.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

---
The reviewed-by was kept despite move this patch towards the end
of the series because there was no clash with the rest of the series.

Changes in v2:
- Move the patch towards the end of the series as not strictly
necessary for SP2.
- Add Volodymyr's reviewed-by
---
 xen/arch/arm/vpsci.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 19ee7caeb4..7ea3ea58e3 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -22,7 +22,7 @@
 #include 
 
 static int do_common_cpu_on(register_t target_cpu, register_t entry_point,
-   register_t context_id,int ver)
+register_t context_id)
 {
 struct vcpu *v;
 struct domain *d = current->domain;
@@ -40,8 +40,7 @@ static int do_common_cpu_on(register_t target_cpu, register_t 
entry_point,
 if ( is_64bit_domain(d) && is_thumb )
 return PSCI_INVALID_PARAMETERS;
 
-if ( (ver == PSCI_VERSION(0, 2)) &&
-!test_bit(_VPF_down, >pause_flags) )
+if ( !test_bit(_VPF_down, >pause_flags) )
 return PSCI_ALREADY_ON;
 
 if ( (ctxt = alloc_vcpu_guest_context()) == NULL )
@@ -55,18 +54,21 @@ static int do_common_cpu_on(register_t target_cpu, 
register_t entry_point,
 ctxt->ttbr0 = 0;
 ctxt->ttbr1 = 0;
 ctxt->ttbcr = 0; /* Defined Reset Value */
+
+/*
+ * x0/r0_usr are always updated because for PSCI 0.1 the general
+ * purpose registers are undefined upon CPU_on.
+ */
 if ( is_32bit_domain(d) )
 {
 ctxt->user_regs.cpsr = PSR_GUEST32_INIT;
-if ( ver == PSCI_VERSION(0, 2) )
-ctxt->user_regs.r0_usr = context_id;
+ctxt->user_regs.r0_usr = context_id;
 }
 #ifdef CONFIG_ARM_64
 else
 {
 ctxt->user_regs.cpsr = PSR_GUEST64_INIT;
-if ( ver == PSCI_VERSION(0, 2) )
-ctxt->user_regs.x0 = context_id;
+ctxt->user_regs.x0 = context_id;
 }
 #endif
 
@@ -93,7 +95,14 @@ static int do_common_cpu_on(register_t target_cpu, 
register_t entry_point,
 
 static int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
 {
-return do_common_cpu_on(vcpuid, entry_point, 0 , PSCI_VERSION(0, 1));
+int32_t ret;
+
+ret = do_common_cpu_on(vcpuid, entry_point, 0);
+/*
+ * PSCI 0.1 does not define the return code PSCI_ALREADY_ON.
+ * Instead, return PSCI_INVALID_PARAMETERS.
+ */
+return (ret == PSCI_ALREADY_ON) ? PSCI_INVALID_PARAMETERS : ret;
 }
 
 static int32_t do_psci_cpu_off(uint32_t power_state)
@@ -137,8 +146,7 @@ static int32_t do_psci_0_2_cpu_on(register_t target_cpu,
   register_t entry_point,
   register_t context_id)
 {
-return do_common_cpu_on(target_cpu, entry_point, context_id,
-PSCI_VERSION(0, 2));
+return do_common_cpu_on(target_cpu, entry_point, context_id);
 }
 
 static const unsigned long target_affinity_mask[] = {
-- 
2.11.0


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

[Xen-devel] [PATCH v3 11/17] xen/arm64: Kill PSCI_GET_VERSION as a variant-2 workaround

[Julien Grall]

Now that we've standardised on SMCCC v1.1 to perform the branch
prediction invalidation, let's drop the previous band-aid. If vendors
haven't updated their firmware to do SMCCC 1.1, they haven't updated
PSCI either, so we don't loose anything.

This is aligned with the Linux commit 3a0a397ff5ff.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

---
Note that the patch is in arm64/for-next/core and should be merged
in master soon.

Changes in v3:
- Add Volodymyr's reviewed-by

Changes in v2:
- Patch added
---
 xen/arch/arm/arm64/bpi.S | 25 --
 xen/arch/arm/cpuerrata.c | 54 +---
 2 files changed, 19 insertions(+), 60 deletions(-)

diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
index 981fb83a88..27ff801ed3 100644
--- a/xen/arch/arm/arm64/bpi.S
+++ b/xen/arch/arm/arm64/bpi.S
@@ -58,31 +58,6 @@ ENTRY(__bp_harden_hyp_vecs_start)
 .endr
 ENTRY(__bp_harden_hyp_vecs_end)
 
-ENTRY(__psci_hyp_bp_inval_start)
-sub sp, sp, #(8 * 18)
-stp x16, x17, [sp, #(16 * 0)]
-stp x14, x15, [sp, #(16 * 1)]
-stp x12, x13, [sp, #(16 * 2)]
-stp x10, x11, [sp, #(16 * 3)]
-stp x8, x9, [sp, #(16 * 4)]
-stp x6, x7, [sp, #(16 * 5)]
-stp x4, x5, [sp, #(16 * 6)]
-stp x2, x3, [sp, #(16 * 7)]
-stp x0, x1, [sp, #(16 * 8)]
-mov x0, #0x8400
-smc #0
-ldp x16, x17, [sp, #(16 * 0)]
-ldp x14, x15, [sp, #(16 * 1)]
-ldp x12, x13, [sp, #(16 * 2)]
-ldp x10, x11, [sp, #(16 * 3)]
-ldp x8, x9, [sp, #(16 * 4)]
-ldp x6, x7, [sp, #(16 * 5)]
-ldp x4, x5, [sp, #(16 * 6)]
-ldp x2, x3, [sp, #(16 * 7)]
-ldp x0, x1, [sp, #(16 * 8)]
-add sp, sp, #(8 * 18)
-ENTRY(__psci_hyp_bp_inval_end)
-
 ENTRY(__smccc_workaround_1_smc_start)
 sub sp, sp, #(8 * 4)
 stp x2, x3, [sp, #(8 * 0)]
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index dec9074422..4eb1567589 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -149,10 +149,11 @@ install_bp_hardening_vec(const struct 
arm_cpu_capabilities *entry,
 
 extern char __smccc_workaround_1_smc_start[], __smccc_workaround_1_smc_end[];
 
-static bool
-check_smccc_arch_workaround_1(const struct arm_cpu_capabilities *entry)
+static int enable_smccc_arch_workaround_1(void *data)
 {
 struct arm_smccc_res res;
+static bool warned = false;
+const struct arm_cpu_capabilities *entry = data;
 
 /*
  * Enable callbacks are called on every CPU based on the
@@ -160,47 +161,30 @@ check_smccc_arch_workaround_1(const struct 
arm_cpu_capabilities *entry)
  * entry.
  */
 if ( !entry->matches(entry) )
-return false;
+return 0;
 
 if ( smccc_ver < SMCCC_VERSION(1, 1) )
-return false;
+goto warn;
 
 arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
   ARM_SMCCC_ARCH_WORKAROUND_1_FID, );
 if ( res.a0 != ARM_SMCCC_SUCCESS )
-return false;
-
-return install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
-__smccc_workaround_1_smc_end,
-"call ARM_SMCCC_ARCH_WORKAROUND_1");
-}
+goto warn;
 
-extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
+return !install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
+ __smccc_workaround_1_smc_end,
+ "call ARM_SMCCC_ARCH_WORKAROUND_1");
 
-static int enable_psci_bp_hardening(void *data)
-{
-bool ret = true;
-static bool warned = false;
-
-if ( check_smccc_arch_workaround_1(data) )
-return 0;
-/*
- * The mitigation is using PSCI version function to invalidate the
- * branch predictor. This function is only available with PSCI 0.2
- * and later.
- */
-else if ( psci_ver >= PSCI_VERSION(0, 2) )
-ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
-   __psci_hyp_bp_inval_end,
-   "call PSCI get version");
-else if ( !warned )
+warn:
+if ( !warned )
 {
 ASSERT(system_state < SYS_STATE_active);
-warning_add("PSCI 0.2 or later is required for the branch predictor 
hardening.\n");
-warned = true;
+warning_add("No support for ARM_SMCCC_ARCH_WORKAROUND_1.\n"
+"Please update your firmware.\n");
+warned = false;
 }
 
-return !ret;
+return 0;
 }
 
 #endif /* CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR */
@@ -316,22 +300,22 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 {
 .capability = ARM_HARDEN_BRANCH_PREDICTOR,
 MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
-.enable = enable_psci_bp_hardening,
+  

[Xen-devel] [PATCH v3 10/17] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Julien Grall]

Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.

Signed-off-by: Julien Grall 

---
Changes in v3:
- Add the missing call to smc #0.

Changes in v2:
- Patch added
---
 xen/arch/arm/arm64/bpi.S| 13 +
 xen/arch/arm/cpuerrata.c| 32 +++-
 xen/include/asm-arm/smccc.h |  1 +
 3 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
index 4b7f1dc21f..981fb83a88 100644
--- a/xen/arch/arm/arm64/bpi.S
+++ b/xen/arch/arm/arm64/bpi.S
@@ -16,6 +16,8 @@
  * along with this program.  If not, see .
  */
 
+#include 
+
 .macro ventry target
 .rept 31
 nop
@@ -81,6 +83,17 @@ ENTRY(__psci_hyp_bp_inval_start)
 add sp, sp, #(8 * 18)
 ENTRY(__psci_hyp_bp_inval_end)
 
+ENTRY(__smccc_workaround_1_smc_start)
+sub sp, sp, #(8 * 4)
+stp x2, x3, [sp, #(8 * 0)]
+stp x0, x1, [sp, #(8 * 2)]
+mov w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
+smc #0
+ldp x2, x3, [sp, #(8 * 0)]
+ldp x0, x1, [sp, #(8 * 2)]
+add sp, sp, #(8 * 4)
+ENTRY(__smccc_workaround_1_smc_end)
+
 /*
  * Local variables:
  * mode: ASM
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 8d5f8d372a..dec9074422 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -147,6 +147,34 @@ install_bp_hardening_vec(const struct arm_cpu_capabilities 
*entry,
 return ret;
 }
 
+extern char __smccc_workaround_1_smc_start[], __smccc_workaround_1_smc_end[];
+
+static bool
+check_smccc_arch_workaround_1(const struct arm_cpu_capabilities *entry)
+{
+struct arm_smccc_res res;
+
+/*
+ * Enable callbacks are called on every CPU based on the
+ * capabilities. So double-check whether the CPU matches the
+ * entry.
+ */
+if ( !entry->matches(entry) )
+return false;
+
+if ( smccc_ver < SMCCC_VERSION(1, 1) )
+return false;
+
+arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
+  ARM_SMCCC_ARCH_WORKAROUND_1_FID, );
+if ( res.a0 != ARM_SMCCC_SUCCESS )
+return false;
+
+return install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
+__smccc_workaround_1_smc_end,
+"call ARM_SMCCC_ARCH_WORKAROUND_1");
+}
+
 extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
 
 static int enable_psci_bp_hardening(void *data)
@@ -154,12 +182,14 @@ static int enable_psci_bp_hardening(void *data)
 bool ret = true;
 static bool warned = false;
 
+if ( check_smccc_arch_workaround_1(data) )
+return 0;
 /*
  * The mitigation is using PSCI version function to invalidate the
  * branch predictor. This function is only available with PSCI 0.2
  * and later.
  */
-if ( psci_ver >= PSCI_VERSION(0, 2) )
+else if ( psci_ver >= PSCI_VERSION(0, 2) )
 ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
__psci_hyp_bp_inval_end,
"call PSCI get version");
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 154772b728..8342cc33fe 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -261,6 +261,7 @@ struct arm_smccc_res {
 /* SMCCC error codes */
 #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
 #define ARM_SMCCC_NOT_SUPPORTED (-1)
+#define ARM_SMCCC_SUCCESS   (0)
 
 /* SMCCC function identifier range which is reserved for existing APIs */
 #define ARM_SMCCC_RESERVED_RANGE_START  0x0
-- 
2.11.0


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

[Xen-devel] [PATCH v3 14/17] xen/arm: psci: Prefix with static any functions not exported

[Julien Grall]

A bunch of PSCI functions are not prefixed with static despite no one is
using them outside the file and the prototype is not available in
psci.h.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

---

Changes in v2:
- Patch added
---
 xen/arch/arm/psci.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 7a8cf54e6d..5d94a9a9ae 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -66,7 +66,7 @@ static int __init psci_features(uint32_t psci_func_id)
 return call_smc(PSCI_1_0_FN32_PSCI_FEATURES, psci_func_id, 0, 0);
 }
 
-int __init psci_is_smc_method(const struct dt_device_node *psci)
+static int __init psci_is_smc_method(const struct dt_device_node *psci)
 {
 int ret;
 const char *prop_str;
@@ -109,7 +109,7 @@ static void __init psci_init_smccc(void)
SMCCC_VERSION_MAJOR(smccc_ver), SMCCC_VERSION_MINOR(smccc_ver));
 }
 
-int __init psci_init_0_1(void)
+static int __init psci_init_0_1(void)
 {
 int ret;
 const struct dt_device_node *psci;
@@ -139,7 +139,7 @@ int __init psci_init_0_1(void)
 return 0;
 }
 
-int __init psci_init_0_2(void)
+static int __init psci_init_0_2(void)
 {
 static const struct dt_device_match psci_ids[] __initconst =
 {
-- 
2.11.0


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

[Xen-devel] [PATCH v3 04/17] xen/arm: Adapt smccc.h to be able to use it in assembly code

[Julien Grall]

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

---
Changes in v2:
- Add Volodymyr's reviewed-by
---
 xen/include/asm-arm/smccc.h | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 2951caa49d..30208d12ca 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -25,18 +25,20 @@
  * http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
  */
 
-#define ARM_SMCCC_STD_CALL  0U
-#define ARM_SMCCC_FAST_CALL 1U
+#define ARM_SMCCC_STD_CALL  _AC(0,U)
+#define ARM_SMCCC_FAST_CALL _AC(1,U)
 #define ARM_SMCCC_TYPE_SHIFT31
 
-#define ARM_SMCCC_CONV_32   0U
-#define ARM_SMCCC_CONV_64   1U
+#define ARM_SMCCC_CONV_32   _AC(0,U)
+#define ARM_SMCCC_CONV_64   _AC(1,U)
 #define ARM_SMCCC_CONV_SHIFT30
 
-#define ARM_SMCCC_OWNER_MASK0x3FU
+#define ARM_SMCCC_OWNER_MASK_AC(0x3F,U)
 #define ARM_SMCCC_OWNER_SHIFT   24
 
-#define ARM_SMCCC_FUNC_MASK 0xU
+#define ARM_SMCCC_FUNC_MASK _AC(0x,U)
+
+#ifndef __ASSEMBLY__
 
 /* Check if this is fast call. */
 static inline bool smccc_is_fast_call(register_t funcid)
@@ -62,6 +64,8 @@ static inline uint32_t smccc_get_owner(register_t funcid)
 return (funcid >> ARM_SMCCC_OWNER_SHIFT) & ARM_SMCCC_OWNER_MASK;
 }
 
+#endif
+
 /*
  * Construct function identifier from call type (fast or standard),
  * calling convention (32 or 64 bit), service owner and function number.
-- 
2.11.0


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

[Xen-devel] [PATCH v3 02/17] xen/arm: vsmc: Implement SMCCC 1.1

[Julien Grall]

The new SMC Calling Convention (v1.1) allows for a reduced overhead when
calling into the firmware, and provides a new feature discovery
mechanism. See "Firmware interfaces for mitigating CVE-2017-5715"
ARM DEN 00070A.

Signed-off-by: Julien Grall 

---
Changes in v3:
- Use ARM_SMCCC_NOT_SUPPORTED rather than hardcoded return

Changes in v2:
- Add a humand readable name for the specification
---
 xen/arch/arm/vpsci.c|  1 +
 xen/arch/arm/vsmc.c | 23 +++
 xen/include/asm-arm/smccc.h | 18 +-
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index e82b62db1a..19ee7caeb4 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -212,6 +212,7 @@ static int32_t do_psci_1_0_features(uint32_t psci_func_id)
 case PSCI_0_2_FN32_SYSTEM_OFF:
 case PSCI_0_2_FN32_SYSTEM_RESET:
 case PSCI_1_0_FN32_PSCI_FEATURES:
+case ARM_SMCCC_VERSION_FID:
 return 0;
 default:
 return PSCI_NOT_SUPPORTED;
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 3d3bd95fee..7ec492741b 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -81,6 +81,26 @@ static bool fill_function_call_count(struct cpu_user_regs 
*regs, uint32_t cnt)
 return true;
 }
 
+/* SMCCC interface for ARM Architecture */
+static bool handle_arch(struct cpu_user_regs *regs)
+{
+uint32_t fid = (uint32_t)get_user_reg(regs, 0);
+
+switch ( fid )
+{
+case ARM_SMCCC_VERSION_FID:
+set_user_reg(regs, 0, ARM_SMCCC_VERSION_1_1);
+return true;
+
+case ARM_SMCCC_ARCH_FEATURES_FID:
+/* Nothing supported yet */
+set_user_reg(regs, 0, ARM_SMCCC_NOT_SUPPORTED);
+return true;
+}
+
+return false;
+}
+
 /* SMCCC interface for hypervisor. Tell about itself. */
 static bool handle_hypervisor(struct cpu_user_regs *regs)
 {
@@ -188,6 +208,9 @@ static bool vsmccc_handle_call(struct cpu_user_regs *regs)
 {
 switch ( smccc_get_owner(funcid) )
 {
+case ARM_SMCCC_OWNER_ARCH:
+handled = handle_arch(regs);
+break;
 case ARM_SMCCC_OWNER_HYPERVISOR:
 handled = handle_hypervisor(regs);
 break;
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 62b3a8cdf5..629cc5150b 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -16,6 +16,9 @@
 #ifndef __ASM_ARM_SMCCC_H__
 #define __ASM_ARM_SMCCC_H__
 
+#define ARM_SMCCC_VERSION_1_0   0x1
+#define ARM_SMCCC_VERSION_1_1   0x10001
+
 /*
  * This file provides common defines for ARM SMC Calling Convention as
  * specified in
@@ -100,8 +103,21 @@ static inline uint32_t smccc_get_owner(register_t funcid)
ARM_SMCCC_OWNER_##owner, \
0xFF03)
 
-/* Only one error code defined in SMCCC */
+#define ARM_SMCCC_VERSION_FID   \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+   ARM_SMCCC_CONV_32,   \
+   ARM_SMCCC_OWNER_ARCH,\
+   0x0) \
+
+#define ARM_SMCCC_ARCH_FEATURES_FID \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+   ARM_SMCCC_CONV_32,   \
+   ARM_SMCCC_OWNER_ARCH,\
+   0x1)
+
+/* SMCCC error codes */
 #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
+#define ARM_SMCCC_NOT_SUPPORTED (-1)
 
 /* SMCCC function identifier range which is reserved for existing APIs */
 #define ARM_SMCCC_RESERVED_RANGE_START  0x0
-- 
2.11.0


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

[Xen-devel] [PATCH v3 16/17] xen/arm: vpsci: Introduce and use PSCI_INVALID_ADDRESS

[Julien Grall]

PSCI 1.0 added the error return PSCI_INVALID_ADDRESS. It is used to
indicate the entry point address is known to be invalid.

In Xen case, this error could be returned when a 64-bit vCPU is using a
Thumb entry address.

For PSCI 0.1 implementation, return PSCI_INVALID_PARAMETERS instead.

Suggested-by: mirela.simono...@aggios.com
Signed-off-by: Julien Grall 
Cc: mirela.simono...@aggios.com

---
Changes in v3:
- Patch added
---
 xen/arch/arm/vpsci.c   | 10 +++---
 xen/include/asm-arm/psci.h |  1 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 9a082aa6ee..1729f7071e 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -38,7 +38,7 @@ static int do_common_cpu_on(register_t target_cpu, register_t 
entry_point,
 
 /* THUMB set is not allowed with 64-bit domain */
 if ( is_64bit_domain(d) && is_thumb )
-return PSCI_INVALID_PARAMETERS;
+return PSCI_INVALID_ADDRESS;
 
 if ( !test_bit(_VPF_down, >pause_flags) )
 return PSCI_ALREADY_ON;
@@ -99,10 +99,14 @@ static int32_t do_psci_cpu_on(uint32_t vcpuid, register_t 
entry_point)
 
 ret = do_common_cpu_on(vcpuid, entry_point, 0);
 /*
- * PSCI 0.1 does not define the return code PSCI_ALREADY_ON.
+ * PSCI 0.1 does not define the return codes PSCI_ALREADY_ON and
+ * PSCI_INVALID_ADDRESS.
  * Instead, return PSCI_INVALID_PARAMETERS.
  */
-return (ret == PSCI_ALREADY_ON) ? PSCI_INVALID_PARAMETERS : ret;
+if ( ret == PSCI_ALREADY_ON || ret == PSCI_INVALID_ADDRESS )
+ret = PSCI_INVALID_PARAMETERS;
+
+return ret;
 }
 
 static int32_t do_psci_cpu_off(uint32_t power_state)
diff --git a/xen/include/asm-arm/psci.h b/xen/include/asm-arm/psci.h
index e2629eed01..9ac820e94a 100644
--- a/xen/include/asm-arm/psci.h
+++ b/xen/include/asm-arm/psci.h
@@ -13,6 +13,7 @@
 #define PSCI_INTERNAL_FAILURE   -6
 #define PSCI_NOT_PRESENT-7
 #define PSCI_DISABLED   -8
+#define PSCI_INVALID_ADDRESS-9
 
 /* availability of PSCI on the host for SMP bringup */
 extern uint32_t psci_ver;
-- 
2.11.0


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

[Xen-devel] [PATCH v3 08/17] xen/arm: psci: Detect SMCCC version

[Julien Grall]

PSCI 1.0 and later allows the SMCCC version to be (indirectly) probed
via PSCI_FEATURES. If the PSCI_FEATURES does not exist (PSCI 0.2 or
earlier) and the function return an error, then we considered SMCCC 1.0
is implemented.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Patch added
---
 xen/arch/arm/psci.c | 34 +-
 xen/include/asm-arm/smccc.h |  2 ++
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 5dda35cd7c..bc7b2260e8 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -37,6 +37,7 @@
 #endif
 
 uint32_t psci_ver;
+uint32_t smccc_ver;
 
 static uint32_t psci_cpu_on_nr;
 
@@ -57,6 +58,14 @@ void call_psci_system_reset(void)
 call_smc(PSCI_0_2_FN32_SYSTEM_RESET, 0, 0, 0);
 }
 
+static int __init psci_features(uint32_t psci_func_id)
+{
+if ( psci_ver < PSCI_VERSION(1, 0) )
+return PSCI_NOT_SUPPORTED;
+
+return call_smc(PSCI_1_0_FN32_PSCI_FEATURES, psci_func_id, 0, 0);
+}
+
 int __init psci_is_smc_method(const struct dt_device_node *psci)
 {
 int ret;
@@ -82,6 +91,24 @@ int __init psci_is_smc_method(const struct dt_device_node 
*psci)
 return 0;
 }
 
+static void __init psci_init_smccc(void)
+{
+/* PSCI is using at least SMCC 1.0 calling convention. */
+smccc_ver = ARM_SMCCC_VERSION_1_0;
+
+if ( psci_features(ARM_SMCCC_VERSION_FID) != PSCI_NOT_SUPPORTED )
+{
+uint32_t ret;
+
+ret = call_smc(ARM_SMCCC_VERSION_FID, 0, 0, 0);
+if ( ret != ARM_SMCCC_NOT_SUPPORTED )
+smccc_ver = ret;
+}
+
+printk(XENLOG_INFO "Using SMC Calling Convention v%u.%u\n",
+   SMCCC_VERSION_MAJOR(smccc_ver), SMCCC_VERSION_MINOR(smccc_ver));
+}
+
 int __init psci_init_0_1(void)
 {
 int ret;
@@ -173,7 +200,12 @@ int __init psci_init(void)
 if ( ret )
 ret = psci_init_0_1();
 
-return ret;
+if ( ret )
+return ret;
+
+psci_init_smccc();
+
+return 0;
 }
 
 /*
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index d0240d64bf..bc067892c7 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -52,6 +52,8 @@
 
 #ifndef __ASSEMBLY__
 
+extern uint32_t smccc_ver;
+
 /* Check if this is fast call. */
 static inline bool smccc_is_fast_call(register_t funcid)
 {
-- 
2.11.0


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

[Xen-devel] [PATCH v3 15/17] xen/arm: vpsci: Update the return type for MIGRATE_INFO_TYPE

[Julien Grall]

From the specification, the PSCI call MIGRATE_INFO_TYPE will return an
int32_t. Update the function return type to match it.

Signed-off-by: Julien Grall 
Cc: mirela.simono...@aggios.com

---
Changes in v3:
- Patch added
---
 xen/arch/arm/vpsci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 7ea3ea58e3..9a082aa6ee 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -186,7 +186,7 @@ static int32_t do_psci_0_2_affinity_info(register_t 
target_affinity,
 return PSCI_0_2_AFFINITY_LEVEL_OFF;
 }
 
-static uint32_t do_psci_0_2_migrate_info_type(void)
+static int32_t do_psci_0_2_migrate_info_type(void)
 {
 return PSCI_0_2_TOS_MP_OR_NOT_PRESENT;
 }
-- 
2.11.0


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  422588e88511d17984544c0f017a927de3315290
baseline version:
 xen  27196d4cc917d91b5b5daee50173565139ca9c9d

Last test of basis   119208  2018-02-14 19:01:09 Z0 days
Testing same since   119270  2018-02-15 12:01:24 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   27196d4cc9..422588e885  422588e88511d17984544c0f017a927de3315290 -> smoke

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

[Xen-devel] [xen-4.6-testing test] 119227: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-2 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 119187 pass 
in 119227
 test-amd64-i386-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail in 119187 
pass in 119227
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail in 119187 pass in 
119227
 test-xtf-amd64-amd64-4   49 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 119187
 test-xtf-amd64-amd64-5   49 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 119187

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 119187 blocked 
in 118166
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 119187 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 119187 never pass
 test-armhf-armhf-xl-rtds 12 guest-start  fail  like 118166
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118166
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118166
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118166
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118166
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118166
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118166
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118166
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 118166
 test-xtf-amd64-amd64-4   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-3   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-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-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  75bdd693033e6dbd6fe5ae235f79961d2f0aa84d
baseline version:
 xen  44ad7f6895da9861042d7a41e635d42d83cb2660

Last test of basis   118166  2018-01-17 16:49:59 Z   28 days
Testing same since   119187  2018-02-14 13:11:25 Z0 days2 attempts

Re: [Xen-devel] [PATCH v4 0/4] hvm/svm: Enable vm events for SVM

[Andrew Cooper]

On 15/02/18 13:05, Razvan Cojocaru wrote:
> On 02/15/2018 02:36 PM, Andrew Cooper wrote:
>> One thing I note however is that patch 2 and 3 both turn on intercepts
>> and have no way of turning them back off.  This appears to be consistent
>> with the Intel side of things, but it is suboptimal for the guest when
>> an introspection agent detaches.
> That's very true (I've also pointed this out to Bitweasil when we've
> discussed the CR3 intercept crash after the noflush bit started to get
> used).
>
> I've also considered this when I've added the MSR write subscription
> code, however it didn't feel safe to just disable those exits when the
> introspection agent unplugs.

The problem is that we don't have a source of information to derive the
intercepts from, which is also what is causing chaos trying to get
nested virt working.

We only have what is programmed into the hardware structures, which
suffers from "multiple-producers" syndrome.

> For one, we'd have to store the previous state somewhere (we might be
> interested in a MSR, for example, for which exits were already enabled
> before we subscribed to it - we shouldn't disable exits for it then).
>
> And even if we did keep the previous state somewhere (with the assorted
> problems - where do we allocate space for it? etc.) - it's theoretically
> possible that some other Xen subsystem fiddles with the exits in the
> meantime, so the state we remember may not be the current state of
> affairs wrt exits.
>
> Am I overthinking this?

No - I don't think so.

The only way to solve this problem is to have all the information for
each agent (including Xen itself) interested in controlling the
behaviour of the guest to be available, hooked off struct domain/vcpu as
appropriate, and one single function to combine everyones view of the
world into the hardware configuration.

If you can't unambiguously recalculate the contents of the VMCS/VMCB,
then something is broken.

>
>> For the CPUID/MSR policy side of things, Jan has talked me in to
>> changing how cpuid_policy_updated() works, and implementing it as a
>> recalculation of the intercepts on the return-to-guest path.  It occurs
>> to me that this usefully extends to changes requested by the
>> introspection agent.
> Thanks, we'll look that up.

It doesn't exist yet :)

~Andrew

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

Re: [Xen-devel] [PATCH 30/30] xen: use the BYTE-based definitions

[Alan Robinson]

Hi Philippe,

On Thu, Feb 15, 2018 at 09:23:52AM -0300, Philippe Mathieu-Daudé wrote:
> 
> Can I add your R-b tag once fixed? Respin will be:
> 
> +xenstore_write_int(dom, "memory/target", ram_size / K_BYTE);
> +xenstore_write_int(vm, "memory", ram_size / M_BYTE);
> +xenstore_write_int(vm, "maxmem", ram_size / M_BYTE);
> 
Yes - Alan


smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC 3/4] x86: add invpcid.h

[Jan Beulich]

>>> On 15.02.18 at 13:35,  wrote:
> On Thu, Feb 15, 2018 at 05:34:26AM -0700, Jan Beulich wrote:
>> >>> On 15.02.18 at 13:10,  wrote:
>> > Provide the functions needed for different modes.
>> 
>> Do we really need all of these? Let's not have dead code sit around
>> and risk it becoming stale.
>> 
> 
> They will be needed when we want to use PCID and INVPCID at the same
> time, which seems to be the plan?

I know of INVPCID plans only, not any PCID ones.

Jan


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

Re: [Xen-devel] [PATCH v4 0/4] hvm/svm: Enable vm events for SVM

[Boris Ostrovsky]

On 02/15/2018 05:22 AM, Alexandru Isaila wrote:
> Hi all,
>
> This series provides a skeleton for enabling vm_events on SVM. For the
> first step, the MSR, CR, Breakpoint and GuestRequest have been tested
> and added to the capabilities list.
>



Reviewed-by: Boris Ostrovsky 

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

Re: [Xen-devel] [PATCH v4 0/4] hvm/svm: Enable vm events for SVM

[Razvan Cojocaru]

On 02/15/2018 02:36 PM, Andrew Cooper wrote:
> One thing I note however is that patch 2 and 3 both turn on intercepts
> and have no way of turning them back off.  This appears to be consistent
> with the Intel side of things, but it is suboptimal for the guest when
> an introspection agent detaches.

That's very true (I've also pointed this out to Bitweasil when we've
discussed the CR3 intercept crash after the noflush bit started to get
used).

I've also considered this when I've added the MSR write subscription
code, however it didn't feel safe to just disable those exits when the
introspection agent unplugs.

For one, we'd have to store the previous state somewhere (we might be
interested in a MSR, for example, for which exits were already enabled
before we subscribed to it - we shouldn't disable exits for it then).

And even if we did keep the previous state somewhere (with the assorted
problems - where do we allocate space for it? etc.) - it's theoretically
possible that some other Xen subsystem fiddles with the exits in the
meantime, so the state we remember may not be the current state of
affairs wrt exits.

Am I overthinking this?

> For the CPUID/MSR policy side of things, Jan has talked me in to
> changing how cpuid_policy_updated() works, and implementing it as a
> recalculation of the intercepts on the return-to-guest path.  It occurs
> to me that this usefully extends to changes requested by the
> introspection agent.

Thanks, we'll look that up.


Thanks,
Razvan

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

[Xen-devel] [PATCH] x86/xpti: avoid copying L4 page table contents when possible

[Juergen Gross]

For mitigation of Meltdown the current L4 page table is copied to the
cpu local root page table each time a 64 bit pv guest is entered.

Copying can be avoided in cases where the guest L4 page table hasn't
been modified while running the hypervisor, e.g. when handling
interrupts or any hypercall not modifying the L4 page table or %cr3.

So add a per-cpu flag whether the copying should be performed and set
that flag only when loading a new %cr3 or modifying the L4 page table.
This includes synchronization of the cpu local root page table with
other cpus, so add a special synchronization flag for that case.

A simple performance check (compiling the hypervisor via "make -j 4")
in dom0 with 4 vcpus shows a significant improvement:

- real time drops from 112 seconds to 103 seconds
- system time drops from 142 seconds to 131 seconds

Signed-off-by: Juergen Gross 
---
To be applied on top of Jan's "Meltdown band-aid overhead reduction"
series
---
 xen/arch/x86/mm.c | 32 +++-
 xen/arch/x86/pv/domain.c  |  1 +
 xen/arch/x86/smp.c|  2 ++
 xen/arch/x86/x86_64/asm-offsets.c |  1 +
 xen/arch/x86/x86_64/entry.S   |  8 ++--
 xen/include/asm-x86/current.h |  8 
 xen/include/asm-x86/flushtlb.h|  2 ++
 7 files changed, 39 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 4c9340ca30..5340a49f00 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -510,6 +510,8 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
 void write_ptbase(struct vcpu *v)
 {
 write_cr3(v->arch.cr3);
+/* Setting copy_l4 unconditionally does no harm. */
+get_cpu_info()->copy_l4 = true;
 }
 
 /*
@@ -3704,18 +3706,22 @@ long do_mmu_update(
 break;
 rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
   cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
-/*
- * No need to sync if all uses of the page can be accounted
- * to the page lock we hold, its pinned status, and uses on
- * this (v)CPU.
- */
-if ( !rc && !cpu_has_no_xpti &&
- ((page->u.inuse.type_info & PGT_count_mask) >
-  (1 + !!(page->u.inuse.type_info & PGT_pinned) +
-   (pagetable_get_pfn(curr->arch.guest_table) == mfn) +
-   (pagetable_get_pfn(curr->arch.guest_table_user) ==
-mfn))) )
-sync_guest = true;
+if ( !rc && !cpu_has_no_xpti )
+{
+get_cpu_info()->copy_l4 = true;
+/*
+ * No need to sync if all uses of the page can be
+ * accounted to the page lock we hold, its pinned
+ * status, and uses on this (v)CPU.
+ */
+if ( (page->u.inuse.type_info & PGT_count_mask) >
+ (1 + !!(page->u.inuse.type_info & PGT_pinned) +
+  (pagetable_get_pfn(curr->arch.guest_table) ==
+   mfn) +
+  (pagetable_get_pfn(curr->arch.guest_table_user) 
==
+   mfn)) )
+sync_guest = true;
+}
 break;
 
 case PGT_writable_page:
@@ -3830,7 +3836,7 @@ long do_mmu_update(
 
 cpumask_andnot(mask, pt_owner->dirty_cpumask, cpumask_of(cpu));
 if ( !cpumask_empty(mask) )
-flush_mask(mask, FLUSH_TLB_GLOBAL);
+flush_mask(mask, FLUSH_TLB_GLOBAL | XPTI_L4_UPDATE);
 }
 
 perfc_add(num_page_updates, i);
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 868a23fd7e..4e6d29e76f 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -238,6 +238,7 @@ static void _toggle_guest_pt(struct vcpu *v, bool force_cr3)
 
 /* Don't flush user global mappings from the TLB. Don't tick TLB clock. */
 asm volatile ( "mov %0, %%cr3" : : "r" (v->arch.cr3) : "memory" );
+get_cpu_info()->copy_l4 = true;
 
 if ( !(v->arch.flags & TF_kernel_mode) )
 return;
diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c
index 033dd05958..6e3c8904fb 100644
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -207,6 +207,8 @@ void invalidate_interrupt(struct cpu_user_regs *regs)
 unsigned int flags = flush_flags;
 ack_APIC_irq();
 perfc_incr(ipis);
+if ( flags & XPTI_L4_UPDATE )
+get_cpu_info()->copy_l4 = true;
 if ( (flags & FLUSH_VCPU_STATE) && __sync_local_execstate() )
 flags &= ~(FLUSH_TLB | FLUSH_TLB_GLOBAL);
 if ( flags & ~(FLUSH_VCPU_STATE | FLUSH_ORDER_MASK) )
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 

Re: [Xen-devel] [PATCH v4 0/4] hvm/svm: Enable vm events for SVM

[Andrew Cooper]

On 15/02/18 10:22, Alexandru Isaila wrote:
> Hi all,
>
> This series provides a skeleton for enabling vm_events on SVM. For the
> first step, the MSR, CR, Breakpoint and GuestRequest have been tested
> and added to the capabilities list.

Ok - this series is looking much clearer now.  Thanks.

Acked-by: Andrew Cooper  (although there is
one trivial style issue in patch 1 I can fix on commit).

You are still waiting for SVM acks on patches 1 and 3 by the looks of
things.

One thing I note however is that patch 2 and 3 both turn on intercepts
and have no way of turning them back off.  This appears to be consistent
with the Intel side of things, but it is suboptimal for the guest when
an introspection agent detaches.

For the CPUID/MSR policy side of things, Jan has talked me in to
changing how cpuid_policy_updated() works, and implementing it as a
recalculation of the intercepts on the return-to-guest path.  It occurs
to me that this usefully extends to changes requested by the
introspection agent.

~Andrew

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

Re: [Xen-devel] [PATCH RFC 3/4] x86: add invpcid.h

[Wei Liu]

On Thu, Feb 15, 2018 at 05:34:26AM -0700, Jan Beulich wrote:
> >>> On 15.02.18 at 13:10,  wrote:
> > Provide the functions needed for different modes.
> 
> Do we really need all of these? Let's not have dead code sit around
> and risk it becoming stale.
> 

They will be needed when we want to use PCID and INVPCID at the same
time, which seems to be the plan?

Wei.

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

Re: [Xen-devel] [PATCH RFC 3/4] x86: add invpcid.h

[Jan Beulich]

>>> On 15.02.18 at 13:10,  wrote:
> Provide the functions needed for different modes.

Do we really need all of these? Let's not have dead code sit around
and risk it becoming stale.

Jan


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

Re: [Xen-devel] [PATCH RFC 1/4] x86: introduce cpu_has_invpcid

[Jan Beulich]

>>> On 15.02.18 at 13:10,  wrote:
> --- a/xen/include/asm-x86/cpufeature.h
> +++ b/xen/include/asm-x86/cpufeature.h
> @@ -93,6 +93,7 @@
>  #define cpu_has_avx2boot_cpu_has(X86_FEATURE_AVX2)
>  #define cpu_has_smepboot_cpu_has(X86_FEATURE_SMEP)
>  #define cpu_has_bmi2boot_cpu_has(X86_FEATURE_BMI2)
> +#define cpu_has_invpcid boot_cpu_has(X86_FEATURE_INVPCID)
>  #define cpu_has_rtm boot_cpu_has(X86_FEATURE_RTM)
>  #define cpu_has_fpu_sel (!boot_cpu_has(X86_FEATURE_NO_FPU_SEL))
>  #define cpu_has_mpx boot_cpu_has(X86_FEATURE_MPX)

Please fold into whatever patch is first using the new macro.

Jan


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

Re: [Xen-devel] [PATCH RFC 3/4] x86: add invpcid.h

[Andrew Cooper]

On 15/02/18 12:24, Wei Liu wrote:
> On Thu, Feb 15, 2018 at 12:15:56PM +, Andrew Cooper wrote:
>> On 15/02/18 12:10, Wei Liu wrote:
>>> Provide the functions needed for different modes.
>>>
>>> Signed-off-by: Wei Liu 
>>> ---
>>>  xen/include/asm-x86/invpcid.h | 61 
>>> +++
>>>  1 file changed, 61 insertions(+)
>>>  create mode 100644 xen/include/asm-x86/invpcid.h
>>>
>>> diff --git a/xen/include/asm-x86/invpcid.h b/xen/include/asm-x86/invpcid.h
>>> new file mode 100644
>>> index 00..7c307ecfc3
>>> --- /dev/null
>>> +++ b/xen/include/asm-x86/invpcid.h
>>> @@ -0,0 +1,61 @@
>>> +#ifndef _ASM_X86_INVPCID_H_
>>> +#define _ASM_X86_INVPCID_H_
>>> +
>>> +#include 
>>> +
>>> +#define INVPCID_TYPE_INDIV_ADDR  0
>>> +#define INVPCID_TYPE_SINGLE_CTXT 1
>>> +#define INVPCID_TYPE_ALL_INCL_GLOBAL 2
>>> +#define INVPCID_TYPE_ALL_NON_GLOBAL  3
>>> +
>>> +struct invpcid_desc {
>>> +uint64_t pcid:12;
>>> +uint64_t reserved:52;
>>> +uint64_t addr;
>>> +};
>>> +
>>> +static inline void invpcid(unsigned long pcid, unsigned long addr,
>>> +   unsigned long type)
>>> +{
>>> +struct invpcid_desc desc = { .pcid = pcid, .addr = addr };
>>> +
>>> +asm volatile ("invpcid (%0), %1"
>>> +  : : "r" (), "r" (type) : "memory" );
>> invpcid %[desc], %[type]
>>
>> And you can use [desc] "m" (desc) for the constraint.  The structure
>> will be built on the stack, meaning that an %rsp based memory reference
>> is more efficient than forcing the use of a register.
> NP.
>
>> We probably also need a -DHAVE_GAS_INVPCID, as INVPCID is newer than
>> some of the instruction groups we already check for.
>>
> Or we can just use the byte code directly -- it is the same for both 64
> and 32 bit, then manually specify the ModRM byte. That's what Linux
> does.

See the vmx __invept() wrapper, which is very similar, but doesn't need
the BUG() handling.

~Andrew

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

Re: [Xen-devel] [PATCH RFC 3/4] x86: add invpcid.h

[Wei Liu]

On Thu, Feb 15, 2018 at 12:15:56PM +, Andrew Cooper wrote:
> On 15/02/18 12:10, Wei Liu wrote:
> > Provide the functions needed for different modes.
> >
> > Signed-off-by: Wei Liu 
> > ---
> >  xen/include/asm-x86/invpcid.h | 61 
> > +++
> >  1 file changed, 61 insertions(+)
> >  create mode 100644 xen/include/asm-x86/invpcid.h
> >
> > diff --git a/xen/include/asm-x86/invpcid.h b/xen/include/asm-x86/invpcid.h
> > new file mode 100644
> > index 00..7c307ecfc3
> > --- /dev/null
> > +++ b/xen/include/asm-x86/invpcid.h
> > @@ -0,0 +1,61 @@
> > +#ifndef _ASM_X86_INVPCID_H_
> > +#define _ASM_X86_INVPCID_H_
> > +
> > +#include 
> > +
> > +#define INVPCID_TYPE_INDIV_ADDR  0
> > +#define INVPCID_TYPE_SINGLE_CTXT 1
> > +#define INVPCID_TYPE_ALL_INCL_GLOBAL 2
> > +#define INVPCID_TYPE_ALL_NON_GLOBAL  3
> > +
> > +struct invpcid_desc {
> > +uint64_t pcid:12;
> > +uint64_t reserved:52;
> > +uint64_t addr;
> > +};
> > +
> > +static inline void invpcid(unsigned long pcid, unsigned long addr,
> > +   unsigned long type)
> > +{
> > +struct invpcid_desc desc = { .pcid = pcid, .addr = addr };
> > +
> > +asm volatile ("invpcid (%0), %1"
> > +  : : "r" (), "r" (type) : "memory" );
> 
> invpcid %[desc], %[type]
> 
> And you can use [desc] "m" (desc) for the constraint.  The structure
> will be built on the stack, meaning that an %rsp based memory reference
> is more efficient than forcing the use of a register.

NP.

> 
> We probably also need a -DHAVE_GAS_INVPCID, as INVPCID is newer than
> some of the instruction groups we already check for.
> 

Or we can just use the byte code directly -- it is the same for both 64
and 32 bit, then manually specify the ModRM byte. That's what Linux
does.

Wei.

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

Re: [Xen-devel] [PATCH 30/30] xen: use the BYTE-based definitions

[Philippe Mathieu-Daudé]

On 02/15/2018 08:00 AM, Alan Robinson wrote:
> Hi Philippe,
> 
> On Thu, Feb 15, 2018 at 01:29:00AM -0300, Philippe Mathieu-Daudé wrote:
>> From: Philippe Mathieu-Daudé 
>> Subject: [Xen-devel] [PATCH 30/30] xen: use the BYTE-based definitions
>> List-Id: Xen developer discussion 
>>
>> It ease code review, unit is explicit.
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  hw/block/xen_disk.c|  4 ++--
>>  hw/xenpv/xen_domainbuild.c | 10 +-
>>  2 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
>> index f74fcd42d1..557005b5e5 100644
>> --- a/hw/block/xen_disk.c
>> +++ b/hw/block/xen_disk.c
>> @@ -1153,9 +1153,9 @@ static int blk_connect(struct XenDevice *xendev)
>>  }
>>  
>>  xen_pv_printf(xendev, 1, "type \"%s\", fileproto \"%s\", filename 
>> \"%s\","
>> -  " size %" PRId64 " (%" PRId64 " MB)\n",
>> +  " size %" PRId64 " (%llu MB)\n",
>>blkdev->type, blkdev->fileproto, blkdev->filename,
>> -  blkdev->file_size, blkdev->file_size >> 20);
>> +  blkdev->file_size, blkdev->file_size / M_BYTE);
>>  
>>  /* Fill in number of sector size and number of sectors */
>>  xenstore_write_be_int(>xendev, "sector-size", blkdev->file_blk);
>> diff --git a/hw/xenpv/xen_domainbuild.c b/hw/xenpv/xen_domainbuild.c
>> index 027f76fad1..083fb80ee5 100644
>> --- a/hw/xenpv/xen_domainbuild.c
>> +++ b/hw/xenpv/xen_domainbuild.c
>> @@ -75,9 +75,9 @@ int xenstore_domain_init1(const char *kernel, const char 
>> *ramdisk,
>>  xenstore_write_str(dom, "vm", vm);
>>  
>>  /* memory */
>> -xenstore_write_int(dom, "memory/target", ram_size >> 10);  // kB
>> -xenstore_write_int(vm, "memory", ram_size >> 20);  // MB
>> -xenstore_write_int(vm, "maxmem", ram_size >> 20);  // MB
>> +xenstore_write_int(dom, "memory/target", ram_size * K_BYTE);
>> +xenstore_write_int(vm, "memory", ram_size * M_BYTE);
>> +xenstore_write_int(vm, "maxmem", ram_size * M_BYTE);
> 
> These changes looks wrong, surely it must be 'ram_size / K_BYTE'...

Oops... Thanks for noticing this mistake!

Can I add your R-b tag once fixed? Respin will be:

+xenstore_write_int(dom, "memory/target", ram_size / K_BYTE);
+xenstore_write_int(vm, "memory", ram_size / M_BYTE);
+xenstore_write_int(vm, "maxmem", ram_size / M_BYTE);

Regards,

Phil.

> 
> Alan
> 

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

Re: [Xen-devel] [PATCH RFC 3/4] x86: add invpcid.h

[Andrew Cooper]

On 15/02/18 12:10, Wei Liu wrote:
> Provide the functions needed for different modes.
>
> Signed-off-by: Wei Liu 
> ---
>  xen/include/asm-x86/invpcid.h | 61 
> +++
>  1 file changed, 61 insertions(+)
>  create mode 100644 xen/include/asm-x86/invpcid.h
>
> diff --git a/xen/include/asm-x86/invpcid.h b/xen/include/asm-x86/invpcid.h
> new file mode 100644
> index 00..7c307ecfc3
> --- /dev/null
> +++ b/xen/include/asm-x86/invpcid.h
> @@ -0,0 +1,61 @@
> +#ifndef _ASM_X86_INVPCID_H_
> +#define _ASM_X86_INVPCID_H_
> +
> +#include 
> +
> +#define INVPCID_TYPE_INDIV_ADDR  0
> +#define INVPCID_TYPE_SINGLE_CTXT 1
> +#define INVPCID_TYPE_ALL_INCL_GLOBAL 2
> +#define INVPCID_TYPE_ALL_NON_GLOBAL  3
> +
> +struct invpcid_desc {
> +uint64_t pcid:12;
> +uint64_t reserved:52;
> +uint64_t addr;
> +};
> +
> +static inline void invpcid(unsigned long pcid, unsigned long addr,
> +   unsigned long type)
> +{
> +struct invpcid_desc desc = { .pcid = pcid, .addr = addr };
> +
> +asm volatile ("invpcid (%0), %1"
> +  : : "r" (), "r" (type) : "memory" );

invpcid %[desc], %[type]

And you can use [desc] "m" (desc) for the constraint.  The structure
will be built on the stack, meaning that an %rsp based memory reference
is more efficient than forcing the use of a register.

We probably also need a -DHAVE_GAS_INVPCID, as INVPCID is newer than
some of the instruction groups we already check for.

~Andrew

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

[Xen-devel] [PATCH RFC 4/4] x86: use invpcid to do global flush

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/arch/x86/flushtlb.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/flushtlb.c b/xen/arch/x86/flushtlb.c
index 8a7a76b8ff..e4ea4f3297 100644
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -120,11 +121,24 @@ unsigned int flush_area_local(const void *va, unsigned 
int flags)
 else
 {
 u32 t = pre_flush();
-unsigned long cr4 = read_cr4();
 
-write_cr4(cr4 & ~X86_CR4_PGE);
-barrier();
-write_cr4(cr4);
+if ( !cpu_has_invpcid )
+{
+unsigned long cr4 = read_cr4();
+
+write_cr4(cr4 & ~X86_CR4_PGE);
+barrier();
+write_cr4(cr4);
+}
+else
+{
+/*
+ * Using invpcid to flush all mappings works
+ * regardless of whether PCID is enabled or not.
+ * It is faster than read-modify-write CR4.
+ */
+invpcid_flush_all();
+}
 
 post_flush(t);
 }
-- 
2.11.0


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

[Xen-devel] [PATCH RFC 0/4] Use INVPCID to flush global mappings

[Wei Liu]

I wrote these patches sometime ago to explore PCID and INVPCID. I haven't
thought through whether how to use both in Xen yet. But seeing Juergen laid out
his thought on PCID and INVPCID I think some of the patches can be useful.

I had done some benchmark on the speed in one of my older branch by inserting
some trace points before and after the flush. It showed that twiddling CR4.PGE
is 3 to 5 times slower than invpcid.

This series is in incomplete -- obviously we have CR4.PGE twiddling in a few
other places. But if you think it is beneficial I can try to convert those
places as well.

Wei.

Wei Liu (4):
  x86: introduce cpu_has_invpcid
  x86: report if PCID and INVPCID are supported
  x86: add invpcid.h
  x86: use invpcid to do global flush

 xen/arch/x86/flushtlb.c  | 22 ---
 xen/arch/x86/setup.c |  7 +
 xen/include/asm-x86/cpufeature.h |  1 +
 xen/include/asm-x86/invpcid.h| 61 
 4 files changed, 87 insertions(+), 4 deletions(-)
 create mode 100644 xen/include/asm-x86/invpcid.h

-- 
2.11.0


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

[Xen-devel] [PATCH RFC 2/4] x86: report if PCID and INVPCID are supported

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/arch/x86/setup.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index ac530ece2c..89e42865a4 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1701,6 +1701,13 @@ void __init noreturn __start_xen(unsigned long mbi_p)
cpu_has_nx ? XENLOG_INFO : XENLOG_WARNING "Warning: ",
cpu_has_nx ? "" : "not ");
 
+
+printk(XENLOG_INFO
+   "PCID (Process-Context IDentifier) %ssupported\n",
+   cpu_has_pcid ? "" : "not ");
+
+printk(XENLOG_INFO "INVPCID %ssupported\n", cpu_has_invpcid ? "" : "not ");
+
 /*
  * We're going to setup domain0 using the module(s) that we stashed safely
  * above our heap. The second module, if present, is an initrd ramdisk.
-- 
2.11.0


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

[Xen-devel] [PATCH RFC 3/4] x86: add invpcid.h

[Wei Liu]

Provide the functions needed for different modes.

Signed-off-by: Wei Liu 
---
 xen/include/asm-x86/invpcid.h | 61 +++
 1 file changed, 61 insertions(+)
 create mode 100644 xen/include/asm-x86/invpcid.h

diff --git a/xen/include/asm-x86/invpcid.h b/xen/include/asm-x86/invpcid.h
new file mode 100644
index 00..7c307ecfc3
--- /dev/null
+++ b/xen/include/asm-x86/invpcid.h
@@ -0,0 +1,61 @@
+#ifndef _ASM_X86_INVPCID_H_
+#define _ASM_X86_INVPCID_H_
+
+#include 
+
+#define INVPCID_TYPE_INDIV_ADDR  0
+#define INVPCID_TYPE_SINGLE_CTXT 1
+#define INVPCID_TYPE_ALL_INCL_GLOBAL 2
+#define INVPCID_TYPE_ALL_NON_GLOBAL  3
+
+struct invpcid_desc {
+uint64_t pcid:12;
+uint64_t reserved:52;
+uint64_t addr;
+};
+
+static inline void invpcid(unsigned long pcid, unsigned long addr,
+   unsigned long type)
+{
+struct invpcid_desc desc = { .pcid = pcid, .addr = addr };
+
+asm volatile ("invpcid (%0), %1"
+  : : "r" (), "r" (type) : "memory" );
+}
+
+/* Flush all mappings for a given PCID and addr, not including globals */
+static inline void invpcid_flush_one(unsigned long pcid,
+ unsigned long addr)
+{
+invpcid(pcid, addr, INVPCID_TYPE_INDIV_ADDR);
+}
+
+/* Flush all mappings for a given PCID, not including globals */
+static inline void invpcid_flush_single_context(unsigned long pcid)
+{
+invpcid(pcid, 0, INVPCID_TYPE_SINGLE_CTXT);
+}
+
+/* Flush all mappings, including globals, for all PCIDs */
+static inline void invpcid_flush_all(void)
+{
+invpcid(0, 0, INVPCID_TYPE_ALL_INCL_GLOBAL);
+}
+
+/* Flush all mappings for all PCIDs, excluding globals */
+static inline void invpcid_flush_all_nonglobals(void)
+{
+invpcid(0, 0, INVPCID_TYPE_ALL_NON_GLOBAL);
+}
+
+#endif /* _ASM_X86_INVPCID_H_ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.11.0


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

[Xen-devel] [PATCH RFC 1/4] x86: introduce cpu_has_invpcid

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/include/asm-x86/cpufeature.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index 55b696ed07..db8072279d 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -93,6 +93,7 @@
 #define cpu_has_avx2boot_cpu_has(X86_FEATURE_AVX2)
 #define cpu_has_smepboot_cpu_has(X86_FEATURE_SMEP)
 #define cpu_has_bmi2boot_cpu_has(X86_FEATURE_BMI2)
+#define cpu_has_invpcid boot_cpu_has(X86_FEATURE_INVPCID)
 #define cpu_has_rtm boot_cpu_has(X86_FEATURE_RTM)
 #define cpu_has_fpu_sel (!boot_cpu_has(X86_FEATURE_NO_FPU_SEL))
 #define cpu_has_mpx boot_cpu_has(X86_FEATURE_MPX)
-- 
2.11.0


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

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemuu-win10-i386

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-win10-i386
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:  a2e5790d841658485d642196dbb0927303d6c22f
  Bug not present: ab2d92ad881da11331280aedf612d82e61cb6d41
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/119262/


  (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-xl-qemuu-win10-i386.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-xl-qemuu-win10-i386.xen-boot
 --summary-out=tmp/119262.bisection-summary --basis-template=118324 
--blessings=real,real-bisect linux-linus test-amd64-i386-xl-qemuu-win10-i386 
xen-boot
Searching for failure / basis pass:
 119117 fail [host=italia1] / 118629 ok.
Failure / basis pass flights: 119117 / 118629
(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 61f14c015f5be9151ba25e638d349f4d40cb7cd4 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
Basis pass b46dc8ae17a427c50c00241898832807576fd28a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
1c3545eeaf4ac6f8d5db5a52c29c112694bcd4f0
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#b46dc8ae17a427c50c00241898832807576fd28a-61f14c015f5be9151ba25e638d349f4d40cb7cd4
 
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-2b033e396f4fa0981bae1213cdacd15775655a97
 
git://xenbits.xen.org/xen.git#1c3545eeaf4ac6f8d5db5a52c29c112694bcd4f0-c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
Loaded 130096 nodes in revision graph
Searching for test results:
 118629 pass b46dc8ae17a427c50c00241898832807576fd28a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
1c3545eeaf4ac6f8d5db5a52c29c112694bcd4f0
 118638 fail irrelevant
 118672 fail irrelevant
 118775 fail irrelevant
 118893 fail d48fcbd864a008802a90c58a9ceddd9436d11a49 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
 118968 fail 7928b2cbe55b2a410a0f5c1f154610059c57b1b2 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
 119064 fail 178e834c47b0d01352c48730235aae69898fbc02 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
 119153 pass b46dc8ae17a427c50c00241898832807576fd28a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
1c3545eeaf4ac6f8d5db5a52c29c112694bcd4f0
 119163 fail 178e834c47b0d01352c48730235aae69898fbc02 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
 119180 fail 1c5b2216fbb973a9410e0b06389740b5c1289171 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
 119185 fail 1029117127540fef4edcf4f0887dc3e1f7d5adb2 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
 119117 fail 61f14c015f5be9151ba25e638d349f4d40cb7cd4 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 

Re: [Xen-devel] [PATCH 0/8] xen: add pvh guest support

[Daniel Kiper]

Hi Juergen,

Sorry for huge delay. It looks that I am recovering slowly and
probably I will have more time for reviews.

On Wed, Nov 29, 2017 at 02:46:42PM +0100, Juergen Gross wrote:
> This patch series adds support for booting Linux as PVH guest.
>
> Similar to i386/xen and x86_64/xen platforms the new i386/xenpvh
> platform grub is booted as a standalone image directly by Xen.
>
> For booting Linux kernel it is using the standard linux kernel
> loader. The only modification of the linux loader is to pass the
> ACPI RSDP address via boot parameters to the kernel, as that table
> might not be located at the usual physical address just below 1MB.

AIUI PVH is quite generic idea and can be implemented by different
virtualization platforms. IIRC Maran Wilson works on PVH for KVM.
So, would not it make more sense to have platform independent GRUB2
PVH code and then on top of that build Xen and KVM support? Could
you do that?

Thank you for your work.

Daniel

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

Re: [Xen-devel] [PATCH 8/8] xenpvh: add support to configure

[Daniel Kiper]

On Wed, Nov 29, 2017 at 02:46:50PM +0100, Juergen Gross wrote:
> Support platform i386/xenpvh in configure.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Daniel Kiper 

Daniel

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

Re: [Xen-devel] [PATCH 7/8] xenpvh: support grub-install for xenpvh

[Daniel Kiper]

On Wed, Nov 29, 2017 at 02:46:49PM +0100, Juergen Gross wrote:
> Add xenpvh support to grub-install.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Daniel Kiper 

Daniel

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

Re: [Xen-devel] [PATCH 6/8] xenpvh: support building a standalone image

[Daniel Kiper]

On Wed, Nov 29, 2017 at 02:46:48PM +0100, Juergen Gross wrote:
> Suppor mkimage for xenpvh.
>
> Signed-off-by: Juergen Gross 
> ---
>  include/grub/util/mkimage.h |  3 ++-
>  util/grub-mkimage32.c   |  1 +
>  util/grub-mkimage64.c   |  1 +
>  util/grub-mkimagexx.c   | 44 
>  util/mkimage.c  | 23 ++-
>  5 files changed, 66 insertions(+), 6 deletions(-)
>
> diff --git a/include/grub/util/mkimage.h b/include/grub/util/mkimage.h
> index b3a5ca132..3f5bc2e00 100644
> --- a/include/grub/util/mkimage.h
> +++ b/include/grub/util/mkimage.h
> @@ -71,7 +71,8 @@ struct grub_install_image_target_desc
>  IMAGE_I386_IEEE1275,
>  IMAGE_LOONGSON_ELF, IMAGE_QEMU, IMAGE_PPC, IMAGE_YEELOONG_FLASH,
>  IMAGE_FULOONG2F_FLASH, IMAGE_I386_PC_PXE, IMAGE_MIPS_ARC,
> -IMAGE_QEMU_MIPS_FLASH, IMAGE_UBOOT, IMAGE_XEN, IMAGE_I386_PC_ELTORITO
> +IMAGE_QEMU_MIPS_FLASH, IMAGE_UBOOT, IMAGE_XEN, IMAGE_I386_PC_ELTORITO,
> +IMAGE_XENPVH
>} id;
>enum
>  {
> diff --git a/util/grub-mkimage32.c b/util/grub-mkimage32.c
> index 9b31397bc..4253c4897 100644
> --- a/util/grub-mkimage32.c
> +++ b/util/grub-mkimage32.c
> @@ -18,5 +18,6 @@
>  # define ELF_R_TYPE(val) ELF32_R_TYPE(val)
>  # define ELF_ST_TYPE(val)ELF32_ST_TYPE(val)

Please add empty line here...

>  #define XEN_NOTE_SIZE 132
> +#define XENPVH_NOTE_SIZE 20

...and align the numbers for XEN_NOTE_SIZE and XENPVH_NOTE_SIZE.

>
>  #include "grub-mkimagexx.c"
> diff --git a/util/grub-mkimage64.c b/util/grub-mkimage64.c
> index d83345924..c862be8c0 100644
> --- a/util/grub-mkimage64.c
> +++ b/util/grub-mkimage64.c
> @@ -18,5 +18,6 @@
>  # define ELF_R_TYPE(val) ELF64_R_TYPE(val)
>  # define ELF_ST_TYPE(val)ELF64_ST_TYPE(val)
>  #define XEN_NOTE_SIZE 120
> +#define XENPVH_NOTE_SIZE 24

Ditto.

>
>  #include "grub-mkimagexx.c"
> diff --git a/util/grub-mkimagexx.c b/util/grub-mkimagexx.c
> index a2bb05439..a024e57b6 100644
> --- a/util/grub-mkimagexx.c
> +++ b/util/grub-mkimagexx.c
> @@ -207,12 +207,12 @@ SUFFIX (grub_mkimage_generate_elf) (const struct 
> grub_install_image_target_desc
>phnum++;
>footer_size += sizeof (struct grub_ieee1275_note);
>  }
> -  if (image_target->id == IMAGE_XEN)
> +  if (image_target->id == IMAGE_XEN || image_target->id == IMAGE_XENPVH)
>  {
>phnum++;
>shnum++;
>string_size += sizeof (".xen");
> -  footer_size += XEN_NOTE_SIZE;
> +  footer_size += (image_target->id == IMAGE_XEN) ? XEN_NOTE_SIZE : 
> XENPVH_NOTE_SIZE;
>  }
>header_size = ALIGN_UP (sizeof (*ehdr) + phnum * sizeof (*phdr)
> + shnum * sizeof (*shdr) + string_size, 
> layout->align);
> @@ -399,6 +399,39 @@ SUFFIX (grub_mkimage_generate_elf) (const struct 
> grub_install_image_target_desc
>phdr->p_offset = grub_host_to_target32 (header_size + program_size);
>  }
>
> +  if (image_target->id == IMAGE_XENPVH)
> +{
> +  char *note_start = (elf_img + program_size + header_size);
> +  Elf_Nhdr *note_ptr;
> +  char *ptr = (char *) note_start;
> +
> +  grub_util_info ("adding XEN NOTE segment");
> +
> +  /* Phys32 Entry.  */
> +  note_ptr = (Elf_Nhdr *) ptr;
> +  note_ptr->n_namesz = grub_host_to_target32 (sizeof 
> (GRUB_XEN_NOTE_NAME));
> +  note_ptr->n_descsz = grub_host_to_target32 
> (image_target->voidp_sizeof);
> +  note_ptr->n_type = grub_host_to_target32 (18);

What 18 means? Could you use an existing constant or if not define one?

> +  ptr += sizeof (Elf_Nhdr);
> +  memcpy (ptr, GRUB_XEN_NOTE_NAME, sizeof (GRUB_XEN_NOTE_NAME));
> +  ptr += ALIGN_UP (sizeof (GRUB_XEN_NOTE_NAME), 4);
> +  memset (ptr, 0, image_target->voidp_sizeof);
> +  *(grub_uint32_t *) ptr = GRUB_KERNEL_I386_XENPVH_LINK_ADDR;
> +  ptr += image_target->voidp_sizeof;
> +
> +  assert (XENPVH_NOTE_SIZE == (ptr - note_start));
> +
> +  phdr++;
> +  phdr->p_type = grub_host_to_target32 (PT_NOTE);
> +  phdr->p_flags = grub_host_to_target32 (PF_R);
> +  phdr->p_align = grub_host_to_target32 (image_target->voidp_sizeof);
> +  phdr->p_vaddr = 0;
> +  phdr->p_paddr = 0;
> +  phdr->p_filesz = grub_host_to_target32 (XENPVH_NOTE_SIZE);
> +  phdr->p_memsz = 0;
> +  phdr->p_offset = grub_host_to_target32 (header_size + program_size);
> +}
> +
>if (note)
>  {
>int note_size = sizeof (struct grub_ieee1275_note);
> @@ -474,7 +507,7 @@ SUFFIX (grub_mkimage_generate_elf) (const struct 
> grub_install_image_target_desc
>  shdr->sh_entsize = grub_host_to_target32 (0);
>  shdr++;
>
> -if (image_target->id == IMAGE_XEN)
> +if (image_target->id == IMAGE_XEN || image_target->id == IMAGE_XENPVH)
>{
>   memcpy (ptr, ".xen", sizeof (".xen"));
>   shdr->sh_name = grub_host_to_target32 (ptr - str_start);
> @@ -482,7 +515,10 @@ SUFFIX 

Re: [Xen-devel] [PATCH 5/8] xenpvh: add build runes for grub-core

[Daniel Kiper]

On Wed, Nov 29, 2017 at 02:46:47PM +0100, Juergen Gross wrote:
> Add the modifications to the build system needed to build a xenpvh
> grub.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Daniel Kiper 

Daniel

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

Re: [Xen-devel] [PATCH 4/8] xen: add xen pvh guest support to grub-core

[Daniel Kiper]

On Wed, Nov 29, 2017 at 02:46:46PM +0100, Juergen Gross wrote:
> Add all the grub-core code needed for Xen PVH guest support. This
> includes:
>
> - The new PVH entry point of grub
> - PVH specific initialization code
> - machine specific header files
> - modifications in Xen specific code to work in PVH environment
> - modifications in other core code to be reusable with PVH
>
> Enabling all this code is done later.
>
> Signed-off-by: Juergen Gross 
> ---
>  grub-core/kern/i386/tsc.c |   2 +-
>  grub-core/kern/i386/xen/pvh.c | 344 
> ++
>  grub-core/kern/i386/xen/startup_pvh.S |  80 
>  grub-core/kern/xen/init.c |  66 ---
>  include/grub/i386/pc/int.h|   3 +
>  include/grub/i386/tsc.h   |   2 +-
>  include/grub/i386/xen/hypercall.h |   5 +-
>  include/grub/i386/xenpvh/boot.h   |   1 +
>  include/grub/i386/xenpvh/console.h|   1 +
>  include/grub/i386/xenpvh/int.h|   1 +
>  include/grub/i386/xenpvh/kernel.h |  30 +++
>  include/grub/i386/xenpvh/memory.h |  54 ++
>  include/grub/i386/xenpvh/time.h   |   1 +
>  include/grub/kernel.h |   4 +-
>  include/grub/offsets.h|   3 +
>  include/grub/xen.h|   6 +
>  16 files changed, 573 insertions(+), 30 deletions(-)
>  create mode 100644 grub-core/kern/i386/xen/pvh.c
>  create mode 100644 grub-core/kern/i386/xen/startup_pvh.S
>  create mode 100644 include/grub/i386/xenpvh/boot.h
>  create mode 100644 include/grub/i386/xenpvh/console.h
>  create mode 100644 include/grub/i386/xenpvh/int.h
>  create mode 100644 include/grub/i386/xenpvh/kernel.h
>  create mode 100644 include/grub/i386/xenpvh/memory.h
>  create mode 100644 include/grub/i386/xenpvh/time.h

May I ask you to split this patch into smaller logical entities?

Daniel

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

Re: [Xen-devel] [PATCH 3/8] xen: carve out grant tab initialization into dedicated function

[Daniel Kiper]

On Wed, Nov 29, 2017 at 02:46:45PM +0100, Juergen Gross wrote:
> Initialize the grant tab in a dedicated function. This will enable
> using it for PVH guests, too.
>
> Signed-off-by: Juergen Gross 
> ---
>  grub-core/kern/xen/init.c | 35 +--
>  1 file changed, 21 insertions(+), 14 deletions(-)
>
> diff --git a/grub-core/kern/xen/init.c b/grub-core/kern/xen/init.c
> index 0559c033c..29f5bc23d 100644
> --- a/grub-core/kern/xen/init.c
> +++ b/grub-core/kern/xen/init.c
> @@ -318,6 +318,25 @@ grub_xenstore_dir (const char *dir,
>
>  unsigned long gntframe = 0;
>
> +static void
> +grub_xen_setup_gnttab (void)
> +{
> +  struct gnttab_set_version gnttab_setver;
> +  struct gnttab_setup_table gnttab_setup;
> +
> +  grub_memset (_setver, 0, sizeof (gnttab_setver));
> +
> +  gnttab_setver.version = 1;
> +  grub_xen_grant_table_op (GNTTABOP_set_version, _setver, 1);
> +
> +  grub_memset (_setup, 0, sizeof (gnttab_setup));
> +  gnttab_setup.dom = DOMID_SELF;
> +  gnttab_setup.nr_frames = 1;
> +  gnttab_setup.frame_list.p = 
> +
> +  grub_xen_grant_table_op (GNTTABOP_setup_table, _setup, 1);
> +}
> +
>  #define MAX_N_UNUSABLE_PAGES 4
>
>  static int
> @@ -357,26 +376,12 @@ map_all_pages (void)
>  (grub_xen_mfn_t *) grub_xen_start_page_addr->mfn_list;
>grub_uint64_t *pg = (grub_uint64_t *) window;
>grub_uint64_t oldpgstart, oldpgend;
> -  struct gnttab_setup_table gnttab_setup;
> -  struct gnttab_set_version gnttab_setver;
>grub_size_t n_unusable_pages = 0;
>struct mmu_update m2p_updates[2 * MAX_N_UNUSABLE_PAGES];
>
>if (total_pages > MAX_TOTAL_PAGES - 4)
>  total_pages = MAX_TOTAL_PAGES - 4;
>
> -  grub_memset (_setver, 0, sizeof (gnttab_setver));
> -
> -  gnttab_setver.version = 1;
> -  grub_xen_grant_table_op (GNTTABOP_set_version, _setver, 1);
> -
> -  grub_memset (_setup, 0, sizeof (gnttab_setup));
> -  gnttab_setup.dom = DOMID_SELF;
> -  gnttab_setup.nr_frames = 1;
> -  gnttab_setup.frame_list.p = 
> -
> -  grub_xen_grant_table_op (GNTTABOP_setup_table, _setup, 1);
> -
>for (j = 0; j < total_pages - n_unusable_pages; j++)
>  while (!grub_xen_is_page_usable (mfn_list[j]))
>{
> @@ -537,6 +542,8 @@ grub_machine_init (void)
>  + GRUB_KERNEL_MACHINE_MOD_GAP,
>  GRUB_KERNEL_MACHINE_MOD_ALIGN);
>
> +  grub_xen_setup_gnttab ();
> +

I am OK with this patch itself but I am not sure why you are moving grant
setup from map_all_pages() to grub_machine_init(). Is it by mistake or by
purpose? If by purpose please explain why in the commit message.

Daniel

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

Re: [Xen-devel] [PATCH v2 02/15] xen/arm: vpsci: Add support for PSCI 1.1

[Julien Grall]

On 14/02/18 19:14, Mirela Simonovic wrote:

Hi Julien,


Hi,


On 02/13/2018 12:44 AM, Julien Grall wrote:



On 12/02/2018 23:16, Mirela Simonovic wrote:

Hi Julien,


Hi,


On 02/12/2018 10:41 PM, Julien Grall wrote:



On 12/02/2018 20:12, Mirela Simonovic wrote:

Hi Julien,


Hi Mirela,

Thank you for the review.

I've done pretty much the same work in parallel, but there are few 
additional minor changes I've made. Briefly, the difference is in 
return values that some already implemented functions should return 
starting from v1.0 (and even v0.2 errata). Please let me know 
whether you omitted that intentionally.


Could you give a bit more details here? From a brief look we don't 
seem to implement correctly:
- CPU_OFF: PSCI_DENY should be return on failure (though it 
should never fail in Xen case) and the check on the vCPU state is 
pointless.


I believe CPU_OFF is fine today, it never returns.

- MIGRATE_INFO_TYPE: should technically return int32_t instead 
of uint32_t. That not really matter for now.


If you speak about denying SMC64 call from AArch32, then this is 
already done in vsmccc.c (see vsmccc_call).


Agreed on above, there are 2 more:

1. MIGRATE_INFO_TYPE should return PSCI_NOT_SUPPORTED instead 
PSCI_0_2_TOS_MP_OR_NOT_PRESENT. The function is effectively not 
implemented, but in v0.2 it was mandatory, so it couldn't return 
PSCI_NOT_SUPPORTED (I guess this was some kind of a workaround). 
Since v0.2 errata and v1.0 release the function is made optional and 
it should return "not supported" error - just removing the function 
should be fine (and mismatching return type issue would be gone).


Looking at the spec:

"2 Trusted OS is either not present or does not require migration. A 
system of this type does not require the caller to use the MIGRATE 
function. MIGRATE function calls return NOT_SUPPORTED."


So returning 2 in our case seems to be valid.



2. A new error code has been introduced in PSCI v1.0: 
PSCI_INVALID_ADDRESS. This error should be returned by PSCI functions 
which receive an address as the argument when the provided address is 
incorrect. In implementation in Xen this affects CPU_ON and 
CPU_SUSPEND. CPU_ON today returns invalid parameter error and that 
needs to be replaced with invalid address error. I'm not sure for 
CPU_SUSPEND since its implementation doesn't use/check any of the 
arguments today...
I disagree, not all PSCI_INVALID_PARAMETERS should be replaced by 
PSCI_INVALID_ADDRESS. They have two distinct meaning. However, I am 
not sure where we would need to use it in Xen. The error is described 
as "INVALID_ADDRESS is returned when the entry point address is known 
by the implementation to be invalid, because it is in a range that is 
known not to be available to the caller."


The only potential one would be the check on is_thumb, but even there 
it does not match the description. The range is still available to the 
guest. I think that check should just be dropped.


To be more specific, I was thinking that in xen/arch/arm/vpsci.c line 41 
for psci version other than 0.1 the PSCI_INVALID_ADDRESS error should be 
returned instead PSCI_INVALID_PARAMETERS.


This is exactly the place I was speaking in my previous e-mail. I am not 
entirely convinced we should keep the check or even switch the return to 
PSCI_INVALID_PARAMETERS as the usage does not entirely match the error 
description.


Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH] xsm:schedop: introduce vcpuinfo permissions verification

[Andrii Anisov]

From: Andrii Anisov 

Introduce per-vcpu scheduler operations permission verification.
As long as Xvcpuinfo are in fact scheduler configuration manipulations
there is no need to introduce specific access vectors.

Signed-off-by: Andrii Anisov 
---
 xen/xsm/flask/hooks.c   | 2 ++
 xen/xsm/flask/policy/access_vectors | 4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 1802d8d..0276493 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -532,9 +532,11 @@ static int flask_domctl_scheduler_op(struct domain *d, int 
op)
 switch ( op )
 {
 case XEN_DOMCTL_SCHEDOP_putinfo:
+case XEN_DOMCTL_SCHEDOP_putvcpuinfo:
 return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SETSCHEDULER);
 
 case XEN_DOMCTL_SCHEDOP_getinfo:
+case XEN_DOMCTL_SCHEDOP_getvcpuinfo:
 return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETSCHEDULER);
 
 default:
diff --git a/xen/xsm/flask/policy/access_vectors 
b/xen/xsm/flask/policy/access_vectors
index 89b9996..dccd9a5 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -71,9 +71,9 @@ class xen
 tmem_op
 # XEN_SYSCTL_tmem_op command of tmem (part of sysctl)
 tmem_control
-# XEN_SYSCTL_scheduler_op with XEN_DOMCTL_SCHEDOP_getinfo, XEN_SYSCTL_sched_id
+# XEN_SYSCTL_scheduler_op with XEN_DOMCTL_SCHEDOP_getinfo, 
XEN_SYSCTL_sched_id, XEN_DOMCTL_SCHEDOP_getvcpuinfo
 getscheduler
-# XEN_SYSCTL_scheduler_op with XEN_DOMCTL_SCHEDOP_putinfo
+# XEN_SYSCTL_scheduler_op with XEN_DOMCTL_SCHEDOP_putinfo, 
XEN_DOMCTL_SCHEDOP_putvcpuinfo
 setscheduler
 }
 
-- 
2.7.4


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

Re: [Xen-devel] Hangs after /etc/init.d/xencommons start

[Wei Liu]

On Tue, Feb 13, 2018 at 04:19:27PM -0800, ls00...@yahoo.com wrote:
> Hi all:
>  I am using arm64 ( hikey) to test for xen.
> After struggling for two week, I was able to build and install everything 
> on the target, xen and dom0 kernel boots up ok. 
> However, when I try to use “xl list”, it hangs, I realized I have to 
> start the xencommons  service first. But it hangs as well after I typed in 
> /etc/init.d/xencommons start. 
>It’s the command “xen-init-dom0” called by the script that hangs.
>Too bad it doesn’t give me any error message.
> I am using the most up to date version of xen from github, I know it’s 
> unstable, can anybody tell me how do I look further into the problem?  Or is 
> this right mailing list to ask for help? This seems more like a user space 
> tool problem.

Please make sure xenstored is running.

Wei.

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

[Xen-devel] [PATCH v4 1/3] hvm/svm: Enable Breakpoint events

[Alexandru Isaila]

This commit implements the breakpoint events for svm.
At the moment, the Breakpoint vmexit is not forwarded to the monitor
layer.
This patch adds the hvm_monitor_debug call to the VMEXIT_EXCEPTION_BP.
Also, the Software Breakpoint cap is moved from the Intel arch to the
common part of the code.

Signed-off-by: Alexandru Isaila 
Acked-by: Tamas K Lengyel 

---
Changes since V3:
-Rebase to the latest staging
---
 xen/arch/x86/hvm/monitor.c|  5 +
 xen/arch/x86/hvm/svm/svm.c| 50 +++
 xen/arch/x86/hvm/vmx/vmx.c|  5 -
 xen/include/asm-x86/monitor.h |  4 ++--
 4 files changed, 48 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index 131b852..5d568a3 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -133,6 +133,11 @@ static inline unsigned long gfn_of_rip(unsigned long rip)
 int hvm_monitor_debug(unsigned long rip, enum hvm_monitor_debug_type type,
   unsigned long trap_type, unsigned long insn_length)
 {
+   /*
+* rc < 0 error in monitor/vm_event, crash
+* !rccontinue normally
+* rc > 0 paused waiting for response, work here is done
+*/
 struct vcpu *curr = current;
 struct arch_domain *ad = >domain->arch;
 vm_event_request_t req = {};
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 81cf5b8..abd3fe5 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 void svm_asm_do_resume(void);
@@ -1079,7 +1080,8 @@ static void svm_ctxt_switch_to(struct vcpu *v)
 static void noreturn svm_do_resume(struct vcpu *v)
 {
 struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
-bool_t debug_state = v->domain->debugger_attached;
+bool debug_state = v->domain->debugger_attached
+|| v->domain->arch.monitor.software_breakpoint_enabled;
 bool_t vcpu_guestmode = 0;
 struct vlapic *vlapic = vcpu_vlapic(v);
 
@@ -2404,6 +2406,19 @@ static bool svm_get_pending_event(struct vcpu *v, struct 
x86_event *info)
 return true;
 }
 
+static void svm_propagate_intr(struct vcpu *v, unsigned long insn_len)
+{
+struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+struct x86_event event = {
+.vector = vmcb->eventinj.fields.type,
+.type = vmcb->eventinj.fields.type,
+.error_code = vmcb->exitinfo1,
+};
+
+event.insn_len = insn_len;
+hvm_inject_event();
+}
+
 static struct hvm_function_table __initdata svm_function_table = {
 .name = "SVM",
 .cpu_up_prepare   = svm_cpu_up_prepare,
@@ -2616,14 +2631,31 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 break;
 
 case VMEXIT_EXCEPTION_BP:
-if ( !v->domain->debugger_attached )
-goto unexpected_exit_type;
-/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. */
-if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
-break;
-__update_guest_eip(regs, inst_len);
-current->arch.gdbsx_vcpu_event = TRAP_int3;
-domain_pause_for_debugger();
+inst_len = __get_instruction_length(v, INSTR_INT3);
+
+if ( inst_len == 0 )
+ break;
+
+if ( v->domain->debugger_attached )
+{
+/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update 
RIP. */
+__update_guest_eip(regs, inst_len);
+current->arch.gdbsx_vcpu_event = TRAP_int3;
+domain_pause_for_debugger();
+}
+else
+{
+   int rc;
+
+   rc = hvm_monitor_debug(regs->rip,
+  HVM_MONITOR_SOFTWARE_BREAKPOINT,
+  X86_EVENTTYPE_SW_EXCEPTION,
+  inst_len);
+   if ( rc < 0 )
+   goto unexpected_exit_type;
+   if ( !rc )
+   svm_propagate_intr(v, inst_len);
+}
 break;
 
 case VMEXIT_EXCEPTION_NM:
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index d35cf55..5cd689e 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3703,11 +3703,6 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
HVM_MONITOR_DEBUG_EXCEPTION,
trap_type, insn_len);
 
-/*
- * rc < 0 error in monitor/vm_event, crash
- * !rccontinue normally
- * rc > 0 paused waiting for response, work here is done
- */
 if ( rc < 0 )
 goto exit_and_crash;
 if ( !rc )
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 9ef6dff..b1902f2 100644
--- a/xen/include/asm-x86/monitor.h
+++ 

[Xen-devel] [PATCH v4 2/3] hvm/svm: Enable MSR events

[Alexandru Isaila]

At this moment there is no function to enable msr interception on svm.

This patch implements this function and moves the mov to msr monitor
event
form the Intel arch side to the common capabilities.

Signed-off-by: Alexandru Isaila 
Acked-by: Tamas K Lengyel 
Reviewed-by: Boris Ostrovsky 

---
Changes since V3:
-Rebase to the latest staging
---
 xen/arch/x86/hvm/svm/svm.c| 9 +
 xen/include/asm-x86/monitor.h | 4 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index abd3fe5..ecef6bd 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -163,6 +163,14 @@ void svm_intercept_msr(struct vcpu *v, uint32_t msr, int 
flags)
 __clear_bit(msr * 2 + 1, msr_bit);
 }
 
+static void svm_enable_msr_interception(struct domain *d, uint32_t msr)
+{
+struct vcpu *v;
+
+for_each_vcpu ( d, v )
+svm_intercept_msr(v, msr, MSR_INTERCEPT_WRITE);
+}
+
 static void svm_save_dr(struct vcpu *v)
 {
 struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
@@ -2457,6 +2465,7 @@ static struct hvm_function_table __initdata 
svm_function_table = {
 .fpu_dirty_intercept  = svm_fpu_dirty_intercept,
 .msr_read_intercept   = svm_msr_read_intercept,
 .msr_write_intercept  = svm_msr_write_intercept,
+.enable_msr_interception = svm_enable_msr_interception,
 .set_rdtsc_exiting= svm_set_rdtsc_exiting,
 .set_descriptor_access_exiting = svm_set_descriptor_access_exiting,
 .get_insn_bytes   = svm_get_insn_bytes,
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index b1902f2..9a8f9d9 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -78,12 +78,12 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 return capabilities;
 
 capabilities = ((1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
-(1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT));
+(1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
+(1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR));
 
 if ( cpu_has_vmx )
 {
 capabilities |= ((1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
- (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
  (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
  (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
  (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
-- 
2.7.4


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

[Xen-devel] [PATCH v4 3/3] hvm/svm: Enable CR events

[Alexandru Isaila]

The CR_INTERCEPT_CR3_WRITE intercept is out of the vmcb->_cr_intercepts
so the AMD arch can't intercept CR events.

This patch implements the CR intercept by adding the flag on a
write_ctrlreg event. The monitor write ctrlreg event is moved from the
Intel side to the common capabilities side.

We just need to enable the SVM intercept and then hvm_mov_to_cr() will
forward the event on to the monitor when appropriate.

Signed-off-by: Alexandru Isaila 
Acked-by: Tamas K Lengyel 

---
Changes since V3:
-Rebase to the latest staging
---
 xen/arch/x86/hvm/svm/svm.c| 11 +++
 xen/include/asm-x86/monitor.h |  6 +++---
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index ecef6bd..e36ad05 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -60,6 +60,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 void svm_asm_do_resume(void);
@@ -560,6 +561,16 @@ void svm_update_guest_cr(struct vcpu *v, unsigned int cr)
 svm_fpu_enter(v);
 }
 
+if ( paging_mode_hap(v->domain) )
+{
+uint32_t intercepts = vmcb_get_cr_intercepts(vmcb);
+
+/* Trap CR3 updates if CR3 memory events are enabled. */
+if ( v->domain->arch.monitor.write_ctrlreg_enabled &
+ monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
+   vmcb_set_cr_intercepts(vmcb, intercepts | 
CR_INTERCEPT_CR3_WRITE);
+}
+
 value = v->arch.hvm_vcpu.guest_cr[0] | hw_cr0_mask;
 if ( !paging_mode_hap(v->domain) )
 value |= X86_CR0_PG | X86_CR0_WP;
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 9a8f9d9..59a2610 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -79,12 +79,12 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 
 capabilities = ((1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
 (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
-(1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR));
+(1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
+(1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG));
 
 if ( cpu_has_vmx )
 {
-capabilities |= ((1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
- (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
+capabilities |= ((1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
  (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
  (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
  (1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED));
-- 
2.7.4


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

[Xen-devel] [PATCH v4 0/4] hvm/svm: Enable vm events for SVM

[Alexandru Isaila]

Hi all,

This series provides a skeleton for enabling vm_events on SVM. For the
first step, the MSR, CR, Breakpoint and GuestRequest have been tested
and added to the capabilities list.

Cheers,

Alexandru Isaila

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

Re: [Xen-devel] [PATCH] x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings

[Jan Beulich]

>>> On 14.02.18 at 17:23,  wrote:
> The current XPTI implementation isolates the directmap (and therefore a lot 
> of
> guest data), but a large quantity of CPU0's state (including its stack)
> remains visible.
> 
> Furthermore, an attacker able to read .text is in a vastly superior position
> to normal when it comes to fingerprinting Xen for known vulnerabilities, or
> scanning for ROP/Spectre gadgets.
> 
> Collect together the entrypoints in .text.entry (currently 3x4k frames, but
> can almost certainly be slimmed down), and create a common mapping which is
> inserted into each per-cpu shadow.  The stubs are also inserted into this
> mapping by pointing at the in-use L2.  This allows stubs allocated later (SMP
> boot, or CPU hotplug) to work without further changes to the common 
> mappings.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Juergen Gross 
> 
> v2:
>  * Drop "incomplete" warning from the docs.  This is about as complete as it
>can reasonably get.
>  * Correct BUILD_BUG_ON() calculation, duplicate in the common_pgt code
>  * scope/const improvements
>  * Use .push/.popsection in preference to .previous
>  * Exclude {compat_}create_bounce_frame from .text.entry
>  * Extend the sanity checking of linear in clone_mapping().  There is a 
> latent
>bug where a bad linear parameter would cause Xen to fall over a NULL 
> pointer.
> ---
>  docs/misc/xen-command-line.markdown |  3 --
>  xen/arch/x86/smpboot.c  | 56 
> +
>  xen/arch/x86/x86_64/compat/entry.S  |  5 
>  xen/arch/x86/x86_64/entry.S | 11 ++--
>  xen/arch/x86/xen.lds.S  |  7 +
>  5 files changed, 71 insertions(+), 11 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index 79feba6..8317639 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1935,9 +1935,6 @@ mode.
>  Override default selection of whether to isolate 64-bit PV guest page
>  tables.
>  
> -** WARNING: Not yet a complete isolation implementation, but better than
> -nothing. **
> -
>  ### xsave
>  > `= `
>  
> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> index 2ebef03..10bf2f3 100644
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -622,6 +622,9 @@ unsigned long alloc_stub_page(unsigned int cpu, unsigned 
> long *mfn)
>  unmap_domain_page(memset(__map_domain_page(pg), 0xcc, PAGE_SIZE));
>  }
>  
> +/* Confirm that all stubs fit in a single L2 pagetable. */
> +BUILD_BUG_ON(NR_CPUS * PAGE_SIZE > (1u << L3_PAGETABLE_SHIFT));

It's a little confusing that the comment talks about L2 yet the check
is on L3. May I suggest you either use
L2_PAGETABLE_ENTRIES << L2_PAGETABLE_SHIFT or say "are
covered by a single L3 entry" in the comment?

> @@ -646,13 +649,23 @@ static int clone_mapping(const void *ptr, 
> root_pgentry_t *rpt)
>  {
>  unsigned long linear = (unsigned long)ptr, pfn;
>  unsigned int flags;
> -l3_pgentry_t *pl3e = 
> l4e_to_l3e(idle_pg_table[root_table_offset(linear)]) +
> - l3_table_offset(linear);
> +l3_pgentry_t *pl3e;
>  l2_pgentry_t *pl2e;
>  l1_pgentry_t *pl1e;
>  
> -if ( linear < DIRECTMAP_VIRT_START )
> -return 0;
> +/*
> + * Sanity check 'linear'.  We only allow cloning from the Xen virtual
> + * range, and in particular, only from the directmap and .text ranges.
> + */
> +if ( root_table_offset(linear) > ROOT_PAGETABLE_LAST_XEN_SLOT ||
> + root_table_offset(linear) < ROOT_PAGETABLE_FIRST_XEN_SLOT )
> +return -EINVAL;
> +if ( !(linear >= DIRECTMAP_VIRT_START ||
> +   (linear >= XEN_VIRT_START && linear < XEN_VIRT_END)) )

Putting it this way is certainly fine, but generally I find using !() on
logical || or && expressions less easy to understand than pushing the
negation through the entire expression. Once having done so, it
might even be debatable whether

if ( linear < XEN_VIRT_START ||
 (linear >= XEN_VIRT_END && linear < DIRECTMAP_VIRT_START)) )
return -EINVAL;

wouldn't be better.

With at least the first (comment vs code) aspect taken care of in
both instances
Reviewed-by: Jan Beulich 

Jan

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

Re: [Xen-devel] PVH Dom0 ACPI tables

[Jan Beulich]

>>> On 14.02.18 at 11:30,  wrote:
> Hello,
> 
> After the comments on the ACPI whitelisting patch for PVH Dom0 I've
> decided to post the list of ACPI tables that I've used to create the
> current whitelist, together with other tables that I've not yet added.
> 
> Allowed tables
> 
> DSDT*, FACP*, FACS*, PSDT*, SSDT*, SBST*, ASF, MCFG*, SLIC*, MSDM*,
> UEFI, WDAT*, BGRT, FPDT*, S3PT*, IBFT.
> 
> * Already whitelisted.
> 
> Tables that might need mappings
> 
> BERT, MCHI, SPCR, SPMI, TCPA, WDDT, WDRT, PCCT, WPBT

You have BERT here, but none of ERST, EINJ, or HEST above.
Albeit ERST and HEST are in use by Xen, so may need to go on
the list further down instead.

> Tables that could point to devices being used by Xen
> 
> DBG2, DBGP
> 
> Tables related to devices in use by Xen (or not available to Dom0)
> 
> HPET, DMAR, IVRS, WAET, CSRT, BOOT, MADT,

Why WAET, CSRT, and BOOT? I can't find Xen using any of these.

> System topology related
> 
> SLIT, SRAT, MPST, PMTT, RASF*
> 
> * Not sure allowing Dom0 to activate 'patrol scrub' is safe.
> 
> ARM only
> 
> IORT, GTDT, STAO

I didn't think STAO is ARM-specific.

Jan


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

Re: [Xen-devel] [PATCH 22/30] hw/display: use the BYTE-based definitions

[Gerd Hoffmann]

On Thu, Feb 15, 2018 at 01:28:52AM -0300, Philippe Mathieu-Daudé wrote:
> It ease code review, unit is explicit.

Reviewed-by: Gerd Hoffmann 


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

Re: [Xen-devel] [PATCH v4 2/7] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

[Jan Beulich]

>>> On 14.02.18 at 18:02,  wrote:
> 2018-02-14 16:37 GMT+08:00 Jan Beulich :
> On 14.02.18 at 08:15,  wrote:
>>> 2018-02-13 23:26 GMT+08:00 Jan Beulich :
>>> On 13.02.18 at 16:15,  wrote:
> I've updated the comments according to your previous suggestions,
> do they look good to you?

 The one in the public header is way too verbose. I specifically don't
 see why you would need to spell out XSM privilege requirements
 there. Please make new comments match existing ones in style and
 verbosity if at all possible, while still conveying all necessary /
 relevant information.

>>>
>>> I shortened it a little bit, and now it looks like:
>>>
>>> #define XENMAPSPACE_gmfn_share   6 /* GMFN from another dom. Unlike
>>> gmfn_foreign,
>>>   if (c) tries to map pages from (t) 
>>> into
>>>   (d), this doesn't require that (d) 
>>> itself
>>>   has the privilege to map the pages, 
>>> but
>>>   instead requires that (c) has the
>>>   privilege to do so, as long as (d) 
>>> and (t)
>>>   are allowed to share memory pages.
>>>   This is XENMEM_add_to_physmap_batch 
>>> only,
>>>   and currently ARM only. */
>>
>> Which leaves unclear what (c), (d), and (t) are. How about
>>
>> "GMFN from another dom, XENMEM_add_to_physmap_batch (and
>> currently ARM) only. Other than XENMAPSPACE_gmfn_foreign this
>> ."
>>
>> (You can and should go into further detail in the commit message.)
>> Without this _properly_ explained, I'll continue to ask why you
>> can't simply make XENMAPSPACE_gmfn_foreign do what you want
>> (as it already takes two domid_t-s as input), by suitably adjusting
>> its XSM check(s).
> 
> I'm sorry that I failed to see the reason why you say "which leaves
> unclear what (c), (d), and (t) are". I think "if (c) tries to map pages
> from (t) into (d)" has already included the necessary information
> about this: (c) is the caller of the hypercall (current), (d) is the
> dest domain, and (t) the source domain.
> I think I still need more of your explanation here.

Someone coming across _just_ this comment (while reading the
public header) will not necessarily know what (c), (d), and (t)
stand for, and (s)he shouldn't be forced to dig into git history to
find the patch description. But anyway - all this should go away
from the header anyway, as explained before. All that's needed
here is a terse but understandable explanation of what's different
from XENMAPSPACE_gmfn_foreign.

Jan


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

[Xen-devel] [seabios test] 119206: regressions - FAIL

[osstest service owner]

flight 119206 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/119206/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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

version targeted for testing:
 seabios  4a6dbcea3e412fe12effa2f812f50dd7eae90955
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z  103 days
Failing since115733  2017-11-10 17:19:59 Z   96 days  122 attempts
Testing same since   118668  2018-02-08 04:50:43 Z7 days   10 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Nikolay Nikolov 
  Paul Menzel 
  Stefan Berger 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel 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 4a6dbcea3e412fe12effa2f812f50dd7eae90955
Author: Nikolay Nikolov 
Date:   Sun Feb 4 17:27:01 2018 +0200

floppy: Use timer_check() in floppy_wait_irq()

Use timer_check() instead of using floppy_motor_counter in BDA for the
timeout check in floppy_wait_irq().

The problem with using floppy_motor_counter was that, after it reaches
0, it immediately stops the floppy motors, which is not what is
supposed to happen on real hardware. Instead, after a timeout (like in
the end of every floppy operation, regardless of the result - success,
timeout or error), the floppy motors must be kept spinning for
additional 2 seconds (the FLOPPY_MOTOR_TICKS). So, now the
floppy_motor_counter is initialized to 255 (the max value) in the
beginning of the floppy operation. For IRQ timeouts, a different
timeout is used, 

Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events

[Alexandru Stefan ISAILA]

On Mi, 2018-02-14 at 19:11 +, Andrew Cooper wrote:
> On 14/02/18 18:22, Andrew Cooper wrote:
> >
> > On 14/02/18 16:10, Alexandru Stefan ISAILA wrote:
> > >
> > > On Lu, 2018-02-12 at 15:54 +, Andrew Cooper wrote:
> > > >
> > > > On 12/02/18 15:08, Alexandru Isaila wrote:
> > > > >
> > > > > @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct
> > > > > cpu_user_regs *regs)
> > > > >  break;
> > > > >
> > > > >  case VMEXIT_EXCEPTION_BP:
> > > > > -if ( !v->domain->debugger_attached )
> > > > > -goto unexpected_exit_type;
> > > > > -/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do
> > > > > not
> > > > > update RIP. */
> > > > > -if ( (inst_len = __get_instruction_length(v,
> > > > > INSTR_INT3))
> > > > > == 0 )
> > > > > +inst_len = __get_instruction_length(v, INSTR_INT3);
> > > > There are multiple ways of ending up with this vmexit, and INT3
> > > > is
> > > > not
> > > > the only way.
> > > >
> > > > The old code was somewhat broken (but only in the case that a
> > > > debugger
> > > > was attached), but now with  this introspection hook active,
> > > > executing
> > > > `0xcd 0x03` will end up crashing the domain because of a length
> > > > mismatch
> > > > looking for 0xcc.
> > > >
> > > > You need to inspect EXITINTINFO to work out what went on here,
> > > > and
> > > > distinguish INT3 from INT $3.
> > > >
> > > > Can I suggest that you run this unit test
> > > > http://xenbits.xen.org/docs/xtf/test-swint-emulation.html under
> > > > debug
> > > > introspection an check that you get all expected events?  Every
> > > > time
> > > > we
> > > > touch this code, we seem to break it :(
> > > >
> > > > ~Andrew
> > > >
> > > I've tested on Intel and AMD and I only get events on int3.
> > > Further
> > > more, I don't think there is any way to use the vmcb->exitintinfo
> > > because all the fields are 0 on the time of VMEXIT_EXCEPTION_BP.
> > > Did I
> > > understand the test scenario correctly?
> > Quite possibly, but now I'm even more confused.  I'll have a quick
> > play.
> Ok - after some investigation, executing `int $3` triggers
> VMEXIT_SWINT,
> with the vector in EXITINFO1, as opposed to triggering VMEXIT_EXCP3,
> except that we don't have INTERCEPT_SWINT active, so it completes
> internally.
>
> Therefore, in your patch, we do expect only ever to find an int3
> triggering VMEXIT_EXCEPTION_BP.  Sorry for the noise.
>
> However, do you mind rebasing the remainder of your series onto
> staging?  It doesn't apply cleanly any more.
>
> ~Andrew
>
Nice to hear that. Ok, I will re base to staging and address your other
comments  as well.

Alex


This email was scanned by Bitdefender
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel