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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  36c560e7f38130f12a36e8b66b0785fb655fe893
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z0 days
Testing same since   118110  2018-01-16 19:02:12 Z0 days6 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Wei Liu 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [RFC v4 8/8] drivers/passthrough/arm: Refactor code for arm smmu drivers

[Manish Jaggi]

On 01/16/2018 07:10 PM, Julien Grall wrote:

Hi Manish,

On 16/01/18 13:27, Manish Jaggi wrote:



On 01/16/2018 06:44 PM, Julien Grall wrote:



On 16/01/18 12:40, Manish Jaggi wrote:

Hi Julien,


Hi,


On 01/16/2018 02:11 AM, Julien Grall wrote:



On 01/03/2018 05:34 AM, Manish Jaggi wrote:

Hi Sameer,


Hi Manish,


+    unsigned int type;
+
+    /* Dummy compatibility defines */
+    unsigned long pgsize_bitmap;
+    struct iommu_domain_geometry geometry;
+
+    atomic_t ref;
+    /* Used to link iommu_domain contexts for a same domain.
+ * There is at least one per-SMMU to used by the domain.
+ */
+    struct list_head    list;
+};
+
+/* Xen: Describes information required for a Xen domain */
+struct arm_smmu_xen_domain {
+    spinlock_t  lock;
+    /* List of iommu domains associated to this domain */
+    struct list_head    contexts;
Could we use a more verbose name, How about 
%s/contexts/iommu_domain_contexts/g ?


How about a much more verbose name...? This name is 21 letters and 
that's only for the field. Just imagine with the variable name 
before and a couple of indentation.
How about io_context? anything which makes it more verbose is ok 
with me.


I much prefer to stick with "contexts".
I am not able to understand why to use contexts for a list which has 
iommu_domain pointers.


Because the comment should have been read "iommu_domain context". As 
it is in other description.


If you are ok with this logic, we can rename all iommu_domain pointer 
variables in this file as context.


Why do you keep asking renaming when I clearly said multiple time that 
we *should not* rename any code coming from Linux. This is breaking 
the idea of keeping Xen and Linux SMMU driver close.


If you don't want to get SMMUv3 close to Linux. Then fine, but it 
means you have to use Xen coding style and dropping all necessary code.


But I am afraid this is not the solution I (and AFAIK Stefano) prefer 
because it adds burden on maintenance on Xen community.


I agree with the point that code imported from linux should be touched 
minimally, but If you look closely the problem is in naming of xen 
specific code that is added later.
Not in code imported from linux. So why we cant fix xen specific code 
naming?


Below are the few examples
a. static struct iommu_domain *arm_smmu_get_domain(struct domain *d,...)
This function use of domain is confusing.
This is not linux function,

a function named arm_smmu_get_domain takes a parameter of domain which 
represents a virtual machine and returns an iommu_domain pointer.

while the file still has a structure arm_smmu_domain.
In what way this function naming explains itself?

If you want to take a cue from linux see this code below
structarm_smmu_domain *smmu_domain = to_smmu_domain(domain); => The 
naming is quite clear and not confusing.
Also If you see there are few functions in xen specifc smmu code which 
are named correctly

Look at arm_smmu_iommu_domain_init(struct domain *d)

But arm_smmu_iommu_domain_init(struct domain *d) and arm_smmu_get_domain 
naming dont match,  they are both referring to iommu_domain


So my _two cents_ on the current use of structures / functions and 
variable names which use domain in xen specific code.


b. Similarly contexts in arm_smmu_xen_domain structure is not coming 
from linux code

c. arm_smmu_assign_dev is a xen specific function so it can be changed
d. Why id arm_smmu_xen_domain named the way it is. Does linux code 
include _linux_ in any structure name?



Cheers,




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

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

[osstest service owner]

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

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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-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  844b86464a5cbfffb62b87808632018ca250d867
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   74 days
Failing since115733  2017-11-10 17:19:59 Z   67 days   79 attempts
Testing same since   117014  2017-12-08 19:11:23 Z   39 days   34 attempts


People who touched revisions under test:
  Kevin O'Connor 
  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 844b86464a5cbfffb62b87808632018ca250d867
Author: Paul Menzel 
Date:   Mon Oct 2 08:13:13 2017 +0200

docs/Download: Use more secure HTTPS URLs where possible

Signed-off-by: Paul Menzel 

commit df46d10c8a7b88eb82f3ceb2aa31782dee15593d
Author: Stefan Berger 
Date:   Tue Nov 14 15:03:47 2017 -0500

tpm: Add support for TPM2 ACPI table

Add support for the TPM2 ACPI table. If we find it and its
of the appropriate size, we can get the log_area_start_address
and log_area_minimum_size from it.

The latest version of the spec can be found here:

https://trustedcomputinggroup.org/tcg-acpi-specification/

Signed-off-by: Stefan Berger 

commit 0541f2f0f246e77d7c726926976920e8072d1119
Author: Kevin O'Connor 
Date:   Fri Nov 10 12:20:35 2017 -0500

paravirt: Only enable sercon in NOGRAPHIC mode if no other console specified

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  36c560e7f38130f12a36e8b66b0785fb655fe893
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z0 days
Testing same since   118110  2018-01-16 19:02:12 Z0 days5 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Wei Liu 

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



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

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

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

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


Not pushing.

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

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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  36c560e7f38130f12a36e8b66b0785fb655fe893
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z0 days
Testing same since   118110  2018-01-16 19:02:12 Z0 days4 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Wei Liu 

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



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

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

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

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


Not pushing.

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

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

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

[osstest service owner]

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

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  bdf693ee61b48d9c04799ba58dbf849220db0019
  Bug not present: 2dd3e229494649fcf3309f8e2ccecece2a2d1685
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/118131/


  commit bdf693ee61b48d9c04799ba58dbf849220db0019
  Author: Jonathan Ludlam 
  Date:   Thu Jan 11 17:47:58 2018 +
  
  tools/libxc: Multi modules support
  
  Signed-off-by: Jonathan Ludlam 
  Signed-off-by: Sergey Dyasli 
  Signed-off-by: Andrew Cooper 
  Signed-off-by: Wei Liu 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build
 --summary-out=tmp/118131.bisection-summary --basis-template=118105 
--blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build
Searching for failure / basis pass:
 118121 fail [host=laxton1] / 118105 ok.
Failure / basis pass flights: 118121 / 118105
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 2b033e396f4fa0981bae1213cdacd15775655a97 
36c560e7f38130f12a36e8b66b0785fb655fe893
Basis pass 2b033e396f4fa0981bae1213cdacd15775655a97 
e871e80c38547d9faefc6604532ba3e985e65873
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen.git#2b033e396f4fa0981bae1213cdacd15775655a97-2b033e396f4fa0981bae1213cdacd15775655a97
 
git://xenbits.xen.org/xen.git#e871e80c38547d9faefc6604532ba3e985e65873-36c560e7f38130f12a36e8b66b0785fb655fe893
Loaded 1001 nodes in revision graph
Searching for test results:
 118105 pass 2b033e396f4fa0981bae1213cdacd15775655a97 
e871e80c38547d9faefc6604532ba3e985e65873
 118110 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
36c560e7f38130f12a36e8b66b0785fb655fe893
 118114 pass 2b033e396f4fa0981bae1213cdacd15775655a97 
e871e80c38547d9faefc6604532ba3e985e65873
 118116 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
36c560e7f38130f12a36e8b66b0785fb655fe893
 118118 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
b95c86b01a8e25b72f3e1a1395c1b544a006abdb
 118119 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
7e98f196bc2450e8b229778f586ef960be1a3b71
 118113 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
36c560e7f38130f12a36e8b66b0785fb655fe893
 118120 pass 2b033e396f4fa0981bae1213cdacd15775655a97 
b7af6be266e3595d7fb925f6156d6732dc456df6
 118122 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
bdf693ee61b48d9c04799ba58dbf849220db0019
 118123 pass 2b033e396f4fa0981bae1213cdacd15775655a97 
83d6b08b8b6d9fa8048cff44372ec0b877bcabb7
 118121 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
36c560e7f38130f12a36e8b66b0785fb655fe893
 118124 pass 2b033e396f4fa0981bae1213cdacd15775655a97 
2dd3e229494649fcf3309f8e2ccecece2a2d1685
 118126 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
bdf693ee61b48d9c04799ba58dbf849220db0019
 118128 pass 2b033e396f4fa0981bae1213cdacd15775655a97 
2dd3e229494649fcf3309f8e2ccecece2a2d1685
 118129 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
bdf693ee61b48d9c04799ba58dbf849220db0019
 118130 pass 2b033e396f4fa0981bae1213cdacd15775655a97 
2dd3e229494649fcf3309f8e2ccecece2a2d1685
 118131 fail 2b033e396f4fa0981bae1213cdacd15775655a97 
bdf693ee61b48d9c04799ba58dbf849220db0019
Searching for interesting versions
 Result found: flight 118105 (pass), for basis pass
 Result found: flight 118110 (fail), for basis failure
 Repro found: flight 118114 (pass), for basis pass
 Repro found: flight 118116 (fail), for basis failure
 0 revisions at 2b033e396f4fa0981bae1213cdacd15775655a97 
2dd3e229494649fcf3309f8e2ccecece2a2d1685
No revisions left to test, checking graph state.
 Result found: flight 118124 (pass), for last pass
 Result found: flight 118126 (fail), for first failure
 Repro found: flight 118128 (pass), for last pass
 Repro found: flight 118129 (fail), for first failure
 Repro found: flight 118130 (pass), for last pass
 Repro found: flight 118131 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  bdf693ee61b48d9c04799ba58dbf849220db0019
  Bug not present: 2dd3e229494649fcf3309f8e2ccecece2a2d1685
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/118131/


  commit bdf693ee61b48d9c04799ba58dbf849220db0019
  Author: Jonathan Ludlam 
  Date:   Thu Jan 11 17:47:58 2018 +
  
  tools/libxc: 

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  36c560e7f38130f12a36e8b66b0785fb655fe893
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z0 days
Testing same since   118110  2018-01-16 19:02:12 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Wei Liu 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 5/5] xen/arm64: Implement branch predictor hardening for affected Cortex-A CPUs

[Stefano Stabellini]

On Tue, 16 Jan 2018, Julien Grall wrote:
> Cortex-A57, A72, A73 and A75 are susceptible to branch predictor
> aliasing and can theoritically be attacked by malicious code.
> 
> This patch implements a PSCI-based mitigation for these CPUs when
> available. The call into firmware will invalidate the branch predictor
> state, preventing any malicious entries from affection other victim
> contexts.
> 
> Ported from Linux 
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> branch kpti.
> 
>  Signed-off-by: Marc Zyngier 
>  Signed-off-by: Will Deacon 
> 
> This is part of XSA-254.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/arm64/bpi.S | 25 
>  xen/arch/arm/cpuerrata.c | 49 
> 
>  2 files changed, 74 insertions(+)
> 
> diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
> index 6cc2f17529..4b7f1dc21f 100644
> --- a/xen/arch/arm/arm64/bpi.S
> +++ b/xen/arch/arm/arm64/bpi.S
> @@ -56,6 +56,31 @@ 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)
> +
>  /*
>   * Local variables:
>   * mode: ASM
> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> index 76d98e771d..f1ea7f3c5b 100644
> --- a/xen/arch/arm/cpuerrata.c
> +++ b/xen/arch/arm/cpuerrata.c
> @@ -4,8 +4,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  
>  /* Override macros from asm/page.h to make them work with mfn_t */
>  #undef virt_to_mfn
> @@ -141,6 +143,31 @@ install_bp_hardening_vec(const struct 
> arm_cpu_capabilities *entry,
>  return ret;
>  }
>  
> +extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
> +
> +static int enable_psci_bp_hardening(void *data)
> +{
> +bool ret = true;
> +static bool warned = false;
> +
> +/*
> + * 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) )
> +ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
> +   __psci_hyp_bp_inval_end);
> +else 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;
> +}
> +
> +return !ret;
> +}
> +
>  #endif /* CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR */
>  
>  #define MIDR_RANGE(model, min, max) \
> @@ -205,6 +232,28 @@ static const struct arm_cpu_capabilities arm_errata[] = {
> (1 << MIDR_VARIANT_SHIFT) | 2),
>  },
>  #endif
> +#ifdef CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR
> +{
> +.capability = ARM_HARDEN_BRANCH_PREDICTOR,
> +MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
> +.enable = enable_psci_bp_hardening,
> +},
> +{
> +.capability = ARM_HARDEN_BRANCH_PREDICTOR,
> +MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
> +.enable = enable_psci_bp_hardening,
> +},
> +{
> +.capability = ARM_HARDEN_BRANCH_PREDICTOR,
> +MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
> +.enable = enable_psci_bp_hardening,
> +},
> +{
> +.capability = ARM_HARDEN_BRANCH_PREDICTOR,
> +MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
> +.enable = enable_psci_bp_hardening,
> +},

We need to add a basic description in the desc field as it is printed by
update_cpu_capabilities.


> +#endif
>  {},
>  };
>  
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 1/5] xen/arm: Introduce enable callback to enable a capabilities on each online CPU

[Stefano Stabellini]

On Tue, 16 Jan 2018, Julien Grall wrote:
> Once Xen knows what features/workarounds present on the platform, it
> might be necessary to configure each online CPU.
> 
> Introduce a new callback "enable" that will be called on each online CPU to
> configure the "capability".
> 
> The code is based on Linux v4.14 (where cpufeature.c comes from), the
> explanation of why using stop_machine_run is kept as we have similar
> problem in the future.
> 
> Lastly introduce enable_errata_workaround that will be called once CPUs
> have booted and before the hardware domain is created.
> 
> This is part of XSA-254.
> 
> Signed-of-by: Julien Grall 

If you took the code from Linux, you need to add the original
Signed-off-by from the Linux commit. Aside from that:

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/cpuerrata.c |  6 ++
>  xen/arch/arm/cpufeature.c| 29 +
>  xen/arch/arm/setup.c |  1 +
>  xen/include/asm-arm/cpuerrata.h  |  1 +
>  xen/include/asm-arm/cpufeature.h |  3 +++
>  5 files changed, 40 insertions(+)
> 
> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> index fe9e9facbe..772587c05a 100644
> --- a/xen/arch/arm/cpuerrata.c
> +++ b/xen/arch/arm/cpuerrata.c
> @@ -64,6 +64,12 @@ void check_local_cpu_errata(void)
>  {
>  update_cpu_capabilities(arm_errata, "enabled workaround for");
>  }
> +
> +void __init enable_errata_workarounds(void)
> +{
> +enable_cpu_capabilities(arm_errata);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
> index 479c9fb011..525b45e22f 100644
> --- a/xen/arch/arm/cpufeature.c
> +++ b/xen/arch/arm/cpufeature.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);
> @@ -40,6 +41,34 @@ void update_cpu_capabilities(const struct 
> arm_cpu_capabilities *caps,
>  }
>  
>  /*
> + * Run through the enabled capabilities and enable() it on all active
> + * CPUs.
> + */
> +void __init enable_cpu_capabilities(const struct arm_cpu_capabilities *caps)
> +{
> +for ( ; caps->matches; caps++ )
> +{
> +if ( !cpus_have_cap(caps->capability) )
> +continue;
> +
> +if ( caps->enable )
> +{
> +int ret;
> +
> +/*
> + * Use stop_machine_run() as it schedules the work allowing
> + * us to modify PSTATE, instead of on_each_cpu() which uses
> + * an IPI, giving us a PSTATE that disappears when we
> + * return.
> + */
> +ret = stop_machine_run(caps->enable, (void *)caps, NR_CPUS);
> +/* stop_machine_run should never fail at this stage of the boot. 
> */
> +BUG_ON(ret);
> +}
> +}
> +}
> +
> +/*
>   * Local variables:
>   * mode: C
>   * c-file-style: "BSD"
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 16a3b1be8e..032a6a882d 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -849,6 +849,7 @@ void __init start_xen(unsigned long boot_phys_offset,
>   * stop_machine (tasklets initialized via an initcall).
>   */
>  apply_alternatives_all();
> +enable_errata_workarounds();
>  
>  /* Create initial domain 0. */
>  /* The vGIC for DOM0 is exactly emulating the hardware GIC */
> diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
> index 8b158429c7..7de68361ff 100644
> --- a/xen/include/asm-arm/cpuerrata.h
> +++ b/xen/include/asm-arm/cpuerrata.h
> @@ -5,6 +5,7 @@
>  #include 
>  
>  void check_local_cpu_errata(void);
> +void enable_errata_workarounds(void);
>  
>  #ifdef CONFIG_HAS_ALTERNATIVE
>  
> diff --git a/xen/include/asm-arm/cpufeature.h 
> b/xen/include/asm-arm/cpufeature.h
> index f00b6dbd39..21c65e198c 100644
> --- a/xen/include/asm-arm/cpufeature.h
> +++ b/xen/include/asm-arm/cpufeature.h
> @@ -74,6 +74,7 @@ struct arm_cpu_capabilities {
>  const char *desc;
>  u16 capability;
>  bool (*matches)(const struct arm_cpu_capabilities *);
> +int (*enable)(void *); /* Called on every active CPUs */
>  union {
>  struct {/* To be used for eratum handling only */
>  u32 midr_model;
> @@ -85,6 +86,8 @@ struct arm_cpu_capabilities {
>  void update_cpu_capabilities(const struct arm_cpu_capabilities *caps,
>   const char *info);
>  
> +void enable_cpu_capabilities(const struct arm_cpu_capabilities *caps);
> +
>  #endif /* __ASSEMBLY__ */
>  
>  #endif
> -- 
> 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] 118113: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  36c560e7f38130f12a36e8b66b0785fb655fe893
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z0 days
Testing same since   118110  2018-01-16 19:02:12 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Wei Liu 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH v3] kexec-tools: Perform run-time linking of libxenctrl.so

[Daniel Kiper]

On Fri, Jan 12, 2018 at 03:21:13PM -0600, Eric DeVolder wrote:
> When kexec is utilized in a Xen environment, it has an explicit
> run-time dependency on libxenctrl.so. This dependency occurs
> during the configure stage and when building kexec-tools.
>
> When kexec is utilized in a non-Xen environment (either bare
> metal or KVM), the configure and build of kexec-tools omits
> any reference to libxenctrl.so.

[...]

Wow! What a long story! Patch looks quite good. Just a few nitpicks.
If you fix them then you can add Reviewed-by: Daniel Kiper 

to the next version.

> Signed-off-by: Eric DeVolder 
> ---
> v1: 29nov2017
>  - Daniel Kiper suggested Debian's libxen package of libraries,
>but I did not find similar package on most other systems.
>
> v2: 14dec2017
>  - Reposted to kexec and xen-devel mailing lists
>
> v3: 12jan2018
>  - Incorporated feedback from Daniel Kiper.
>Configure changes for --with-xen=dl, style problems corrected.
>Extensive testing of the new mode.
> ---
>  configure.ac   | 27 ++
>  kexec/Makefile |  1 +
>  kexec/arch/i386/crashdump-x86.c|  4 +--
>  kexec/arch/i386/kexec-x86-common.c |  4 +--
>  kexec/crashdump-xen.c  |  4 +--
>  kexec/kexec-xen.c  | 41 -
>  kexec/kexec-xen.h  | 73 
> ++
>  7 files changed, 138 insertions(+), 16 deletions(-)
>  create mode 100644 kexec/kexec-xen.h
>
> diff --git a/configure.ac b/configure.ac
> index 208dc0a..4dab57f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -167,12 +167,27 @@ if test "$with_xen" = yes ; then
>   AC_CHECK_HEADER(xenctrl.h,
>   [AC_CHECK_LIB(xenctrl, xc_kexec_load, ,
>   AC_MSG_NOTICE([Xen support disabled]))])
> - if test "$ac_cv_lib_xenctrl_xc_kexec_load" = yes ; then
> - AC_CHECK_LIB(xenctrl, xc_kexec_status,
> - AC_DEFINE(HAVE_KEXEC_CMD_STATUS, 1,
> - [The kexec_status call is available]),
> - AC_MSG_NOTICE([The kexec_status call is not 
> available]))
> - fi
> +fi
> +
> +dnl Link libxenctrl.so at run-time rather than build-time
> +if test "$with_xen" = dl ; then
> + AC_CHECK_HEADER(dlfcn.h,
> + [AC_CHECK_LIB(dl, dlopen, ,
> + AC_MSG_ERROR([Dynamic library linking not available]))],
> + AC_MSG_ERROR([Dynamic library linking not available]))

I think that this error message should be like this:
  Dynamic library linking header not available

> + AC_DEFINE(CONFIG_LIBXENCTRL_DL, 1, [Define to 1 to link libxenctrl.so 
> at run-time rather than build-time])
> + AC_CHECK_HEADER(xenctrl.h,
> + [AC_CHECK_LIB(xenctrl, xc_kexec_load,
> + AC_DEFINE(HAVE_LIBXENCTRL, 1, ), # required define, and prevent 
> -lxenctrl
> + AC_MSG_NOTICE([Xen support disabled]))])
> +fi
> +
> +dnl Check for the Xen kexec_status hypercall - reachable from 
> --with-xen=yes|dl
> +if test "$ac_cv_lib_xenctrl_xc_kexec_load" = yes ; then
> + AC_CHECK_LIB(xenctrl, xc_kexec_status,
> + AC_DEFINE(HAVE_KEXEC_CMD_STATUS, 1,
> + [The kexec_status call is available]),
> + AC_MSG_NOTICE([The kexec_status call is not available]))
>  fi
>
>  dnl ---Sanity checks
> diff --git a/kexec/Makefile b/kexec/Makefile
> index 2b4fb3d..8871731 100644
> --- a/kexec/Makefile
> +++ b/kexec/Makefile
> @@ -36,6 +36,7 @@ dist += kexec/Makefile  
> \
>   kexec/kexec-elf-boot.h  \
>   kexec/kexec-elf.h kexec/kexec-sha256.h  \
>   kexec/kexec-zlib.h kexec/kexec-lzma.h   \
> + kexec/kexec-xen.h   
> \

Could you fix backslash alignment? Maybe in separate patch. It can be
part of this series.

>   kexec/kexec-syscall.h kexec/kexec.h kexec/kexec.8
>
>  dist += kexec/proc_iomem.c
> diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
> index 69a063a..a948d9f 100644
> --- a/kexec/arch/i386/crashdump-x86.c
> +++ b/kexec/arch/i386/crashdump-x86.c
> @@ -44,9 +44,7 @@
>  #include "kexec-x86.h"
>  #include "crashdump-x86.h"
>

Please remove this blank line...

> -#ifdef HAVE_LIBXENCTRL
> -#include 
> -#endif /* HAVE_LIBXENCTRL */
> +#include "../../kexec-xen.h"
>

...and this... Same things below... This was done to separate
conditional include from unconditional ones. So, blank lines
after your patch are no longer needed.

>  #include "x86-linux-setup.h"
>
> diff --git a/kexec/arch/i386/kexec-x86-common.c 
> b/kexec/arch/i386/kexec-x86-common.c
> index be03618..b44c8b7 100644
> --- a/kexec/arch/i386/kexec-x86-common.c
> +++ 

Re: [Xen-devel] [PATCH 3/5] xen/arm: cpuerrata: Add MIDR_ALL_VERSIONS

[Stefano Stabellini]

On Tue, 16 Jan 2018, Julien Grall wrote:
> Introduce a new macro MIDR_ALL_VERSIONS to match all variant/revision of a
> given CPU model.
> 
> This is part of XSA-254.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/cpuerrata.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> index 772587c05a..c50d3331f2 100644
> --- a/xen/arch/arm/cpuerrata.c
> +++ b/xen/arch/arm/cpuerrata.c
> @@ -7,6 +7,12 @@
>  .midr_range_min = min,  \
>  .midr_range_max = max
>  
> +#define MIDR_ALL_VERSIONS(model)\
> +.matches = is_affected_midr_range,  \
> +.midr_model = model,\
> +.midr_range_min = 0,\
> +.midr_range_max = (MIDR_VARIANT_MASK | MIDR_REVISION_MASK)
> +
>  static bool __maybe_unused
>  is_affected_midr_range(const struct arm_cpu_capabilities *entry)
>  {
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 2/5] xen/arm64: Add missing MIDR values for Cortex-A72, A73 and A75

[Stefano Stabellini]

On Tue, 16 Jan 2018, Julien Grall wrote:
> Cortex-A72, A73 and A75 MIDR will be used to a follow-up for hardening
> the branch predictor.
> 
> This is part of XSA-254.
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 


> ---
>  xen/include/asm-arm/processor.h | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index 65eb1071e1..3edab1b893 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -47,10 +47,16 @@
>  #define ARM_CPU_PART_CORTEX_A15 0xC0F
>  #define ARM_CPU_PART_CORTEX_A53 0xD03
>  #define ARM_CPU_PART_CORTEX_A57 0xD07
> +#define ARM_CPU_PART_CORTEX_A72 0xD08
> +#define ARM_CPU_PART_CORTEX_A73 0xD09
> +#define ARM_CPU_PART_CORTEX_A75 0xD0A
>  
>  #define MIDR_CORTEX_A15 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
> ARM_CPU_PART_CORTEX_A15)
>  #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
> ARM_CPU_PART_CORTEX_A53)
>  #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
> ARM_CPU_PART_CORTEX_A57)
> +#define MIDR_CORTEX_A72 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
> ARM_CPU_PART_CORTEX_A72)
> +#define MIDR_CORTEX_A73 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
> ARM_CPU_PART_CORTEX_A73)
> +#define MIDR_CORTEX_A75 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
> ARM_CPU_PART_CORTEX_A75)
>  
>  /* MPIDR Multiprocessor Affinity Register */
>  #define _MPIDR_UP   (30)
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH v8 12/17] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

[Andrew Cooper]

On 15/01/18 12:09, Jan Beulich wrote:
 On 12.01.18 at 19:01,  wrote:
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -668,6 +668,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>  set_processor_id(0);
>>  set_current(INVALID_VCPU); /* debug sanity. */
>>  idle_vcpu[0] = current;
>> +init_shadow_spec_ctrl_state();
> Considering the strict need to fill struct cpu_info fields early on (also
> in my SP3 band-aid) I wonder whether we wouldn't be better off
> uniformly memset()-ing the whole structure first thing here and in
> start_secondary(). But this is just a remark, not necessarily
> something to be done in this patch.

One thing I didn't quite get to in my KAISER series actually switched to
having BSP fill in the entire top-of-stack block for APs when the stack
was allocated.

I think that would be a good change in a future patch.

>
>> @@ -586,6 +611,10 @@ ENTRY(double_fault)
>>  movl  $TRAP_double_fault,4(%rsp)
>>  /* Set AC to reduce chance of further SMAP faults */
>>  SAVE_ALL STAC
>> +
>> +SPEC_CTRL_ENTRY_FROM_INTR /* Req: %rsp=regs Clob: acd */
>> +/* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */
> Is it actually useful to do _anything_ in the double fault handler?

Typically no, but then again we hope never to execute this code.

OTOH, we would need to do this if we ever get around to doing espfix64.

>
>> +.macro DO_SPEC_CTRL_ENTRY maybexen:req ibrs_val:req
>> +/*
>> + * Requires %rsp=regs (also cpuinfo if !maybexen)
>> + * Clobbers %rax, %rcx, %rdx
>> + *
>> + * PV guests can't update MSR_SPEC_CTRL behind Xen's back, so no need to 
>> read
>> + * it back.  Entries from guest context need to clear SPEC_CTRL shadowing,
>> + * while entries from Xen must leave shadowing in its current state.
>> + */
>> +mov $MSR_SPEC_CTRL, %ecx
>> +
>> +.if \maybexen
>> +cmpw $__HYPERVISOR_CS, UREGS_cs(%rsp)
> I see you've changed to cmpw here. To eliminate your length-
> changing-prefix concern, how about using testb instead to
> just evaluate RPL or the selector, as I'm doing in the SP3
> band-aid?

That would be better still.

~Andrew

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

[Xen-devel] [qemu-mainline test] 118102: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt  broken
 build-armhf-libvirt   5 host-build-prep  fail REGR. vs. 117930
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 117930
 build-arm64   6 xen-build  fail in 118091 REGR. vs. 117930

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat  fail pass in 118091

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked in 118091 n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked in 118091 n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked in 118091 n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked in 118091 n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 118091 like 
117930
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 118091 like 
117930
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 118091 like 
117930
 test-armhf-armhf-libvirt13 migrate-support-check fail in 118091 never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 118091 never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 118091 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 117930
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 117930
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 117930
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-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:
 qemuu 

Re: [Xen-devel] [PATCH v8 11/17] x86: Protect unaware domains from meddling hyperthreads

[Andrew Cooper]

On 15/01/18 11:26, Jan Beulich wrote:
 On 12.01.18 at 19:01,  wrote:
>> --- a/xen/include/asm-x86/spec_ctrl.h
>> +++ b/xen/include/asm-x86/spec_ctrl.h
>> @@ -20,8 +20,29 @@
>>  #ifndef __X86_SPEC_CTRL_H__
>>  #define __X86_SPEC_CTRL_H__
>>  
>> +#include 
>> +
>>  void init_speculation_mitigations(void);
>>  
>> +/*
>> + * For guests which know about IBRS but are not told about STIBP running on
>> + * hardware supporting hyperthreading, the guest doesn't know to protect
>> + * itself fully.  (Such a guest won't be permitted direct access to the 
>> MSR.)
>> + * Have Xen fill in the gaps, so an unaware guest can't be interfered with 
>> by
>> + * a meddling guest on an adjacent hyperthread.
>> + */
>> +static inline unsigned int spec_ctrl_host_val(const struct domain *d,
>> +  unsigned int guest_val)
>> +{
>> +const struct cpuid_policy *cp = d->arch.cpuid;
>> +
>> +if ( !cp->feat.stibp && cpu_has_stibp &&
>> + !(guest_val & (SPEC_CTRL_IBRS | SPEC_CTRL_STIBP)) )
>> +return SPEC_CTRL_STIBP;
>> +else
>> +return guest_val;
>> +}
> The comment's "won't be permitted direct access" can be verified
> by looking at patch 10, but where's the HT dependency here (or
> in another patch)? For now it looks to me as if you enabled this
> behind-the-back protection even in the non-HT case.

The problem is that this is all speculative programming (pardon the
pun), without answers to several questions, and without microcode to
actually try it out on.  I guess I will have to unwind the changes, and
hope there isn't some leaky record of this train of thought somewhere...
(Sorry - I couldn't resist!)

I've guessed since the very first spec I saw that STIBP was expected not
always to be advertised, and the fact that there are two CPUID bits
means that, whether the situation exists in practice, it is possible to
level a VM into such a state.

Therefore, Xen should provide a defence against such a levelling so an
unassuming guest doesn't get caught out.

The latest intel spec (published since I posted v8) says:

"These include processors on which Intel Hyper-Threading Technology is
not enabled and those that do not share indirect branch predictors
between logical processors. To simplify software enabling and enhance
workload migration, STIBP may be enumerated (and setting
IA32_SPEC_CTRL.STIBP allowed) on such processors."

which I take to mean "for microcode simplicity, we will always advertise
it on HT-capable hardware", and

"A processor may enumerate support for the IA32_SPEC_CTRL MSR (e.g., by
enumerating CPUID.(EAX=7H,ECX=0):EDX[26] as 1) but not for STIBP
(CPUID.(EAX=7H,ECX=0):EDX[27] is enumerated as 0). On such processors,
execution of WRMSR to IA32_SPEC_CTRL ignores the value of bit 1 (STIBP)
and does not cause a general-protection exception (#GP) if bit 1 of the
source operand is set. It is expected that this fact will simplify
virtualization in some cases."

which I take to mean "non-HT hardware won't enumerate STIBP, but will
cope with an OS trying to use it".

An alternative to the current levelling logic would be to treat STIBP as
a Special Bit (in CPUID terms, like OSXSAVE/etc) and unconditionally set
it equal to IBRS, irrespective of the toolstack setting.  That way,
migration between HT and non-HT hardware is safe and a VM which chooses
to use STIBP will work even on non-HT hardware which simply ignores the
request.

~Andrew

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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  36c560e7f38130f12a36e8b66b0785fb655fe893
baseline version:
 xen  e871e80c38547d9faefc6604532ba3e985e65873

Last test of basis   118105  2018-01-16 17:04:09 Z0 days
Testing same since   118110  2018-01-16 19:02:12 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Bob Moore 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jon Ludlam 
  Jonathan Ludlam 
  Lv Zheng 
  Rafael J. Wysocki 
  Roger Pau Monne 
  Roger Pau Monné 
  Sergey Dyasli 
  Wei Liu 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [libvirt test] 118006: regressions - FAIL

[Ian Jackson]

Jim Fehlig writes ("Re: [Xen-devel] [libvirt test] 118006: regressions - FAIL"):
> Should be fixed by
> https://libvirt.org/git/?p=libvirt.git;a=commit;h=66aa7e02c69cd90995f29dbfaca6c659ffe11693

Thanks for letting us know.

Ian.

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

Re: [Xen-devel] [PATCH v3 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

[Wei Liu]

On Tue, Jan 16, 2018 at 05:28:40PM +, Andy Smith wrote:
> Hi Jan,
> 
> On Tue, Jan 16, 2018 at 08:21:52AM -0700, Jan Beulich wrote:
> > This is a very simplistic change limiting the amount of memory a running
> > 64-bit PV guest has mapped (and hence available for attacking): Only the
> > mappings of stack, IDT, and TSS are being cloned from the direct map
> > into per-CPU page tables.
> 
> Can this be used with Comet/Vixen to further protect PV guests? i.e.
> if the shim hypervisor has these changes then will it also limit
> what a process in the PV guest can see in that shim hypervisor,
> which therefore protects its own guest kernel a bit too?
> 

Yes, but please be warned that the guest is very very slow. I don't
think XPTI + shim is very usable at this stage.

If you're interested in trying that out, check out staging branch and
build a shim from there.

Wei.

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

Re: [Xen-devel] Rudolph: merging Vixen and Comet

[Wei Liu]

On Tue, Jan 16, 2018 at 07:23:43PM +0100, Anthony Liguori wrote:
> On Tue, Jan 16, 2018 at 5:51 PM, George Dunlap  wrote:
> > On Tue, Jan 16, 2018 at 4:42 PM, Doug Goldstein  wrote:
> >> On 1/12/18 8:20 AM, Wei Liu wrote:
> >>> On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote:
>  On Fri, Jan 12, Wei Liu wrote:
> 
> >   Vixen  Comet
> > Guest console Output onlyBi-directional
> 
>  With the proper patch input works for Vixen. Unless this item mean
>  something else.
> >>>
> >>> Vixen means the version upstream put into the advisory. The patch you
> >>> talked about is not provided in that branch.
> >>>
> >>> Wei.
> >>>
> >>
> >> Can we merge some fixes people have proposed into the Vixen branch?
> >> There are a number of virtualization providers that have rolled forward
> >> with Vixen. They are clearly contributing patches on the ML and having
> >> one place to work together would be nice.
> >
> > If Anthony is OK, we can call him the "maintainer" for the Vixen
> > branch; the committers can check in anything that has his Ack to the
> > Vixen branch, and the Security Team can post new signed tags when
> > appropriate.
> >
> > It looked like Anthony had some issues with the most recent patch though.
> 
> I am very happy to review stuff for the Vixen branch but I'm even more
> eager to get Vixen and Comet merged.  Getting Comet into staging will
> help out us a lot.
> 

I just pushed a bunch of comet patches to staging. I will push some of
the pending fixes tomorrow.

Wei.

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

Re: [Xen-devel] Rudolph: merging Vixen and Comet

[Wei Liu]

On Tue, Jan 16, 2018 at 05:55:38PM +, Andrew Cooper wrote:
> On 16/01/18 17:11, Jan Beulich wrote:
>  On 16.01.18 at 17:52,  wrote:
> >> I've pushed comet-for-unstable to my xenbits/xen.git. That branch is a
> >> forward port of 4.10.0-shim-comet branch to staging.
> >>
> >> https://xenbits.xen.org/gitweb/?p=people/liuw/xen.git;a=shortlog;h=refs/head
> >>  
> >> s/comet-for-unstable
> >>
> >> There will be follow-up patches to fix some bugs, which have not been
> >> pushed to that branch yet:
> >>
> >> 1. Michael Young's -xen-attach patch
> >> 2. Roger's patch to move mapping vcpu_info earlier
> >>
> >> (Due to things go in parallel, they are probably not yet on list)
> >>
> >> Jan and Andrew, please check the branch and explicitly ack the action of
> >> committing that branch.
> > Looks plausible, but of course I don't have the time to go through
> > the individual commit. "No objection" is the best you're going to get,
> > and here you go: No objection.
> 
> Throw it in.  It is easier to iterate on fixes with some stuff committed
> to being with.
> 

Thanks. I rebased my branch and fixed two trivial conflicts. Built and
ran some smoke test and pushed the code to staging.

Wei.

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

Re: [Xen-devel] [PATCH 2/2] xen-netfront: Fix race between device setup and open

[Boris Ostrovsky]

On 01/11/2018 04:36 AM, Ross Lagerwall wrote:
> When a netfront device is set up it registers a netdev fairly early on,
> before it has set up the queues and is actually usable. A userspace tool
> like NetworkManager will immediately try to open it and access its state
> as soon as it appears. The bug can be reproduced by hotplugging VIFs
> until the VM runs out of grant refs. It registers the netdev but fails
> to set up any queues (since there are no more grant refs). In the
> meantime, NetworkManager opens the device and the kernel crashes trying
> to access the queues (of which there are none).
>
> Fix this in two ways:
> * For initial setup, register the netdev much later, after the queues
> are setup. This avoids the race entirely.
> * During a suspend/resume cycle, the frontend reconnects to the backend
> and the queues are recreated. It is possible (though highly unlikely) to
> race with something opening the device and accessing the queues after
> they have been destroyed but before they have been recreated. Extend the
> region covered by the rtnl semaphore to protect against this race. There
> is a possibility that we fail to recreate the queues so check for this
> in the open function.
>
> Signed-off-by: Ross Lagerwall 

Reviewed-by: Boris Ostrovsky 



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

Re: [Xen-devel] [RFC 02/11] acpi: arm: API to query estimated size of hardware domain's IORT

[Julien Grall]

Hi Manish,

On 02/01/18 09:28, manish.ja...@linaro.org wrote:

From: Manish Jaggi 

  Code to query estimated IORT size for hardware domain.


Please avoid indenting the commit message.


  IORT for hardware domain is generated using the requesterId and deviceId map.

  Signed-off-by: Manish Jaggi 
---
  xen/arch/arm/domain_build.c |  12 -
  xen/drivers/acpi/arm/Makefile   |   1 +
  xen/drivers/acpi/arm/gen-iort.c | 101 
  xen/include/acpi/gen-iort.h |   6 +++
  4 files changed, 119 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c74f4dd69d..f5d5e3d271 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -14,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -1799,7 +1800,7 @@ static int acpi_create_fadt(struct domain *d, struct 
membank tbl_add[])
  
  static int estimate_acpi_efi_size(struct domain *d, struct kernel_info *kinfo)

  {
-size_t efi_size, acpi_size, madt_size;
+size_t efi_size, acpi_size, madt_size, iort_size;


Rather than introduce a variable for 10 instructions, you can rename 
madt_size so it can be re-used. I would be ok for this to be in the same 
patch (providing a proper commit message).



  u64 addr;
  struct acpi_table_rsdp *rsdp_tbl;
  struct acpi_table_header *table;
@@ -1840,6 +1841,15 @@ static int estimate_acpi_efi_size(struct domain *d, 
struct kernel_info *kinfo)
  acpi_os_unmap_memory(table, sizeof(struct acpi_table_header));
  
  acpi_size += ROUNDUP(sizeof(struct acpi_table_rsdp), 8);

+
+if( estimate_iort_size(_size) )


Coding style.


+{
+printk("Unable to get hwdom iort size\n");
+return -EINVAL;
+}
+
+acpi_size += ROUNDUP(iort_size, 8);
+
  d->arch.efi_acpi_len = PAGE_ALIGN(ROUNDUP(efi_size, 8)
+ ROUNDUP(acpi_size, 8));
  
diff --git a/xen/drivers/acpi/arm/Makefile b/xen/drivers/acpi/arm/Makefile

index 046fad5e3d..13f1a9159f 100644
--- a/xen/drivers/acpi/arm/Makefile
+++ b/xen/drivers/acpi/arm/Makefile
@@ -1 +1,2 @@
  obj-y = ridmap.o
+obj-y += gen-iort.o
diff --git a/xen/drivers/acpi/arm/gen-iort.c b/xen/drivers/acpi/arm/gen-iort.c
new file mode 100644
index 00..3fc32959c6
--- /dev/null
+++ b/xen/drivers/acpi/arm/gen-iort.c
@@ -0,0 +1,101 @@
+/*
+ * xen/drivers/acpi/arm/gen-iort.c
+ *
+ * Code to generate IORT for hardware domain using the requesterId
+ * and deviceId map.
+ *
+ * Manish Jaggi 
+ * Copyright (c) 2018 Linaro.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.


The license is wrong (see patch #1).


+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+
+/*
+ * Size of hardware domains iort is calulcated based on the number of


s/iort/IORT/
s/calulcated/calculated/


+ * mappings in the requesterId - deviceId mapping list.
+ */
+int estimate_iort_size(size_t *iort_size)
+{
+int count = 0;
+int pcirc_count = 0;
+int itsg_count = 0;
+uint64_t *pcirc_array;
+uint64_t *itsg_array;


What is the rationale to store the address directly rather than "void 
*"? This would avoid the cast in the code.



+struct rid_deviceid_map *rmap;
+


A bit more documention of this function would be appreciated. For 
instance, the rationale between browsing the list twice for allocation.


I actually do think this might be avoidable by storing a bit more 
information from the IORT. From the table you can easily deduced the 
number of root complex and ITS group. They could be store with the rest 
of information.


For the rest of the function, please be careful on the coding style. I 
am not going to point them all, but I expect you to fix them.



+list_for_each_entry(rmap, _deviceid_map_list, entry)
+count++;
+
+pcirc_array = xzalloc_bytes(sizeof(uint64_t)*count);
+if ( !pcirc_array )
+return -ENOMEM;
+
+itsg_array = xzalloc_bytes(sizeof(uint64_t)*count);
+if ( !itsg_array )
+return -ENOMEM;
+
+list_for_each_entry(rmap, _deviceid_map_list, entry)
+{
+int i = 0;
+
+for (i=0; i <= pcirc_count; i++)
+{
+if ( pcirc_array[i] == (uint64_t)rmap->pcirc_node )
+break;
+if ( i == pcirc_count )
+{
+pcirc_array[i] = (uint64_t)rmap->pcirc_node;
+pcirc_count++;
+break;
+}
+

Re: [Xen-devel] [PATCH v3 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

[Andrew Cooper]

On 16/01/18 17:28, Andy Smith wrote:
> Hi Jan,
>
> On Tue, Jan 16, 2018 at 08:21:52AM -0700, Jan Beulich wrote:
>> This is a very simplistic change limiting the amount of memory a running
>> 64-bit PV guest has mapped (and hence available for attacking): Only the
>> mappings of stack, IDT, and TSS are being cloned from the direct map
>> into per-CPU page tables.
> Can this be used with Comet/Vixen to further protect PV guests? i.e.
> if the shim hypervisor has these changes then will it also limit
> what a process in the PV guest can see in that shim hypervisor,
> which therefore protects its own guest kernel a bit too?

Yes.

~Andrew

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

Re: [Xen-devel] [RFC 01/11] acpi: arm: Public API for populating and query based on requesterid

[Julien Grall]

Hi Manish,

I sent the previous e-mail too soon.

On 02/01/18 09:27, manish.ja...@linaro.org wrote:

From: Manish Jaggi 

  Public API to populate and query map between requester id and
  streamId/DeviceID. IORT is parsed one time (outside this patch)
  and two lists are created one for mapping between reuesterId and streamid
  and another between requesterID and deviceID.

  These lists eliminate the need to reparse IORT for querying streamid
  or deviceid using requesterid.

  Signed-off-by: Manish Jaggi 
---
  xen/drivers/acpi/Makefile |   1 +
  xen/drivers/acpi/arm/Makefile |   1 +


We have a directory arch/arm/acpi/. So please move all your code there.


  xen/drivers/acpi/arm/ridmap.c | 124 ++
  xen/include/acpi/ridmap.h |  77 ++


No need to make this header available in common. That should go under 
asm-arm/acpi/



  4 files changed, 203 insertions(+)

diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index 444b11d583..80a074e007 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -1,6 +1,7 @@
  subdir-y += tables
  subdir-y += utilities
  subdir-$(CONFIG_X86) += apei
+subdir-$(CONFIG_ARM) += arm
  
  obj-bin-y += tables.init.o

  obj-$(CONFIG_NUMA) += numa.o
diff --git a/xen/drivers/acpi/arm/Makefile b/xen/drivers/acpi/arm/Makefile
new file mode 100644
index 00..046fad5e3d
--- /dev/null
+++ b/xen/drivers/acpi/arm/Makefile
@@ -0,0 +1 @@
+obj-y = ridmap.o
diff --git a/xen/drivers/acpi/arm/ridmap.c b/xen/drivers/acpi/arm/ridmap.c
new file mode 100644
index 00..2c3a8876ea
--- /dev/null
+++ b/xen/drivers/acpi/arm/ridmap.c
@@ -0,0 +1,124 @@
+/*
+ * xen/drivers/acpi/arm/ridmap.c
+ *
+ * Public API to populate and query map between requester id and
+ * streamId/DeviceID


I don't care whether you use deviceID or DeviceID but please stay 
consistent with the naming.



+ *
+ * Manish Jaggi 
+ * Copyright (c) 2018 Linaro.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.


Xen is GPLv2 only and hence the copyright wrong. You want to use:

This program is free software; you can redistribute it and/or modify it
under the terms and conditions of the GNU General Public License,
version 2, as published by the Free Software Foundation.


+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct list_head rid_streamid_map_list;
+struct list_head rid_deviceid_map_list;


Please drop _list. This is pointless to know that when you can discover it.

Also, can you explain the rationale of using an unsorted list over 
another structure? Along that please give an idea how often and where 
the query API will be used.



+
+void init_ridmaps(void)


This likely need to be __init.


+{
+INIT_LIST_HEAD(_deviceid_map_list);
+INIT_LIST_HEAD(_streamid_map_list);
+}


This function is not necessary. Declaring 
LIST_HEAD(rid_streamid_map_list) will do the trick.



+
+int add_rid_streamid_map(struct acpi_iort_node *pcirc_node,


Ditto.


+ struct acpi_iort_node *smmu_node,
+ u32 input_base, u32 output_base, u32 id_count)


u32 & co should not be used in new code (unless imported from Linux). 
Please use uint32_t & co.



+{
+struct rid_streamid_map *rid_map;


Newline here as it should be between after declarations.



+rid_map = xzalloc(struct rid_streamid_map);
+
+if (!rid_map)


This should be ( ... ).


+return -ENOMEM;


You either return -ENOMEM or 0 in this function. It sounds like to me 
that bool would be the best.



+
+rid_map->idmap.input_base = input_base;
+rid_map->idmap.output_base = output_base;
+rid_map->idmap.id_count = id_count;
+rid_map->pcirc_node = pcirc_node;
+rid_map->smmu_node = smmu_node;
+
+list_add_tail(_map->entry, _streamid_map_list);


Newline here.


+return 0;
+}
+
+int add_rid_deviceid_map(struct acpi_iort_node *pcirc_node,
+ struct acpi_iort_node *its_node,
+ u32 input_base, u32 output_base, u32 id_count)


s/u*/uint_/


+{
+struct rid_deviceid_map *rid_map;


Newline here.


+rid_map = xzalloc(struct rid_deviceid_map);
+
+if (!rid_map)


Coding style.


+return -ENOMEM;
+
+rid_map->idmap.input_base = input_base;
+rid_map->idmap.output_base = output_base;
+rid_map->idmap.id_count = id_count;
+rid_map->pcirc_node = pcirc_node;
+

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

[osstest service owner]

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

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  e871e80c38547d9faefc6604532ba3e985e65873
baseline version:
 xen  bd61fe94bee0556bc2f64999a4a8315b93f90f21

Last test of basis   118056  2018-01-15 14:01:28 Z1 days
Testing same since   118105  2018-01-16 17:04:09 Z0 days1 attempts


People who touched revisions under test:
  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
   bd61fe94be..e871e80c38  e871e80c38547d9faefc6604532ba3e985e65873 -> smoke

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

Re: [Xen-devel] Rudolph: merging Vixen and Comet

[Anthony Liguori]

On Tue, Jan 16, 2018 at 5:51 PM, George Dunlap  wrote:
> On Tue, Jan 16, 2018 at 4:42 PM, Doug Goldstein  wrote:
>> On 1/12/18 8:20 AM, Wei Liu wrote:
>>> On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote:
 On Fri, Jan 12, Wei Liu wrote:

>   Vixen  Comet
> Guest console Output onlyBi-directional

 With the proper patch input works for Vixen. Unless this item mean
 something else.
>>>
>>> Vixen means the version upstream put into the advisory. The patch you
>>> talked about is not provided in that branch.
>>>
>>> Wei.
>>>
>>
>> Can we merge some fixes people have proposed into the Vixen branch?
>> There are a number of virtualization providers that have rolled forward
>> with Vixen. They are clearly contributing patches on the ML and having
>> one place to work together would be nice.
>
> If Anthony is OK, we can call him the "maintainer" for the Vixen
> branch; the committers can check in anything that has his Ack to the
> Vixen branch, and the Security Team can post new signed tags when
> appropriate.
>
> It looked like Anthony had some issues with the most recent patch though.

I am very happy to review stuff for the Vixen branch but I'm even more
eager to get Vixen and Comet merged.  Getting Comet into staging will
help out us a lot.

Regards,

Anthony Liguori

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

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

Re: [Xen-devel] [PATCH v3 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

[George Dunlap]

On Tue, Jan 16, 2018 at 5:28 PM, Andy Smith  wrote:
> Hi Jan,
>
> On Tue, Jan 16, 2018 at 08:21:52AM -0700, Jan Beulich wrote:
>> This is a very simplistic change limiting the amount of memory a running
>> 64-bit PV guest has mapped (and hence available for attacking): Only the
>> mappings of stack, IDT, and TSS are being cloned from the direct map
>> into per-CPU page tables.
>
> Can this be used with Comet/Vixen to further protect PV guests? i.e.
> if the shim hypervisor has these changes then will it also limit
> what a process in the PV guest can see in that shim hypervisor,
> which therefore protects its own guest kernel a bit too?

Technically, yes, it should.

However,
 1) It should be unnecessary.  If you're running PV with the
"bandaid", you should be reasonably safe without using the shim
 2) The shim adds nearly 40% overhead in my words-case tests; and so
does the bandaid.  Together I think your performance would be pretty
terrible.

 -George

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

Re: [Xen-devel] [xen-unstable test] 118078: regressions - FAIL

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 16 January 2018 09:27
> To: 'Jan Beulich' 
> Cc: xen-devel ; osstest-
> ad...@xenproject.org
> Subject: Re: [Xen-devel] [xen-unstable test] 118078: regressions - FAIL
> 
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 16 January 2018 08:58
> > To: Paul Durrant 
> > Cc: xen-devel ; osstest-
> > ad...@xenproject.org
> > Subject: Re: [Xen-devel] [xen-unstable test] 118078: regressions - FAIL
> >
> > >>> On 16.01.18 at 09:43,  wrote:
> > > flight 118078 xen-unstable real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/118078/
> > >
> > > Regressions :-(
> > >
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > >  build-arm64-pvops 6 kernel-build fail REGR. vs. 
> > > 118003
> > >  test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR.
> vs.
> > 118003
> >
> > Paul,
> >
> > is this last one something you could look into?
> >
> > (XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 sp: 0
> > build: 1db0
> > (XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3
> > (XEN) d4v0: VIRIDIAN VP_ASSIST_PAGE: enabled: 1 pfn: 3fffe
> > (XEN) domain_crash called from viridian.c:452
> > (XEN) Domain 4 (vcpu#0) crashed on cpu#1:
> > (XEN) [ Xen-4.11-unstable  x86_64  debug=y   Not tainted ]
> > (XEN) CPU:1
> > (XEN) RIP:0010:[]
> > (XEN) RFLAGS: 0286   CONTEXT: hvm guest (d4v0)
> > (XEN) rax:    rbx: f800027f7e80   rcx: 0001
> > (XEN) rdx:    rsi: fa800129d040   rdi: f80002805c40
> > (XEN) rbp: 0080   rsp: f880009b0d80   r8:
> 
> > (XEN) r9:  f800027f7e80   r10: fa800129d040   r11: f800027f7e90
> > (XEN) r12: f88129a0   r13: f800028b9be0   r14: fa8001239b30
> > (XEN) r15: f8b96080   cr0: 80050031   cr4:
> 06b8
> > (XEN) cr3: 00187000   cr2: 
> > (XEN) fsb:    gsb: f800027f7d00   gss: f800027f7d00
> > (XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010
> >
> > I.e. the domain_crash() in viridian_start_apic_assist().
> >
> 
> Yes, I'll have a look at that.

No real clue about this as yet. It is odd that the guest has only set up one of 
the APIC assist pages and yet has taken an interrupt...

Jan 16 01:46:05.691223 (XEN) Dumping guest's current state at key_handler...
Jan 16 01:46:05.691265 (XEN) Size of VMCB = 4096, paddr = 00020f7f7000, 
vaddr = 83020f7f7000
Jan 16 01:46:05.699269 (XEN) cr_intercepts = 0xfef3fef3 dr_intercepts = 
0x exception_intercepts = 0x60082
Jan 16 01:46:05.707128 (XEN) general1_intercepts = 0xbdc4000f 
general2_intercepts = 0x2e7f
Jan 16 01:46:05.715222 (XEN) iopm_base_pa = 0xdfd71000 msrpm_base_pa = 
0x20f7f4000 tsc_offset = 0xfc36684278c9
Jan 16 01:46:05.723116 (XEN) tlb_control = 0 vintr = 0x1020001 interrupt_shadow 
= 0
Jan 16 01:46:05.723153 (XEN) eventinj 802f, valid? 1, ec? 0, type 
0, vector 0x2f
Jan 16 01:46:05.731141 (XEN) exitcode = 0x64 exitintinfo = 0
Jan 16 01:46:05.739123 (XEN) exitinfo1 = 0 exitinfo2 = 0
Jan 16 01:46:05.739157 (XEN) np_enable = 0x1 guest_asid = 0x4b49
Jan 16 01:46:05.739187 (XEN) virtual vmload/vmsave = 0, virt_ext = 0

I'd expect it to have interrupts disabled at this point. Seemingly doesn't 
repro on Intel h/w (although I was testing with Win7 SP1 rather than RTM) so 
I'll try to find some AMD h/w and try again.

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

Re: [Xen-devel] [RFC 01/11] acpi: arm: Public API for populating and query based on requesterid

[Julien Grall]

Hi Manish,

On 02/01/18 09:27, manish.ja...@linaro.org wrote:

From: Manish Jaggi 

  Public API to populate and query map between requester id and


The commit message should not be indented.


  streamId/DeviceID. IORT is parsed one time (outside this patch)
  and two lists are created one for mapping between reuesterId and streamid


s/reuesterId/requesterID/

Please stay consistent in the naming (including the lowercase/uppercase).

Cheers,


  and another between requesterID and deviceID.

  These lists eliminate the need to reparse IORT for querying streamid
  or deviceid using requesterid.

  Signed-off-by: Manish Jaggi 
---
  xen/drivers/acpi/Makefile |   1 +
  xen/drivers/acpi/arm/Makefile |   1 +
  xen/drivers/acpi/arm/ridmap.c | 124 ++
  xen/include/acpi/ridmap.h |  77 ++
  4 files changed, 203 insertions(+)

diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index 444b11d583..80a074e007 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -1,6 +1,7 @@
  subdir-y += tables
  subdir-y += utilities
  subdir-$(CONFIG_X86) += apei
+subdir-$(CONFIG_ARM) += arm
  
  obj-bin-y += tables.init.o

  obj-$(CONFIG_NUMA) += numa.o
diff --git a/xen/drivers/acpi/arm/Makefile b/xen/drivers/acpi/arm/Makefile
new file mode 100644
index 00..046fad5e3d
--- /dev/null
+++ b/xen/drivers/acpi/arm/Makefile
@@ -0,0 +1 @@
+obj-y = ridmap.o
diff --git a/xen/drivers/acpi/arm/ridmap.c b/xen/drivers/acpi/arm/ridmap.c
new file mode 100644
index 00..2c3a8876ea
--- /dev/null
+++ b/xen/drivers/acpi/arm/ridmap.c
@@ -0,0 +1,124 @@
+/*
+ * xen/drivers/acpi/arm/ridmap.c
+ *
+ * Public API to populate and query map between requester id and
+ * streamId/DeviceID
+ *
+ * Manish Jaggi 
+ * Copyright (c) 2018 Linaro.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct list_head rid_streamid_map_list;
+struct list_head rid_deviceid_map_list;
+
+void init_ridmaps(void)
+{
+INIT_LIST_HEAD(_deviceid_map_list);
+INIT_LIST_HEAD(_streamid_map_list);
+}
+
+int add_rid_streamid_map(struct acpi_iort_node *pcirc_node,
+ struct acpi_iort_node *smmu_node,
+ u32 input_base, u32 output_base, u32 id_count)
+{
+struct rid_streamid_map *rid_map;
+rid_map = xzalloc(struct rid_streamid_map);
+
+if (!rid_map)
+return -ENOMEM;
+
+rid_map->idmap.input_base = input_base;
+rid_map->idmap.output_base = output_base;
+rid_map->idmap.id_count = id_count;
+rid_map->pcirc_node = pcirc_node;
+rid_map->smmu_node = smmu_node;
+
+list_add_tail(_map->entry, _streamid_map_list);
+return 0;
+}
+
+int add_rid_deviceid_map(struct acpi_iort_node *pcirc_node,
+ struct acpi_iort_node *its_node,
+ u32 input_base, u32 output_base, u32 id_count)
+{
+struct rid_deviceid_map *rid_map;
+rid_map = xzalloc(struct rid_deviceid_map);
+
+if (!rid_map)
+return -ENOMEM;
+
+rid_map->idmap.input_base = input_base;
+rid_map->idmap.output_base = output_base;
+rid_map->idmap.id_count = id_count;
+rid_map->pcirc_node = pcirc_node;
+rid_map->its_node = its_node;
+
+list_add_tail(_map->entry, _deviceid_map_list);
+return 0;
+}
+
+void query_streamid(struct acpi_iort_node *pcirc_node, u16 rid, u32 *streamid,
+struct acpi_iort_node **smmu_node)
+{
+struct rid_streamid_map *rmap;
+
+list_for_each_entry(rmap, _streamid_map_list, entry)
+{
+if (rmap->pcirc_node == pcirc_node)
+{
+if ( (rid >= rmap->idmap.input_base) &&
+ (rid < rmap->idmap.input_base + rmap->idmap.id_count) )
+{
+*streamid = rid - rmap->idmap.input_base +
+rmap->idmap.output_base;
+*smmu_node = rmap->smmu_node;
+break;
+}
+}
+}
+
+}
+
+void query_deviceid(struct acpi_iort_node *pcirc_node, u16 rid, u32 *deviceid)
+{
+struct rid_deviceid_map *rmap;
+
+list_for_each_entry(rmap, _deviceid_map_list, entry)
+{
+if (rmap->pcirc_node == pcirc_node)
+{
+if ( (rid >= rmap->idmap.input_base) &&
+ (rid < rmap->idmap.input_base + rmap->idmap.id_count) )
+{
+*deviceid 

Re: [Xen-devel] [RFC 00/11] acpi: arm: IORT Support for Xen

[Julien Grall]

Hi Manish,

On 02/01/18 09:27, manish.ja...@linaro.org wrote:

From: Manish Jaggi 

This patch aims to add the support of IORT in Xen. Below is the list
of major components which this patchset provides.
a. Add support for parsing the IORT
b. Provides API to populate/query requesterid - streamID mappings and
reuqesterid - deviceid mappings
c. The requesterid - deviceid mappings is used to create the IORT for
hardware domain (which hides smmu nodes from IORT)
d. iort.c fwnode.h fwspec code is imported from linux and modified.
e. Few kernel helper routines are also imported from linux.


A link to the design document or a copy would have been helpful here.

Cheers,



This patchset compiles with [1]  [RFC v4 0/8] SMMUv3 driver.

[1] https://lists.xen.org/archives/html/xen-devel/2017-12/msg01294.html

Manish Jaggi (11):
   acpi: arm: Public API for populating and query based on requesterid
   acpi: arm: API to query estimated size of hardware domain's IORT
   acpi: arm: Code to generate Hardware Domains IORT
   acpi: arm: Import iort.c and acpi_iort.h
   acpi: arm: Import fwnode.h from linux
   acpi: arm: fwnode xen spacific changes
   Add kernel helper functions
   Add ACPI_IORT config
   acpi: arm: Xen IORT Changes
   acpi: arm: IORT parsing functions to prepare requesterId maps
   Add to_pci_dev macro

  xen/arch/arm/Kconfig|   5 +
  xen/arch/arm/domain_build.c |  40 ++-
  xen/arch/arm/setup.c|   2 +
  xen/drivers/acpi/Kconfig|   3 +
  xen/drivers/acpi/Makefile   |   1 +
  xen/drivers/acpi/arm/Makefile   |   3 +
  xen/drivers/acpi/arm/gen-iort.c | 352 +
  xen/drivers/acpi/arm/iort.c | 569 
  xen/drivers/acpi/arm/ridmap.c   | 124 +
  xen/drivers/passthrough/iommu.c |  75 ++
  xen/include/acpi/acpi_iort.h|  57 
  xen/include/acpi/gen-iort.h |   7 +
  xen/include/acpi/ridmap.h   |  77 ++
  xen/include/asm-arm/acpi.h  |   1 +
  xen/include/asm-arm/device.h|  11 +-
  xen/include/xen/fwnode.h| 125 +
  xen/include/xen/iommu.h |  22 ++
  xen/include/xen/kernel.h|  10 +
  xen/include/xen/pci.h   |   3 +
  19 files changed, 1484 insertions(+), 3 deletions(-)
  create mode 100644 xen/drivers/acpi/arm/Makefile
  create mode 100644 xen/drivers/acpi/arm/gen-iort.c
  create mode 100644 xen/drivers/acpi/arm/iort.c
  create mode 100644 xen/drivers/acpi/arm/ridmap.c
  create mode 100644 xen/include/acpi/acpi_iort.h
  create mode 100644 xen/include/acpi/gen-iort.h
  create mode 100644 xen/include/acpi/ridmap.h
  create mode 100644 xen/include/xen/fwnode.h



--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/efi: Avoid EFI stub using absolute symbols

[Julien Grall]

Hi Jan,

On 12/01/18 13:13, Jan Beulich wrote:

On 09.01.18 at 20:43,  wrote:

When I compiled the snippet on x86 and Arm, no relocation is available
for the pointers to string in the array in the final binary. Yet they
are available in the object.


I can see them there in the binary I look at. I use my own tool
for dumping, so the output may look unfamiliar to you, but here
are the relevant pieces:


I am a bit confused. Which binary are you looking at? Is it xen.efi?
I don't seem to find them in xen-syms.



Section count   0009 ( 9)
...
   Section 0004 (4): '.init', size 00085578, RVA 0060, flags E0D00060
   code data read write exec 4096-byte align
 00086000 bytes at file offset 00191000

Symbol count1DE2 (  7650)
...
   115A: ErrCodeToStr.9795
 Value 00044340, Section 0004, Type none, Storage static

which makes the array start at RVA 0x644340.

  Fixups for page at 00644000, 0094 (   148) bytes
...
   DIR64   0318  DIR64   0320  DIR64   0328  DIR64   0368  DIR64   0378
   DIR64   0388  DIR64   0390  DIR64   0398  DIR64   03A0  DIR64   03A8
   DIR64   03B0  DIR64   03B8  DIR64   0410  DIR64   0418  DIR64   0448

The numbers here are the offsets into the page named in the
"title" line, and the last 12 are the ones targeting the array in
question.


Indeed the relocation seem to be absolute (e.g R_X86_64_64) and
disappeared at linking. Hence why I suggested a compiler bug because the
code should be PIE and that would not even work is the binary is
randomized on Linux.


Well, without having seen the binary I don't think I can conclude
in the direction of compiler bug. Please don't forget that ld itself
does indeed not (yet) create any relocations in PE executables
(which an EFI application is). They're being added in a post-
processing step (hence the need to link the binary twice at
different base addresses, for the helper tool [mkreloc] to figure
out where relocations are needed).


If the code compiled is position independent, then you should not need
relocation. Right? So what are you trying to achieve with mkreloc?

Also, it does not explain why the compiler is issuing absolute address 
when building with -fpie.





So I am wondering how this work on x86? Note that this code is only used
in error path.


Sure, but an error path is being taken every now and then, and
I personally have seen errors coming back (mostly after having
made mistakes elsewhere).


And I guess the binary will never be loaded at the same as virtual 
address as Xen would be meant to run?


Cheers,

--
Julien Grall

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

[Xen-devel] Xen Security Advisory 254 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) - Information leak via side effects of speculative execution

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
 version 8

Information leak via side effects of speculative execution

UPDATES IN VERSION 8


PVH shim ("Comet") is now available for Xen 4.8.

Fixes for two bugs in PVH shim "Comet": one relating to shim
initialisation, which can cause hangs during guest boot shortly after
host boot(!), and one to make qemu PV backends work in PVH mode.
Thanks to the respective contributors.

We are longer inclined to port the "Comet" patches to Xen 4.9.  If
this causes you a problem please let us know by contacting us:
 To: secur...@xenproject.org; CC: xen-devel@lists.xenproject.org

ISSUE DESCRIPTION
=

Processors give the illusion of a sequence of instructions executed
one-by-one.  However, in order to most efficiently use cpu resources,
modern superscalar processors actually begin executing many
instructions in parallel.  In cases where instructions depend on the
result of previous instructions or checks which have not yet
completed, execution happens based on guesses about what the outcome
will be.  If the guess is correct, execution has been sped up.  If the
guess is incorrect, partially-executed instructions are cancelled and
architectural state changes (to registers, memory, and so on)
reverted; but the whole process is no slower than if no guess had been
made at all.  This is sometimes called "speculative execution".

Unfortunately, although architectural state is rolled back, there are
other side effects, such as changes to TLB or cache state, which are
not rolled back.  These side effects can subsequently be detected by
an attacker to determine information about what happened during the
speculative execution phase.  If an attacker can cause speculative
execution to access sensitive memory areas, they may be able to infer
what that sensitive memory contained.

Furthermore, these guesses can often be 'poisoned', such that attacker
can cause logic to reliably 'guess' the way the attacker chooses.
This advisory discusses three ways to cause speculative execution to
access sensitive memory areas (named here according to the
discoverer's naming scheme):

"Bounds-check bypass" (aka SP1, "Variant 1", Spectre CVE-2017-5753):
Poison the branch predictor, such that victim code is speculatively
executed past boundary and security checks.  This would allow an
attacker to, for instance, cause speculative code in the normal
hypercall / emulation path to execute with wild array indexes.

"Branch Target Injection" (aka SP2, "Variant 2", Spectre CVE-2017-5715):
Poison the branch predictor.  Well-abstracted code often involves
calling function pointers via indirect branches; reading these
function pointers may involve a (slow) memory access, so the CPU
attempts to guess where indirect branches will lead.  Poisoning this
enables an attacker to speculatively branch to any code that is
executable by the victim (eg, anywhere in the hypervisor).

"Rogue Data Load" (aka SP3, "Variant 3", Meltdown, CVE-2017-5754):
On some processors, certain pagetable permission checks only happen
when the instruction is retired; effectively meaning that speculative
execution is not subject to pagetable permission checks.  On such
processors, an attacker can speculatively execute arbitrary code in
userspace with, effectively, the highest privilege level.

More information is available here:
  https://meltdownattack.com/
  https://spectreattack.com/
  
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html

Additional Xen-specific background:

Xen hypervisors on most systems map all of physical RAM, so code
speculatively executed in a hypervisor context can read all of system
RAM.

When running PV guests, the guest and the hypervisor share the address
space; guest kernels run in a lower privilege level, and Xen runs in
the highest privilege level.  (x86 HVM and PVH guests, and ARM guests,
run in a separate address space to the hypervisor.)  However, only
64-bit PV guests can generate addresses large enough to point to
hypervisor memory.

IMPACT
==

Xen guests may be able to infer the contents of arbitrary host memory,
including memory assigned to other guests.

An attacker's choice of code to speculatively execute (and thus the
ease of extracting useful information) goes up with the numbers.  For
SP1, an attacker is limited to windows of code after bound checks of
user-supplied indexes.  For SP2, the attacker will in many cases will
be limited to executing arbitrary pre-existing code inside of Xen.
For SP3 (and other cases for SP2), an attacker can write arbitrary
code to speculatively execute.

Additionally, in general, attacks within a guest (from guest user to
guest kernel) will be the same as on real hardware.  Consult your
operating system provider for more information.

NOTE ON TIMING
==

This 

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install fail in 118078 pass in 
118096
 test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail pass in 118078

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

Re: [Xen-devel] [PATCH v8 08/17] x86/msr: Emulation of MSR_{SPEC_CTRL, PRED_CMD} for guests

[Andrew Cooper]

On 16/01/18 11:10, David Woodhouse wrote:
> On Fri, 2018-01-12 at 18:00 +, Andrew Cooper wrote:
>> @@ -152,14 +163,38 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr,
>> uint64_t val)
>>  {
>>  const struct vcpu *curr = current;
>>  struct domain *d = v->domain;
>> +    const struct cpuid_policy *cp = d->arch.cpuid;
>>  struct msr_domain_policy *dp = d->arch.msr;
>>  struct msr_vcpu_policy *vp = v->arch.msr;
>>  
>>  switch ( msr )
>>  {
>>  case MSR_INTEL_PLATFORM_INFO:
>> +    /* Read-only */
>>  goto gp_fault;
>>  
>> +    case MSR_SPEC_CTRL:
>> +    if ( !cp->feat.ibrsb )
>> +    goto gp_fault; /* MSR available? */
>> +    if ( val & ~(SPEC_CTRL_IBRS |
>> + (cp->feat.stibp ? SPEC_CTRL_STIBP : 0)) )
> Intel defines the STIBP bit as non-faulting and ignored, even when
> STIBP isn't advertised. So you should probably just mask it out
> if !cp->feat.stibp.

Well - this published spec finally answers several several-month-old
outstanding questions of mine.

Time for some rewriting.  /sigh

>
>> +    goto gp_fault; /* Rsvd bit set? */
>> +    vp->spec_ctrl.guest = val;
>> +    vp->spec_ctrl.host  = val;
>> +    break;
>> +
> There's no actual wrmsr there. This is fine, because you're going to do
> it on the way back to the guest (albeit in a later patch in the
> series). But it probably warrants a comment?

Actually, IBPB being a wrmsr() here is going to be the rare
circustances.  Most of guest_wrmsr() will only be updating internal
hypervisor state, and/or the VMCS/VMCB when I move some more of the HVM
logic here.

~Andrew

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

Re: [Xen-devel] [PATCH v3 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

[Andy Smith]

Hi Jan,

On Tue, Jan 16, 2018 at 08:21:52AM -0700, Jan Beulich wrote:
> This is a very simplistic change limiting the amount of memory a running
> 64-bit PV guest has mapped (and hence available for attacking): Only the
> mappings of stack, IDT, and TSS are being cloned from the direct map
> into per-CPU page tables.

Can this be used with Comet/Vixen to further protect PV guests? i.e.
if the shim hypervisor has these changes then will it also limit
what a process in the PV guest can see in that shim hypervisor,
which therefore protects its own guest kernel a bit too?

Thanks,
Andy

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

Re: [Xen-devel] Rudolph: merging Vixen and Comet

[Wei Liu]

On Tue, Jan 16, 2018 at 10:42:17AM -0600, Doug Goldstein wrote:
> On 1/12/18 8:20 AM, Wei Liu wrote:
> > On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote:
> >> On Fri, Jan 12, Wei Liu wrote:
> >>
> >>>   Vixen  Comet
> >>> Guest console Output onlyBi-directional
> >>
> >> With the proper patch input works for Vixen. Unless this item mean
> >> something else.
> > 
> > Vixen means the version upstream put into the advisory. The patch you
> > talked about is not provided in that branch.
> > 
> > Wei.
> > 
> 
> Can we merge some fixes people have proposed into the Vixen branch?
> There are a number of virtualization providers that have rolled forward
> with Vixen. They are clearly contributing patches on the ML and having
> one place to work together would be nice.
> 

There will be update to that branch.

> We can always host a fork on GitHub and merge patches there as well if
> that's preferred.
> 

No please don't. :-)

Wei.

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

Re: [Xen-devel] Rudolph: merging Vixen and Comet

[Wei Liu]

On Tue, Jan 16, 2018 at 12:46:10PM +, Wei Liu wrote:
> On Fri, Jan 12, 2018 at 01:24:09PM +, Wei Liu wrote:
> > Hi all,
> > 
> > Two solutions are proposed to mitigate Meltdown. One is called Vixen and the
> > other is called Comet. The long term goal is to merge the two 
> > implementations
> > to one.
> > 
> > Here I list the differences between the two implementations.
> > 
> >   Vixen  Comet
> > Boot mode HVMPVH + HVM
> > Kconfig options   XEN_GUEST  XEN_GUEST + PVH_GUEST 
> > + SHIM_EXCLUSIVE
> > Xen build system  No change  New build target for 
> > shim 
> > Guest console Output onlyBi-directional
> > Guest domid   1 or set via shim option   1 or retrieved via 
> > cpuid
> > Guest typeHardware domainNormal domain
> > Time source   Emulated   Xen PV clock
> > Shutdown  PV + HWPV
> > SI mappingReserved page  Fixed map, PFN chosen 
> > at runtime
> > VCPU id   Handled by L1  Provide by L0 if 
> > available
> > VCPU runstate Forwarded to L0Handled by L1
> > Xen version   L0 version L1 version
> > CPUID faultingNone   Changes for Intel and 
> > AMD
> > Grant table   What is forwarded is more or less the same but 
> > differs in implementation
> > Event channel setup   3 mechanisms   1 mechanism
> > Event channel ECS_PROXY stateUse ECS_RESERVED
> >   Differences in what gets forwarded
> > Migration No Yes
> > CPU hotplug   No Yes
> > Memory hotplugNo Yes
> > 
> > These are the things I can think of when comparing the two series side
> > by side.  Feel free to provide addition and / or correction.  The list
> > serves as a guidance on what areas need attention.
> 
> We've come to agree on the following goals among stakeholders:
> 
> 1. We will use Comet as base to develop Rudolph.
> 2. We will start to commit patches into staging and develop there.
> 3. We will maintain Vixen and Comet until Rudolph is ready. We will
>be cherry-picking bug fixes to Vixen and Comet as we develop Rudolph.
> 
> In order to make goal #3 easier, I suggest we commit Comet almost as-is
> to minimise the difference between staging and backported Comet
> branches.
> 
> I will post a version of Comet suitable for committing to staging as
> soon as possible.  We will start porting over functionalities from Vixen
> once Comet is committed.

I've pushed comet-for-unstable to my xenbits/xen.git. That branch is a
forward port of 4.10.0-shim-comet branch to staging.

https://xenbits.xen.org/gitweb/?p=people/liuw/xen.git;a=shortlog;h=refs/heads/comet-for-unstable

There will be follow-up patches to fix some bugs, which have not been
pushed to that branch yet:

1. Michael Young's -xen-attach patch
2. Roger's patch to move mapping vcpu_info earlier

(Due to things go in parallel, they are probably not yet on list)

Jan and Andrew, please check the branch and explicitly ack the action of
committing that branch.

Wei.

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

Re: [Xen-devel] Rudolph: merging Vixen and Comet

[George Dunlap]

On Tue, Jan 16, 2018 at 4:42 PM, Doug Goldstein  wrote:
> On 1/12/18 8:20 AM, Wei Liu wrote:
>> On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote:
>>> On Fri, Jan 12, Wei Liu wrote:
>>>
   Vixen  Comet
 Guest console Output onlyBi-directional
>>>
>>> With the proper patch input works for Vixen. Unless this item mean
>>> something else.
>>
>> Vixen means the version upstream put into the advisory. The patch you
>> talked about is not provided in that branch.
>>
>> Wei.
>>
>
> Can we merge some fixes people have proposed into the Vixen branch?
> There are a number of virtualization providers that have rolled forward
> with Vixen. They are clearly contributing patches on the ML and having
> one place to work together would be nice.

If Anthony is OK, we can call him the "maintainer" for the Vixen
branch; the committers can check in anything that has his Ack to the
Vixen branch, and the Security Team can post new signed tags when
appropriate.

It looked like Anthony had some issues with the most recent patch though.

 -George

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

Re: [Xen-devel] Rudolph: merging Vixen and Comet

[Doug Goldstein]

On 1/12/18 8:20 AM, Wei Liu wrote:
> On Fri, Jan 12, 2018 at 03:17:04PM +0100, Olaf Hering wrote:
>> On Fri, Jan 12, Wei Liu wrote:
>>
>>>   Vixen  Comet
>>> Guest console Output onlyBi-directional
>>
>> With the proper patch input works for Vixen. Unless this item mean
>> something else.
> 
> Vixen means the version upstream put into the advisory. The patch you
> talked about is not provided in that branch.
> 
> Wei.
> 

Can we merge some fixes people have proposed into the Vixen branch?
There are a number of virtualization providers that have rolled forward
with Vixen. They are clearly contributing patches on the ML and having
one place to work together would be nice.

We can always host a fork on GitHub and merge patches there as well if
that's preferred.

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH v3 2/2] x86: allow Meltdown band-aid to be disabled

[Andrew Cooper]

On 16/01/18 15:22, Jan Beulich wrote:
> First of all we don't need it on AMD systems. Additionally allow its use
> to be controlled by command line option. For best backportability, this
> intentionally doesn't use alternative instruction patching to achieve
> the intended effect - while we likely want it, this will be later
> follow-up.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v3 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

[Andrew Cooper]

On 16/01/18 15:21, Jan Beulich wrote:
> --- a/xen/include/asm-x86/x86_64/page.h
> +++ b/xen/include/asm-x86/x86_64/page.h
> @@ -24,8 +24,8 @@
>  /* These are architectural limits. Current CPUs support only 40-bit phys. */
>  #define PADDR_BITS  52
>  #define VADDR_BITS  48
> -#define PADDR_MASK  ((1UL << PADDR_BITS)-1)
> -#define VADDR_MASK  ((1UL << VADDR_BITS)-1)
> +#define PADDR_MASK  ((_AC(1,UL) << PADDR_BITS)-1)
> +#define VADDR_MASK  ((_AC(1,UL) << VADDR_BITS)-1)

Sorry to only notice these now, but spaces as you're adjusting these.

Reviewed-by: Andrew Cooper 

>  
>  #define VADDR_TOP_BIT   (1UL << (VADDR_BITS - 1))
>  #define CANONICAL_MASK  (~0UL & ~VADDR_MASK)
>


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

Re: [Xen-devel] Access I2C bus from guest/DomU on ARM board

[Andrii Anisov]

Dear Rajesh,


You can try to get an I2C bus controller in DomU in PIO mode following 
[1], keeping in mind [2].


If you want it DMA capable you need Renesas IPMMU support in XEN [3], 
[4] to be incorporated.



[1] - https://xenbits.xen.org/docs/unstable/misc/arm/passthrough.txt

[2] - 
https://lists.xenproject.org/archives/html/xen-users/2017-10/msg00031.html


[3] - 
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02545.html


[4] - 
https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02679.html



--

*Andrii Anisov*



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

[Xen-devel] [PATCH 10/10] Enable Trapping of Group1 registers which is controlled by command line

[mjaggi]

From: Manish Jaggi 

In order to be able to trap Group-1 GICv3 system registers, we need to
set ICH_HCR_EL2.TALL1 before entering the guest. This is controlled by
the command line parameter group1_trap.

Singed-off-by: Manish Jaggi 
---
 xen/arch/arm/gic-v3.c | 11 ++-
 xen/include/asm-arm/gic.h |  1 +
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 5dba8bc932..f22877c468 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -833,9 +833,12 @@ static void gicv3_cpu_disable(void)
 isb();
 }
 
+static unsigned int group1_trap = 0;
+integer_param("group1_trap", group1_trap);
+
 static void gicv3_hyp_init(void)
 {
-uint32_t vtr;
+uint32_t vtr, reg32;
 
 vtr = READ_SYSREG32(ICH_VTR_EL2);
 gicv3_info.nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
@@ -847,6 +850,12 @@ static void gicv3_hyp_init(void)
 
 WRITE_SYSREG32(GICH_VMCR_EOI | GICH_VMCR_VENG1, ICH_VMCR_EL2);
 WRITE_SYSREG32(GICH_HCR_EN, ICH_HCR_EL2);
+
+reg32 = READ_SYSREG32(ICH_HCR_EL2);
+if ( group1_trap )
+reg32 |= GICH_HCR_TALL1;
+
+WRITE_SYSREG32(reg32, ICH_HCR_EL2);
 }
 
 /* Set up the per-CPU parts of the GIC for a secondary CPU */
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index d3d7bda50d..e4c77fefd6 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -117,6 +117,7 @@
 #define GICH_HCR_VGRP0DIE (1 << 5)
 #define GICH_HCR_VGRP1EIE (1 << 6)
 #define GICH_HCR_VGRP1DIE (1 << 7)
+#define GICH_HCR_TALL1(1 << 12)
 
 #define GICH_MISR_EOI (1 << 0)
 #define GICH_MISR_U   (1 << 1)
-- 
2.14.1


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

[Xen-devel] [PATCH 06/10] Expose gicv3_ich_read/write_lr

[mjaggi]

From: Manish Jaggi 

gicv3_ich_read/write_lr functions are static in gic-v3.c
This patch creates wrapper functions which can be used from outside the file.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/gic-v3.c| 10 ++
 xen/include/asm-arm/gic_v3.h |  7 +++
 2 files changed, 17 insertions(+)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 473e26111f..5dba8bc932 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -184,6 +184,11 @@ static uint64_t gicv3_ich_read_lr(int lr)
 }
 }
 
+uint64_t __gicv3_ich_read_lr(int lr)
+{
+return gicv3_ich_read_lr(lr);
+}
+
 static void gicv3_ich_write_lr(int lr, uint64_t val)
 {
 switch ( lr )
@@ -242,6 +247,11 @@ static void gicv3_ich_write_lr(int lr, uint64_t val)
 isb();
 }
 
+void __gicv3_ich_write_lr(int lr, uint64_t val)
+{
+return gicv3_ich_write_lr(lr, val);
+}
+
 /*
  * System Register Enable (SRE). Enable to access CPU & Virtual
  * interface registers as system registers in EL2
diff --git a/xen/include/asm-arm/gic_v3.h b/xen/include/asm-arm/gic_v3.h
new file mode 100644
index 00..544aad5932
--- /dev/null
+++ b/xen/include/asm-arm/gic_v3.h
@@ -0,0 +1,7 @@
+#ifndef GICV3_H
+#define GICV3_H
+
+uint64_t __gicv3_ich_read_lr(int lr);
+void __gicv3_ich_write_lr(int lr, uint64_t val);
+
+#endif
-- 
2.14.1


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

[Xen-devel] [RFC PATCH 02/10] arm64: Add hook to handle guest GICv3 sysreg accesses

[mjaggi]

From: Manish Jaggi 

In order to start handling guest access to GICv3 system registers,
let's add a hook that will get called when we trap a system register
access.
This handling code is kept independent of other traps.
Set CONFIG_VGIC_ERRATA to enable this code.

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/arm64/vsysreg.c  | 17 +
 xen/arch/arm/traps.c  | 11 +++
 xen/include/asm-arm/arm64/traps.h |  2 ++
 3 files changed, 30 insertions(+)

diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
index c57ac12503..a5c17e460f 100644
--- a/xen/arch/arm/arm64/vsysreg.c
+++ b/xen/arch/arm/arm64/vsysreg.c
@@ -219,6 +219,23 @@ void do_sysreg(struct cpu_user_regs *regs,
 regs->pc += 4;
 }
 
+#ifdef CONFIG_VGIC_ERRATA
+int do_fixup_vgic_errata(struct cpu_user_regs *regs, const union hsr hsr)
+{
+int ret = 0;
+
+local_irq_disable();
+switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
+{
+default:
+ret = -1;
+break;
+}
+local_irq_enable();
+
+return ret;
+}
+#endif
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f6f6de3691..d4f0581d33 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2103,6 +2103,17 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
 {
 const union hsr hsr = { .bits = regs->hsr };
 
+#ifdef CONFIG_VGIC_ERRATA
+int ret;
+
+ret  = do_fixup_vgic_errata(regs,hsr);
+if ( !ret )
+{
+advance_pc(regs, hsr);
+return;
+}
+#endif
+
 enter_hypervisor_head(regs);
 
 switch (hsr.ec) {
diff --git a/xen/include/asm-arm/arm64/traps.h 
b/xen/include/asm-arm/arm64/traps.h
index 2379b578cb..7378a1b022 100644
--- a/xen/include/asm-arm/arm64/traps.h
+++ b/xen/include/asm-arm/arm64/traps.h
@@ -5,6 +5,8 @@ void inject_undef64_exception(struct cpu_user_regs *regs, int 
instr_len);
 
 void do_sysreg(struct cpu_user_regs *regs,
const union hsr hsr);
+int do_fixup_vgic_errata(struct cpu_user_regs *regs,
+   const union hsr hsr);
 
 #endif /* __ASM_ARM64_TRAPS__ */
 /*
-- 
2.14.1


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

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

[mjaggi]

From: Manish Jaggi 

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

Signed-off-by: Manish Jaggi 
---
 xen/arch/arm/arm64/vsysreg.c| 192 
 xen/include/asm-arm/arm64/sysregs.h |   1 +
 xen/include/asm-arm/gic_v3_defs.h   |  18 
 3 files changed, 211 insertions(+)

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

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

[mjaggi]

From: Manish Jaggi 

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

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

The errata has been validated on Cavium ThunderX platform.

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

Code in this patchset fixes this issue.

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

Manish Jaggi (10):
  arm64: Add CONFIG_VGIC_ERRATA
  arm64: Add hook to handle guest GICv3 sysreg accesses
  arm64: Add ICV_BPR1_EL1 handler
  arm64: Add ICV_IGRPEN1_EL1 handler
  arm64: Add accessors for the ICH_APxRn_EL2 registers
  arm64: Expose gicv3_ich_read/write_lr
  arm64: Add ICV_IAR1_EL1 handler
  arm64: Add ICV_EOIR1_EL1 handler
  arm64: Add a handler for ICV_HPPIR1_EL1
  arm64: Enable Trapping of Group1 registers which is controlled by
command line

 xen/arch/arm/Kconfig|   9 +
 xen/arch/arm/arm64/vsysreg.c| 564 
 xen/arch/arm/gic-v3.c   |  21 +-
 xen/arch/arm/traps.c|  11 +
 xen/include/asm-arm/arm64/sysregs.h |   5 +
 xen/include/asm-arm/arm64/traps.h   |   2 +
 xen/include/asm-arm/gic.h   |   1 +
 xen/include/asm-arm/gic_v3.h|   7 +
 xen/include/asm-arm/gic_v3_defs.h   |  30 ++
 9 files changed, 649 insertions(+), 1 deletion(-)
 create mode 100644 xen/include/asm-arm/gic_v3.h

-- 
2.14.1


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

[Xen-devel] [PATCH 03/10] arm64: Add ICV_BPR1_EL1 handler

[mjaggi]

From: Manish Jaggi 

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

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

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


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

[Xen-devel] [PATCH 08/10] Add ICV_EOIR1_EL1 handler

[mjaggi]

From: Manish Jaggi 

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

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

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

[Xen-devel] [PATCH 09/10] arm64: Add a handler for ICV_HPPIR1_EL1

[mjaggi]

From: Manish Jaggi 

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

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

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


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

[Xen-devel] [PATCH 05/10] arm64: Add accessors for the ICH_APxRn_EL2 registers

[mjaggi]

From: Manish Jaggi 

define accessors that take the register number as a parameter.

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

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


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

[Xen-devel] [PATCH v3 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

[Jan Beulich]

This is a very simplistic change limiting the amount of memory a running
64-bit PV guest has mapped (and hence available for attacking): Only the
mappings of stack, IDT, and TSS are being cloned from the direct map
into per-CPU page tables. Guest controlled parts of the page tables are
being copied into those per-CPU page tables upon entry into the guest.
Cross-vCPU synchronization of top level page table entry changes is
being effected by forcing other active vCPU-s of the guest into the
hypervisor.

The change to context_switch() isn't strictly necessary, but there's no
reason to keep switching page tables once a PV guest is being scheduled
out.

This isn't providing full isolation yet, but it should be covering all
pieces of information exposure of which would otherwise require an XSA.

There is certainly much room for improvement, especially of performance,
here - first and foremost suppressing all the negative effects on AMD
systems. But in the interest of backportability (including to really old
hypervisors, which may not even have alternative patching) any such is
being left out here.

Signed-off-by: Jan Beulich 
---
v3: Add remark in description as to not doing full isolation here. Drop
use of UNLIKELY_*() from CSTAR and INT80 entry paths.
v2: Use sensible numbers for the register classification constants also
for the low 8 registers. Insert 'r' into their names to make their
purpose more clear. Use "sub" instead of "add" when adding an
immediate of 128. Defer sync IPI in do_mmu_update() until the end of
the main loop. Use flush IPI there instead event check one. Make
setup functions return a proper error code. Use better suited local
variables in clone_mapping(). Add comment to new struct cpu_info
fields.
---
Backporting notes:
- This needs f9eb74789a ("x86/entry: Remove support for partial
  cpu_user_regs frames") as a prereq, due to the uses of %r14 and %r15.
  But that's intended to be backported anyway (for Spectre/SP2).
- This further needs bd61fe94be ("x86/mm: Always set _PAGE_ACCESSED on
  L4e updates") as a prereq.
- The use of "root" instead of "l4" here is mainly to not make 5-level
  page table additions any harder. In backports "l4" should probably be
  preferred.
---
Follow-up notes:
- use alternatives patching for fully suppressing performance effects
  when disabled
- check whether running globally with CR4.PGE clear helps overall
  performance

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1511,6 +1511,9 @@ void paravirt_ctxt_switch_to(struct vcpu
 {
 unsigned long cr4;
 
+this_cpu(root_pgt)[root_table_offset(PERDOMAIN_VIRT_START)] =
+l4e_from_page(v->domain->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
+
 cr4 = pv_guest_cr4_to_real_cr4(v);
 if ( unlikely(cr4 != read_cr4()) )
 write_cr4(cr4);
@@ -1682,6 +1685,8 @@ void context_switch(struct vcpu *prev, s
 
 ASSERT(local_irq_is_enabled());
 
+get_cpu_info()->xen_cr3 = 0;
+
 cpumask_copy(_mask, next->vcpu_dirty_cpumask);
 /* Allow at most one CPU at a time to be dirty. */
 ASSERT(cpumask_weight(_mask) <= 1);
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3520,6 +3520,7 @@ long do_mmu_update(
 struct vcpu *curr = current, *v = curr;
 struct domain *d = v->domain, *pt_owner = d, *pg_owner;
 mfn_t map_mfn = INVALID_MFN;
+bool sync_guest = false;
 uint32_t xsm_needed = 0;
 uint32_t xsm_checked = 0;
 int rc = put_old_guest_table(curr);
@@ -3683,6 +3684,8 @@ long do_mmu_update(
 break;
 rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
   cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
+if ( !rc )
+sync_guest = true;
 break;
 
 case PGT_writable_page:
@@ -3787,6 +3790,24 @@ long do_mmu_update(
 if ( va )
 unmap_domain_page(va);
 
+if ( sync_guest )
+{
+/*
+ * Force other vCPU-s of the affected guest to pick up L4 entry
+ * changes (if any). Issue a flush IPI with empty operation mask to
+ * facilitate this (including ourselves waiting for the IPI to
+ * actually have arrived). Utilize the fact that FLUSH_VA_VALID is
+ * meaningless without FLUSH_CACHE, but will allow to pass the no-op
+ * check in flush_area_mask().
+ */
+unsigned int cpu = smp_processor_id();
+cpumask_t *mask = per_cpu(scratch_cpumask, cpu);
+
+cpumask_andnot(mask, pt_owner->domain_dirty_cpumask, cpumask_of(cpu));
+if ( !cpumask_empty(mask) )
+flush_area_mask(mask, ZERO_BLOCK_PTR, FLUSH_VA_VALID);
+}
+
 perfc_add(num_page_updates, i);
 
  out:
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -327,6 +327,9 @@ void start_secondary(void *unused)
  */
 spin_debug_disable();
 
+get_cpu_info()->xen_cr3 = 0;
+

[Xen-devel] [PATCH v3 2/2] x86: allow Meltdown band-aid to be disabled

[Jan Beulich]

First of all we don't need it on AMD systems. Additionally allow its use
to be controlled by command line option. For best backportability, this
intentionally doesn't use alternative instruction patching to achieve
the intended effect - while we likely want it, this will be later
follow-up.

Signed-off-by: Jan Beulich 
---
v3: Add warning about incomplete implementation to command line option
doc. Use local variable in paravirt_ctxt_switch_to().
v2: New.

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1849,6 +1849,18 @@ In the case that x2apic is in use, this
 clustered mode.  The default, given no hint from the **FADT**, is cluster
 mode.
 
+### xpti
+> `= `
+
+> Default: `false` on AMD hardware
+> Default: `true` everywhere else
+
+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
 > `= `
 
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1509,10 +1509,13 @@ void paravirt_ctxt_switch_from(struct vc
 
 void paravirt_ctxt_switch_to(struct vcpu *v)
 {
+root_pgentry_t *root_pgt = this_cpu(root_pgt);
 unsigned long cr4;
 
-this_cpu(root_pgt)[root_table_offset(PERDOMAIN_VIRT_START)] =
-l4e_from_page(v->domain->arch.perdomain_l3_pg, __PAGE_HYPERVISOR_RW);
+if ( root_pgt )
+root_pgt[root_table_offset(PERDOMAIN_VIRT_START)] =
+l4e_from_page(v->domain->arch.perdomain_l3_pg,
+  __PAGE_HYPERVISOR_RW);
 
 cr4 = pv_guest_cr4_to_real_cr4(v);
 if ( unlikely(cr4 != read_cr4()) )
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3685,7 +3685,7 @@ long do_mmu_update(
 rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
   cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
 if ( !rc )
-sync_guest = true;
+sync_guest = this_cpu(root_pgt);
 break;
 
 case PGT_writable_page:
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -328,7 +328,7 @@ void start_secondary(void *unused)
 spin_debug_disable();
 
 get_cpu_info()->xen_cr3 = 0;
-get_cpu_info()->pv_cr3 = __pa(this_cpu(root_pgt));
+get_cpu_info()->pv_cr3 = this_cpu(root_pgt) ? __pa(this_cpu(root_pgt)) : 0;
 
 load_system_tables();
 
@@ -734,14 +734,20 @@ static int clone_mapping(const void *ptr
 return 0;
 }
 
+static __read_mostly int8_t opt_xpti = -1;
+boolean_param("xpti", opt_xpti);
 DEFINE_PER_CPU(root_pgentry_t *, root_pgt);
 
 static int setup_cpu_root_pgt(unsigned int cpu)
 {
-root_pgentry_t *rpt = alloc_xen_pagetable();
+root_pgentry_t *rpt;
 unsigned int off;
 int rc;
 
+if ( !opt_xpti )
+return 0;
+
+rpt = alloc_xen_pagetable();
 if ( !rpt )
 return -ENOMEM;
 
@@ -992,10 +998,14 @@ void __init smp_prepare_cpus(unsigned in
 
 stack_base[0] = stack_start;
 
+if ( opt_xpti < 0 )
+opt_xpti = boot_cpu_data.x86_vendor != X86_VENDOR_AMD;
+
 rc = setup_cpu_root_pgt(0);
 if ( rc )
 panic("Error %d setting up PV root page table\n", rc);
-get_cpu_info()->pv_cr3 = __pa(per_cpu(root_pgt, 0));
+if ( per_cpu(root_pgt, 0) )
+get_cpu_info()->pv_cr3 = __pa(per_cpu(root_pgt, 0));
 
 set_nr_sockets();
 
@@ -1067,6 +1077,7 @@ void __init smp_prepare_boot_cpu(void)
 #endif
 
 get_cpu_info()->xen_cr3 = 0;
+get_cpu_info()->pv_cr3 = 0;
 }
 
 static void
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -46,6 +46,7 @@ restore_all_guest:
 movabs $DIRECTMAP_VIRT_START, %rcx
 mov   %rdi, %rax
 and   %rsi, %rdi
+jz.Lrag_keep_cr3
 and   %r9, %rsi
 add   %rcx, %rdi
 add   %rcx, %rsi
@@ -62,6 +63,7 @@ restore_all_guest:
 rep movsq
 mov   %r9, STACK_CPUINFO_FIELD(xen_cr3)(%rdx)
 write_cr3 rax, rdi, rsi
+.Lrag_keep_cr3:
 
 RESTORE_ALL
 testw $TRAP_syscall,4(%rsp)



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

Re: [Xen-devel] [PATCH v8 13/17] x86/boot: Calculate the most appropriate BTI mitigation to use

[Andrew Cooper]

On 16/01/18 14:25, Boris Ostrovsky wrote:
> On 01/16/2018 09:13 AM, Andrew Cooper wrote:
>> On 16/01/18 14:10, Boris Ostrovsky wrote:
>>> On 01/12/2018 01:01 PM, Andrew Cooper wrote:
  
 +if ( boot_cpu_has(X86_FEATURE_IBRSB) )
 +{
 +/*
 + * Even if we've chosen to not have IBRS set in Xen context, we 
 still
 + * need the IBRS entry/exit logic to virtualise IBRS support for
 + * guests.
 + */
 +if ( ibrs )
 +setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_SET);
 +else
 +setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_CLEAR);
 +}

>>> Are you going to add support for Intel's "Enhanced IBRS" (I think that's
>>> what they call the "always on" mode")?
>> I'm not going to touch IBRS_ATT mode until I've got an SDP to develop
>> against.
>>
>> Given how many times the IBRS_ATT spec has changed already, I have
>> little confidence that it will remain unchanged right to the eventual
>> hardware arrives.
> I don't know if you are aware of it (I learned about this doc on Sunday) but
>
> https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf
>
> (Not part of the SDM but still, an official specification. For a change.)

Wow - the published 1.0 has far more than the prerelease versions.

Still, ARCH_CAPS is only going to appear in new hardware, which is still
probably years away.  There are more important things to worry about at
the moment.

~Andrew

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

Re: [Xen-devel] [PATCH v8 13/17] x86/boot: Calculate the most appropriate BTI mitigation to use

[Boris Ostrovsky]

On 01/16/2018 09:13 AM, Andrew Cooper wrote:
> On 16/01/18 14:10, Boris Ostrovsky wrote:
>> On 01/12/2018 01:01 PM, Andrew Cooper wrote:
>>>  
>>> +if ( boot_cpu_has(X86_FEATURE_IBRSB) )
>>> +{
>>> +/*
>>> + * Even if we've chosen to not have IBRS set in Xen context, we 
>>> still
>>> + * need the IBRS entry/exit logic to virtualise IBRS support for
>>> + * guests.
>>> + */
>>> +if ( ibrs )
>>> +setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_SET);
>>> +else
>>> +setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_CLEAR);
>>> +}
>>>
>> Are you going to add support for Intel's "Enhanced IBRS" (I think that's
>> what they call the "always on" mode")?
> I'm not going to touch IBRS_ATT mode until I've got an SDP to develop
> against.
>
> Given how many times the IBRS_ATT spec has changed already, I have
> little confidence that it will remain unchanged right to the eventual
> hardware arrives.

I don't know if you are aware of it (I learned about this doc on Sunday) but

https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf

(Not part of the SDM but still, an official specification. For a change.)

-boris

-boris

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

[Xen-devel] [PATCH 4/5] xen/arm64: Add skeleton to harden the branch predictor aliasing attacks

[Julien Grall]

Aliasing attacked against CPU branch predictors can allow an attacker to
redirect speculative control flow on some CPUs and potentially divulge
information from one context to another.

This patch adds initial skeleton code behind a new Kconfig option to
enable implementation-specific mitigations against these attacks for
CPUs that are affected.

Most of the mitigations will have to be applied when entering to the
hypervisor from the guest context. For safety, it is applied at every
exception entry. So there are potential for optimizing when receiving
an exception at the same level.

Because the attack is against branch predictor, it is not possible to
safely use branch instruction before the mitigation is applied.
Therefore, this has to be done in the vector entry before jump to the
helper handling a given exception.

On Arm64, each vector can hold 32 instructions. This leave us 31
instructions for the mitigation. The last one is the branch instruction
to the helper.

Because a platform may have CPUs with different micro-architectures,
per-CPU vector table needs to be provided. Realistically, only a few
different mitigations will be necessary. So provide a small set of
vector tables. They will be re-used and patch with the mitigations
on-demand.

This is based on the work done in Linux (see [1]).

This is part of XSA-254.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
branch ktpi

Signed-off-by: Julien Grall 
---
 xen/arch/arm/Kconfig |  20 ++
 xen/arch/arm/arm64/Makefile  |   1 +
 xen/arch/arm/arm64/bpi.S |  64 ++
 xen/arch/arm/cpuerrata.c | 142 +++
 xen/arch/arm/traps.c |   5 +-
 xen/include/asm-arm/cpuerrata.h  |   1 +
 xen/include/asm-arm/cpufeature.h |   3 +-
 xen/include/asm-arm/processor.h  |   5 +-
 8 files changed, 237 insertions(+), 4 deletions(-)
 create mode 100644 xen/arch/arm/arm64/bpi.S

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index f58019d6ed..06fd85cc77 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -171,6 +171,26 @@ config ARM64_ERRATUM_834220
 
 endmenu
 
+config HARDEN_BRANCH_PREDICTOR
+   bool "Harden the branch predictor against aliasing attacks" if EXPERT
+   default y
+   help
+ Speculation attacks against some high-performance processors rely on
+ being able to manipulate the branch predictor for a victim context by
+ executing aliasing branches in the attacker context.  Such attacks
+ can be partially mitigated against by clearing internal branch
+ predictor state and limiting the prediction logic in some situations.
+
+ This config option will take CPU-specific actions to harden the
+ branch predictor against aliasing attacks and may rely on specific
+ instruction sequences or control bits being set by the system
+ firmware.
+
+ If unsure, say Y.
+
+config ARM64_HARDEN_BRANCH_PREDICTOR
+def_bool y if ARM_64 && HARDEN_BRANCH_PREDICTOR
+
 source "common/Kconfig"
 
 source "drivers/Kconfig"
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 718fe44455..bb5c610b2a 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,6 +1,7 @@
 subdir-y += lib
 
 obj-y += cache.o
+obj-$(CONFIG_HARDEN_BRANCH_PREDICTOR) += bpi.o
 obj-$(EARLY_PRINTK) += debug.o
 obj-y += domctl.o
 obj-y += domain.o
diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
new file mode 100644
index 00..6cc2f17529
--- /dev/null
+++ b/xen/arch/arm/arm64/bpi.S
@@ -0,0 +1,64 @@
+/*
+ * Contains CPU specific branch predictor invalidation sequences
+ *
+ * Copyright (C) 2018 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+.macro ventry target
+.rept 31
+nop
+.endr
+b  \target
+.endm
+
+.macro vectors target
+ventry \target + 0x000
+ventry \target + 0x080
+ventry \target + 0x100
+ventry \target + 0x180
+
+ventry \target + 0x200
+ventry \target + 0x280
+ventry \target + 0x300
+ventry \target + 0x380
+
+ventry \target + 0x400
+ventry \target + 0x480
+ventry \target + 0x500
+ventry \target + 0x580
+
+ventry \target + 0x600
+ventry \target + 0x680
+ventry \target + 0x700
+ventry \target + 0x780
+.endm
+
+/*
+ * Populate 4 vector tables. This will cover up to 4 

Re: [Xen-devel] Rudolph: merging Vixen and Comet

[Wei Liu]

On Tue, Jan 16, 2018 at 01:03:06PM +, Roger Pau Monné wrote:
> On Tue, Jan 16, 2018 at 12:46:10PM +, Wei Liu wrote:
> > On Fri, Jan 12, 2018 at 01:24:09PM +, Wei Liu wrote:
> > > Hi all,
> > > 
> > > Two solutions are proposed to mitigate Meltdown. One is called Vixen and 
> > > the
> > > other is called Comet. The long term goal is to merge the two 
> > > implementations
> > > to one.
> > > 
> > > Here I list the differences between the two implementations.
> > > 
> > >   Vixen  Comet
> > > Boot mode HVMPVH + HVM
> > > Kconfig options   XEN_GUEST  XEN_GUEST + 
> > > PVH_GUEST + SHIM_EXCLUSIVE
> > > Xen build system  No change  New build target for 
> > > shim 
> > > Guest console Output onlyBi-directional
> > > Guest domid   1 or set via shim option   1 or retrieved via 
> > > cpuid
> > > Guest typeHardware domainNormal domain
> > > Time source   Emulated   Xen PV clock
> > > Shutdown  PV + HWPV
> > > SI mappingReserved page  Fixed map, PFN 
> > > chosen at runtime
> > > VCPU id   Handled by L1  Provide by L0 if 
> > > available
> > > VCPU runstate Forwarded to L0Handled by L1
> > > Xen version   L0 version L1 version
> > > CPUID faultingNone   Changes for Intel 
> > > and AMD
> > > Grant table   What is forwarded is more or less the same but 
> > > differs in implementation
> > > Event channel setup   3 mechanisms   1 mechanism
> > > Event channel ECS_PROXY stateUse ECS_RESERVED
> > >   Differences in what gets forwarded
> > > Migration No Yes
> > > CPU hotplug   No Yes
> > > Memory hotplugNo Yes
> > > 
> > > These are the things I can think of when comparing the two series side
> > > by side.  Feel free to provide addition and / or correction.  The list
> > > serves as a guidance on what areas need attention.
> > 
> > We've come to agree on the following goals among stakeholders:
> > 
> > 1. We will use Comet as base to develop Rudolph.
> > 2. We will start to commit patches into staging and develop there.
> > 3. We will maintain Vixen and Comet until Rudolph is ready. We will
> >be cherry-picking bug fixes to Vixen and Comet as we develop Rudolph.
> > 
> > In order to make goal #3 easier, I suggest we commit Comet almost as-is
> > to minimise the difference between staging and backported Comet
> > branches.
> > 
> > I will post a version of Comet suitable for committing to staging as
> > soon as possible.
> 
> Iff maintainers agree that a version of Comet will be committed to
> staging now I think it should be 4.10.0-shim-comet rebased into
> staging, so that further patches (including bugfixes) can be easily
> backported to the 4.10.0-shim-comet branch.
> 

There isn't any substantial difference between comet-4.10 and the
version I'm going to post other than I clean up the commit message a bit
and collect tags if applicable. I can also pick comet-4.10 if people
prefer that.  I don't really care.

Wei.

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

[Xen-devel] [PATCH 0/5] xen/arm64: Branch predictor hardening (XSA-254 variant 2)

[Julien Grall]

Hi all,

This series provides a framework for mitigating branch predictor hardening on
Arm64 on exception entry.

It also implements a dummy PSCI "VERSION" call as the hook for affected
Cortex-A CPUs. This will invalidate the predictor state with the latest
Arm Trusted Firmware patches which will appear at [1] and SoC vendors
with affected CPUs are strongly encouraged to update. We plan to switch to a
more efficient, special-purpose call when it is available and the PSCI spec
has been updated accordingly.

For more information about the impact of this issue and the software mitigations
for Arm processors, please see http://www.arm.com/security-update.

[1] 
https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6

Julien Grall (5):
  xen/arm: Introduce enable callback to enable a capabilities on each
online CPU
  xen/arm64: Add missing MIDR values for Cortex-A72, A73 and A75
  xen/arm: cpuerrata: Add MIDR_ALL_VERSIONS
  xen/arm64: Add skeleton to harden the branch predictor aliasing
attacks
  xen/arm64: Implement branch predictor hardening for affected Cortex-A
CPUs

 xen/arch/arm/Kconfig |  20 
 xen/arch/arm/arm64/Makefile  |   1 +
 xen/arch/arm/arm64/bpi.S |  89 +
 xen/arch/arm/cpuerrata.c | 203 +++
 xen/arch/arm/cpufeature.c|  29 ++
 xen/arch/arm/setup.c |   1 +
 xen/arch/arm/traps.c |   5 +-
 xen/include/asm-arm/cpuerrata.h  |   2 +
 xen/include/asm-arm/cpufeature.h |   6 +-
 xen/include/asm-arm/processor.h  |  11 ++-
 10 files changed, 363 insertions(+), 4 deletions(-)
 create mode 100644 xen/arch/arm/arm64/bpi.S

-- 
2.11.0


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

[Xen-devel] [PATCH 5/5] xen/arm64: Implement branch predictor hardening for affected Cortex-A CPUs

[Julien Grall]

Cortex-A57, A72, A73 and A75 are susceptible to branch predictor
aliasing and can theoritically be attacked by malicious code.

This patch implements a PSCI-based mitigation for these CPUs when
available. The call into firmware will invalidate the branch predictor
state, preventing any malicious entries from affection other victim
contexts.

Ported from Linux git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
branch kpti.

 Signed-off-by: Marc Zyngier 
 Signed-off-by: Will Deacon 

This is part of XSA-254.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/arm64/bpi.S | 25 
 xen/arch/arm/cpuerrata.c | 49 
 2 files changed, 74 insertions(+)

diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
index 6cc2f17529..4b7f1dc21f 100644
--- a/xen/arch/arm/arm64/bpi.S
+++ b/xen/arch/arm/arm64/bpi.S
@@ -56,6 +56,31 @@ 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)
+
 /*
  * Local variables:
  * mode: ASM
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 76d98e771d..f1ea7f3c5b 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -4,8 +4,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 /* Override macros from asm/page.h to make them work with mfn_t */
 #undef virt_to_mfn
@@ -141,6 +143,31 @@ install_bp_hardening_vec(const struct arm_cpu_capabilities 
*entry,
 return ret;
 }
 
+extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
+
+static int enable_psci_bp_hardening(void *data)
+{
+bool ret = true;
+static bool warned = false;
+
+/*
+ * 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) )
+ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
+   __psci_hyp_bp_inval_end);
+else 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;
+}
+
+return !ret;
+}
+
 #endif /* CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR */
 
 #define MIDR_RANGE(model, min, max) \
@@ -205,6 +232,28 @@ static const struct arm_cpu_capabilities arm_errata[] = {
(1 << MIDR_VARIANT_SHIFT) | 2),
 },
 #endif
+#ifdef CONFIG_ARM64_HARDEN_BRANCH_PREDICTOR
+{
+.capability = ARM_HARDEN_BRANCH_PREDICTOR,
+MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
+.enable = enable_psci_bp_hardening,
+},
+{
+.capability = ARM_HARDEN_BRANCH_PREDICTOR,
+MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
+.enable = enable_psci_bp_hardening,
+},
+{
+.capability = ARM_HARDEN_BRANCH_PREDICTOR,
+MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
+.enable = enable_psci_bp_hardening,
+},
+{
+.capability = ARM_HARDEN_BRANCH_PREDICTOR,
+MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
+.enable = enable_psci_bp_hardening,
+},
+#endif
 {},
 };
 
-- 
2.11.0


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

[Xen-devel] [PATCH 3/5] xen/arm: cpuerrata: Add MIDR_ALL_VERSIONS

[Julien Grall]

Introduce a new macro MIDR_ALL_VERSIONS to match all variant/revision of a
given CPU model.

This is part of XSA-254.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/cpuerrata.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 772587c05a..c50d3331f2 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -7,6 +7,12 @@
 .midr_range_min = min,  \
 .midr_range_max = max
 
+#define MIDR_ALL_VERSIONS(model)\
+.matches = is_affected_midr_range,  \
+.midr_model = model,\
+.midr_range_min = 0,\
+.midr_range_max = (MIDR_VARIANT_MASK | MIDR_REVISION_MASK)
+
 static bool __maybe_unused
 is_affected_midr_range(const struct arm_cpu_capabilities *entry)
 {
-- 
2.11.0


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

[Xen-devel] [PATCH 2/5] xen/arm64: Add missing MIDR values for Cortex-A72, A73 and A75

[Julien Grall]

Cortex-A72, A73 and A75 MIDR will be used to a follow-up for hardening
the branch predictor.

This is part of XSA-254.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/processor.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 65eb1071e1..3edab1b893 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -47,10 +47,16 @@
 #define ARM_CPU_PART_CORTEX_A15 0xC0F
 #define ARM_CPU_PART_CORTEX_A53 0xD03
 #define ARM_CPU_PART_CORTEX_A57 0xD07
+#define ARM_CPU_PART_CORTEX_A72 0xD08
+#define ARM_CPU_PART_CORTEX_A73 0xD09
+#define ARM_CPU_PART_CORTEX_A75 0xD0A
 
 #define MIDR_CORTEX_A15 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A15)
 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A53)
 #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A57)
+#define MIDR_CORTEX_A72 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A72)
+#define MIDR_CORTEX_A73 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A73)
+#define MIDR_CORTEX_A75 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A75)
 
 /* MPIDR Multiprocessor Affinity Register */
 #define _MPIDR_UP   (30)
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v8 13/17] x86/boot: Calculate the most appropriate BTI mitigation to use

[Boris Ostrovsky]

On 01/12/2018 01:01 PM, Andrew Cooper wrote:
>  
> +if ( boot_cpu_has(X86_FEATURE_IBRSB) )
> +{
> +/*
> + * Even if we've chosen to not have IBRS set in Xen context, we still
> + * need the IBRS entry/exit logic to virtualise IBRS support for
> + * guests.
> + */
> +if ( ibrs )
> +setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_SET);
> +else
> +setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_CLEAR);
> +}
>

Are you going to add support for Intel's "Enhanced IBRS" (I think that's
what they call the "always on" mode")?

-boris

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

Re: [Xen-devel] [PATCH v8 02/17] x86: Support indirect thunks from assembly code

[Jan Beulich]

>>> On 16.01.18 at 14:55,  wrote:
> On 15/01/18 10:28, Jan Beulich wrote:
>>>  ctxt->io_emul_stub[10] = 0xff;
>>>  ctxt->io_emul_stub[11] = 0xd1;
>>>  
>>> +/*
>>> + * 3 bytes of P6_NOPS.
>>> + * TODO: untangle ideal_nops from init/livepatch Kconfig options.
>>> + */
>>> +memcpy(>io_emul_stub[12], "\x0f\x1f\x00", 3);
>> Perhaps better "P6_NOP3" in the comment? And perhaps
>> __stringify(P6_NOP3) in the memcpy() invocation, which may then
>> make unnecessary that part of the comment?
> 
> __stringify(P6_NOP3) really doesn't do what you expect here.  This is
> the preprocessed result:
> 
> __builtin_memcpy(>io_emul_stub[12], "0x0f,0x1f,0x00", 3);

Oops, of course - I'm sorry for the noise.

Jan


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

Re: [Xen-devel] [PATCH v8 02/17] x86: Support indirect thunks from assembly code

[Andrew Cooper]

On 15/01/18 10:28, Jan Beulich wrote:
>>  ctxt->io_emul_stub[10] = 0xff;
>>  ctxt->io_emul_stub[11] = 0xd1;
>>  
>> +/*
>> + * 3 bytes of P6_NOPS.
>> + * TODO: untangle ideal_nops from init/livepatch Kconfig options.
>> + */
>> +memcpy(>io_emul_stub[12], "\x0f\x1f\x00", 3);
> Perhaps better "P6_NOP3" in the comment? And perhaps
> __stringify(P6_NOP3) in the memcpy() invocation, which may then
> make unnecessary that part of the comment?

__stringify(P6_NOP3) really doesn't do what you expect here.  This is
the preprocessed result:

__builtin_memcpy(>io_emul_stub[12], "0x0f,0x1f,0x00", 3);

I've fixed up the other points, but left this one opencoded.

~Andrew

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

Re: [Xen-devel] [Embedded-pv-devel] Xen on RCarH3 Starter Kit

[Andrii Anisov]

Dear Ganesh,

Could you please specify your exact target board? Is it salvator-x or
starter kit premier (h3ulcb)?
Actually Renesas BSP 2.19.0 is easily being built for salvator-x. In
step 8 you should select an appropriate conf from
`meta-rcar-gen3/docs/sample/conf/salvator-x/`.

> But the Yocto build instructions given in the link is for RcarH3 Starter
> kit.So I am unable to find Image-r8a7795-salvator-x-xen.dtb
You would not find it if you build for u3ulcb machine, this is
restricted in the recipe [1].

> and xen-salvator-x.uImage which is mentioned in the tutorial.
I guess in your build it is named xen-h3ulcb.uImage, it is set in
another recipe [2].

> Does the Xen dtb and uImage for salvator will work on RCarH3 starter kit.
Xen image is machine agnostic. Salvator-X specific dtb is not suitable
for h3ulcb.

> Can anyone explain what can be the issue and the fix for it.
Add a h3ulcb device tree to [3], update recipe [2].
Do not forget to PR the stuff to our meta-demo.

[1] - 
https://github.com/xen-troops/meta-demo/blob/master/meta-rcar-gen3-xen/recipes-kernel/linux/linux-renesas_4.9.bbappend#L13

[2] - 
https://github.com/xen-troops/meta-demo/blob/master/meta-rcar-gen3-xen/recipes-extended/xen/xen_git.bbappend#L17

[3] - 
https://github.com/xen-troops/meta-demo/tree/master/meta-rcar-gen3-xen/recipes-kernel/linux/linux-renesas

Sincerely,
Andrii Anisov.


2018-01-16 8:52 GMT+02:00 Ganesh  H :
> Hi,
>
>
>
> Does Xen support RCarH3 Starter Kit -  https://elinux.org/R-Car/Boards/H3SK
>
>
>
> I followed the build procedures explained in this link for Salvator X -
> https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
>
>
>

>
> Can anyone explain what can be the issue and the fix for it. Does the Xen
> dtb and uImage for salvator will work on RCarH3 starter kit.
>
>
>
> Best Regards
>
> Ganesh.H
>
>
>
>
> ___
> Embedded-pv-devel mailing list
> embedded-pv-de...@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/embedded-pv-devel

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

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

[Jan Beulich]

>>> On 16.01.18 at 14:20,  wrote:
> The isolation is definitely not complete.  Amongst other things, remote
> stacks are in view of an attacker, which is why my KAISER-prereq series
> pushes for the fully isolated per-pcpu range.

How are remote stacks visible? The local page tables contain only
mappings of the local CPU's stack.

Jan


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

[Xen-devel] Access I2C bus from guest/DomU on ARM board

[Saumya Rajesh]

Hi Xen community


I have built and brought up Xen 4.8 on Renesas RCar H3. For a specific
requirement, I need to use the I2C bus of the board from Domain U. Is there
a way to use the I2C bus from the guest?
I have looked into para-virtualization and passthrough [1][2] but there
isn't enough support or resources related to I2C bus sharing on ARM. Any
possible idea would be appreciated.

Regards
Saumya

[1]
https://lists.xenproject.org/archives/html/xen-users/2017-10/msg00019.html
[2] https://wiki.xenproject.org/wiki/File:DriverDomainonARM01.pdf
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC v4 8/8] drivers/passthrough/arm: Refactor code for arm smmu drivers

[Julien Grall]

Hi Manish,

On 16/01/18 13:27, Manish Jaggi wrote:



On 01/16/2018 06:44 PM, Julien Grall wrote:



On 16/01/18 12:40, Manish Jaggi wrote:

Hi Julien,


Hi,


On 01/16/2018 02:11 AM, Julien Grall wrote:



On 01/03/2018 05:34 AM, Manish Jaggi wrote:

Hi Sameer,


Hi Manish,


+    unsigned int    type;
+
+    /* Dummy compatibility defines */
+    unsigned long pgsize_bitmap;
+    struct iommu_domain_geometry geometry;
+
+    atomic_t ref;
+    /* Used to link iommu_domain contexts for a same domain.
+ * There is at least one per-SMMU to used by the domain.
+ */
+    struct list_head    list;
+};
+
+/* Xen: Describes information required for a Xen domain */
+struct arm_smmu_xen_domain {
+    spinlock_t  lock;
+    /* List of iommu domains associated to this domain */
+    struct list_head    contexts;
Could we use a more verbose name, How about 
%s/contexts/iommu_domain_contexts/g ?


How about a much more verbose name...? This name is 21 letters and 
that's only for the field. Just imagine with the variable name 
before and a couple of indentation.
How about io_context? anything which makes it more verbose is ok with 
me.


I much prefer to stick with "contexts".
I am not able to understand why to use contexts for a list which has 
iommu_domain pointers.


Because the comment should have been read "iommu_domain context". As it 
is in other description.


If you are ok with this logic, we can rename all iommu_domain pointer 
variables in this file as context.


Why do you keep asking renaming when I clearly said multiple time that 
we *should not* rename any code coming from Linux. This is breaking the 
idea of keeping Xen and Linux SMMU driver close.


If you don't want to get SMMUv3 close to Linux. Then fine, but it means 
you have to use Xen coding style and dropping all necessary code.


But I am afraid this is not the solution I (and AFAIK Stefano) prefer 
because it adds burden on maintenance on Xen community.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC v4 8/8] drivers/passthrough/arm: Refactor code for arm smmu drivers

[Manish Jaggi]

On 01/16/2018 06:44 PM, Julien Grall wrote:



On 16/01/18 12:40, Manish Jaggi wrote:

Hi Julien,


Hi,


On 01/16/2018 02:11 AM, Julien Grall wrote:



On 01/03/2018 05:34 AM, Manish Jaggi wrote:

Hi Sameer,


Hi Manish,


+    unsigned int    type;
+
+    /* Dummy compatibility defines */
+    unsigned long pgsize_bitmap;
+    struct iommu_domain_geometry geometry;
+
+    atomic_t ref;
+    /* Used to link iommu_domain contexts for a same domain.
+ * There is at least one per-SMMU to used by the domain.
+ */
+    struct list_head    list;
+};
+
+/* Xen: Describes information required for a Xen domain */
+struct arm_smmu_xen_domain {
+    spinlock_t  lock;
+    /* List of iommu domains associated to this domain */
+    struct list_head    contexts;
Could we use a more verbose name, How about 
%s/contexts/iommu_domain_contexts/g ?


How about a much more verbose name...? This name is 21 letters and 
that's only for the field. Just imagine with the variable name 
before and a couple of indentation.
How about io_context? anything which makes it more verbose is ok with 
me.


I much prefer to stick with "contexts".
I am not able to understand why to use contexts for a list which has 
iommu_domain pointers.
If you are ok with this logic, we can rename all iommu_domain pointer 
variables in this file as context.
It is not intuitive to use context for iommu_domain in the same file it 
is confusing.


smmu code in xen is not easy to read.
There are other places which confuse...

|struct arm_smmu_xen_domain *xen_domain = dom_iommu(d)->arch.priv; What 
is the first impression from this variable xen_domain, does it refer to 
a VM ? It is confusing. |




Cheers,




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

Re: [Xen-devel] [PATCH v2 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

[Andrew Cooper]

On 16/01/18 12:33, Jan Beulich wrote:
>>
>> On 15.01.18 at 19:23,  wrote:
  can we collect these together into macros, rather than
 opencoding?  We seem to have 3 distinct variations.
>>> I had considered that (following the model you use in the SP2
>>> series), but decided against it not the least because of the
>>> dependent but placement-wise separated code additions to
>>> restore original values. Plus again this might be a hindrance of
>>> backporting to really old Xen (which then typically will also be
>>> built on really old tool chains) - as you certainly recall old gas
>>> had quite a few issues with macro handling.
>> There is nothing special in these macros though?  I found the SP2-style
>> far easier to backport because they are a single slot-in line.
> I've just found the patch here needing a change in register use
> in 4.7 - such would be a little harder with pre-cooked macros,
> especially when they don't allow to specify all registers to be
> used (including ones for temporaries).
>
>> Anyway, I'm not overly fussed, but I have a
> Unfinished sentence?

Oops.  "I have a feeling that the duplication will lead to subtle bugs
when we need to change things, and inevitably miss one."

>
> @@ -585,6 +692,17 @@ ENTRY(double_fault)
>  movl  $TRAP_double_fault,4(%rsp)
>  /* Set AC to reduce chance of further SMAP faults */
>  SAVE_ALL STAC
> +
> +GET_STACK_END(bx)
> +mov   STACK_CPUINFO_FIELD(xen_cr3)(%rbx), %rbx
> +test  %rbx, %rbx
> +jz.Ldblf_cr3_okay
> +jns   .Ldblf_cr3_load
> +neg   %rbx
> +.Ldblf_cr3_load:
> +write_cr3 rbx, rdi, rsi
> +.Ldblf_cr3_okay:
> +
 It is moderately common for there to be cascade faults in #DF.  This
 would be better if it were the general IST switch.
>>> Based on the issues I had with #DF occurring while debugging this,
>>> I've decided to keep the code here as simple as possible without
>>> being incorrect: There's no point looking at the incoming CR3.
>>> There's no point in trying to avoid nested faults (including
>>> subsequent #DF) restoring CR3. There's also no point in retaining
>>> the value for later restoring here, as we never return. In fact, as
>>> mentioned elsewhere, we should imo indeed consider unilaterally
>>> switching to idle_pg_table[] here.
>> Ok.
> "Ok" to which parts of this - keeping the code simple, switching to
> idle_pg_table[] (perhaps in a follow-up patch), or both?

Keeping the code as it is now, and adjusting in a follow-up.  Thinking
about things, idle_pg_table[], while nice, is incompatible with a more
complete isolation strategy.

~Andrew

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

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

[Andrew Cooper]

On 16/01/18 08:12, Jan Beulich wrote:
 On 15.01.18 at 19:26,  wrote:
>> On 15/01/18 11:07, Jan Beulich wrote:
>>> --- a/docs/misc/xen-command-line.markdown
>>> +++ b/docs/misc/xen-command-line.markdown
>>> @@ -1849,6 +1849,15 @@ In the case that x2apic is in use, this
>>>  clustered mode.  The default, given no hint from the **FADT**, is cluster
>>>  mode.
>>>  
>>> +### xpti
>>> +> `= `
>>> +
>>> +> Default: `false` on AMD hardware
>>> +> Default: `true` everywhere else
>> This is fine for now, but any further isolation is going to have to be
>> unconditional, or possibly compile-time choice, but maintaining that
>> going forwards is going to be truly horrible.
>>
>>> +
>>> +Override default selection of whether to isolate 64-bit PV guest page
>>> +tables.
>> This wants a
>>
>> ** WARNING: Not yet a complete isolation implementation, but better than
>> nothing. **
>>
>> or similar, just to avoid giving the people the impression that it is
>> complete.  Perhaps also a similar warning in the patch 1 commit message?
> I've added the warning text here as suggested, and a respective
> remark to patch 1's description, albeit under the current guidelines
> of when we would consider an information leak a security issue, I
> think isolation is sufficiently complete: No parts of the direct map
> not pertaining to the current guest are being exposed, which
> implies that no parts of the Xen heap not pertaining to the current
> guest are. Leaking control page contents of other guests as well
> as leaking the bits and pieces of the Xen image is not an issue by
> itself.
>
> IOW I'm not convinced such a warning is - strictly from a "would
> this need an XSA on its own" pov - entirely appropriate.

The isolation is definitely not complete.  Amongst other things, remote
stacks are in view of an attacker, which is why my KAISER-prereq series
pushes for the fully isolated per-pcpu range.

We do not, under any circumstances, want to give the impression that
this patch makes them completely immune to leaks, but improvements on
this status quo shouldn't need an XSA.

~Andrew

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

Re: [Xen-devel] [RFC v4 6/8] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Julien Grall]

Hi,

On 16/01/18 12:37, Manish Jaggi wrote:

On 01/16/2018 02:04 AM, Julien Grall wrote:

On 01/03/2018 05:47 AM, Manish Jaggi wrote:
+int devm_request_threaded_irq(struct device *dev, unsigned int irq, 
irq_handler_t handler,

+  irq_handler_t thread_fn, unsigned long irqflags,
+  const char *devname, void *dev_id)
+{
+    return devm_request_irq(dev, irq, thread_fn, irqflags, devname, 
dev_id);

+}
Is it possible to change the name from threaded to something more 
meaningful as IIUC in xen we dont  have threaded irqs.
Though the code is coming from linux, but it has to be called/named 
in the place it is intended to be used


What do you mean? This is a wrapper for Linux. So we should keep the 
name as it is.

It creates confusion as xne doesnt use threads. So we should rename it.
There is no reason why we cannot rename a function used in linux.


Read my previous e-mail until the end to understand the reason...



[...]


@@ -433,6 +807,7 @@ enum pri_resp {
  PRI_RESP_SUCC,
  };
+#if 0 /* Xen: No MSI support in this iteration */
  enum arm_smmu_msi_index {
  EVTQ_MSI_INDEX,
  GERROR_MSI_INDEX,
@@ -457,6 +832,7 @@ static phys_addr_t 
arm_smmu_msi_cfg[ARM_SMMU_MAX_MSIS][3] = {

  ARM_SMMU_PRIQ_IRQ_CFG2,
  },
  };
+#endif
IMHO can we avoid #if 0 from the code, unless we intend to use the 
code in future.


In the past, I made the mistake to remove all unecessary code from 
SMMUv2. Few months after, we decided to delete it and import directly 
from Linux with limited modifications. This was the best choice 
because it is easier to track difference.


We are in the same situation here. We want to stay as close as Linux. 
This means no renaming, no code removal, and very limited change in 
the code to accommodate Xen.


... particularly this paragraph.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] Rudolph: merging Vixen and Comet

[Roger Pau Monné]

On Tue, Jan 16, 2018 at 12:46:10PM +, Wei Liu wrote:
> On Fri, Jan 12, 2018 at 01:24:09PM +, Wei Liu wrote:
> > Hi all,
> > 
> > Two solutions are proposed to mitigate Meltdown. One is called Vixen and the
> > other is called Comet. The long term goal is to merge the two 
> > implementations
> > to one.
> > 
> > Here I list the differences between the two implementations.
> > 
> >   Vixen  Comet
> > Boot mode HVMPVH + HVM
> > Kconfig options   XEN_GUEST  XEN_GUEST + PVH_GUEST 
> > + SHIM_EXCLUSIVE
> > Xen build system  No change  New build target for 
> > shim 
> > Guest console Output onlyBi-directional
> > Guest domid   1 or set via shim option   1 or retrieved via 
> > cpuid
> > Guest typeHardware domainNormal domain
> > Time source   Emulated   Xen PV clock
> > Shutdown  PV + HWPV
> > SI mappingReserved page  Fixed map, PFN chosen 
> > at runtime
> > VCPU id   Handled by L1  Provide by L0 if 
> > available
> > VCPU runstate Forwarded to L0Handled by L1
> > Xen version   L0 version L1 version
> > CPUID faultingNone   Changes for Intel and 
> > AMD
> > Grant table   What is forwarded is more or less the same but 
> > differs in implementation
> > Event channel setup   3 mechanisms   1 mechanism
> > Event channel ECS_PROXY stateUse ECS_RESERVED
> >   Differences in what gets forwarded
> > Migration No Yes
> > CPU hotplug   No Yes
> > Memory hotplugNo Yes
> > 
> > These are the things I can think of when comparing the two series side
> > by side.  Feel free to provide addition and / or correction.  The list
> > serves as a guidance on what areas need attention.
> 
> We've come to agree on the following goals among stakeholders:
> 
> 1. We will use Comet as base to develop Rudolph.
> 2. We will start to commit patches into staging and develop there.
> 3. We will maintain Vixen and Comet until Rudolph is ready. We will
>be cherry-picking bug fixes to Vixen and Comet as we develop Rudolph.
> 
> In order to make goal #3 easier, I suggest we commit Comet almost as-is
> to minimise the difference between staging and backported Comet
> branches.
> 
> I will post a version of Comet suitable for committing to staging as
> soon as possible.

Iff maintainers agree that a version of Comet will be committed to
staging now I think it should be 4.10.0-shim-comet rebased into
staging, so that further patches (including bugfixes) can be easily
backported to the 4.10.0-shim-comet branch.

Or else the whole point of committing something to staging is not so
important IMHO.

Roger.

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

Re: [Xen-devel] Rudolph: merging Vixen and Comet

[Wei Liu]

On Fri, Jan 12, 2018 at 01:24:09PM +, Wei Liu wrote:
> Hi all,
> 
> Two solutions are proposed to mitigate Meltdown. One is called Vixen and the
> other is called Comet. The long term goal is to merge the two implementations
> to one.
> 
> Here I list the differences between the two implementations.
> 
>   Vixen  Comet
> Boot mode HVMPVH + HVM
> Kconfig options   XEN_GUEST  XEN_GUEST + PVH_GUEST + 
> SHIM_EXCLUSIVE
> Xen build system  No change  New build target for 
> shim 
> Guest console Output onlyBi-directional
> Guest domid   1 or set via shim option   1 or retrieved via cpuid
> Guest typeHardware domainNormal domain
> Time source   Emulated   Xen PV clock
> Shutdown  PV + HWPV
> SI mappingReserved page  Fixed map, PFN chosen at 
> runtime
> VCPU id   Handled by L1  Provide by L0 if 
> available
> VCPU runstate Forwarded to L0Handled by L1
> Xen version   L0 version L1 version
> CPUID faultingNone   Changes for Intel and AMD
> Grant table   What is forwarded is more or less the same but differs 
> in implementation
> Event channel setup   3 mechanisms   1 mechanism
> Event channel ECS_PROXY stateUse ECS_RESERVED
>   Differences in what gets forwarded
> Migration No Yes
> CPU hotplug   No Yes
> Memory hotplugNo Yes
> 
> These are the things I can think of when comparing the two series side
> by side.  Feel free to provide addition and / or correction.  The list
> serves as a guidance on what areas need attention.

We've come to agree on the following goals among stakeholders:

1. We will use Comet as base to develop Rudolph.
2. We will start to commit patches into staging and develop there.
3. We will maintain Vixen and Comet until Rudolph is ready. We will
   be cherry-picking bug fixes to Vixen and Comet as we develop Rudolph.

In order to make goal #3 easier, I suggest we commit Comet almost as-is
to minimise the difference between staging and backported Comet
branches.

I will post a version of Comet suitable for committing to staging as
soon as possible.  We will start porting over functionalities from Vixen
once Comet is committed.

In the meantime I will also collect patches for Vixen and Comet and
forward port them when necessary.

Wei.

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

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

[George Dunlap]

On Tue, Jan 16, 2018 at 12:35 PM, Jan Beulich  wrote:
 On 16.01.18 at 13:12,  wrote:
>> On Mon, Jan 15, 2018 at 11:07 AM, Jan Beulich  wrote:
>>> First of all we don't need it on AMD systems. Additionally allow its use
>>> to be controlled by command line option. For best backportability, this
>>> intentionally doesn't use alternative instruction patching to achieve
>>> the intended effect - while we likely want it, this will be later
>>> follow-up.
>>
>> Is it worth making it optional to apply to dom0?  In most cases, if an
>> attacker can manage to get userspace on dom0, they should be able to
>> take over the whole system anyway; turning it off on dom0 to get
>> better performance seems like a policy decision that administrators
>> might reasonably make.
>
> Irrespective of Jürgen's reply (which I agree with) this would be an
> option, but I'd prefer to fold this into the stage 2 activities (if we
> really want it in the first place).

That sounds reasonable.

 -George

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

Re: [Xen-devel] [RFC v4 8/8] drivers/passthrough/arm: Refactor code for arm smmu drivers

[Manish Jaggi]

Hi Julien,


On 01/16/2018 02:11 AM, Julien Grall wrote:



On 01/03/2018 05:34 AM, Manish Jaggi wrote:

Hi Sameer,


Hi Manish,


+    unsigned int    type;
+
+    /* Dummy compatibility defines */
+    unsigned long pgsize_bitmap;
+    struct iommu_domain_geometry geometry;
+
+    atomic_t ref;
+    /* Used to link iommu_domain contexts for a same domain.
+ * There is at least one per-SMMU to used by the domain.
+ */
+    struct list_head    list;
+};
+
+/* Xen: Describes information required for a Xen domain */
+struct arm_smmu_xen_domain {
+    spinlock_t  lock;
+    /* List of iommu domains associated to this domain */
+    struct list_head    contexts;
Could we use a more verbose name, How about 
%s/contexts/iommu_domain_contexts/g ?


How about a much more verbose name...? This name is 21 letters and 
that's only for the field. Just imagine with the variable name before 
and a couple of indentation.

How about io_context? anything which makes it more verbose is ok with me.


This is where comment are helpful, a developer can easily look for the 
structure/field to see a description of the field. So let's not make 
the code more horrible because you would have to split the line.


Cheers,




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

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

[George Dunlap]

On Tue, Jan 16, 2018 at 12:21 PM, Juergen Gross  wrote:
> On 16/01/18 13:12, George Dunlap wrote:
>> On Mon, Jan 15, 2018 at 11:07 AM, Jan Beulich  wrote:
>>> First of all we don't need it on AMD systems. Additionally allow its use
>>> to be controlled by command line option. For best backportability, this
>>> intentionally doesn't use alternative instruction patching to achieve
>>> the intended effect - while we likely want it, this will be later
>>> follow-up.
>>
>> Is it worth making it optional to apply to dom0?  In most cases, if an
>> attacker can manage to get userspace on dom0, they should be able to
>> take over the whole system anyway; turning it off on dom0 to get
>> better performance seems like a policy decision that administrators
>> might reasonably make.
>
> You are implying here that Linux is insecure: why does userspace access
> allow you to take over the machine? I can see that being true for root
> access, but not for any other unprivileged user account.

Well first of all, go look at my talk about local root exploits in
Linux -- usually there are a few found every month.

But let's ignore that out for a minute.  Consider a "typical"
recommended dom0 setup:
- Dom0 on a separate network
- Nothing running on dom0 except Xen-related services, and toolstack

How would an attacker get userspace access on such a host at all?
- Attack a devicemodel running in dom0
- Attack a backend running in the kernel
- Attack xenstore

We don't yet have a deprivileged QEMu, so at the moment an attack on
any of these will already give you full control of the system.

Obviously this wouldn't be appropriate to all systems; but it could be
appropriate to a fair number of them.

 -George

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

Re: [Xen-devel] [RFC v4 6/8] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Manish Jaggi]

Hi Julien,


On 01/16/2018 02:04 AM, Julien Grall wrote:



On 01/03/2018 05:47 AM, Manish Jaggi wrote:


Hi Sameer,


Hi Manish,


+
+/* Xen: Type definitions for iommu_domain */
+#define IOMMU_DOMAIN_UNMANAGED 0
+#define IOMMU_DOMAIN_DMA 1
+#define IOMMU_DOMAIN_IDENTITY 2
+
+/* Xen: Dummy iommu_domain */
+struct iommu_domain {
+    /* Runtime SMMU configuration for this iommu_domain */
+    struct arm_smmu_domain    *priv;

Can we use a more meaningful name in place of priv.


I believe this was taken from the iommu_domain structure in SMMUv2 
which was based on an ancient version of Linux. It looks like recent 
Linux will not use priv, so I am wondering why it is added here?



+    unsigned int type;
+
+    /* Dummy compatibility defines */
+    unsigned long pgsize_bitmap;
+    struct iommu_domain_geometry geometry;
+
+    atomic_t ref;
+    /*
+ * Used to link iommu_domain contexts for a same domain.
+ * There is at least one per-SMMU to used by the domain.
+ */
+    struct list_head    list;
+};
+
+
+/* Xen: Describes information required for a Xen domain */
+struct arm_smmu_xen_domain {
+    spinlock_t    lock;
+    /* List of iommu domains associated to this domain */
+    struct list_head    iommu_domains;
+};
+
+/*
+ * Xen: Information about each device stored in dev->archdata.iommu
+ *
+ * The dev->archdata.iommu stores the iommu_domain (runtime 
configuration of

+ * the SMMU).
   */
+struct arm_smmu_xen_device {
+    struct iommu_domain *domain;
domain name is confusing, if you read just the variable name it is 
not easy to understand that it is a struct domain pointer or few 
other structures which have _domain in their names.

Same comment for all usages of variables with just the name domain.


If this is used by Xen only code, then it should be alright. Which 
name do you suggest? iommu_domain?

Looks ok.


[...]


+/*
+ * Xen: The pgtable_ops are used by the S1 translations, so return 
the dummy

+ * address.
+ */
+#define alloc_io_pgtable_ops(f, c, o) ((struct io_pgtable_ops 
*)0xDEADBEEF)

+#define free_io_pgtable_ops(o) (o = 0)
+
+/* Xen: Define wrapper for requesting IRQs */
+#define IRQF_ONESHOT 0
+
+typedef void (*irq_handler_t)(int, void *, struct cpu_user_regs *);
+
+static inline int devm_request_irq(struct device *dev, unsigned int 
irq,

+   irq_handler_t handler, unsigned long irqflags,
+   const char *devname, void *dev_id)
+{
+    /*TODO: Check if we really need to set a type */
+    irq_set_type(irq, IRQ_TYPE_EDGE_BOTH);
+    return request_irq(irq, irqflags, handler, devname, dev_id);
+
+}
+
+int devm_request_threaded_irq(struct device *dev, unsigned int irq, 
irq_handler_t handler,

+  irq_handler_t thread_fn, unsigned long irqflags,
+  const char *devname, void *dev_id)
+{
+    return devm_request_irq(dev, irq, thread_fn, irqflags, devname, 
dev_id);

+}
Is it possible to change the name from threaded to something more 
meaningful as IIUC in xen we dont  have threaded irqs.
Though the code is coming from linux, but it has to be called/named 
in the place it is intended to be used


What do you mean? This is a wrapper for Linux. So we should keep the 
name as it is.

It creates confusion as xne doesnt use threads. So we should rename it.
There is no reason why we cannot rename a function used in linux.


[...]


@@ -433,6 +807,7 @@ enum pri_resp {
  PRI_RESP_SUCC,
  };
+#if 0 /* Xen: No MSI support in this iteration */
  enum arm_smmu_msi_index {
  EVTQ_MSI_INDEX,
  GERROR_MSI_INDEX,
@@ -457,6 +832,7 @@ static phys_addr_t 
arm_smmu_msi_cfg[ARM_SMMU_MAX_MSIS][3] = {

  ARM_SMMU_PRIQ_IRQ_CFG2,
  },
  };
+#endif
IMHO can we avoid #if 0 from the code, unless we intend to use the 
code in future.


In the past, I made the mistake to remove all unecessary code from 
SMMUv2. Few months after, we decided to delete it and import directly 
from Linux with limited modifications. This was the best choice 
because it is easier to track difference.


We are in the same situation here. We want to stay as close as Linux. 
This means no renaming, no code removal, and very limited change in 
the code to accommodate Xen.


In that particular case, we likely going to want to support MSIs 
because an implementation may only support that.

ok for this case, but the code looks clumsy.


Cheers,



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

[Xen-devel] [PATCH V6] pci: removed the is_express field since a uniform interface was inserted

[Yoni Bettan]

according to Eduardo Habkost's commit fd3b02c889 all PCIEs now implement
INTERFACE_PCIE_DEVICE so we don't need is_express field anymore.

Devices that implements only INTERFACE_PCIE_DEVICE (is_express == 1)
or
devices that implements only INTERFACE_CONVENTIONAL_PCI_DEVICE (is_express == 0)
where not affected by the change.

The only devices that were affected are those that are hybrid and also
had (is_express == 1) - therefor only:
  - hw/vfio/pci.c
  - hw/usb/hcd-xhci.c
  - hw/xen/xen_pt.c

For those 3 I made sure that QEMU_PCI_CAP_EXPRESS is on in instance_init()

Reviewed-by: Marcel Apfelbaum 
Reviewed-by: Eduardo Habkost 
Signed-off-by: Yoni Bettan 
---

V5 --> V6 : rebased on Michael S. Tsirkin pci branch as requested.
V4 --> V5 : updated the patch to work with a new inserted device hw/xen/xen_pt.c
V3 --> V4 : added a comment on the devices to explain why cap_present is set
manually
V2 --> V3 : turned the cap_present on in instance_init instead of a
pre-reallize function that was created just for that purpose
V1 --> V2 : V1 was asked to be ignored


 docs/pcie_pci_bridge.txt   | 2 +-
 hw/block/nvme.c| 1 -
 hw/net/e1000e.c| 1 -
 hw/pci-bridge/pcie_pci_bridge.c| 1 -
 hw/pci-bridge/pcie_root_port.c | 1 -
 hw/pci-bridge/xio3130_downstream.c | 1 -
 hw/pci-bridge/xio3130_upstream.c   | 1 -
 hw/pci-host/xilinx-pcie.c  | 1 -
 hw/pci/pci.c   | 8 ++--
 hw/scsi/megasas.c  | 4 
 hw/usb/hcd-xhci.c  | 9 -
 hw/vfio/pci.c  | 5 -
 hw/xen/xen_pt.c| 9 -
 include/hw/pci/pci.h   | 3 ---
 14 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/docs/pcie_pci_bridge.txt b/docs/pcie_pci_bridge.txt
index 5a4203f97c..ab35ebf3ca 100644
--- a/docs/pcie_pci_bridge.txt
+++ b/docs/pcie_pci_bridge.txt
@@ -110,5 +110,5 @@ To enable device hot-plug into the bridge on Linux there're 
3 ways:
 Implementation
 ==
 The PCIE-PCI bridge is based on PCI-PCI bridge, but also accumulates PCI 
Express
-features as a PCI Express device (is_express=1).
+features as a PCI Express device.
 
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 1ac356d3a5..c4c7a0a1c5 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -1331,7 +1331,6 @@ static void nvme_class_init(ObjectClass *oc, void *data)
 pc->vendor_id = PCI_VENDOR_ID_INTEL;
 pc->device_id = 0x5845;
 pc->revision = 2;
-pc->is_express = 1;
 
 set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
 dc->desc = "Non-Volatile Memory Express";
diff --git a/hw/net/e1000e.c b/hw/net/e1000e.c
index 191398a3d5..16a9417a85 100644
--- a/hw/net/e1000e.c
+++ b/hw/net/e1000e.c
@@ -675,7 +675,6 @@ static void e1000e_class_init(ObjectClass *class, void 
*data)
 c->revision = 0;
 c->romfile = "efi-e1000e.rom";
 c->class_id = PCI_CLASS_NETWORK_ETHERNET;
-c->is_express = 1;
 
 dc->desc = "Intel 82574L GbE Controller";
 dc->reset = e1000e_qdev_reset;
diff --git a/hw/pci-bridge/pcie_pci_bridge.c b/hw/pci-bridge/pcie_pci_bridge.c
index a4d827c99d..b7d9ebbec2 100644
--- a/hw/pci-bridge/pcie_pci_bridge.c
+++ b/hw/pci-bridge/pcie_pci_bridge.c
@@ -169,7 +169,6 @@ static void pcie_pci_bridge_class_init(ObjectClass *klass, 
void *data)
 DeviceClass *dc = DEVICE_CLASS(klass);
 HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass);
 
-k->is_express = 1;
 k->is_bridge = 1;
 k->vendor_id = PCI_VENDOR_ID_REDHAT;
 k->device_id = PCI_DEVICE_ID_REDHAT_PCIE_BRIDGE;
diff --git a/hw/pci-bridge/pcie_root_port.c b/hw/pci-bridge/pcie_root_port.c
index 9b6e4ce512..45f9e8cd4a 100644
--- a/hw/pci-bridge/pcie_root_port.c
+++ b/hw/pci-bridge/pcie_root_port.c
@@ -145,7 +145,6 @@ static void rp_class_init(ObjectClass *klass, void *data)
 DeviceClass *dc = DEVICE_CLASS(klass);
 PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
 
-k->is_express = 1;
 k->is_bridge = 1;
 k->config_write = rp_write_config;
 k->realize = rp_realize;
diff --git a/hw/pci-bridge/xio3130_downstream.c 
b/hw/pci-bridge/xio3130_downstream.c
index 1e09d2afb7..613a0d6bb7 100644
--- a/hw/pci-bridge/xio3130_downstream.c
+++ b/hw/pci-bridge/xio3130_downstream.c
@@ -177,7 +177,6 @@ static void xio3130_downstream_class_init(ObjectClass 
*klass, void *data)
 DeviceClass *dc = DEVICE_CLASS(klass);
 PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
 
-k->is_express = 1;
 k->is_bridge = 1;
 k->config_write = xio3130_downstream_write_config;
 k->realize = xio3130_downstream_realize;
diff --git a/hw/pci-bridge/xio3130_upstream.c b/hw/pci-bridge/xio3130_upstream.c
index 227997ce46..d4645bddee 100644
--- a/hw/pci-bridge/xio3130_upstream.c
+++ b/hw/pci-bridge/xio3130_upstream.c
@@ -148,7 +148,6 @@ static void xio3130_upstream_class_init(ObjectClass *klass, 
void *data)
 DeviceClass 

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

[Jan Beulich]

>>> On 16.01.18 at 13:12,  wrote:
> On Mon, Jan 15, 2018 at 11:07 AM, Jan Beulich  wrote:
>> First of all we don't need it on AMD systems. Additionally allow its use
>> to be controlled by command line option. For best backportability, this
>> intentionally doesn't use alternative instruction patching to achieve
>> the intended effect - while we likely want it, this will be later
>> follow-up.
> 
> Is it worth making it optional to apply to dom0?  In most cases, if an
> attacker can manage to get userspace on dom0, they should be able to
> take over the whole system anyway; turning it off on dom0 to get
> better performance seems like a policy decision that administrators
> might reasonably make.

Irrespective of Jürgen's reply (which I agree with) this would be an
option, but I'd prefer to fold this into the stage 2 activities (if we
really want it in the first place).

Jan

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

Re: [Xen-devel] [PATCH v2 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

[Jan Beulich]

>>> On 16.01.18 at 12:51,  wrote:
> On 16/01/18 07:46, Jan Beulich wrote:
> On 15.01.18 at 19:23,  wrote:
>>> Also, can we collect these together into macros, rather than
>>> opencoding?  We seem to have 3 distinct variations.
>> I had considered that (following the model you use in the SP2
>> series), but decided against it not the least because of the
>> dependent but placement-wise separated code additions to
>> restore original values. Plus again this might be a hindrance of
>> backporting to really old Xen (which then typically will also be
>> built on really old tool chains) - as you certainly recall old gas
>> had quite a few issues with macro handling.
> 
> There is nothing special in these macros though?  I found the SP2-style
> far easier to backport because they are a single slot-in line.

I've just found the patch here needing a change in register use
in 4.7 - such would be a little harder with pre-cooked macros,
especially when they don't allow to specify all registers to be
used (including ones for temporaries).

> Anyway, I'm not overly fussed, but I have a

Unfinished sentence?

 @@ -71,6 +97,18 @@ iret_exit_to_guest:
  ALIGN
  /* No special register assumptions. */
  restore_all_xen:
 +/*
 + * Check whether we need to switch to the per-CPU page tables, in
 + * case we return to late PV exit code (from an NMI or #MC).
 + */
 +GET_STACK_END(ax)
 +mov   STACK_CPUINFO_FIELD(xen_cr3)(%rax), %rdx
 +mov   STACK_CPUINFO_FIELD(pv_cr3)(%rax), %rax
 +test  %rdx, %rdx
 +UNLIKELY_START(g, exit_cr3)
>>> cmp or ne ?
>> "ne" (or really "nz" when used with "test") is outright wrong - we
>> want to skip the restore when the value is zero _or_ negative.
>> What's wrong with "jg" and "test" in combination? There simply is
>> no "jnsz" (other than e.g. "jnbe"). "cmp" against zero could be
>> used here, but why would I use the larger instruction when "test"
>> does?
> 
> greater or less than is not commonly related to the test instruction,
> which is why this looks wrong to a reviewer.
> 
> A comment of /* Ideally jnsz, but jg will have to do */ would go a very
> long way.

Added.

> I've double checked the logic and I agree with your conclusions, but the
> only reason this works is because test unconditionally zeroes the
> overflow flag.

Because, well, there is no overflow possible for AND (and hence
TEST), OR, and XOR.

 @@ -585,6 +692,17 @@ ENTRY(double_fault)
  movl  $TRAP_double_fault,4(%rsp)
  /* Set AC to reduce chance of further SMAP faults */
  SAVE_ALL STAC
 +
 +GET_STACK_END(bx)
 +mov   STACK_CPUINFO_FIELD(xen_cr3)(%rbx), %rbx
 +test  %rbx, %rbx
 +jz.Ldblf_cr3_okay
 +jns   .Ldblf_cr3_load
 +neg   %rbx
 +.Ldblf_cr3_load:
 +write_cr3 rbx, rdi, rsi
 +.Ldblf_cr3_okay:
 +
>>> It is moderately common for there to be cascade faults in #DF.  This
>>> would be better if it were the general IST switch.
>> Based on the issues I had with #DF occurring while debugging this,
>> I've decided to keep the code here as simple as possible without
>> being incorrect: There's no point looking at the incoming CR3.
>> There's no point in trying to avoid nested faults (including
>> subsequent #DF) restoring CR3. There's also no point in retaining
>> the value for later restoring here, as we never return. In fact, as
>> mentioned elsewhere, we should imo indeed consider unilaterally
>> switching to idle_pg_table[] here.
> 
> Ok.

"Ok" to which parts of this - keeping the code simple, switching to
idle_pg_table[] (perhaps in a follow-up patch), or both?

Jan


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

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

[George Dunlap]

On Mon, Jan 15, 2018 at 11:07 AM, Jan Beulich  wrote:
> First of all we don't need it on AMD systems. Additionally allow its use
> to be controlled by command line option. For best backportability, this
> intentionally doesn't use alternative instruction patching to achieve
> the intended effect - while we likely want it, this will be later
> follow-up.

Is it worth making it optional to apply to dom0?  In most cases, if an
attacker can manage to get userspace on dom0, they should be able to
take over the whole system anyway; turning it off on dom0 to get
better performance seems like a policy decision that administrators
might reasonably make.

 -George

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

Re: [Xen-devel] [PATCH v2 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

[Andrew Cooper]

On 16/01/18 09:33, Jan Beulich wrote:
 On 15.01.18 at 19:23,  wrote:
>> On 15/01/18 11:06, Jan Beulich wrote:
>>> This also wants Andrew's "[PATCH RFC 11/44] x86/pt-shadow: Always set
>>> _PAGE_ACCESSED on L4e updates".
>> I've cleaned this patch up and committed it in preparation.
>>
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=bd61fe94bee0556bc2f6 
>> 4999a4a8315b93f90f21
> Only now that I'm doing backports thereof I notice an oddity with
> 32-bit guest handling: Why would you set the accessed bit in that
> case? The L4 is an internal thing there, and hence by us knowing
> that we don't care, this is unnecessary (but of course also not
> wrong). I'll do the 4.9 and older backports according to that
> observation (making for slightly less of a code change).

There are no paths leading to adjust_guest_l4e() for 32bit PV guests. 
The only L4 handling which exists is constructing the monitor table,
which writes the PTEs directly.

~Andrew

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64   6 xen-buildfail REGR. vs. 117930
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 117930

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 117930
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 117930
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 117930
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 117930
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 117930
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 117930
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-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-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  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:
 qemuuf5213bd060b460c99e605472b7e03967db43
baseline version:
 qemuu7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac

Last test of basis   117930  2018-01-12 23:48:34 Z3 days
Failing since118034  2018-01-15 10:18:58 Z1 days2 attempts
Testing same since   118091  2018-01-16 05:03:58 Z0 days1 attempts


People who touched revisions under test:
  Alexey Perevalov 
  Daniel P. Berrange 
  Dr. David Alan Gilbert 
  Frediano Ziglio 
  Gerd Hoffmann 
  Jindrich Makovicka 
  Juan Quintela 
  Laurent Vivier 
  linzhecheng 
  Peter Maydell 
  Peter Xu 
  Philippe Mathieu-Daudé 
  Samuel Thibault 
  Thomas Huth 
  

Re: [Xen-devel] [RFC v4 6/8] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Julien Grall]

On 01/03/2018 05:47 AM, Manish Jaggi wrote:


Hi Sameer,


Hi Manish,


+
+/* Xen: Type definitions for iommu_domain */
+#define IOMMU_DOMAIN_UNMANAGED 0
+#define IOMMU_DOMAIN_DMA 1
+#define IOMMU_DOMAIN_IDENTITY 2
+
+/* Xen: Dummy iommu_domain */
+struct iommu_domain {
+    /* Runtime SMMU configuration for this iommu_domain */
+    struct arm_smmu_domain    *priv;

Can we use a more meaningful name in place of priv.


I believe this was taken from the iommu_domain structure in SMMUv2 which 
was based on an ancient version of Linux. It looks like recent Linux 
will not use priv, so I am wondering why it is added here?



+    unsigned int type;
+
+    /* Dummy compatibility defines */
+    unsigned long pgsize_bitmap;
+    struct iommu_domain_geometry geometry;
+
+    atomic_t ref;
+    /*
+ * Used to link iommu_domain contexts for a same domain.
+ * There is at least one per-SMMU to used by the domain.
+ */
+    struct list_head    list;
+};
+
+
+/* Xen: Describes information required for a Xen domain */
+struct arm_smmu_xen_domain {
+    spinlock_t    lock;
+    /* List of iommu domains associated to this domain */
+    struct list_head    iommu_domains;
+};
+
+/*
+ * Xen: Information about each device stored in dev->archdata.iommu
+ *
+ * The dev->archdata.iommu stores the iommu_domain (runtime 
configuration of

+ * the SMMU).
   */
+struct arm_smmu_xen_device {
+    struct iommu_domain *domain;
domain name is confusing, if you read just the variable name it is not 
easy to understand that it is a struct domain pointer or few other 
structures which have _domain in their names.

Same comment for all usages of variables with just the name domain.


If this is used by Xen only code, then it should be alright. Which name 
do you suggest? iommu_domain?


[...]


+/*
+ * Xen: The pgtable_ops are used by the S1 translations, so return 
the dummy

+ * address.
+ */
+#define alloc_io_pgtable_ops(f, c, o) ((struct io_pgtable_ops 
*)0xDEADBEEF)

+#define free_io_pgtable_ops(o) (o = 0)
+
+/* Xen: Define wrapper for requesting IRQs */
+#define IRQF_ONESHOT 0
+
+typedef void (*irq_handler_t)(int, void *, struct cpu_user_regs *);
+
+static inline int devm_request_irq(struct device *dev, unsigned int irq,
+   irq_handler_t handler, unsigned long irqflags,
+   const char *devname, void *dev_id)
+{
+    /*TODO: Check if we really need to set a type */
+    irq_set_type(irq, IRQ_TYPE_EDGE_BOTH);
+    return request_irq(irq, irqflags, handler, devname, dev_id);
+
+}
+
+int devm_request_threaded_irq(struct device *dev, unsigned int irq, 
irq_handler_t handler,

+  irq_handler_t thread_fn, unsigned long irqflags,
+  const char *devname, void *dev_id)
+{
+    return devm_request_irq(dev, irq, thread_fn, irqflags, devname, 
dev_id);

+}
Is it possible to change the name from threaded to something more 
meaningful as IIUC in xen we dont  have threaded irqs.
Though the code is coming from linux, but it has to be called/named in 
the place it is intended to be used


What do you mean? This is a wrapper for Linux. So we should keep the 
name as it is.


[...]


@@ -433,6 +807,7 @@ enum pri_resp {
  PRI_RESP_SUCC,
  };
+#if 0 /* Xen: No MSI support in this iteration */
  enum arm_smmu_msi_index {
  EVTQ_MSI_INDEX,
  GERROR_MSI_INDEX,
@@ -457,6 +832,7 @@ static phys_addr_t 
arm_smmu_msi_cfg[ARM_SMMU_MAX_MSIS][3] = {

  ARM_SMMU_PRIQ_IRQ_CFG2,
  },
  };
+#endif
IMHO can we avoid #if 0 from the code, unless we intend to use the code 
in future.


In the past, I made the mistake to remove all unecessary code from 
SMMUv2. Few months after, we decided to delete it and import directly 
from Linux with limited modifications. This was the best choice because 
it is easier to track difference.


We are in the same situation here. We want to stay as close as Linux. 
This means no renaming, no code removal, and very limited change in the 
code to accommodate Xen.


In that particular case, we likely going to want to support MSIs because 
an implementation may only support that.


Cheers,

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

Re: [Xen-devel] [PATCH v8 08/17] x86/msr: Emulation of MSR_{SPEC_CTRL, PRED_CMD} for guests

[David Woodhouse]

On Fri, 2018-01-12 at 18:00 +, Andrew Cooper wrote:
> 
> @@ -152,14 +163,38 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr,
> uint64_t val)
>  {
>  const struct vcpu *curr = current;
>  struct domain *d = v->domain;
> +    const struct cpuid_policy *cp = d->arch.cpuid;
>  struct msr_domain_policy *dp = d->arch.msr;
>  struct msr_vcpu_policy *vp = v->arch.msr;
>  
>  switch ( msr )
>  {
>  case MSR_INTEL_PLATFORM_INFO:
> +    /* Read-only */
>  goto gp_fault;
>  
> +    case MSR_SPEC_CTRL:
> +    if ( !cp->feat.ibrsb )
> +    goto gp_fault; /* MSR available? */
> +    if ( val & ~(SPEC_CTRL_IBRS |
> + (cp->feat.stibp ? SPEC_CTRL_STIBP : 0)) )

Intel defines the STIBP bit as non-faulting and ignored, even when
STIBP isn't advertised. So you should probably just mask it out
if !cp->feat.stibp.

> +    goto gp_fault; /* Rsvd bit set? */
> +    vp->spec_ctrl.guest = val;
> +    vp->spec_ctrl.host  = val;
> +    break;
> +

There's no actual wrmsr there. This is fine, because you're going to do
it on the way back to the guest (albeit in a later patch in the
series). But it probably warrants a comment?


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 v2] -xen-attach is needed for pvh boot with qemu-xen

[Wei Liu]

On Mon, Jan 15, 2018 at 09:23:20PM +, Michael Young wrote:
> Currently the boot of a pvh guest using the qemu-xen device model fails
> with the error
> xen emulation not implemented (yet)
> in the qemu-dm log file. This patch adds the missing -xen-attach
> argument.
> 
> V2: Use  b_info->type != LIBXL_DOMAIN_TYPE_HVMinstead of
>   (b_info->type == LIBXL_DOMAIN_TYPE_PV) ||
>   (b_info->type == LIBXL_DOMAIN_TYPE_PVH)
> as recommended by Roger Pau Monné.
> 
> Signed-off-by: Michael Young 
> Reviewed-by: Roger Pau Monné 
> 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] x86: Meltdown band-aid against malicious 64-bit PV guests

[George Dunlap]

On 01/16/2018 07:12 AM, Jan Beulich wrote:
 On 15.01.18 at 17:54,  wrote:
>> On Jan 12, 2018, at 05:19, Jan Beulich  wrote:
>>>
>>> This is a very simplistic change limiting the amount of memory a running
>>> 64-bit PV guest has mapped (and hence available for attacking): Only the
>>> mappings of stack, IDT, and TSS are being cloned from the direct map
>>> into per-CPU page tables. Guest controlled parts of the page tables are
>>> being copied into those per-CPU page tables upon entry into the guest.
>>> Cross-vCPU synchronization of top level page table entry changes is
>>> being effected by forcing other active vCPU-s of the guest into the
>>> hypervisor.
>>>
>>> The change to context_switch() isn't strictly necessary, but there's no
>>> reason to keep switching page tables once a PV guest is being scheduled
>>> out.
>>>
>>> There is certainly much room for improvement, especially of performance,
>>> here - first and foremost suppressing all the negative effects on AMD
>>> systems. But in the interest of backportability (including to really old
>>> hypervisors, which may not even have alternative patching) any such is
>>> being left out here.
>>
>> Thanks for releasing this patch to support use cases not covered by the 
>> previous mitigations.  Is there a name or acronym we can use to reference 
>> this patch in the FAQ, XSA and other support documents?
> 
> I'm against any such naming, but XPTI-light would come to mind.

Rich, I'm afraid we tend to be a pedestrian bunch when it comes to
naming. :-)

I personally much prefer labels that contain enough information to hint
as to what the thing being referred to is.  One of the things I really
dislike about, say, OpenStack, is the hundreds of projects they have,
each with a cute name that people throw around, that as an outsider you
have no idea what they're talking about, and no real way to find out
rather than brute-force memorization.

Vixen / Comet thing was a special case.  First of all, Amazon had
already named Vixen; but even so, I initially referred to the two shims
as "the HVM shim" and "the PVH shim".  But when "the HVM shim" began to
get PVH support, and "the PVH shim" successfully got HVM support, those
names started to be inaccurate.  They really were just different
versions of the same thing (even sharing a lot of the same code).  Under
those circumstances, there's not much choice but to give "meaningless"
names.

Hopefully we'll never be in a position of discussing which of two
nearly-identical XPTI patches to start future development from, nor of
presenting two nearly-identical XPTI patchsets to our downstreams.

Since it seems like we may have several iterations of an SP3 solution,
each of which adds more protection / improves performance on previous
iterations, what about adding a number?  Say, "XPTI stage 1"?

Then we can discuss which technical mitigations will be in each 'stage'
that we release.

 -George

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

Re: [Xen-devel] [PATCH v2 1/2] x86: Meltdown band-aid against malicious 64-bit PV guests

[Jan Beulich]

>>> On 15.01.18 at 19:23,  wrote:
> On 15/01/18 11:06, Jan Beulich wrote:
>> This also wants Andrew's "[PATCH RFC 11/44] x86/pt-shadow: Always set
>> _PAGE_ACCESSED on L4e updates".
> 
> I've cleaned this patch up and committed it in preparation.
> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=bd61fe94bee0556bc2f6 
> 4999a4a8315b93f90f21

Only now that I'm doing backports thereof I notice an oddity with
32-bit guest handling: Why would you set the accessed bit in that
case? The L4 is an internal thing there, and hence by us knowing
that we don't care, this is unnecessary (but of course also not
wrong). I'll do the 4.9 and older backports according to that
observation (making for slightly less of a code change).

Jan


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

Re: [Xen-devel] [xen-unstable test] 118078: regressions - FAIL

[Jan Beulich]

>>> On 16.01.18 at 09:43,  wrote:
> flight 118078 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/118078/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-arm64-pvops 6 kernel-build fail REGR. vs. 
> 118003
>  test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 
> 118003

Paul,

is this last one something you could look into?

(XEN) d4: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 sp: 0 build: 
1db0
(XEN) d4: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3
(XEN) d4v0: VIRIDIAN VP_ASSIST_PAGE: enabled: 1 pfn: 3fffe
(XEN) domain_crash called from viridian.c:452
(XEN) Domain 4 (vcpu#0) crashed on cpu#1:
(XEN) [ Xen-4.11-unstable  x86_64  debug=y   Not tainted ]
(XEN) CPU:1
(XEN) RIP:0010:[]
(XEN) RFLAGS: 0286   CONTEXT: hvm guest (d4v0)
(XEN) rax:    rbx: f800027f7e80   rcx: 0001
(XEN) rdx:    rsi: fa800129d040   rdi: f80002805c40
(XEN) rbp: 0080   rsp: f880009b0d80   r8:  
(XEN) r9:  f800027f7e80   r10: fa800129d040   r11: f800027f7e90
(XEN) r12: f88129a0   r13: f800028b9be0   r14: fa8001239b30
(XEN) r15: f8b96080   cr0: 80050031   cr4: 06b8
(XEN) cr3: 00187000   cr2: 
(XEN) fsb:    gsb: f800027f7d00   gss: f800027f7d00
(XEN) ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018   cs: 0010

I.e. the domain_crash() in viridian_start_apic_assist().

Jan


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

Re: [Xen-devel] [PATCH RESEND v1 0/7] Intel Processor Trace virtulization enabling

[Jan Beulich]

>>> On 15.01.18 at 19:12,  wrote:
> Luwei Kang (7):
>   x86: add a flag to enable Intel processor trace
>   x86: configure vmcs for Intel processor trace virtualization
>   x86: add intel proecessor trace support for cpuid
>   x86: add intel processor trace context
>   x86: Implement Intel Processor Trace context switch
>   x86: Implement Intel Processor Trace MSRs read/write
>   x86: Disable Intel Processor Trace when VMXON in L1 guest

How can this be a re-send of v1 when the original v1 consisted of
just 6 patches?

Jan


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

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

[Jan Beulich]

>>> On 15.01.18 at 19:26,  wrote:
> On 15/01/18 11:07, Jan Beulich wrote:
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -1849,6 +1849,15 @@ In the case that x2apic is in use, this
>>  clustered mode.  The default, given no hint from the **FADT**, is cluster
>>  mode.
>>  
>> +### xpti
>> +> `= `
>> +
>> +> Default: `false` on AMD hardware
>> +> Default: `true` everywhere else
> 
> This is fine for now, but any further isolation is going to have to be
> unconditional, or possibly compile-time choice, but maintaining that
> going forwards is going to be truly horrible.
> 
>> +
>> +Override default selection of whether to isolate 64-bit PV guest page
>> +tables.
> 
> This wants a
> 
> ** WARNING: Not yet a complete isolation implementation, but better than
> nothing. **
> 
> or similar, just to avoid giving the people the impression that it is
> complete.  Perhaps also a similar warning in the patch 1 commit message?

I've added the warning text here as suggested, and a respective
remark to patch 1's description, albeit under the current guidelines
of when we would consider an information leak a security issue, I
think isolation is sufficiently complete: No parts of the direct map
not pertaining to the current guest are being exposed, which
implies that no parts of the Xen heap not pertaining to the current
guest are. Leaking control page contents of other guests as well
as leaking the bits and pieces of the Xen image is not an issue by
itself.

IOW I'm not convinced such a warning is - strictly from a "would
this need an XSA on its own" pov - entirely appropriate.

Furthermore the command line option really exists to _disable_
the isolation (it also being capable of enabling is more a side
effect, but perhaps a useful one in the niche of running Xen
itself virtualized with being given the impression of running on
AMD hardware, but actually running on Intel), at which point the
warning is completely irrelevant.

One thing we may want/need to consider (but which is orthogonal
to the changes here) is to overwrite the part of the hypervisor
stack which isn't already being overwritten during context switch.

>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -1511,8 +1511,10 @@ void paravirt_ctxt_switch_to(struct vcpu
>>  {
>>  unsigned long cr4;
>>  
>> -this_cpu(root_pgt)[root_table_offset(PERDOMAIN_VIRT_START)] =
>> -l4e_from_page(v->domain->arch.perdomain_l3_pg, 
>> __PAGE_HYPERVISOR_RW);
>> +if ( this_cpu(root_pgt) )
>> +this_cpu(root_pgt)[root_table_offset(PERDOMAIN_VIRT_START)] =
>> +l4e_from_page(v->domain->arch.perdomain_l3_pg,
>> +  __PAGE_HYPERVISOR_RW);
> 
> This would be cleaner and have better generated code by pulling
> this_cpu(root_pgt) into a local variable.

Done.

>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -3685,7 +3685,7 @@ long do_mmu_update(
>>  rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
>>cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
>>  if ( !rc )
>> -sync_guest = true;
>> +sync_guest = this_cpu(root_pgt);
> 
> This is quite deceptive, as it is actually sync_guest =
> this_cpu(root_pgt) != NULL;

We omit such "!= NULL" / "!= 0" elsewhere too.

> It would probably be cleaner to export opt_xpti and use that, rather
> than imply things based on root_pgt.  It would certainly be more
> efficient code.

Again I had considered this and decided against: Other reasons to
have NULL in here may arise, so it felt better to key the decision
off of the actual fact that it depends on, rather than that one's
pre-condition.

>> @@ -992,10 +998,13 @@ void __init smp_prepare_cpus(unsigned in
>>  
>>  stack_base[0] = stack_start;
>>  
>> +if ( opt_xpti < 0 )
>> +opt_xpti = boot_cpu_data.x86_vendor != X86_VENDOR_AMD;
> 
> Newline?

I've added one, but imo it hides that the assignment is a pre-condition
for ...

>>  rc = setup_cpu_root_pgt(0);

... this call (i.e. makes less obvious that re-ordering here is not an
option).

>> --- a/xen/arch/x86/x86_64/entry.S
>> +++ b/xen/arch/x86/x86_64/entry.S
>> @@ -46,6 +46,7 @@ restore_all_guest:
>>  movabs $DIRECTMAP_VIRT_START, %rcx
>>  mov   %rdi, %rax
>>  and   %rsi, %rdi
>> +jz.Lrag_keep_cr3
> 
> What is rag?  What about .L_skip_cr3_reload ?

Look at the function name: It's the acronym of "restore_all_guest".
I specifically wanted to avoid any unspecific names like the one
you suggest, and short of a better idea I've used this one (to
parallel infixes like "cstar" used elsewhere).

Jan

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

Re: [Xen-devel] [PATCH v3 2/2] docs: note default for timer_mode in xl.cfg man

[Roger Pau Monné]

On Mon, Jan 15, 2018 at 09:24:52PM -0600, Doug Goldstein wrote:
> There was no default documented but inspecting
> libxl__domain_build_info_setdefault() shows the default to be
> LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS.
> 
> Signed-off-by: Doug Goldstein 
> ---
> CC: Wei Liu 
> CC: Ian Jackson 
> CC: Roger Pau Monné 
> # George for the 4.8 and 4.9 backport
> CC: George Dunlap 
> 
> change from v2:
> - Roger noted that the code differed from the
>   header that I used as the source of truth
> change from v1:
> - added same docs addition to HVM
> ---
>  docs/man/xl.cfg.pod.5.in | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
> index b7b91d8627..6b3ee81602 100644
> --- a/docs/man/xl.cfg.pod.5.in
> +++ b/docs/man/xl.cfg.pod.5.in
> @@ -1889,7 +1889,7 @@ advance the vCPU's virtual time stepwise for each one.
>  
>  No delay for missed ticks. As above, missed interrupts are delivered,
>  but guest time always tracks wallclock (i.e., real) time while doing
> -so.
> +so. This is the default.
>  
>  =item B
>  
> @@ -2348,13 +2348,14 @@ Specifies the mode for Virtual Timers. The valid 
> values are as follows:
>  Delay for missed ticks. Do not advance a vCPU's time beyond the
>  correct delivery time for interrupts that have been missed due to
>  preemption. Deliver missed interrupts when the vCPU is rescheduled and
> -advance the vCPU's virtual time stepwise for each one.
> +advance the vCPU's virtual time stepwise for each one. This is the
> +default.

The chunk above is now stale, since we agreed that
no_delay_for_missed_ticks was the default.

Thanks, Roger.

>  =item B
>  
>  No delay for missed ticks. As above, missed interrupts are delivered,
>  but guest time always tracks wallclock (i.e., real) time while doing
> -so.
> +so. This is the default.
>  
>  =item B
>  
> -- 
> 2.13.6
> 

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