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

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsmbroken
 build-armhf  broken
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken REGR. 
vs. 119692
 build-armhf   4 host-install(4)broken REGR. vs. 119692

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

Last test of basis   119692  2018-02-20 02:00:09 Z1 days
Testing same since   119749  2018-02-20 18:44:56 Z0 days1 attempts


People who touched revisions under test:
  Andreas Schwab 
  Gerd Hoffmann 
  Greg Kurz 
  Guido Günther 
  Jan Kiszka 
  Laurent Vivier 
  Marc-André Lureau 
  Peter Maydell 
  Philippe Mathieu-Daudé 
  Samuel Thibault 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-pvops 

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

[osstest service owner]

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

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  23b40df6f098e3bcb2f105a4909860240976e40f
baseline version:
 xen  197fbdb501257fdbbe0cfed35e3a99ef5b166107

Last test of basis   119752  2018-02-20 19:01:35 Z0 days
Failing since119761  2018-02-20 22:01:09 Z0 days2 attempts
Testing same since   119783  2018-02-21 02:39:03 Z0 days1 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Julien Grall 
  Razvan Cojocaru 

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
   197fbdb501..23b40df6f0  23b40df6f098e3bcb2f105a4909860240976e40f -> smoke

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd 4 host-install(4) broken in 119698 pass in 
119748
 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore.2 fail pass in 119698

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

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

Last test of basis   115539  2017-11-03 20:48:58 Z  109 days
Failing since115733  2017-11-10 17:19:59 Z  102 days  133 attempts
Testing same since   119258  2018-02-15 09:12:54 Z5 days   11 attempts


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

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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

broken-job test-amd64-i386-qemuu-rhel6hvm-amd broken

Not pushing.


commit af0daeb2687ad2595482b8a71b02a082a5672ceb
Author: Nikolay Nikolov 
Date:   Sat Feb 10 13:52:17 2018 +0200

floppy: Send 4 sense interrupt commands during controller initialization

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

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

Signed-off-by: Nikolay Nikolov 

commit 2611db472c0f0bad4987c20990a45c175342fc22
Author: Nikolay Nikolov 
Date:   Sat Feb 10 13:52:16 20

[Xen-devel] [xen-unstable test] 119713: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  8f9ccfe93570ecae18d9cc224931787d0bca9c66
baseline version:
 xen  24470b99c1671dca531c2cf5747eda2f8892ecbc

Last test of basis   119651  2018-02-19 12:24:01 Z1 days
Testing same since   119713  2018-02-20 07:56:20 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  Jan Beulich 
  Wei Liu 

jobs:
 build-amd64-xsm  pass 

[Xen-devel] [xen-unstable-smoke test] 119761: trouble: broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt broken
 test-amd64-amd64-libvirt  4 host-install(4)broken REGR. vs. 119752

Tests which did not succeed, but are not blocking:
 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  454ae490487659a51d71adc77aa02892d0725235
baseline version:
 xen  197fbdb501257fdbbe0cfed35e3a99ef5b166107

Last test of basis   119752  2018-02-20 19:01:35 Z0 days
Testing same since   119761  2018-02-20 22:01:09 Z0 days1 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Razvan Cojocaru 

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 broken  



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

broken-job test-amd64-amd64-libvirt broken
broken-step test-amd64-amd64-libvirt host-install(4)

Not pushing.


commit 454ae490487659a51d71adc77aa02892d0725235
Author: Alexandru Isaila 
Date:   Mon Feb 19 15:07:06 2018 +0200

asm-x86/monitor: Add MONITOR_EVENT_INTERRUPT to common capabilities

Signed-off-by: Alexandru Isaila 
Acked-by: Razvan Cojocaru 
(qemu changes not included)

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

Re: [Xen-devel] AD bits in traditional PV mode

[Andrew Cooper]

On 21/02/2018 00:42, Andres Lagar Cavilla wrote:
> Hello everyone,
>
> I was thinking of the traditional Xen PV mode in which page table
> pages are write protected from guest meddling and PTE
> modifications are audited by the hypervisor (ptwr_emulated_update()
> these days, still?).

Something like that, yes.  Alternatively, via explicit hypercall which
is faster than the trap&emulate path.

> Without software shadows or paging to e.g. an EPT, native PV loads the
> actual CR3 pointing to a write protected page table tree.

Unfortunately, I've lost you here.  There is no such thing as a
write-protected pagetable tree in the traditional PV sense.

> When the cr3 is loaded, the hardware walker will want to set A and D
> bits in PTEs -- is this action immune to the write protection in the
> page table pages themselves? Or do we take emulation faults on these
> updates as well?

The protection that Xen enforces on PV guests is that an L1 PTE mapping
a pagetable frame must never be writeable.  This protection happens at
the linear address level.  When the CPU pagewalker tries to set A/D
bits, it issues an atomic update to the physical address of the
pagetable entry which needs updating.

As with everything, there are complicating factors.  With EPT/NPT for
HVM guests these days, the hypervisor can also apply permissions to
guest physical addresses, as part of their translation to host physical
addresses.  The hardware pagewalker, when attempting to set an A/D bit
of the HVM guests regular pagetables, issues an EPT/NPT write (well -
RMW strictly) to set the bits.

Therefore, if the hypervisor marks an HVM guest's pagetable as
read-only, then the hardware pagewalker trying to set A/D bits will
vmexit with an EPT/NPT permissions violation.  This is one major
performance limiting factor of introspection technology at the moment.

~Andrew

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

[Xen-devel] [xen-4.6-testing test] 119720: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ws16-amd64 broken
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsmbroken
 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 119227

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken pass in 
119682
 test-amd64-i386-xl-qemuu-ws16-amd64  4 host-install(4)   broken pass in 119682
 test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 119682 pass 
in 119720
 test-armhf-armhf-libvirt-raw  6 xen-installfail pass in 119682

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

Re: [Xen-devel] [PATCH v2] xen/arm: vgic: Make sure the number of SPIs is a multiple of 32

[Stefano Stabellini]

On Fri, 16 Feb 2018, Julien Grall wrote:
> The vGIC relies on having a pending_irq available for every IRQs
> described in the ranks. As each rank describes 32 interrupts, we need to
> make sure the number of SPIs is a multiple of 32.
> 
> Reported-by: Jeff Kubascik 
> Signed-off-by: Julien Grall 
> Cc: Jarvis Roach 

Reviewed-by: Stefano Stabellini 

> ---
> This should be backported up to Xen 4.8.
> 
> Changes in v2:
> - Update the Reported-by address
> ---
>  xen/arch/arm/vgic.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 9921769b15..34269bcf27 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -123,6 +123,13 @@ int domain_vgic_init(struct domain *d, unsigned int 
> nr_spis)
>  
>  d->arch.vgic.ctlr = 0;
>  
> +/*
> + * The vGIC relies on having a pending_irq available for every IRQ
> + * described in the ranks. As each rank describes 32 interrupts, we
> + * need to make sure the number of SPIs is a multiple of 32.
> + */
> +nr_spis = ROUNDUP(nr_spis, 32);
> +
>  /* Limit the number of virtual SPIs supported to (1020 - 32) = 988  */
>  if ( nr_spis > (1020 - NR_LOCAL_IRQS) )
>  return -EINVAL;
> -- 
> 2.11.0
> 

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

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

[Stefano Stabellini]

On Thu, 15 Feb 2018, Julien Grall wrote:
> 32-bit domain is able to select the instruction (ARM vs Thumb) to use
> when boot a new vCPU via CPU_ON. This is indicated via bit[0] of the
> entry point address (see "T32 support" in PSCI v1.1 DEN0022D). bit[0]
> must be cleared when setting the PC.
> 
> At the moment, Xen is setting the CPSR.T but never clear bit[0]. Clear
> it to match the specification.
> 
> At the same time, slighlty rework the code to make clear thumb is only for
> 32-bit domain. Lastly, take the opportunity to switch is_thumb from int
> to bool.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


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

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

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

[Stefano Stabellini]

On Thu, 15 Feb 2018, Julien Grall wrote:
> PSCI 1.0 added the error return PSCI_INVALID_ADDRESS. It is used to
> indicate the entry point address is known to be invalid.
> 
> In Xen case, this error could be returned when a 64-bit vCPU is using a
> Thumb entry address.
> 
> For PSCI 0.1 implementation, return PSCI_INVALID_PARAMETERS instead.
> 
> Suggested-by: mirela.simono...@aggios.com
> Signed-off-by: Julien Grall 
> Cc: mirela.simono...@aggios.com

Reviewed-by: Stefano Stabellini 


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

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

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

[Stefano Stabellini]

On Thu, 15 Feb 2018, Julien Grall wrote:
> >From the specification, the PSCI call MIGRATE_INFO_TYPE will return an
> int32_t. Update the function return type to match it.
> 
> Signed-off-by: Julien Grall 
> Cc: mirela.simono...@aggios.com

Reviewed-by: Stefano Stabellini 

> ---
> Changes in v3:
> - Patch added
> ---
>  xen/arch/arm/vpsci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
> index 7ea3ea58e3..9a082aa6ee 100644
> --- a/xen/arch/arm/vpsci.c
> +++ b/xen/arch/arm/vpsci.c
> @@ -186,7 +186,7 @@ static int32_t do_psci_0_2_affinity_info(register_t 
> target_affinity,
>  return PSCI_0_2_AFFINITY_LEVEL_OFF;
>  }
>  
> -static uint32_t do_psci_0_2_migrate_info_type(void)
> +static int32_t do_psci_0_2_migrate_info_type(void)
>  {
>  return PSCI_0_2_TOS_MP_OR_NOT_PRESENT;
>  }
 

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

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

[Stefano Stabellini]

On Thu, 15 Feb 2018, Julien Grall wrote:
> A bunch of PSCI functions are not prefixed with static despite no one is
> using them outside the file and the prototype is not available in
> psci.h.
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Volodymyr Babchuk 

Acked-by: Stefano Stabellini 

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

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

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

[Stefano Stabellini]

On Thu, 15 Feb 2018, Julien Grall wrote:
> Currently, the behavior of do_common_cpu will slightly change depending
> on the PSCI version passed in parameter. Looking at the code, more the
> specific 0.2 behavior could move out of the function or adapted for 0.1:
> 
> - x0/r0 can be updated on PSCI 0.1 because general purpose registers
> are undefined upon CPU on.
> - PSCI 0.1 does not defined PSCI_ALREADY_ON. However, it would be
> safer to bail out if the CPU is already on.
> 
> Based on this, the parameter 'ver' is removed and do_psci_cpu_on
> (implementation for PSCI 0.1) is adapted to avoid returning
> PSCI_ALREADY_ON.
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Volodymyr Babchuk 

Acked-by: Stefano Stabellini 

> ---
> The reviewed-by was kept despite move this patch towards the end
> of the series because there was no clash with the rest of the series.
> 
> Changes in v2:
> - Move the patch towards the end of the series as not strictly
> necessary for SP2.
> - Add Volodymyr's reviewed-by
> ---
>  xen/arch/arm/vpsci.c | 28 ++--
>  1 file changed, 18 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
> index 19ee7caeb4..7ea3ea58e3 100644
> --- a/xen/arch/arm/vpsci.c
> +++ b/xen/arch/arm/vpsci.c
> @@ -22,7 +22,7 @@
>  #include 
>  
>  static int do_common_cpu_on(register_t target_cpu, register_t entry_point,
> -   register_t context_id,int ver)
> +register_t context_id)
>  {
>  struct vcpu *v;
>  struct domain *d = current->domain;
> @@ -40,8 +40,7 @@ static int do_common_cpu_on(register_t target_cpu, 
> register_t entry_point,
>  if ( is_64bit_domain(d) && is_thumb )
>  return PSCI_INVALID_PARAMETERS;
>  
> -if ( (ver == PSCI_VERSION(0, 2)) &&
> -!test_bit(_VPF_down, &v->pause_flags) )
> +if ( !test_bit(_VPF_down, &v->pause_flags) )
>  return PSCI_ALREADY_ON;
>  
>  if ( (ctxt = alloc_vcpu_guest_context()) == NULL )
> @@ -55,18 +54,21 @@ static int do_common_cpu_on(register_t target_cpu, 
> register_t entry_point,
>  ctxt->ttbr0 = 0;
>  ctxt->ttbr1 = 0;
>  ctxt->ttbcr = 0; /* Defined Reset Value */
> +
> +/*
> + * x0/r0_usr are always updated because for PSCI 0.1 the general
> + * purpose registers are undefined upon CPU_on.
> + */
>  if ( is_32bit_domain(d) )
>  {
>  ctxt->user_regs.cpsr = PSR_GUEST32_INIT;
> -if ( ver == PSCI_VERSION(0, 2) )
> -ctxt->user_regs.r0_usr = context_id;
> +ctxt->user_regs.r0_usr = context_id;
>  }
>  #ifdef CONFIG_ARM_64
>  else
>  {
>  ctxt->user_regs.cpsr = PSR_GUEST64_INIT;
> -if ( ver == PSCI_VERSION(0, 2) )
> -ctxt->user_regs.x0 = context_id;
> +ctxt->user_regs.x0 = context_id;
>  }
>  #endif
>  
> @@ -93,7 +95,14 @@ static int do_common_cpu_on(register_t target_cpu, 
> register_t entry_point,
>  
>  static int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
>  {
> -return do_common_cpu_on(vcpuid, entry_point, 0 , PSCI_VERSION(0, 1));
> +int32_t ret;
> +
> +ret = do_common_cpu_on(vcpuid, entry_point, 0);
> +/*
> + * PSCI 0.1 does not define the return code PSCI_ALREADY_ON.
> + * Instead, return PSCI_INVALID_PARAMETERS.
> + */
> +return (ret == PSCI_ALREADY_ON) ? PSCI_INVALID_PARAMETERS : ret;
>  }
>  
>  static int32_t do_psci_cpu_off(uint32_t power_state)
> @@ -137,8 +146,7 @@ static int32_t do_psci_0_2_cpu_on(register_t target_cpu,
>register_t entry_point,
>register_t context_id)
>  {
> -return do_common_cpu_on(target_cpu, entry_point, context_id,
> -PSCI_VERSION(0, 2));
> +return do_common_cpu_on(target_cpu, entry_point, context_id);
>  }
>  
>  static const unsigned long target_affinity_mask[] = {
> -- 
> 2.11.0
> 

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

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

[Stefano Stabellini]

On Thu, 15 Feb 2018, Julien Grall wrote:
> Xen is printing the same way the PSCI version for 0.1, 0.2 and later.
> The only different is the former is hardcoded.
> 
> Furthermore PSCI is now used for other things than SMP bring up. So only
> print the PSCI version in psci_init.
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Volodymyr Babchuk 

Acked-by: Stefano Stabellini 


> ---
> Changes in v3:
> - Add Volodymyr's reviewed-by
> 
> Changes in v2:
> - Patch added
> ---
>  xen/arch/arm/psci.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
> index bc7b2260e8..7a8cf54e6d 100644
> --- a/xen/arch/arm/psci.c
> +++ b/xen/arch/arm/psci.c
> @@ -136,8 +136,6 @@ int __init psci_init_0_1(void)
>  
>  psci_ver = PSCI_VERSION(0, 1);
>  
> -printk(XENLOG_INFO "Using PSCI-0.1 for SMP bringup\n");
> -
>  return 0;
>  }
>  
> @@ -183,9 +181,6 @@ int __init psci_init_0_2(void)
>  
>  psci_cpu_on_nr = PSCI_0_2_FN_NATIVE(CPU_ON);
>  
> -printk(XENLOG_INFO "Using PSCI-%u.%u for SMP bringup\n",
> -   PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver));
> -
>  return 0;
>  }
>  
> @@ -205,6 +200,9 @@ int __init psci_init(void)
>  
>  psci_init_smccc();
>  
> +printk(XENLOG_INFO "Using PSCI v%u.%u\n",
> +   PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver));
> +
>  return 0;
>  }
>  
> -- 
> 2.11.0
> 

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

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

[Stefano Stabellini]

On Thu, 15 Feb 2018, Julien Grall wrote:
> Now that we've standardised on SMCCC v1.1 to perform the branch
> prediction invalidation, let's drop the previous band-aid. If vendors
> haven't updated their firmware to do SMCCC 1.1, they haven't updated
> PSCI either, so we don't loose anything.
> 
> This is aligned with the Linux commit 3a0a397ff5ff.
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Volodymyr Babchuk 

Reviewed-by: Stefano Stabellini 


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

[Xen-devel] AD bits in traditional PV mode

[Andres Lagar Cavilla]

Hello everyone,

I was thinking of the traditional Xen PV mode in which page table pages are
write protected from guest meddling and PTE modifications are audited by
the hypervisor (ptwr_emulated_update() these days, still?).

Without software shadows or paging to e.g. an EPT, native PV loads the
actual CR3 pointing to a write protected page table tree. When the cr3 is
loaded, the hardware walker will want to set A and D bits in PTEs -- is
this action immune to the write protection in the page table pages
themselves? Or do we take emulation faults on these updates as well?

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

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

[Stefano Stabellini]

On Thu, 15 Feb 2018, Julien Grall wrote:
> The function SMCCC_ARCH_WORKAROUND_1 will be called by the guest for
> hardening the branch predictor. So we want the handling to be as fast as
> possible.
> 
> As the mitigation is applied on every guest exit, we can check for the
> call before saving all the context and return very early.
> 
> For now, only provide a fast path for HVC64 call. Because the code rely
> on 2 registers, x0 and x1 are saved in advance.
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Volodymyr Babchuk 

Nice!

Reviewed-by: Stefano Stabellini 


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

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

Re: [Xen-devel] [PATCH v3 01/17] xen/arm: vpsci: Add support for PSCI 1.1

[Stefano Stabellini]

On Thu, 15 Feb 2018, Julien Grall wrote:
> At the moment, Xen provides virtual PSCI interface compliant with 0.1
> and 0.2. Since them, the specification has been updated and the latest
> version is 1.1 (see ARM DEN 0022D).
> 
> >From an implementation point of view, only PSCI_FEATURES is mandatory.
> The rest is optional and can be left unimplemented for now.
> 
> At the same time, the compatible for PSCI node have been updated to
> expose "arm,psci-1.0".
> 
> Signed-off-by: Julien Grall 
> Acked-by: Wei Liu 
> Reviewed-by: Volodymyr Babchuk 
> Cc: Ian Jackson 
> Cc: mirela.simono...@aggios.com

This patch doesn't apply cleanly to staging. Am I missing a
prerequisite?


> ---
> We may want to provide a way for the toolstack to specify a PSCI
> version. This could be useful if a guest is expecting a given
> version.
> 
> Changes in v3:
> - Add Wei's acked-by
> - Add Volodymyr's reviewed-by
> 
> Changes in v2:
> - Return v1.1 on GET_VERSION call as claimed by this patch
> - Order by function ID the calls in FEATURES call
> ---
>  tools/libxl/libxl_arm.c  |  3 ++-
>  xen/arch/arm/domain_build.c  |  1 +
>  xen/arch/arm/vpsci.c | 39 ++-
>  xen/include/asm-arm/perfc_defn.h |  1 +
>  xen/include/asm-arm/psci.h   |  1 +
>  xen/include/asm-arm/vpsci.h  |  2 +-
>  6 files changed, 44 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 3e46554301..86f59c0d80 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -410,7 +410,8 @@ static int make_psci_node(libxl__gc *gc, void *fdt)
>  res = fdt_begin_node(fdt, "psci");
>  if (res) return res;
>  
> -res = fdt_property_compat(gc, fdt, 2, "arm,psci-0.2","arm,psci");
> +res = fdt_property_compat(gc, fdt, 3, "arm,psci-1.0",
> +  "arm,psci-0.2", "arm,psci");
>  if (res) return res;
>  
>  res = fdt_property_string(fdt, "method", "hvc");
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 155c952349..941688a2ce 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -637,6 +637,7 @@ static int make_psci_node(void *fdt, const struct 
> dt_device_node *parent)
>  {
>  int res;
>  const char compat[] =
> +"arm,psci-1.0""\0"
>  "arm,psci-0.2""\0"
>  "arm,psci";
>  
> diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
> index 6ab8ab64d0..e82b62db1a 100644
> --- a/xen/arch/arm/vpsci.c
> +++ b/xen/arch/arm/vpsci.c
> @@ -106,7 +106,11 @@ static int32_t do_psci_cpu_off(uint32_t power_state)
>  
>  static uint32_t do_psci_0_2_version(void)
>  {
> -return PSCI_VERSION(0, 2);
> +/*
> + * PSCI is backward compatible from 0.2. So we can bump the version
> + * without any issue.
> + */
> +return PSCI_VERSION(1, 1);
>  }
>  
>  static register_t do_psci_0_2_cpu_suspend(uint32_t power_state,
> @@ -191,6 +195,29 @@ static void do_psci_0_2_system_reset(void)
>  domain_shutdown(d,SHUTDOWN_reboot);
>  }
>  
> +static int32_t do_psci_1_0_features(uint32_t psci_func_id)
> +{
> +/* /!\ Ordered by function ID and not name */
> +switch ( psci_func_id )
> +{
> +case PSCI_0_2_FN32_PSCI_VERSION:
> +case PSCI_0_2_FN32_CPU_SUSPEND:
> +case PSCI_0_2_FN64_CPU_SUSPEND:
> +case PSCI_0_2_FN32_CPU_OFF:
> +case PSCI_0_2_FN32_CPU_ON:
> +case PSCI_0_2_FN64_CPU_ON:
> +case PSCI_0_2_FN32_AFFINITY_INFO:
> +case PSCI_0_2_FN64_AFFINITY_INFO:
> +case PSCI_0_2_FN32_MIGRATE_INFO_TYPE:
> +case PSCI_0_2_FN32_SYSTEM_OFF:
> +case PSCI_0_2_FN32_SYSTEM_RESET:
> +case PSCI_1_0_FN32_PSCI_FEATURES:
> +return 0;
> +default:
> +return PSCI_NOT_SUPPORTED;
> +}
> +}
> +
>  #define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)
>  #define PSCI_ARG(reg, n) get_user_reg(reg, n)
>  
> @@ -304,6 +331,16 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, 
> uint32_t fid)
>  PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff, laff));
>  return true;
>  }
> +
> +case PSCI_1_0_FN32_PSCI_FEATURES:
> +{
> +uint32_t psci_func_id = PSCI_ARG32(regs, 1);
> +
> +perfc_incr(vpsci_features);
> +PSCI_SET_RESULT(regs, do_psci_1_0_features(psci_func_id));
> +return true;
> +}
> +
>  default:
>  return false;
>  }
> diff --git a/xen/include/asm-arm/perfc_defn.h 
> b/xen/include/asm-arm/perfc_defn.h
> index a7acb7d21c..87866264ca 100644
> --- a/xen/include/asm-arm/perfc_defn.h
> +++ b/xen/include/asm-arm/perfc_defn.h
> @@ -31,6 +31,7 @@ PERFCOUNTER(vpsci_system_off,  "vpsci: system_off")
>  PERFCOUNTER(vpsci_system_reset,"vpsci: system_reset")
>  PERFCOUNTER(vpsci_cpu_suspend, "vpsci: cpu_suspend")
>  PERFCOUNTER(vpsci_cpu_affinity_info,   "vpsci: cpu_affinity_info")
> +PERFCOUNTER(vpsci_features,  

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

[Stefano Stabellini]

On Thu, 15 Feb 2018, Julien Grall wrote:
> Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> Changes in v3:
> - Add the missing call to smc #0.
> 
> Changes in v2:
> - Patch added
> ---
>  xen/arch/arm/arm64/bpi.S| 13 +
>  xen/arch/arm/cpuerrata.c| 32 +++-
>  xen/include/asm-arm/smccc.h |  1 +
>  3 files changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
> index 4b7f1dc21f..981fb83a88 100644
> --- a/xen/arch/arm/arm64/bpi.S
> +++ b/xen/arch/arm/arm64/bpi.S
> @@ -16,6 +16,8 @@
>   * along with this program.  If not, see .
>   */
>  
> +#include 
> +
>  .macro ventry target
>  .rept 31
>  nop
> @@ -81,6 +83,17 @@ ENTRY(__psci_hyp_bp_inval_start)
>  add sp, sp, #(8 * 18)
>  ENTRY(__psci_hyp_bp_inval_end)
>  
> +ENTRY(__smccc_workaround_1_smc_start)
> +sub sp, sp, #(8 * 4)
> +stp x2, x3, [sp, #(8 * 0)]
> +stp x0, x1, [sp, #(8 * 2)]
> +mov w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
> +smc #0
> +ldp x2, x3, [sp, #(8 * 0)]
> +ldp x0, x1, [sp, #(8 * 2)]
> +add sp, sp, #(8 * 4)
> +ENTRY(__smccc_workaround_1_smc_end)
> +
>  /*
>   * Local variables:
>   * mode: ASM
> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
> index 8d5f8d372a..dec9074422 100644
> --- a/xen/arch/arm/cpuerrata.c
> +++ b/xen/arch/arm/cpuerrata.c
> @@ -147,6 +147,34 @@ install_bp_hardening_vec(const struct 
> arm_cpu_capabilities *entry,
>  return ret;
>  }
>  
> +extern char __smccc_workaround_1_smc_start[], __smccc_workaround_1_smc_end[];
> +
> +static bool
> +check_smccc_arch_workaround_1(const struct arm_cpu_capabilities *entry)
> +{
> +struct arm_smccc_res res;
> +
> +/*
> + * Enable callbacks are called on every CPU based on the
> + * capabilities. So double-check whether the CPU matches the
> + * entry.
> + */
> +if ( !entry->matches(entry) )
> +return false;

I think this should be return true?


> +if ( smccc_ver < SMCCC_VERSION(1, 1) )
> +return false;
> +
> +arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FID,
> +  ARM_SMCCC_ARCH_WORKAROUND_1_FID, &res);
> +if ( res.a0 != ARM_SMCCC_SUCCESS )
> +return false;
> +
> +return install_bp_hardening_vec(entry,__smccc_workaround_1_smc_start,
> +__smccc_workaround_1_smc_end,
> +"call ARM_SMCCC_ARCH_WORKAROUND_1");
> +}
> +
>  extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
>  
>  static int enable_psci_bp_hardening(void *data)
> @@ -154,12 +182,14 @@ static int enable_psci_bp_hardening(void *data)
>  bool ret = true;
>  static bool warned = false;
>  
> +if ( check_smccc_arch_workaround_1(data) )
> +return 0;
>  /*
>   * The mitigation is using PSCI version function to invalidate the
>   * branch predictor. This function is only available with PSCI 0.2
>   * and later.
>   */
> -if ( psci_ver >= PSCI_VERSION(0, 2) )
> +else if ( psci_ver >= PSCI_VERSION(0, 2) )
>  ret = install_bp_hardening_vec(data, __psci_hyp_bp_inval_start,
> __psci_hyp_bp_inval_end,
> "call PSCI get version");
> diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
> index 154772b728..8342cc33fe 100644
> --- a/xen/include/asm-arm/smccc.h
> +++ b/xen/include/asm-arm/smccc.h
> @@ -261,6 +261,7 @@ struct arm_smccc_res {
>  /* SMCCC error codes */
>  #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
>  #define ARM_SMCCC_NOT_SUPPORTED (-1)
> +#define ARM_SMCCC_SUCCESS   (0)
>  
>  /* SMCCC function identifier range which is reserved for existing APIs */
>  #define ARM_SMCCC_RESERVED_RANGE_START  0x0
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH v3 1/2] x86/hvm: introduce cr{0, 4}_host_mask to store trapped bits of CR accesses

[Boris Ostrovsky]

On 02/20/2018 03:56 AM, Roger Pau Monne wrote:
> At the moment this is currently set at VMC{S/B} creation and not changed,
> but further patches are going to change the CR4 mask at runtime.
>
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Boris Ostrovsky 
> Cc: Suravee Suthikulpanit 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Jun Nakajima 
> Cc: Kevin Tian 
> ---
> Changes since v2:
>  - Introduce masks only for CR4 and CR0.
>
> Changes since v1:
>  - New in this version.
> ---
>  xen/arch/x86/hvm/svm/vmcb.c| 1 +
>  xen/arch/x86/hvm/vmx/vmcs.c| 1 +
>  xen/include/asm-x86/hvm/vcpu.h | 4 
>  3 files changed, 6 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
> index 0e6cba5b7b..beeafad235 100644
> --- a/xen/arch/x86/hvm/svm/vmcb.c
> +++ b/xen/arch/x86/hvm/svm/vmcb.c
> @@ -169,6 +169,7 @@ static int construct_vmcb(struct vcpu *v)
>  vmcb->tr.base = 0;
>  vmcb->tr.limit = 0xff;
>  
> +v->arch.hvm_vcpu.cr0_host_mask = v->arch.hvm_vcpu.cr4_host_mask = ~0UL;
>  v->arch.hvm_vcpu.guest_cr[0] = X86_CR0_PE | X86_CR0_ET;
>  hvm_update_guest_cr(v, 0);


Is there a reason for setting those fields? SVM won't use them, will it?


-boris



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

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

[Stefano Stabellini]

On Thu, 15 Feb 2018, Julien Grall wrote:
> One of the major improvement of SMCCC v1.1 is that it only clobbers the
> first 4 registers, both on 32 and 64bit. This means that it becomes very
> easy to provide an inline version of the SMC call primitive, and avoid
> performing a function call to stash the registers that woudl otherwise
> be clobbered by SMCCC v1.0.
> 
> This patch has been adapted to Xen from Linux commit f2d3b2e8759a. The
> changes mades are:
> - Using Xen coding style
> - Remove HVC as not used by Xen
> - Add arm_smccc_res structure
> 
>  Reviewed-by: Robin Murphy 
>  Tested-by: Ard Biesheuvel 
>  Signed-off-by: Marc Zyngier 
>  Signed-off-by: Catalin Marinas 
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 


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

Re: [Xen-devel] [PATCH 0/2] x86/svm: add pause filtering threshold for SVM

[Brian Woods]

HW Setup:
CPU: AMD EPYC 7401 24c/48t x 2 
RAM: 128GB RAM
Storage: HDD for dom0, SSDs for VMs
SW Setup:
Xen base 4c7e478d597b0346eef3a256cfd6794ac778b608
32 VMs
6 VPCUs per VM
3.5GB RAM per VM
7.5GB disk per VM

Results:
kernbench:
half -> -j vpcu/2 = one job per host thread
quad -> -j vpcu*4 = two VMs per host thread,
four jobs per VM VCPU
pi:
03 ->  3 in parallel = one pi per host thread
24 -> 24 in parallel = two VMs per host thread,
   four pis per VM VCPU

Kernbench: 
https://github.com/linux-test-project/ltp/blob/master/utils/benchmark/kernbench-0.42/kernbench
pi: based off of 
https://stackoverflow.com/questions/4084571/implementing-the-spigot-algorithm-for-%CF%80-pi
but with yields and 10ns sleeps added in. 

Between the current usage of pause filtering counter, there's about an
~.5% improve in performance.  While this isn't huge, all that's
required is to write a value in the VMCB.

Attached: 
elapsed_time_kernbenchhalf.pdf
elapsed_time_kernbenchquad.pdf
elapsed_time_pi03.pdf
elapsed_time_pi24.pdf

-- 
Brian Woods


elapsed_time_kernbenchquad.pdf
Description: Adobe PDF document


elapsed_time_kernbenchhalf.pdf
Description: Adobe PDF document


elapsed_time_pi03.pdf
Description: Adobe PDF document


elapsed_time_pi24.pdf
Description: Adobe PDF document
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Stefano Stabellini]

On Thu, 15 Feb 2018, Julien Grall wrote:
> PSCI 1.0 and later allows the SMCCC version to be (indirectly) probed
> via PSCI_FEATURES. If the PSCI_FEATURES does not exist (PSCI 0.2 or
> earlier) and the function return an error, then we considered SMCCC 1.0
> is implemented.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


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

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

[Xen-devel] [PATCH 2/2] x86/svm: enable pause filtering threshold

[Brian Woods]

If available, enable the pause filtering threshold feature.  See the
previous commit for more information.

Signed-off-by: Brian Woods 
---
 xen/arch/x86/hvm/svm/svm.c  | 1 +
 xen/arch/x86/hvm/svm/vmcb.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 9f58afc2d8..b6b92365bf 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1694,6 +1694,7 @@ const struct hvm_function_table * __init start_svm(void)
 P(cpu_has_svm_vloadsave, "Virtual VMLOAD/VMSAVE");
 P(cpu_has_svm_vgif, "Virtual GIF");
 P(cpu_has_pause_filter, "Pause-Intercept Filter");
+P(cpu_has_pause_thresh, "Pause-Intercept Filter Threshold");
 P(cpu_has_tsc_ratio, "TSC Rate MSR");
 #undef P
 
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 0e6cba5b7b..ebe6f0c751 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -227,6 +227,9 @@ static int construct_vmcb(struct vcpu *v)
 {
 vmcb->_pause_filter_count = SVM_PAUSEFILTER_INIT;
 vmcb->_general1_intercepts |= GENERAL1_INTERCEPT_PAUSE;
+
+if ( cpu_has_pause_thresh )
+vmcb->_pause_filter_thresh = SVM_PAUSETHRESH_INIT;
 }
 
 vmcb->cleanbits.bytes = 0;
-- 
2.11.0


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

[Xen-devel] [PATCH 1/2] x86/svm: add support for pause filtering threshold

[Brian Woods]

Add support for enabling the pause filtering threshold feature.  This
causes the pause filtering count to reset if there's pause filtering
threshold cycles or greater between pauses.  See AMD APM Vol 2 Section
15.14.4 for more details.

The values of the pause filtering count and threshold were found by
iterating over different values of the count and threshold while running
kernbench and a pi spigot algorithm with yields placed in it.  A
balanced setting for both variable provides:

(Using averaged elapsed time with kernbench)
old = 852.0
new = 848.8
improvement = .4%

For system without pause filtering threshold, the change, from 3000 to
4000 for the count, should not negatively effect system performance.

Signed-off-by: Brian Woods 
---
 xen/include/asm-x86/hvm/svm/svm.h  | 5 -
 xen/include/asm-x86/hvm/svm/vmcb.h | 3 ++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-x86/hvm/svm/svm.h 
b/xen/include/asm-x86/hvm/svm/svm.h
index 462cb89b7c..593546fb56 100644
--- a/xen/include/asm-x86/hvm/svm/svm.h
+++ b/xen/include/asm-x86/hvm/svm/svm.h
@@ -64,6 +64,7 @@ extern u32 svm_feature_flags;
 #define SVM_FEATURE_FLUSHBYASID6 /* TLB flush by ASID support */
 #define SVM_FEATURE_DECODEASSISTS  7 /* Decode assists support */
 #define SVM_FEATURE_PAUSEFILTER   10 /* Pause intercept filter support */
+#define SVM_FEATURE_PAUSETHRESH   12 /* Pause intercept filter support */
 #define SVM_FEATURE_VLOADSAVE 15 /* virtual vmload/vmsave */
 #define SVM_FEATURE_VGIF  16 /* Virtual GIF */
 
@@ -76,10 +77,12 @@ extern u32 svm_feature_flags;
 #define cpu_has_svm_decodecpu_has_svm_feature(SVM_FEATURE_DECODEASSISTS)
 #define cpu_has_svm_vgif  cpu_has_svm_feature(SVM_FEATURE_VGIF)
 #define cpu_has_pause_filter  cpu_has_svm_feature(SVM_FEATURE_PAUSEFILTER)
+#define cpu_has_pause_thresh  cpu_has_svm_feature(SVM_FEATURE_PAUSETHRESH)
 #define cpu_has_tsc_ratio cpu_has_svm_feature(SVM_FEATURE_TSCRATEMSR)
 #define cpu_has_svm_vloadsave cpu_has_svm_feature(SVM_FEATURE_VLOADSAVE)
 
-#define SVM_PAUSEFILTER_INIT3000
+#define SVM_PAUSEFILTER_INIT4000
+#define SVM_PAUSETHRESH_INIT1000
 
 /* TSC rate */
 #define DEFAULT_TSC_RATIO   0x0001ULL
diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h 
b/xen/include/asm-x86/hvm/svm/vmcb.h
index 9d5dfc58f2..de07429dff 100644
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -412,7 +412,7 @@ struct vmcb_struct {
 u64 res04;  /* offset 0x28 */
 u64 res05;  /* offset 0x30 */
 u32 res06;  /* offset 0x38 */
-u16 res06a; /* offset 0x3C */
+u16 _pause_filter_thresh;   /* offset 0x3C - cleanbit 0 */
 u16 _pause_filter_count;/* offset 0x3E - cleanbit 0 */
 u64 _iopm_base_pa;  /* offset 0x40 - cleanbit 1 */
 u64 _msrpm_base_pa; /* offset 0x48 - cleanbit 1 */
@@ -568,6 +568,7 @@ VMCB_ACCESSORS(exception_intercepts, intercepts)
 VMCB_ACCESSORS(general1_intercepts, intercepts)
 VMCB_ACCESSORS(general2_intercepts, intercepts)
 VMCB_ACCESSORS(pause_filter_count, intercepts)
+VMCB_ACCESSORS(pause_filter_thresh, intercepts)
 VMCB_ACCESSORS(tsc_offset, intercepts)
 VMCB_ACCESSORS(iopm_base_pa, iopm)
 VMCB_ACCESSORS(msrpm_base_pa, iopm)
-- 
2.11.0


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

[Xen-devel] [PATCH 0/2] x86/svm: add pause filtering threshold for SVM

[Brian Woods]

This patch series adds support and enablement of the pause filtering
threshold.  Once there's pause filtering threshold amount of cycles
between pauses, the pause filtering counter resets to what was in the
VMCB.  This allows the pause filtering count to "reset" between pauses
and keeps the guset from getting intercepted by the hypervisor.  See AMD
APM vol 2 section 15.14.4 for more details.

In reply to this will be an email with graphs showing some benchmark
results of why the values of the counter and threshold were picked.

Brian Woods (2):
  x86/svm: add support for pause filtering threshold
  x86/svm: enable pause filtering threshold

 xen/arch/x86/hvm/svm/svm.c | 1 +
 xen/arch/x86/hvm/svm/vmcb.c| 3 +++
 xen/include/asm-x86/hvm/svm/svm.h  | 5 -
 xen/include/asm-x86/hvm/svm/vmcb.h | 3 ++-
 4 files changed, 10 insertions(+), 2 deletions(-)

-- 
2.11.0


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

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: read cacheline size when needed

[Stefano Stabellini]

On Tue, 20 Feb 2018, Julien Grall wrote:
> On 20/02/2018 21:16, Julien Grall wrote:
> > Hi,
> > 
> > On 20/02/2018 21:03, Stefano Stabellini wrote:
> >> On Tue, 20 Feb 2018, Julien Grall wrote:
> >>> On 19/02/18 21:58, Stefano Stabellini wrote:
>  +    mrc   CP32(r6, CSSELR_EL1)
> >>>
> >>> The size of the cache is read using CSSIDR_EL1. But it looks like the 
> >>> way we
> >>> get the cache line size in Xen is fragile.
> >>>
> >>> We are retrieving the cache line size of Level 1 and assume this will 
> >>> be valid
> >>> for all the other caches. Indeed cache maintenance ops may propagate 
> >>> to other
> >>> caches depending the target (Point of Coherency vs Point of 
> >>> Unification).
> >>>
> >>> Looking at the ARM ARM "Cache hierarchy abstraction for address-based
> >>> operations" (D3-2061 DDI 0487C.a), CTR_EL0/CTR will holds the minimum 
> >>> line
> >>> lenght values for the data caches. The value will be the most efficient
> >>> address stride to use to apply a sequence of VA-based maintenance 
> >>> instructions
> >>> to a range of VAs.
> >>>
> >>> So it would be best and safer for Xen to use CTR/CTLR_EL0.DminLine.
> >>
> >> This is insightful, thank you. Given that this patch is a backport
> >> candidate, I would prefer to retain the same behavior we had before in
> >> setup_cache. I can write a separate patch on top of this to make the
> >> change to use CTR/CTLR_EL0.DminLine. That way, we can make a separate
> >> decision on each of them on whether we want to backport them (and
> >> potentially revert them) or not. In other words: this patch as-is is
> >> suboptimal but is of very little risk. Making changes to the way we
> >> determine the cacheline size improves the patch but significantly
> >> increases the risk factor associated with it.
> >>
> >> Does it make sense?
> > 
> > By this patch you mean big.LITTLE? If so, then I don't consider it as a 
> > potential backport. big.LITTLE has never been supported on Xen and hence 
> > should be considered as a new feature. What is backportable is the patch 
> > #1 that forbid big.LITTLE.

Patch #1 ends up forcing people to use big cores only on many platforms,
which from what you wrote can be unsafe. I suggest we backport the whole
series, so that at least users can configure the system to use LITTLE
cores only, or a mix of the two. The big.LITTLE doc in particular is
certainly worth backporting but only makes sense with the rest of the
series.

On support statements: I noticed that big.LITTLE is actually lacking from
SUPPORT.md.


> > Regarding the cache line size, I didn't suggest the change because it is 
> > more efficient. I suggested the patch because the current code to find 
> > the cache line size is wrong. Imagine there is a cache in the hierarchy 
> > that has a smaller cache line than your L1 cache. Then you would not 
> > clean/invalidate correctly that cache.

I didn't mean to imply that what you are suggesting is not important, or
less important than the purpose of patch. I just meant to say that this
patch is about removing the cacheline_bytes variable, it is not about
fixing the way we read the cacheline size. I like to keep one patch
doing one thing only.

The fix you are suggesting is important, in fact it is probably more
important than this series. I am OK writing a patch for it. It is just
that it is a separate issue, and should be fix separately.

I'll have a look at it and propose it a separate patch.


>  +    and   r6, r6, #0x7
>  +    add   r6, r6, #4
>  +    mov   r7, #1
>  +    lsl   r6, r7, r6
>     mov   r7, r3
>   1:  mcr   CP32(r7, DCCMVAC)
>  diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
>  index fa0ef70..edea300 100644
>  --- a/xen/arch/arm/arm64/head.S
>  +++ b/xen/arch/arm/arm64/head.S
>  @@ -631,8 +631,14 @@ ENTRY(relocate_xen)
>     dsb   sy    /* So the CPU issues all writes to the 
>  range */
>   mov   x9, x3
>  -    ldr   x10, =cacheline_bytes /* x10 := step */
>  -    ldr   x10, [x10]
>  +
>  +    mov   x10, #0
>  +    msr   CSSELR_EL1, x10
>  +    mrs   x10, CSSELR_EL1
>  +    and   x10, x10, #0x7
>  +    add   x10, x10, #4
>  +    mov   x11, #1
>  +    lsl   x10, x11, x10
> >>>
> >>> Please use dcache_line_size macro (see cache.S).
> >>
> >> Similarly, I would prefer to retain the same old behavior here, and
> >> fix it/improve it in a separate patch.
> > 
> > See above, you got the wrong end of the stick about the cache line size.
> 
> You might want to look at the following patch in Linux:
> 
> commit f91e2c3bd427239c198351f44814dd39db91afe0
> Author: Catalin Marinas 
> Date:   Tue Dec 7 16:52:04 2010 +0100
> 
> ARM: 6527/1: Use CTR instead of CCSIDR for the D-cache line size on ARMv7
> 
> The current implementation of the dcache_line_size macro reads the L1
> cache size 

Re: [Xen-devel] [PATCH] mm: don't defer struct page initialization for Xen pv guests

[Andrew Morton]

On Mon, 19 Feb 2018 02:45:27 +0800 kbuild test robot  wrote:

> [auto build test ERROR on mmotm/master]
> [also build test ERROR on v4.16-rc1 next-20180216]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Juergen-Gross/mm-don-t-defer-struct-page-initialization-for-Xen-pv-guests/20180218-233657
> base:   git://git.cmpxchg.org/linux-mmotm.git master
> config: i386-randconfig-x010-201807 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All errors (new ones prefixed by >>):
> 
>mm/page_alloc.c: In function 'update_defer_init':
> >> mm/page_alloc.c:352:6: error: implicit declaration of function 
> >> 'xen_pv_domain' [-Werror=implicit-function-declaration]
>  if (xen_pv_domain())
>  ^

I think I already fixed this.



From: Andrew Morton 
Subject: mm-dont-defer-struct-page-initialization-for-xen-pv-guests-fix

explicitly include xen.h

Cc: Juergen Gross 
Signed-off-by: Andrew Morton 
---

 mm/page_alloc.c |1 +
 1 file changed, 1 insertion(+)

diff -puN 
mm/page_alloc.c~mm-dont-defer-struct-page-initialization-for-xen-pv-guests-fix 
mm/page_alloc.c
--- 
a/mm/page_alloc.c~mm-dont-defer-struct-page-initialization-for-xen-pv-guests-fix
+++ a/mm/page_alloc.c
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
_



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

Re: [Xen-devel] [PATCH v4 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

[Boris Ostrovsky]

On 02/20/2018 05:27 PM, Brian Woods wrote:
> Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.
>
> Reported-by: Andrew Cooper 
> Signed-off-by: Brian Woods 

Reviewed-by: Boris Ostrovsky 



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

[Xen-devel] [PATCH v4 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

[Brian Woods]

Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.

Reported-by: Andrew Cooper 
Signed-off-by: Brian Woods 
---
 xen/arch/x86/hvm/svm/nestedsvm.c| 66 +
 xen/arch/x86/hvm/svm/svm.c  |  6 +++
 xen/arch/x86/hvm/svm/vmcb.c | 17 -
 xen/include/asm-x86/hvm/svm/nestedsvm.h |  1 +
 4 files changed, 73 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index 1f7b0d3e88..9295e583d7 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -1659,3 +1659,69 @@ void svm_vmexit_do_clgi(struct cpu_user_regs *regs, 
struct vcpu *v)
 
 __update_guest_eip(regs, inst_len);
 }
+
+/*
+ * This runs on EFER change to see if nested features need to either be
+ * turned off or on.
+ */
+void svm_nested_features_on_efer_update(struct vcpu *v)
+{
+struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+struct nestedsvm *svm = &vcpu_nestedsvm(v);
+u32 general2_intercepts;
+vintr_t vintr;
+
+/*
+ * Need state for transfering the nested gif status so only write on
+ * the hvm_vcpu EFER.SVME changing.
+ */
+if ( v->arch.hvm_vcpu.guest_efer & EFER_SVME )
+{
+if ( !vmcb->virt_ext.fields.vloadsave_enable &&
+ paging_mode_hap(v->domain) &&
+ cpu_has_svm_vloadsave )
+{
+vmcb->virt_ext.fields.vloadsave_enable = 1;
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts &= ~(GENERAL2_INTERCEPT_VMLOAD |
+ GENERAL2_INTERCEPT_VMSAVE);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+
+if ( !vmcb->_vintr.fields.vgif_enable &&
+ cpu_has_svm_vgif )
+{
+vintr = vmcb_get_vintr(vmcb);
+vintr.fields.vgif = svm->ns_gif;
+vintr.fields.vgif_enable = 1;
+vmcb_set_vintr(vmcb, vintr);
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts &= ~(GENERAL2_INTERCEPT_STGI |
+ GENERAL2_INTERCEPT_CLGI);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+}
+else
+{
+if ( vmcb->virt_ext.fields.vloadsave_enable )
+{
+vmcb->virt_ext.fields.vloadsave_enable = 0;
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts |= (GENERAL2_INTERCEPT_VMLOAD |
+GENERAL2_INTERCEPT_VMSAVE);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+
+if ( vmcb->_vintr.fields.vgif_enable )
+{
+vintr = vmcb_get_vintr(vmcb);
+svm->ns_gif = vintr.fields.vgif;
+vintr.fields.vgif_enable = 0;
+vmcb_set_vintr(vmcb, vintr);
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts |= (GENERAL2_INTERCEPT_STGI |
+GENERAL2_INTERCEPT_CLGI);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+}
+}
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index c48fdfaa5d..89140f02f3 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -611,6 +611,12 @@ static void svm_update_guest_efer(struct vcpu *v)
 if ( lma )
 new_efer |= EFER_LME;
 vmcb_set_efer(vmcb, new_efer);
+
+ASSERT(nestedhvm_enabled(v->domain) || 
+   !(v->arch.hvm_vcpu.guest_efer & EFER_SVME));
+
+if ( nestedhvm_enabled(v->domain) )
+svm_nested_features_on_efer_update(v);
 }
 
 static void svm_cpuid_policy_changed(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 0e6cba5b7b..997e7597e0 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -200,29 +200,12 @@ static int construct_vmcb(struct vcpu *v)
 
 /* PAT is under complete control of SVM when using nested paging. */
 svm_disable_intercept_for_msr(v, MSR_IA32_CR_PAT);
-
-/* Use virtual VMLOAD/VMSAVE if available. */
-if ( cpu_has_svm_vloadsave )
-{
-vmcb->virt_ext.fields.vloadsave_enable = 1;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_VMLOAD;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_VMSAVE;
-}
 }
 else
 {
 vmcb->_exception_intercepts |= (1U << TRAP_page_fault);
 }
 
-/* if available, enable and configure virtual gif */
-if ( cpu_has_svm_vgif )
-{
-vmcb->_vintr.fields.vgif = 1;
-vmcb->_vintr.fields.vgif_enable = 1;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_STGI;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_CLGI;
-}
-
 if ( cpu_has_pause_filter )
 {
   

Re: [Xen-devel] [PATCH v2 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

[Brian Woods]

On Tue, Feb 20, 2018 at 05:09:24PM -0500, Boris Ostrovsky wrote:
> That's possibly because you needed an SVM maintainer ACK.
> 
> I think Jan was waiting for decision on how to present the ASSERT. From
> the 3 options I slightly more prefer
> 
> ASSERT(nestedhvm_enabled(v->domain) || !(v->arch.hvm_vcpu.guest_efer & 
> EFER_SVME));
> 
> (which wasn't the first choice for either of you ;-))
> 
> -boris

I'll change it and send out a new version then. 

-- 
Brian Woods

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

Re: [Xen-devel] [PATCH v2 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

[Boris Ostrovsky]

On 02/20/2018 05:00 PM, Brian Woods wrote:
> I've seen patch 1 and 3 are in but this one isn't.  Any status on it?
>

That's possibly because you needed an SVM maintainer ACK.

I think Jan was waiting for decision on how to present the ASSERT. From
the 3 options I slightly more prefer

ASSERT(nestedhvm_enabled(v->domain) || !(v->arch.hvm_vcpu.guest_efer & 
EFER_SVME));

(which wasn't the first choice for either of you ;-))

-boris


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

Re: [Xen-devel] [PATCH v2 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

[Brian Woods]

I've seen patch 1 and 3 are in but this one isn't.  Any status on it?

-- 
Brian Woods

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

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: read cacheline size when needed

[Julien Grall]

On 20/02/2018 21:16, Julien Grall wrote:
> Hi,
> 
> On 20/02/2018 21:03, Stefano Stabellini wrote:
>> On Tue, 20 Feb 2018, Julien Grall wrote:
>>> On 19/02/18 21:58, Stefano Stabellini wrote:
 +    mrc   CP32(r6, CSSELR_EL1)
>>>
>>> The size of the cache is read using CSSIDR_EL1. But it looks like the 
>>> way we
>>> get the cache line size in Xen is fragile.
>>>
>>> We are retrieving the cache line size of Level 1 and assume this will 
>>> be valid
>>> for all the other caches. Indeed cache maintenance ops may propagate 
>>> to other
>>> caches depending the target (Point of Coherency vs Point of 
>>> Unification).
>>>
>>> Looking at the ARM ARM "Cache hierarchy abstraction for address-based
>>> operations" (D3-2061 DDI 0487C.a), CTR_EL0/CTR will holds the minimum 
>>> line
>>> lenght values for the data caches. The value will be the most efficient
>>> address stride to use to apply a sequence of VA-based maintenance 
>>> instructions
>>> to a range of VAs.
>>>
>>> So it would be best and safer for Xen to use CTR/CTLR_EL0.DminLine.
>>
>> This is insightful, thank you. Given that this patch is a backport
>> candidate, I would prefer to retain the same behavior we had before in
>> setup_cache. I can write a separate patch on top of this to make the
>> change to use CTR/CTLR_EL0.DminLine. That way, we can make a separate
>> decision on each of them on whether we want to backport them (and
>> potentially revert them) or not. In other words: this patch as-is is
>> suboptimal but is of very little risk. Making changes to the way we
>> determine the cacheline size improves the patch but significantly
>> increases the risk factor associated with it.
>>
>> Does it make sense?
> 
> By this patch you mean big.LITTLE? If so, then I don't consider it as a 
> potential backport. big.LITTLE has never been supported on Xen and hence 
> should be considered as a new feature. What is backportable is the patch 
> #1 that forbid big.LITTLE.
> 
> Regarding the cache line size, I didn't suggest the change because it is 
> more efficient. I suggested the patch because the current code to find 
> the cache line size is wrong. Imagine there is a cache in the hierarchy 
> that has a smaller cache line than your L1 cache. Then you would not 
> clean/invalidate correctly that cache.
> 
 +    and   r6, r6, #0x7
 +    add   r6, r6, #4
 +    mov   r7, #1
 +    lsl   r6, r7, r6
    mov   r7, r3
  1:  mcr   CP32(r7, DCCMVAC)
 diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
 index fa0ef70..edea300 100644
 --- a/xen/arch/arm/arm64/head.S
 +++ b/xen/arch/arm/arm64/head.S
 @@ -631,8 +631,14 @@ ENTRY(relocate_xen)
    dsb   sy    /* So the CPU issues all writes to the 
 range */
  mov   x9, x3
 -    ldr   x10, =cacheline_bytes /* x10 := step */
 -    ldr   x10, [x10]
 +
 +    mov   x10, #0
 +    msr   CSSELR_EL1, x10
 +    mrs   x10, CSSELR_EL1
 +    and   x10, x10, #0x7
 +    add   x10, x10, #4
 +    mov   x11, #1
 +    lsl   x10, x11, x10
>>>
>>> Please use dcache_line_size macro (see cache.S).
>>
>> Similarly, I would prefer to retain the same old behavior here, and
>> fix it/improve it in a separate patch.
> 
> See above, you got the wrong end of the stick about the cache line size.

You might want to look at the following patch in Linux:

commit f91e2c3bd427239c198351f44814dd39db91afe0
Author: Catalin Marinas 
Date:   Tue Dec 7 16:52:04 2010 +0100

ARM: 6527/1: Use CTR instead of CCSIDR for the D-cache line size on ARMv7

The current implementation of the dcache_line_size macro reads the L1
cache size from the CCSIDR register. This, however, is not guaranteed to
be the smallest cache line in the cache hierarchy. The patch changes to
the macro to use the more architecturally correct CTR register.

Reported-by: Kevin Sapp 
Signed-off-by: Catalin Marinas 
Signed-off-by: Russell King 

Cheers,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: read cacheline size when needed

[Julien Grall]

Hi,

On 20/02/2018 21:03, Stefano Stabellini wrote:

On Tue, 20 Feb 2018, Julien Grall wrote:

On 19/02/18 21:58, Stefano Stabellini wrote:

+mrc   CP32(r6, CSSELR_EL1)


The size of the cache is read using CSSIDR_EL1. But it looks like the way we
get the cache line size in Xen is fragile.

We are retrieving the cache line size of Level 1 and assume this will be valid
for all the other caches. Indeed cache maintenance ops may propagate to other
caches depending the target (Point of Coherency vs Point of Unification).

Looking at the ARM ARM "Cache hierarchy abstraction for address-based
operations" (D3-2061 DDI 0487C.a), CTR_EL0/CTR will holds the minimum line
lenght values for the data caches. The value will be the most efficient
address stride to use to apply a sequence of VA-based maintenance instructions
to a range of VAs.

So it would be best and safer for Xen to use CTR/CTLR_EL0.DminLine.


This is insightful, thank you. Given that this patch is a backport
candidate, I would prefer to retain the same behavior we had before in
setup_cache. I can write a separate patch on top of this to make the
change to use CTR/CTLR_EL0.DminLine. That way, we can make a separate
decision on each of them on whether we want to backport them (and
potentially revert them) or not. In other words: this patch as-is is
suboptimal but is of very little risk. Making changes to the way we
determine the cacheline size improves the patch but significantly
increases the risk factor associated with it.

Does it make sense?


By this patch you mean big.LITTLE? If so, then I don't consider it as a 
potential backport. big.LITTLE has never been supported on Xen and hence 
should be considered as a new feature. What is backportable is the patch 
#1 that forbid big.LITTLE.


Regarding the cache line size, I didn't suggest the change because it is 
more efficient. I suggested the patch because the current code to find 
the cache line size is wrong. Imagine there is a cache in the hierarchy 
that has a smaller cache line than your L1 cache. Then you would not 
clean/invalidate correctly that cache.



+and   r6, r6, #0x7
+add   r6, r6, #4
+mov   r7, #1
+lsl   r6, r7, r6
   mov   r7, r3
 1:  mcr   CP32(r7, DCCMVAC)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index fa0ef70..edea300 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -631,8 +631,14 @@ ENTRY(relocate_xen)
   dsb   sy/* So the CPU issues all writes to the range */
 mov   x9, x3
-ldr   x10, =cacheline_bytes /* x10 := step */
-ldr   x10, [x10]
+
+mov   x10, #0
+msr   CSSELR_EL1, x10
+mrs   x10, CSSELR_EL1
+and   x10, x10, #0x7
+add   x10, x10, #4
+mov   x11, #1
+lsl   x10, x11, x10


Please use dcache_line_size macro (see cache.S).


Similarly, I would prefer to retain the same old behavior here, and
fix it/improve it in a separate patch.


See above, you got the wrong end of the stick about the cache line size.

Cheers,

--
Julien Grall

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

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

[osstest service owner]

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

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  197fbdb501257fdbbe0cfed35e3a99ef5b166107
baseline version:
 xen  a44f1697968e04fcc6145e3bd51c748b57047240

Last test of basis   119721  2018-02-20 10:01:08 Z0 days
Testing same since   119752  2018-02-20 19:01:35 Z0 days1 attempts


People who touched revisions under test:
  Sergey Dyasli 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   a44f169796..197fbdb501  197fbdb501257fdbbe0cfed35e3a99ef5b166107 -> smoke

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

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: read cacheline size when needed

[Stefano Stabellini]

On Tue, 20 Feb 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 19/02/18 21:58, Stefano Stabellini wrote:
> > On big.LITTLE systems the cacheline size might differ between big and
> > LITTLE cores. Instead of reading the cacheline size once at boot,
> > read it as needed from the system registers.
> > 
> > Suggested-by: Julien Grall 
> > Signed-off-by: Stefano Stabellini 
> > ---
> >   xen/arch/arm/arm32/head.S  |  9 +++--
> >   xen/arch/arm/arm64/head.S  | 10 --
> >   xen/arch/arm/setup.c   | 17 -
> >   xen/include/asm-arm/page.h | 17 +++--
> >   4 files changed, 30 insertions(+), 23 deletions(-)
> > 
> > diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
> > index 43374e7..db470ad 100644
> > --- a/xen/arch/arm/arm32/head.S
> > +++ b/xen/arch/arm/arm32/head.S
> > @@ -504,8 +504,13 @@ ENTRY(relocate_xen)
> >   dsb/* So the CPU issues all writes to the range */
> > mov   r5, r4
> > -ldr   r6, =cacheline_bytes /* r6 := step */
> > -ldr   r6, [r6]
> > +mov   r6, #0
> 
> Comments in the code would be nice to know what you exactly do. Also in that
> case, it would make sense to have a macro as this may be useful in other
> places.

OK. This is a 1:1 translation from setup_cache.


> > +mcr   CP32(r6, CSSELR_EL1)
> 
> Please use 32-bit naming in the 32-bit code.

I'll change.

 
> > +mrc   CP32(r6, CSSELR_EL1)
> 
> The size of the cache is read using CSSIDR_EL1. But it looks like the way we
> get the cache line size in Xen is fragile.
> 
> We are retrieving the cache line size of Level 1 and assume this will be valid
> for all the other caches. Indeed cache maintenance ops may propagate to other
> caches depending the target (Point of Coherency vs Point of Unification).
> 
> Looking at the ARM ARM "Cache hierarchy abstraction for address-based
> operations" (D3-2061 DDI 0487C.a), CTR_EL0/CTR will holds the minimum line
> lenght values for the data caches. The value will be the most efficient
> address stride to use to apply a sequence of VA-based maintenance instructions
> to a range of VAs.
> 
> So it would be best and safer for Xen to use CTR/CTLR_EL0.DminLine.

This is insightful, thank you. Given that this patch is a backport
candidate, I would prefer to retain the same behavior we had before in
setup_cache. I can write a separate patch on top of this to make the
change to use CTR/CTLR_EL0.DminLine. That way, we can make a separate
decision on each of them on whether we want to backport them (and
potentially revert them) or not. In other words: this patch as-is is
suboptimal but is of very little risk. Making changes to the way we
determine the cacheline size improves the patch but significantly
increases the risk factor associated with it.

Does it make sense?


> > +and   r6, r6, #0x7
> > +add   r6, r6, #4
> > +mov   r7, #1
> > +lsl   r6, r7, r6
> >   mov   r7, r3
> > 1:  mcr   CP32(r7, DCCMVAC)
> > diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> > index fa0ef70..edea300 100644
> > --- a/xen/arch/arm/arm64/head.S
> > +++ b/xen/arch/arm/arm64/head.S
> > @@ -631,8 +631,14 @@ ENTRY(relocate_xen)
> >   dsb   sy/* So the CPU issues all writes to the range */
> > mov   x9, x3
> > -ldr   x10, =cacheline_bytes /* x10 := step */
> > -ldr   x10, [x10]
> > +
> > +mov   x10, #0
> > +msr   CSSELR_EL1, x10
> > +mrs   x10, CSSELR_EL1
> > +and   x10, x10, #0x7
> > +add   x10, x10, #4
> > +mov   x11, #1
> > +lsl   x10, x11, x10
> 
> Please use dcache_line_size macro (see cache.S).

Similarly, I would prefer to retain the same old behavior here, and
fix it/improve it in a separate patch.


> >   mov   x11, x2
> > 1:  dccvac, x11
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 032a6a8..4754c95 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -680,21 +680,6 @@ static void __init setup_mm(unsigned long dtb_paddr,
> > size_t dtb_size)
> >   }
> >   #endif
> >   -size_t __read_mostly cacheline_bytes;
> > -
> > -/* Very early check of the CPU cache properties */
> > -void __init setup_cache(void)
> > -{
> > -uint32_t ccsid;
> > -
> > -/* Read the cache size ID register for the level-0 data cache */
> > -WRITE_SYSREG32(0, CSSELR_EL1);
> > -ccsid = READ_SYSREG32(CCSIDR_EL1);
> > -
> > -/* Low 3 bits are log2(cacheline size in words) - 2. */
> > -cacheline_bytes = 1U << (4 + (ccsid & 0x7));
> > -}
> > -
> >   /* C entry point for boot CPU */
> >   void __init start_xen(unsigned long boot_phys_offset,
> > unsigned long fdt_paddr,
> > @@ -708,8 +693,6 @@ void __init start_xen(unsigned long boot_phys_offset,
> >   struct domain *dom0;
> >   struct xen_arch_domainconfig config;
> >   -setup_cache();
> > -
> >   per

Re: [Xen-devel] [PATCH v2 4/6] xen/arm: make vpidr per vcpu

[Stefano Stabellini]

On Tue, 20 Feb 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 19/02/18 21:58, Stefano Stabellini wrote:
> > On big.LITTLE systems not all cores have the same midr. Instead of
> > storing only one vpidr per domain, make it per vcpu and initialize it to
> > the value of the midr of the pcpu where the vcpu will run.
> > 
> > This way, assuming that the vcpu has been created with the right pcpu
> > affinity, the guest will be able to read the right vpidr value, matching
> > the one of the physical cpu.
> > 
> > Signed-off-by: Stefano Stabellini 
> > 
> > ---
> > 
> > - remove warning message
> > - make vpidr per vcpu
> > ---
> >   xen/arch/arm/domain.c| 6 ++
> >   xen/arch/arm/vcpreg.c| 4 ++--
> >   xen/include/asm-arm/domain.h | 6 +++---
> >   3 files changed, 7 insertions(+), 9 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> > index fb51415..41d5d25 100644
> > --- a/xen/arch/arm/domain.c
> > +++ b/xen/arch/arm/domain.c
> > @@ -180,7 +180,7 @@ static void ctxt_switch_to(struct vcpu *n)
> > p2m_restore_state(n);
> >   -WRITE_SYSREG32(n->domain->arch.vpidr, VPIDR_EL2);
> > +WRITE_SYSREG32(n->arch.vpidr, VPIDR_EL2);
> 
> Do we really need to store the vpidr in struct vcpu? It would be simpler and
> more efficient (no memory access) to use directly read MDIR_EL1 and copy it to
> VPIDR_EL1.

I followed your suggestion to drop vpidr from struct vcpu and just read
MDIR_EL1 in ctxt_switch_to. In do_cp14_32 I replaced v->arch.vpidr with
current_cpu_data.midr.bits for simplicity.

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

Re: [Xen-devel] [PATCH v1 2/2] hvm/svm: Implement CPUID events

[Tamas K Lengyel]

On Tue, Feb 20, 2018 at 3:37 AM, Alexandru Stefan ISAILA
 wrote:
> On Lu, 2018-02-19 at 08:25 -0700, Tamas K Lengyel wrote:
>> On Mon, Feb 19, 2018 at 6:07 AM, Alexandru Isaila
>>  wrote:
>> >
>> > At this moment the CPUID events for the AMD architecture are not
>> > forwarded to the monitor layer.
>> >
>> > This patch adds the CPUID event to the common capabilities and then
>> > forwards the event to the monitor layer.
>> >
>> > Signed-off-by: Alexandru Isaila 
>> > ---
>> >  xen/arch/x86/hvm/svm/svm.c| 8 +++-
>> >  xen/include/asm-x86/monitor.h | 2 +-
>> >  2 files changed, 8 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/xen/arch/x86/hvm/svm/svm.c
>> > b/xen/arch/x86/hvm/svm/svm.c
>> > index e36ad05..0f1c57d 100644
>> > --- a/xen/arch/x86/hvm/svm/svm.c
>> > +++ b/xen/arch/x86/hvm/svm/svm.c
>> > @@ -1804,6 +1804,7 @@ static void svm_vmexit_do_cpuid(struct
>> > cpu_user_regs *regs)
>> >  struct vcpu *curr = current;
>> >  unsigned int inst_len;
>> >  struct cpuid_leaf res;
>> > +int rc = 0;
>> >
>> >  if ( (inst_len = __get_instruction_length(curr, INSTR_CPUID))
>> > == 0 )
>> >  return;
>> > @@ -1822,7 +1823,12 @@ static void svm_vmexit_do_cpuid(struct
>> > cpu_user_regs *regs)
>> >  regs->rcx = res.c;
>> >  regs->rdx = res.d;
>> >
>> > -__update_guest_eip(regs, inst_len);
>> > +rc = hvm_monitor_cpuid(inst_len, regs->eax, regs->ecx);
>> > +
>> > +if ( !rc )
>> Missing the rc < 0 case handling.
> Hi Tamas,
>
> I think we can resolve this in 2 ways:
> 1. I do it like on the vmx side and take the __update_guest_eip out of
> the function, return the result from hvm_monitor_cpuid and handle the
> result in the case statement.

+1, I think it helps if the flow is the same across vmx and svm as
much as possible.

Thanks,
Tamas

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

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

[osstest service owner]

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

Regressions :-(

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

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

Re: [Xen-devel] [PATCH 5/5] x86: Rework MSR_TSC_AUX handling from scratch.

[Andrew Cooper]

On 20/02/18 17:35, Roger Pau Monné wrote:
> On Tue, Feb 20, 2018 at 11:58:43AM +, Andrew Cooper wrote:
>> There are many problems with MSR_TSC_AUX handling.
>>
>> To being with, the RDPID instruction reads MSR_TSC_AUX, but it is only the
>> RDTSCP feature which enumerates the MSR.  Therefore, RDPID functionally
>> depends on RDTSCP.
>>
>> For PV guests, we hide RDTSCP but advertise RDPID.  We also silently drop
>> writes to MSR_TSC_AUX, which is very antisocial.  Therefore, enable RDTSCP 
>> for
>> PV guests, which in turn allows RDPID to work.
>>
>> To support RDTSCP properly for PV guests, the MSR_TSC_AUX handling is moved
>> into the generic MSR policy infrastructure, and becomes common.  One
>> improvement is that we will now reject invalid values, rather than silently
>> truncating an accepting them.  This also causes the emulator to reject RDTSCP
>> for guests without the features.
>>
>> One complication is TSC_MODE_PVRDTSCP, in which Xen takes control of
>> MSR_TSC_AUX and the reported value is actually the migration incarnation.  
>> The
>> previous behaviour of this mode was to silently drop writes, but as it is a
>> break in the x86 ABI to start with, switch the semantics to be more sane, and
>> have TSC_MODE_PVRDTSCP make the MSR properly read-only.
>>
>> With PV guests getting to use MSR_TSC_AUX properly now, the MSR needs
>> migrating.  Cope with it the common migration logic.  Care must be taken
>> however to avoid sending the MSR if TSC_MODE_PVRDTSCP is active, as the
>> receiving side will reject the guest_wrmsr().
>>
>> What remains is that tsc_set_info() need to broadcast d->arch.incarnation to
>> all vCPUs MSR block if in TSC_MODE_PVRDTSCP, so the context switching and
>> emulation code functions correctly.
> I have one likely stupid question about the PVRDTSCP, how does the
> guest know it's actually using it? I'm not able to find any cpuid or
> xenfeat to signal the guest it's running in PVRDTSCP mode, and thus
> that MSR_TSC_AUX contains this magic incarnation value?

4x03[0].b

Which I notice now isn't a constant in the public API. :(

(Oh - another misfeature this feature is responsible for is the fact
that there is a time subleaf of the hypervisor CPUID leaves, without any
ability to calculate the number of valid subleaves.)

I've never seen any guest-side code to cope with feature, even in the
classic-linux fork.  I'll defer to Konrad on the topic, but I'm fairly
sure it is vestigial Oracle-ism.

>
> Which TBH seems quite pointless, the guest should be perfectly capable
> of maintaining it's own count of migrations.

The only useful piece of information is whether Xen is having to
virtualise your time values because the frequency is now different to
how it was previously advertised.

Oh - we also include support for emulating RDTSCP for PV guests only, on
incapable hardware (via emul-invl-op).  I was considering restricting
this to PVRDTSC mode only.

>
>> Signed-off-by: Andrew Cooper 
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index 0539551..ab24f87 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -792,7 +792,7 @@ static int hvm_save_cpu_ctxt(struct domain *d, 
>> hvm_domain_context_t *h)
>>  
>>  ctxt.tsc = hvm_get_guest_tsc_fixed(v, d->arch.hvm_domain.sync_tsc);
>>  
>> -ctxt.msr_tsc_aux = hvm_msr_tsc_aux(v);
>> +/* ctxt.msr_tsc_aux omitted - now sent via generic MSR record. */
>>  
>>  hvm_get_segment_register(v, x86_seg_idtr, &seg);
>>  ctxt.idtr_limit = seg.limit;
>> @@ -1046,7 +1046,24 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
>> hvm_domain_context_t *h)
>>  if ( hvm_funcs.tsc_scaling.setup )
>>  hvm_funcs.tsc_scaling.setup(v);
>>  
>> -v->arch.hvm_vcpu.msr_tsc_aux = ctxt.msr_tsc_aux;
>> +/*
>> + * Backwards compatibility.  MSR_TSC_AUX contains different information
>> + * depending on whether TSC_MODE_PVRDTSCP is enabled.
>> + *
>> + * Before Xen 4.11, ctxt.msr_tsc_aux was sent unconditionally and 
>> restored
>> + * here, but the value was otherwise ignored in TSC_MODE_PVRDTSCP.
>> + *
>> + * In 4.11, the logic was changed to send MSR_TSC_AUX via the generic 
>> MSR
>> + * mechanism if tsc_mode != TSC_MODE_PVRDTSCP.  If tsc_mode ==
>> + * TSC_MODE_PVRDTSCP, the tsc logic is responsibile for setting the
>> + * correct value.
>> + *
>> + * For compatibility with migration streams from before 4.11, we restore
>> + * from ctxt.msr_tsc_aux if the TSC code hasn't/isn't in charge, and 
>> we've
>> + * not seen a value arrive in the generic MSR record.
>> + */
>> +if ( d->arch.tsc_mode != TSC_MODE_PVRDTSCP && !v->arch.msr->tsc_aux )
>> +v->arch.msr->tsc_aux = ctxt.msr_tsc_aux;
> I'm having a hard time figuring out whether the MSRs have been loaded
> at this point, I assume there's some guarantee that MSR will be loaded
> before loading the CPU context?

Actually, this is subtly brok

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 119644
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 119644
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 119644
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 119644
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 119644
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 119644
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-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-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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   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:
 qemuuafd3397a8149d8b645004e459bf2002d78f5e267
baseline version:
 qemuue5ecc287a7bd24a1364e23e263cb60cfc8d21eb5

Last test of basis   119644  2018-02-19 10:22:34 Z1 days
Testing same since   119692  2018-02-20 02:00:09 Z0 days1 attempts


People who touched revisions under test:
  Cornelia Huck 
  Jon Emil Jahren 
  Marcel Apfelbaum 
  Peter Maydell 
  Stefan Hajnoczi 
  Yuval Shaia 

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

[Xen-devel] [seabios test] 119698: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  4 host-install(4)broken pass in 119648

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

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

Last test of basis   115539  2017-11-03 20:48:58 Z  108 days
Failing since115733  2017-11-10 17:19:59 Z  101 days  132 attempts
Testing same since   119258  2018-02-15 09:12:54 Z5 days   10 attempts


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

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   broken  
 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

broken-job test-amd64-i386-qemuu-rhel6hvm-amd broken
broken-step test-amd64-i386-qemuu-rhel6hvm-amd host-install(4)

Not pushing.


commit af0daeb2687ad2595482b8a71b02a082a5672ceb
Author: Nikolay Nikolov 
Date:   Sat Feb 10 13:52:17 2018 +0200

floppy: Send 4 sense interrupt commands during controller initialization

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

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

Signed-off-by: Nikolay Nikolov 

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

floppy: Wait for the 

Re: [Xen-devel] [PATCH 5/5] x86: Rework MSR_TSC_AUX handling from scratch.

[Andrew Cooper]

On 20/02/18 17:03, Wei Liu wrote:
> On Tue, Feb 20, 2018 at 11:58:43AM +, Andrew Cooper wrote:
>> There are many problems with MSR_TSC_AUX handling.
>>
>> To being with, the RDPID instruction reads MSR_TSC_AUX, but it is only the
>  ^
>  begin
>
>> RDTSCP feature which enumerates the MSR.  Therefore, RDPID functionally
>> depends on RDTSCP.
>>
>> For PV guests, we hide RDTSCP but advertise RDPID.  We also silently drop
>> writes to MSR_TSC_AUX, which is very antisocial.  Therefore, enable RDTSCP 
>> for
>> PV guests, which in turn allows RDPID to work.
>>
>> To support RDTSCP properly for PV guests, the MSR_TSC_AUX handling is moved
>> into the generic MSR policy infrastructure, and becomes common.  One
>> improvement is that we will now reject invalid values, rather than silently
>> truncating an accepting them.  This also causes the emulator to reject RDTSCP
>  ^
>  and
>
>> for guests without the features.
>>
>>  
> [...]
>> @@ -1284,7 +1285,18 @@ long arch_do_domctl(
>>  for ( j = 0; j < ARRAY_SIZE(msrs_to_send); ++j )
>>  {
>>  uint64_t val;
>> -int rc = guest_rdmsr(v, msrs_to_send[j], &val);
>> +int rc;
>> +
>> +/*
>> + * Skip MSR_TSC_AUX if using TSC_MODE_PVRDTSCP.  In this
>> + * case, the MSR is read-only, and should be rejected if
>> + * seen on the restore side.
>> + */
>> +if ( msrs_to_send[j] == MSR_TSC_AUX &&
>> + d->arch.tsc_mode == TSC_MODE_PVRDTSCP )
>> +continue;
> Shouldn't we increment incarnation and send it over to the remote end?
> Or send the original value and let the remote increments it?

incarnation, and its increments, is handled in tsc_set_info(), which is
keyed off the TSC_INFO record in the migration stream.  That side of
things "already works" (FSVO "works").

The check here is to cause us to skip everything to do with migrating
MSR_TSC_AUX if we think the TSC code is responsible for the value.

> Frankly I'm not sure how guest is supposed to use that value, but
> letting the receiving end restart at 0, which can end up using the same
> incarnation as before seems conceptually wrong to me. The more so you
> mention a lot of migration's in your previous patches.

I don't understand what thought and planning lead to TSC_MODE_PVRDTSCP.

From an implementation side of things, it was also responsible for
introducing a binary incompatibility into the migration stream between
3.3 and 3.4 which caused sporadic loss of interrupts on migrate, and was
sufficiently complicated to track down that it only got fixed in 4.2 
(c/s 620ce29a2d45, but not that that change is an accurate reflection of
how much stress and effort went into tracking the issue down).

> This is not disagreeing with the point that IA32_TSC_AUX should be
> read-only for PV guest.

Any guest running with TSC_MODE_PVRDTSCP.  It supposedly works for HVM
guests as well.

> And +1 for the unification of HVM and PV code for handling this.

An observant person might notice that all MSR handing is starting to
become common, and this might be following suite from CPUID a few
release ago.  This totally isn't on purpose...

~Andrew

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

Re: [Xen-devel] [PATCH 4/5] x86/pv: Remove deferred RDTSC{, P} handling in pv_emulate_privileged_op()

[Roger Pau Monné]

On Tue, Feb 20, 2018 at 04:37:51PM +, Andrew Cooper wrote:
> On 20/02/18 16:28, Roger Pau Monné wrote:
> > On Tue, Feb 20, 2018 at 11:58:42AM +, Andrew Cooper wrote:
> >> The handling of RDTSCP for PV guests has been broken (AFAICT forever).
> >>
> >> To start with, RDTSCP is hidden from PV guests so the MSR_TSC_AUX path 
> >> should
> >> be unreachable.  However, this appears to be a "feature" of 
> >> TSC_MODE_PVRDTSCP,
> >> and the emulator doesn't perform appropriate feature checking.  
> >> (Conversely,
> >> we unilaterally advertise RDPID which uses the same path, but it should 
> >> never
> >> trap on #GP to arrive here in the first place).
> >>
> >> A PV guest typically can see RDTSCP in native CPUID, so userspace will
> >> probably end up using it.  On a capable pipeline (without TSD, see below), 
> >> it
> >> will execute normally and return non-virtualised data.
> >>
> >> When a virtual TSC mode is not specified for the domain, CR4.TSD is left
> >> clear, so executing RDTSCP will execute without trapping.  However, a guest
> >> kernel may set TSD itself, at which point the emulator should not suddenly
> >> switch to virtualised TSC mode and start handing out differently-scaled
> >> values.
> >>
> >> Drop all the deferral logic, and return scaled or raw TSC values depending
> >> only on currd->arch.vtsc.  This changes the exact moment at which the
> >> timestamp is taken, but that doesn't matter from the guests point of view, 
> >> and
> >> is consistent with the HVM side of things.  It also means that RDTSC and
> >> RDTSCP are now consistent WRT handing out native or virtualised timestamps.
> >>
> >> The MSR_TSC_AUX case unconditionally returns the migration incarnation or
> >> zero, depending on TSC_MODE_PVRDTSCP, which is faster than re-reading it 
> >> out
> >> of hardware.
> >>
> >> This is a behavioural change for guests, but the semantics are rather more
> >> sane.  It lays groundwork for further fixes.
> >>
> >> Signed-off-by: Andrew Cooper 
> >> ---
> >> CC: Jan Beulich 
> >> CC: Wei Liu 
> >> CC: Roger Pau Monné 
> >> CC: Konrad Rzeszutek Wilk 
> >> ---
> >>  xen/arch/x86/pv/emul-priv-op.c | 35 +--
> >>  1 file changed, 5 insertions(+), 30 deletions(-)
> >>
> >> diff --git a/xen/arch/x86/pv/emul-priv-op.c 
> >> b/xen/arch/x86/pv/emul-priv-op.c
> >> index d4d64f2..4e3641d 100644
> >> --- a/xen/arch/x86/pv/emul-priv-op.c
> >> +++ b/xen/arch/x86/pv/emul-priv-op.c
> >> @@ -60,9 +60,6 @@ struct priv_op_ctxt {
> >>  } cs;
> >>  char *io_emul_stub;
> >>  unsigned int bpmatch;
> >> -unsigned int tsc;
> >> -#define TSC_BASE 1
> >> -#define TSC_AUX 2
> >>  };
> >>  
> >>  /* I/O emulation support. Helper routines for, and type of, the stack 
> >> stub. */
> >> @@ -843,8 +840,7 @@ static inline bool is_cpufreq_controller(const struct 
> >> domain *d)
> >>  static int read_msr(unsigned int reg, uint64_t *val,
> >>  struct x86_emulate_ctxt *ctxt)
> >>  {
> >> -struct priv_op_ctxt *poc = container_of(ctxt, struct priv_op_ctxt, 
> >> ctxt);
> >> -const struct vcpu *curr = current;
> >> +struct vcpu *curr = current;
> > I think you can keep the const here?
> 
> pv_soft_rdtsc() mutates curr.  This change is most certainly not spurious.

Oh right, you constified regs but not the vcpu parameter. AFAICT the
vcpu parameter of pv_soft_rdtsc could also be constified? It's only
used to get the domain and whether the guests is in kernel or user
mode.

> >>  const struct domain *currd = curr->domain;
> >>  bool vpmu_msr = false;
> >>  int ret;
> >> @@ -880,20 +876,13 @@ static int read_msr(unsigned int reg, uint64_t *val,
> >>  *val = curr->arch.pv_vcpu.gs_base_user;
> >>  return X86EMUL_OKAY;
> >>  
> >> -/*
> >> - * In order to fully retain original behavior, defer calling
> >> - * pv_soft_rdtsc() until after emulation. This may want/need to be
> >> - * reconsidered.
> >> - */
> >>  case MSR_IA32_TSC:
> >> -poc->tsc |= TSC_BASE;
> >> -goto normal;
> >> +*val = currd->arch.vtsc ? pv_soft_rdtsc(curr, ctxt->regs) : 
> >> rdtsc();
> >> +return X86EMUL_OKAY;
> >>  
> >>  case MSR_TSC_AUX:
> >> -poc->tsc |= TSC_AUX;
> >> -if ( cpu_has_rdtscp )
> >> -goto normal;
> >> -*val = 0;
> >> +*val = (uint32_t)((currd->arch.tsc_mode == TSC_MODE_PVRDTSCP)
> >> +  ? currd->arch.incarnation : 0);
> > I wonder whether Xen should inject a #GP here if tsc_mode is not
> > PVRDTSCP and RDPID is not available.
> 
> RDPID would be a layering violation.  Also, a lot of this changes again
> in patch 5.

I see, patch 5 makes this all much better. And this is not any worse
that the previous behavior:

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 5/5] x86: Rework MSR_TSC_AUX handling from scratch.

[Roger Pau Monné]

On Tue, Feb 20, 2018 at 11:58:43AM +, Andrew Cooper wrote:
> There are many problems with MSR_TSC_AUX handling.
> 
> To being with, the RDPID instruction reads MSR_TSC_AUX, but it is only the
> RDTSCP feature which enumerates the MSR.  Therefore, RDPID functionally
> depends on RDTSCP.
> 
> For PV guests, we hide RDTSCP but advertise RDPID.  We also silently drop
> writes to MSR_TSC_AUX, which is very antisocial.  Therefore, enable RDTSCP for
> PV guests, which in turn allows RDPID to work.
> 
> To support RDTSCP properly for PV guests, the MSR_TSC_AUX handling is moved
> into the generic MSR policy infrastructure, and becomes common.  One
> improvement is that we will now reject invalid values, rather than silently
> truncating an accepting them.  This also causes the emulator to reject RDTSCP
> for guests without the features.
> 
> One complication is TSC_MODE_PVRDTSCP, in which Xen takes control of
> MSR_TSC_AUX and the reported value is actually the migration incarnation.  The
> previous behaviour of this mode was to silently drop writes, but as it is a
> break in the x86 ABI to start with, switch the semantics to be more sane, and
> have TSC_MODE_PVRDTSCP make the MSR properly read-only.
> 
> With PV guests getting to use MSR_TSC_AUX properly now, the MSR needs
> migrating.  Cope with it the common migration logic.  Care must be taken
> however to avoid sending the MSR if TSC_MODE_PVRDTSCP is active, as the
> receiving side will reject the guest_wrmsr().
> 
> What remains is that tsc_set_info() need to broadcast d->arch.incarnation to
> all vCPUs MSR block if in TSC_MODE_PVRDTSCP, so the context switching and
> emulation code functions correctly.

I have one likely stupid question about the PVRDTSCP, how does the
guest know it's actually using it? I'm not able to find any cpuid or
xenfeat to signal the guest it's running in PVRDTSCP mode, and thus
that MSR_TSC_AUX contains this magic incarnation value?

Which TBH seems quite pointless, the guest should be perfectly capable
of maintaining it's own count of migrations.

> 
> Signed-off-by: Andrew Cooper 

> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 0539551..ab24f87 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -792,7 +792,7 @@ static int hvm_save_cpu_ctxt(struct domain *d, 
> hvm_domain_context_t *h)
>  
>  ctxt.tsc = hvm_get_guest_tsc_fixed(v, d->arch.hvm_domain.sync_tsc);
>  
> -ctxt.msr_tsc_aux = hvm_msr_tsc_aux(v);
> +/* ctxt.msr_tsc_aux omitted - now sent via generic MSR record. */
>  
>  hvm_get_segment_register(v, x86_seg_idtr, &seg);
>  ctxt.idtr_limit = seg.limit;
> @@ -1046,7 +1046,24 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
> hvm_domain_context_t *h)
>  if ( hvm_funcs.tsc_scaling.setup )
>  hvm_funcs.tsc_scaling.setup(v);
>  
> -v->arch.hvm_vcpu.msr_tsc_aux = ctxt.msr_tsc_aux;
> +/*
> + * Backwards compatibility.  MSR_TSC_AUX contains different information
> + * depending on whether TSC_MODE_PVRDTSCP is enabled.
> + *
> + * Before Xen 4.11, ctxt.msr_tsc_aux was sent unconditionally and 
> restored
> + * here, but the value was otherwise ignored in TSC_MODE_PVRDTSCP.
> + *
> + * In 4.11, the logic was changed to send MSR_TSC_AUX via the generic MSR
> + * mechanism if tsc_mode != TSC_MODE_PVRDTSCP.  If tsc_mode ==
> + * TSC_MODE_PVRDTSCP, the tsc logic is responsibile for setting the
> + * correct value.
> + *
> + * For compatibility with migration streams from before 4.11, we restore
> + * from ctxt.msr_tsc_aux if the TSC code hasn't/isn't in charge, and 
> we've
> + * not seen a value arrive in the generic MSR record.
> + */
> +if ( d->arch.tsc_mode != TSC_MODE_PVRDTSCP && !v->arch.msr->tsc_aux )
> +v->arch.msr->tsc_aux = ctxt.msr_tsc_aux;

I'm having a hard time figuring out whether the MSRs have been loaded
at this point, I assume there's some guarantee that MSR will be loaded
before loading the CPU context?

The rest LGTM.

Roger.

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

Re: [Xen-devel] [PATCH 5/5] x86: Rework MSR_TSC_AUX handling from scratch.

[Wei Liu]

On Tue, Feb 20, 2018 at 11:58:43AM +, Andrew Cooper wrote:
> There are many problems with MSR_TSC_AUX handling.
> 
> To being with, the RDPID instruction reads MSR_TSC_AUX, but it is only the
 ^
 begin

> RDTSCP feature which enumerates the MSR.  Therefore, RDPID functionally
> depends on RDTSCP.
> 
> For PV guests, we hide RDTSCP but advertise RDPID.  We also silently drop
> writes to MSR_TSC_AUX, which is very antisocial.  Therefore, enable RDTSCP for
> PV guests, which in turn allows RDPID to work.
> 
> To support RDTSCP properly for PV guests, the MSR_TSC_AUX handling is moved
> into the generic MSR policy infrastructure, and becomes common.  One
> improvement is that we will now reject invalid values, rather than silently
> truncating an accepting them.  This also causes the emulator to reject RDTSCP
 ^
 and

> for guests without the features.
> 
>  
[...]
> @@ -1284,7 +1285,18 @@ long arch_do_domctl(
>  for ( j = 0; j < ARRAY_SIZE(msrs_to_send); ++j )
>  {
>  uint64_t val;
> -int rc = guest_rdmsr(v, msrs_to_send[j], &val);
> +int rc;
> +
> +/*
> + * Skip MSR_TSC_AUX if using TSC_MODE_PVRDTSCP.  In this
> + * case, the MSR is read-only, and should be rejected if
> + * seen on the restore side.
> + */
> +if ( msrs_to_send[j] == MSR_TSC_AUX &&
> + d->arch.tsc_mode == TSC_MODE_PVRDTSCP )
> +continue;

Shouldn't we increment incarnation and send it over to the remote end?
Or send the original value and let the remote increments it?

Frankly I'm not sure how guest is supposed to use that value, but
letting the receiving end restart at 0, which can end up using the same
incarnation as before seems conceptually wrong to me. The more so you
mention a lot of migration's in your previous patches.

This is not disagreeing with the point that IA32_TSC_AUX should be
read-only for PV guest.

And +1 for the unification of HVM and PV code for handling this.

Wei.

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

Re: [Xen-devel] [PATCH 4/5] x86/pv: Remove deferred RDTSC{, P} handling in pv_emulate_privileged_op()

[Andrew Cooper]

On 20/02/18 16:28, Roger Pau Monné wrote:
> On Tue, Feb 20, 2018 at 11:58:42AM +, Andrew Cooper wrote:
>> The handling of RDTSCP for PV guests has been broken (AFAICT forever).
>>
>> To start with, RDTSCP is hidden from PV guests so the MSR_TSC_AUX path should
>> be unreachable.  However, this appears to be a "feature" of 
>> TSC_MODE_PVRDTSCP,
>> and the emulator doesn't perform appropriate feature checking.  (Conversely,
>> we unilaterally advertise RDPID which uses the same path, but it should never
>> trap on #GP to arrive here in the first place).
>>
>> A PV guest typically can see RDTSCP in native CPUID, so userspace will
>> probably end up using it.  On a capable pipeline (without TSD, see below), it
>> will execute normally and return non-virtualised data.
>>
>> When a virtual TSC mode is not specified for the domain, CR4.TSD is left
>> clear, so executing RDTSCP will execute without trapping.  However, a guest
>> kernel may set TSD itself, at which point the emulator should not suddenly
>> switch to virtualised TSC mode and start handing out differently-scaled
>> values.
>>
>> Drop all the deferral logic, and return scaled or raw TSC values depending
>> only on currd->arch.vtsc.  This changes the exact moment at which the
>> timestamp is taken, but that doesn't matter from the guests point of view, 
>> and
>> is consistent with the HVM side of things.  It also means that RDTSC and
>> RDTSCP are now consistent WRT handing out native or virtualised timestamps.
>>
>> The MSR_TSC_AUX case unconditionally returns the migration incarnation or
>> zero, depending on TSC_MODE_PVRDTSCP, which is faster than re-reading it out
>> of hardware.
>>
>> This is a behavioural change for guests, but the semantics are rather more
>> sane.  It lays groundwork for further fixes.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Wei Liu 
>> CC: Roger Pau Monné 
>> CC: Konrad Rzeszutek Wilk 
>> ---
>>  xen/arch/x86/pv/emul-priv-op.c | 35 +--
>>  1 file changed, 5 insertions(+), 30 deletions(-)
>>
>> diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
>> index d4d64f2..4e3641d 100644
>> --- a/xen/arch/x86/pv/emul-priv-op.c
>> +++ b/xen/arch/x86/pv/emul-priv-op.c
>> @@ -60,9 +60,6 @@ struct priv_op_ctxt {
>>  } cs;
>>  char *io_emul_stub;
>>  unsigned int bpmatch;
>> -unsigned int tsc;
>> -#define TSC_BASE 1
>> -#define TSC_AUX 2
>>  };
>>  
>>  /* I/O emulation support. Helper routines for, and type of, the stack stub. 
>> */
>> @@ -843,8 +840,7 @@ static inline bool is_cpufreq_controller(const struct 
>> domain *d)
>>  static int read_msr(unsigned int reg, uint64_t *val,
>>  struct x86_emulate_ctxt *ctxt)
>>  {
>> -struct priv_op_ctxt *poc = container_of(ctxt, struct priv_op_ctxt, 
>> ctxt);
>> -const struct vcpu *curr = current;
>> +struct vcpu *curr = current;
> I think you can keep the const here?

pv_soft_rdtsc() mutates curr.  This change is most certainly not spurious.

>>  const struct domain *currd = curr->domain;
>>  bool vpmu_msr = false;
>>  int ret;
>> @@ -880,20 +876,13 @@ static int read_msr(unsigned int reg, uint64_t *val,
>>  *val = curr->arch.pv_vcpu.gs_base_user;
>>  return X86EMUL_OKAY;
>>  
>> -/*
>> - * In order to fully retain original behavior, defer calling
>> - * pv_soft_rdtsc() until after emulation. This may want/need to be
>> - * reconsidered.
>> - */
>>  case MSR_IA32_TSC:
>> -poc->tsc |= TSC_BASE;
>> -goto normal;
>> +*val = currd->arch.vtsc ? pv_soft_rdtsc(curr, ctxt->regs) : rdtsc();
>> +return X86EMUL_OKAY;
>>  
>>  case MSR_TSC_AUX:
>> -poc->tsc |= TSC_AUX;
>> -if ( cpu_has_rdtscp )
>> -goto normal;
>> -*val = 0;
>> +*val = (uint32_t)((currd->arch.tsc_mode == TSC_MODE_PVRDTSCP)
>> +  ? currd->arch.incarnation : 0);
> I wonder whether Xen should inject a #GP here if tsc_mode is not
> PVRDTSCP and RDPID is not available.

RDPID would be a layering violation.  Also, a lot of this changes again
in patch 5.

~Andrew

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

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

[Stefano Stabellini]

On Tue, 20 Feb 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 19/02/18 21:58, Stefano Stabellini wrote:
> > diff --git a/docs/misc/xen-command-line.markdown
> > b/docs/misc/xen-command-line.markdown
> > index 2184cb9..8997904 100644
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -1007,7 +1007,12 @@ Control Xens use of the APEI Hardware Error Source
> > Table, should one be found.
> > Say yes at your own risk if you want to enable heterogenous computing
> >   (such as big.LITTLE). This may result to an unstable and insecure
> > -platform. When the option is disabled (default), CPUs that are not
> > +platform, unless you manually specify the cpu affinity of all domains so
> > +that all vcpus are scheduled on the same class of pcpus (big or LITTLE
> > +but not both). vcpu migration between big cores and LITTLE cores is not
> > +supported. See docs/misc/arm/big.LITTLE.txt for more information.
> > +
> > +When the hmp-unsafe option is disabled (default), CPUs that are not
> >   identical to the boot CPU will be parked and not used by Xen.
> > ### hpetbroadcast
> > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> > index 122c0b5..d04b7c7 100644
> > --- a/xen/arch/arm/smpboot.c
> > +++ b/xen/arch/arm/smpboot.c
> > @@ -266,7 +266,7 @@ void __init smp_init_cpus(void)
> > if ( opt_hmp_unsafe )
> >   warning_add("WARNING: HMP COMPUTING HAS BEEN ENABLED.\n"
> > -"It has implications on the security and stability of
> > the system.\n");
> > +"It has implications on the security and stability of
> > the system, unless the cpu affinity of all domains is specified.\n");
> 
> The warning message will not be print nicely on serial. Please make sure it is
> split at 72 characters.

OK


> >   }
> > int __init
> > @@ -308,13 +308,14 @@ void start_secondary(unsigned long boot_phys_offset,
> >   /*
> >* Currently Xen assumes the platform has only one kind of CPUs.
> >* This assumption does not hold on big.LITTLE platform and may
> > - * result to instability and insecure platform. Better to park them
> > - * for now.
> > + * result to instability and insecure platform (unless cpu affinity
> > + * is manually specified for all domains). Better to park them for
> > + * now.
> >*/
> >   if ( !opt_hmp_unsafe &&
> >current_cpu_data.midr.bits != boot_cpu_data.midr.bits )
> >   {
> > -printk(XENLOG_ERR "CPU%u MIDR (0x%x) does not match boot CPU MIDR
> > (0x%x).\n",
> > +printk(XENLOG_ERR "CPU%u MIDR (0x%x) does not match boot CPU MIDR
> > (0x%x), disable cpu (see big.LITTLE.txt under docs/).\n",
> 
> Same here.
> 
> >  smp_processor_id(), current_cpu_data.midr.bits,
> >  boot_cpu_data.midr.bits);
> >   stop_cpu();
> > 
> 
> Cheers,
> 
> -- 
> Julien Grall
> 

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

Re: [Xen-devel] [PATCH 4/5] x86/pv: Remove deferred RDTSC{, P} handling in pv_emulate_privileged_op()

[Roger Pau Monné]

On Tue, Feb 20, 2018 at 11:58:42AM +, Andrew Cooper wrote:
> The handling of RDTSCP for PV guests has been broken (AFAICT forever).
> 
> To start with, RDTSCP is hidden from PV guests so the MSR_TSC_AUX path should
> be unreachable.  However, this appears to be a "feature" of TSC_MODE_PVRDTSCP,
> and the emulator doesn't perform appropriate feature checking.  (Conversely,
> we unilaterally advertise RDPID which uses the same path, but it should never
> trap on #GP to arrive here in the first place).
> 
> A PV guest typically can see RDTSCP in native CPUID, so userspace will
> probably end up using it.  On a capable pipeline (without TSD, see below), it
> will execute normally and return non-virtualised data.
> 
> When a virtual TSC mode is not specified for the domain, CR4.TSD is left
> clear, so executing RDTSCP will execute without trapping.  However, a guest
> kernel may set TSD itself, at which point the emulator should not suddenly
> switch to virtualised TSC mode and start handing out differently-scaled
> values.
> 
> Drop all the deferral logic, and return scaled or raw TSC values depending
> only on currd->arch.vtsc.  This changes the exact moment at which the
> timestamp is taken, but that doesn't matter from the guests point of view, and
> is consistent with the HVM side of things.  It also means that RDTSC and
> RDTSCP are now consistent WRT handing out native or virtualised timestamps.
> 
> The MSR_TSC_AUX case unconditionally returns the migration incarnation or
> zero, depending on TSC_MODE_PVRDTSCP, which is faster than re-reading it out
> of hardware.
> 
> This is a behavioural change for guests, but the semantics are rather more
> sane.  It lays groundwork for further fixes.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> CC: Konrad Rzeszutek Wilk 
> ---
>  xen/arch/x86/pv/emul-priv-op.c | 35 +--
>  1 file changed, 5 insertions(+), 30 deletions(-)
> 
> diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
> index d4d64f2..4e3641d 100644
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -60,9 +60,6 @@ struct priv_op_ctxt {
>  } cs;
>  char *io_emul_stub;
>  unsigned int bpmatch;
> -unsigned int tsc;
> -#define TSC_BASE 1
> -#define TSC_AUX 2
>  };
>  
>  /* I/O emulation support. Helper routines for, and type of, the stack stub. 
> */
> @@ -843,8 +840,7 @@ static inline bool is_cpufreq_controller(const struct 
> domain *d)
>  static int read_msr(unsigned int reg, uint64_t *val,
>  struct x86_emulate_ctxt *ctxt)
>  {
> -struct priv_op_ctxt *poc = container_of(ctxt, struct priv_op_ctxt, ctxt);
> -const struct vcpu *curr = current;
> +struct vcpu *curr = current;

I think you can keep the const here?

>  const struct domain *currd = curr->domain;
>  bool vpmu_msr = false;
>  int ret;
> @@ -880,20 +876,13 @@ static int read_msr(unsigned int reg, uint64_t *val,
>  *val = curr->arch.pv_vcpu.gs_base_user;
>  return X86EMUL_OKAY;
>  
> -/*
> - * In order to fully retain original behavior, defer calling
> - * pv_soft_rdtsc() until after emulation. This may want/need to be
> - * reconsidered.
> - */
>  case MSR_IA32_TSC:
> -poc->tsc |= TSC_BASE;
> -goto normal;
> +*val = currd->arch.vtsc ? pv_soft_rdtsc(curr, ctxt->regs) : rdtsc();
> +return X86EMUL_OKAY;
>  
>  case MSR_TSC_AUX:
> -poc->tsc |= TSC_AUX;
> -if ( cpu_has_rdtscp )
> -goto normal;
> -*val = 0;
> +*val = (uint32_t)((currd->arch.tsc_mode == TSC_MODE_PVRDTSCP)
> +  ? currd->arch.incarnation : 0);

I wonder whether Xen should inject a #GP here if tsc_mode is not
PVRDTSCP and RDPID is not available.

Thanks, Roger.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  a4b37cd0f1d038a7b754a87942d6bddc33493223
baseline version:
 libvirt  fb0db76a47d0ce66b7fe11f88fee53dcdfbe6f12

Last test of basis   119539  2018-02-18 04:26:44 Z2 days
Testing same since   119702  2018-02-20 04:20:38 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Daniel P. Berrangé 
  Laine Stump 
  Peter Krempa 

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



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

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

Explanation of these reports, and of 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


Push

Re: [Xen-devel] [PATCH 3/5] x86/time: Rework pv_soft_rdtsc() to aid further cleanup

[Andrew Cooper]

On 20/02/18 16:04, Roger Pau Monné wrote:
> On Tue, Feb 20, 2018 at 11:58:41AM +, Andrew Cooper wrote:
>> Having pv_soft_rdtsc() emulate all parts of an rdtscp is awkward, and gets in
>> the way of some intended cleanup.
>>
>>  * Drop the rdtscp parameter and always make the caller responsible for ecx
>>updates when appropriate.
>>  * Switch the function from being void, and return the main timestamp in the
>>return value.
>>
>> The regs parameter is still needed, but only for the stats collection, once
>> again bringing into question their utility.  The parameter can however switch
>> to being const.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Wei Liu 
>> CC: Roger Pau Monné 
>> CC: Konrad Rzeszutek Wilk 
>> ---
>>  xen/arch/x86/pv/emul-inv-op.c  |  7 ++-
>>  xen/arch/x86/pv/emul-priv-op.c | 12 
>>  xen/arch/x86/time.c|  8 ++--
>>  xen/include/asm-x86/time.h |  2 +-
>>  4 files changed, 17 insertions(+), 12 deletions(-)
>>
>> diff --git a/xen/arch/x86/pv/emul-inv-op.c b/xen/arch/x86/pv/emul-inv-op.c
>> index f894417..b1916b4 100644
>> --- a/xen/arch/x86/pv/emul-inv-op.c
>> +++ b/xen/arch/x86/pv/emul-inv-op.c
>> @@ -46,6 +46,7 @@ static int emulate_invalid_rdtscp(struct cpu_user_regs 
>> *regs)
>>  char opcode[3];
>>  unsigned long eip, rc;
>>  struct vcpu *v = current;
>> +struct domain *currd = v->domain;
> const?
>
>>  
>>  eip = regs->rip;
>>  if ( (rc = copy_from_user(opcode, (char *)eip, sizeof(opcode))) != 0 )
>> @@ -56,7 +57,11 @@ static int emulate_invalid_rdtscp(struct cpu_user_regs 
>> *regs)
>>  if ( memcmp(opcode, "\xf\x1\xf9", sizeof(opcode)) )
>>  return 0;
>>  eip += sizeof(opcode);
>> -pv_soft_rdtsc(v, regs, 1);
>> +
>> +msr_split(regs, pv_soft_rdtsc(v, regs));
>> +regs->rcx = ((currd->arch.tsc_mode == TSC_MODE_PVRDTSCP)
>> + ? currd->arch.incarnation : 0);
> In the previous patch you use the same expression without any
> parentheses. I think I prefer the version without parentheses. I also
> wonder whether it would make sense to turn this into a macro (seeing
> it being used in the previous patch and also further below).
>
> With those fixed (if applicable):

None of them survive patch 5 in the series.  I'll fix the formatting,
but I'm not going to macro-ise anything.

>
> Reviewed-by: Roger Pau Monné 
>
> Thanks, Roger.


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

Re: [Xen-devel] [PATCH 4/5] x86/pv: Remove deferred RDTSC{, P} handling in pv_emulate_privileged_op()

[Wei Liu]

On Tue, Feb 20, 2018 at 11:58:42AM +, Andrew Cooper wrote:
> The handling of RDTSCP for PV guests has been broken (AFAICT forever).
> 
> To start with, RDTSCP is hidden from PV guests so the MSR_TSC_AUX path should
> be unreachable.  However, this appears to be a "feature" of TSC_MODE_PVRDTSCP,
> and the emulator doesn't perform appropriate feature checking.  (Conversely,
> we unilaterally advertise RDPID which uses the same path, but it should never
> trap on #GP to arrive here in the first place).
> 
> A PV guest typically can see RDTSCP in native CPUID, so userspace will
> probably end up using it.  On a capable pipeline (without TSD, see below), it
> will execute normally and return non-virtualised data.
> 
> When a virtual TSC mode is not specified for the domain, CR4.TSD is left
> clear, so executing RDTSCP will execute without trapping.  However, a guest
> kernel may set TSD itself, at which point the emulator should not suddenly
> switch to virtualised TSC mode and start handing out differently-scaled
> values.
> 
> Drop all the deferral logic, and return scaled or raw TSC values depending
> only on currd->arch.vtsc.  This changes the exact moment at which the
> timestamp is taken, but that doesn't matter from the guests point of view, and
> is consistent with the HVM side of things.  It also means that RDTSC and
> RDTSCP are now consistent WRT handing out native or virtualised timestamps.
> 
> The MSR_TSC_AUX case unconditionally returns the migration incarnation or
> zero, depending on TSC_MODE_PVRDTSCP, which is faster than re-reading it out
> of hardware.
> 
> This is a behavioural change for guests, but the semantics are rather more
> sane.  It lays groundwork for further fixes.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 3/5] x86/time: Rework pv_soft_rdtsc() to aid further cleanup

[Roger Pau Monné]

On Tue, Feb 20, 2018 at 11:58:41AM +, Andrew Cooper wrote:
> Having pv_soft_rdtsc() emulate all parts of an rdtscp is awkward, and gets in
> the way of some intended cleanup.
> 
>  * Drop the rdtscp parameter and always make the caller responsible for ecx
>updates when appropriate.
>  * Switch the function from being void, and return the main timestamp in the
>return value.
> 
> The regs parameter is still needed, but only for the stats collection, once
> again bringing into question their utility.  The parameter can however switch
> to being const.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> CC: Konrad Rzeszutek Wilk 
> ---
>  xen/arch/x86/pv/emul-inv-op.c  |  7 ++-
>  xen/arch/x86/pv/emul-priv-op.c | 12 
>  xen/arch/x86/time.c|  8 ++--
>  xen/include/asm-x86/time.h |  2 +-
>  4 files changed, 17 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/x86/pv/emul-inv-op.c b/xen/arch/x86/pv/emul-inv-op.c
> index f894417..b1916b4 100644
> --- a/xen/arch/x86/pv/emul-inv-op.c
> +++ b/xen/arch/x86/pv/emul-inv-op.c
> @@ -46,6 +46,7 @@ static int emulate_invalid_rdtscp(struct cpu_user_regs 
> *regs)
>  char opcode[3];
>  unsigned long eip, rc;
>  struct vcpu *v = current;
> +struct domain *currd = v->domain;
const?

>  
>  eip = regs->rip;
>  if ( (rc = copy_from_user(opcode, (char *)eip, sizeof(opcode))) != 0 )
> @@ -56,7 +57,11 @@ static int emulate_invalid_rdtscp(struct cpu_user_regs 
> *regs)
>  if ( memcmp(opcode, "\xf\x1\xf9", sizeof(opcode)) )
>  return 0;
>  eip += sizeof(opcode);
> -pv_soft_rdtsc(v, regs, 1);
> +
> +msr_split(regs, pv_soft_rdtsc(v, regs));
> +regs->rcx = ((currd->arch.tsc_mode == TSC_MODE_PVRDTSCP)
> + ? currd->arch.incarnation : 0);

In the previous patch you use the same expression without any
parentheses. I think I prefer the version without parentheses. I also
wonder whether it would make sense to turn this into a macro (seeing
it being used in the previous patch and also further below).

With those fixed (if applicable):

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v2] build: remove shim related targets

[Jan Beulich]

>>> On 20.02.18 at 15:37,  wrote:
> --- a/tools/firmware/xen-dir/Makefile
> +++ b/tools/firmware/xen-dir/Makefile
> @@ -48,13 +48,14 @@ shim-%config: $(D) FORCE
>   KCONFIG_CONFIG=$(CURDIR)/shim.config
>  
>  xen-shim: $(D) shim-olddefconfig
> - $(MAKE) -C $(D)/xen install-shim \
> + $(MAKE) -C $(D)/xen build \
>   XEN_CONFIG_EXPERT=y \
> - KCONFIG_CONFIG=$(CURDIR)/shim.config \
> - DESTDIR=$(CURDIR)
> + KCONFIG_CONFIG=$(CURDIR)/shim.config
> + ln -sf $(D)/xen/xen xen-shim
> + ln -sf $(D)/xen/xen-syms xen-shim-syms

I think it is advisable to use $@ instead of open coding the target.

> @@ -151,9 +144,6 @@ $(TARGET): delete-unfresh-files
>   $(MAKE) -f $(BASEDIR)/Rules.mk include/asm-$(TARGET_ARCH)/asm-offsets.h
>   $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) $(TARGET)
>  
> -$(TARGET)-shim: $(TARGET)
> - $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) $(TARGET)-shim

I think you need to rebase over the change I've committed earlier
today.

Jan


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

Re: [Xen-devel] [PATCH] build: remove shim related targets

[Ian Jackson]

Roger Pau Monné writes ("Re: [PATCH] build: remove shim related targets"):
> On Tue, Feb 20, 2018 at 03:09:18PM +, Ian Jackson wrote:
> > Roger Pau Monne writes ("[PATCH] build: remove shim related targets"):
> > > There's no need to have shim specific targets, so just use the regular
> > > xen makefile targets in order to build the shim binary.
> > 
> > I haven't been following this, mostly because I've been away, but:
> > 
> > Previously (in the Comet advice in the advisory, for example) we told
> > people to run this special Makefile target, and that special Makefile
> > target would rebuild the whole of the hypervisor in some special way.
> > 
> > Is that linkfarm and rebuild now no longer needed, then ?
> 
> That's still needed in order to build the shim with the right Kconfig
> (which should be different from the Kconfig used for the bare metal
> hypervisor build).
> 
> The main difference is that we can get rid of the shim related
> makefile targets inside of xen/ because the same makefile targets can
> be used to build a shim or a bare-metal version of Xen.

Ah I see.  Indeed if I look at the patch again the existing published
entrypoint shim target is being retained, and I am being needlessly
alarmed by the patch subject line.

Thanks for the explanation.

Ian.

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

Re: [Xen-devel] [PATCH] build: remove shim related targets

[Roger Pau Monné]

On Tue, Feb 20, 2018 at 03:09:18PM +, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH] build: remove shim related targets"):
> > There's no need to have shim specific targets, so just use the regular
> > xen makefile targets in order to build the shim binary.
> 
> I haven't been following this, mostly because I've been away, but:
> 
> Previously (in the Comet advice in the advisory, for example) we told
> people to run this special Makefile target, and that special Makefile
> target would rebuild the whole of the hypervisor in some special way.
> 
> Is that linkfarm and rebuild now no longer needed, then ?

That's still needed in order to build the shim with the right Kconfig
(which should be different from the Kconfig used for the bare metal
hypervisor build).

The main difference is that we can get rid of the shim related
makefile targets inside of xen/ because the same makefile targets can
be used to build a shim or a bare-metal version of Xen.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 2/5] x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV context

[Roger Pau Monné]

On Tue, Feb 20, 2018 at 11:58:40AM +, Andrew Cooper wrote:
> If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value in
> MSR_TSC_AUX, irrespective of whether the relevant CPUID features are
> advertised/hidden.
> 
> At the moment, paravirt_ctxt_switch_to() only writes to MSR_TSC_AUX if
> TSC_MODE_PVRDTSCP mode is enabled, but this is not the default mode.
> Therefore, default PV guests can read the value from a previously scheduled
> HVM vcpu, or TSC_MODE_PVRDTSCP-enabled PV guest.
> 
> Alter the PV path to always write to MSR_TSC_AUX, using 0 in the common case.
> 
> To amortise overhead cost, introduce wrmsr_tsc_aux() which performs a lazy
> update of the MSR, and use this function consistently across the codebase.
>
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 3/5] x86/time: Rework pv_soft_rdtsc() to aid further cleanup

[Wei Liu]

On Tue, Feb 20, 2018 at 11:58:41AM +, Andrew Cooper wrote:
> Having pv_soft_rdtsc() emulate all parts of an rdtscp is awkward, and gets in
> the way of some intended cleanup.
> 
>  * Drop the rdtscp parameter and always make the caller responsible for ecx
>updates when appropriate.
>  * Switch the function from being void, and return the main timestamp in the
>return value.
> 
> The regs parameter is still needed, but only for the stats collection, once
> again bringing into question their utility.  The parameter can however switch
> to being const.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 2/5] x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV context

[Wei Liu]

On Tue, Feb 20, 2018 at 03:26:20PM +, Andrew Cooper wrote:
> On 20/02/18 15:22, Wei Liu wrote:
> > On Tue, Feb 20, 2018 at 11:58:40AM +, Andrew Cooper wrote:
> >> If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the 
> >> value in
> >> MSR_TSC_AUX, irrespective of whether the relevant CPUID features are
> >> advertised/hidden.
> >>
> > This setup works only because CR4.TSD=0?
> 
> Having CR4.TSD clear is the default, and means RDTSCP will work at any
> privilege level.  Setting CR4.TSD (either due to virtualised TSC, or
> because the guest kernel wants to trap user accesses) will cause RDTSCP
> to trap into emul-priv-op.
> 
> There is no way of causing RDPID to trap (on hardware which supports the
> instruction), and it will read read the current value of MSR_TSC_AUX.

Alright.

In any case:

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 2/5] x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV context

[Andrew Cooper]

On 20/02/18 15:22, Wei Liu wrote:
> On Tue, Feb 20, 2018 at 11:58:40AM +, Andrew Cooper wrote:
>> If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value 
>> in
>> MSR_TSC_AUX, irrespective of whether the relevant CPUID features are
>> advertised/hidden.
>>
> This setup works only because CR4.TSD=0?

Having CR4.TSD clear is the default, and means RDTSCP will work at any
privilege level.  Setting CR4.TSD (either due to virtualised TSC, or
because the guest kernel wants to trap user accesses) will cause RDTSCP
to trap into emul-priv-op.

There is no way of causing RDPID to trap (on hardware which supports the
instruction), and it will read read the current value of MSR_TSC_AUX.

~Andrew

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

Re: [Xen-devel] [PATCH 2/5] x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV context

[Wei Liu]

On Tue, Feb 20, 2018 at 11:58:40AM +, Andrew Cooper wrote:
> If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value in
> MSR_TSC_AUX, irrespective of whether the relevant CPUID features are
> advertised/hidden.
> 

This setup works only because CR4.TSD=0?

> At the moment, paravirt_ctxt_switch_to() only writes to MSR_TSC_AUX if
> TSC_MODE_PVRDTSCP mode is enabled, but this is not the default mode.
> Therefore, default PV guests can read the value from a previously scheduled
> HVM vcpu, or TSC_MODE_PVRDTSCP-enabled PV guest.
> 
> Alter the PV path to always write to MSR_TSC_AUX, using 0 in the common case.
> 
> To amortise overhead cost, introduce wrmsr_tsc_aux() which performs a lazy
> update of the MSR, and use this function consistently across the codebase.
> 
> Signed-off-by: Andrew Cooper 

The code looks correct to me.

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

Re: [Xen-devel] [OSSTEST PATCH v2 00/19] Upgrade to Stretch

[Ian Jackson]

Wei Liu writes ("Re: [OSSTEST PATCH v2 00/19] Upgrade to Stretch"):
> IIRC Ian suggested you copy one of the udev rules from Jessie's d-i to
> the initrd osstest generated for stretch, and perhaps copy it to the
> installed OS as well. I can't remember which files and don't have a
> jessie system to hand.

75-persistent-net-generator.rules
which is in /lib/udev/rules.d on jessie but would go in /etc
on a stretch system.  It will make 70-persistent-net.rules.

IDK if stretch installer will naturally copy 70-persistent-net.rules
to the installed system.  If not then a hook will have to be used to
do that too, so that the device name(s) assigned during the install
are replicated on the installed system.

Ian.

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

Re: [Xen-devel] [PATCH 1/5] x86/hvm: Don't shadow the domain parameter in hvm_save_cpu_msrs()

[Wei Liu]

On Tue, Feb 20, 2018 at 11:58:39AM +, Andrew Cooper wrote:
> c/s d2f86bf604 which introduced "struct hvm_save_descriptor *d" accidentally
> ended up shadowing the "struct domain *d" function parameter.  Rename the
> former to desc.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] build: remove shim related targets

[Ian Jackson]

Roger Pau Monne writes ("[PATCH] build: remove shim related targets"):
> There's no need to have shim specific targets, so just use the regular
> xen makefile targets in order to build the shim binary.

I haven't been following this, mostly because I've been away, but:

Previously (in the Comet advice in the advisory, for example) we told
people to run this special Makefile target, and that special Makefile
target would rebuild the whole of the hypervisor in some special way.

Is that linkfarm and rebuild now no longer needed, then ?

Ian.

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

Re: [Xen-devel] [PATCH v2] build: remove shim related targets

[Roger Pau Monné]

On Tue, Feb 20, 2018 at 02:43:25PM +, Wei Liu wrote:
> On Tue, Feb 20, 2018 at 02:37:54PM +, Roger Pau Monne wrote:
> >  xen-shim: $(D) shim-olddefconfig
> > -   $(MAKE) -C $(D)/xen install-shim \
> > +   $(MAKE) -C $(D)/xen build \
> > XEN_CONFIG_EXPERT=y \
> > -   KCONFIG_CONFIG=$(CURDIR)/shim.config \
> > -   DESTDIR=$(CURDIR)
> > +   KCONFIG_CONFIG=$(CURDIR)/shim.config
> > +   ln -sf $(D)/xen/xen xen-shim
> > +   ln -sf $(D)/xen/xen-syms xen-shim-syms
> 
> I'm not sure this is right -- do you get to install the shim to DESTDIR
> like this?

Yes, the file installed is the target, not the symlink itself:

# ls -lah /usr/local/lib/xen/boot/xen-shim
-rw-r--r--  1 root  wheel   1.9M Feb 20 14:36 /usr/local/lib/xen/boot/xen-shim

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v2] build: remove shim related targets

[Roger Pau Monné]

On Tue, Feb 20, 2018 at 02:42:27PM +, Andrew Cooper wrote:
> On 20/02/18 14:37, Roger Pau Monne wrote:
> > diff --git a/tools/firmware/xen-dir/Makefile 
> > b/tools/firmware/xen-dir/Makefile
> > index 7fd36a0e15..01a2850194 100644
> > --- a/tools/firmware/xen-dir/Makefile
> > +++ b/tools/firmware/xen-dir/Makefile
> > @@ -48,13 +48,14 @@ shim-%config: $(D) FORCE
> > KCONFIG_CONFIG=$(CURDIR)/shim.config
> >  
> >  xen-shim: $(D) shim-olddefconfig
> > -   $(MAKE) -C $(D)/xen install-shim \
> > +   $(MAKE) -C $(D)/xen build \
> > XEN_CONFIG_EXPERT=y \
> > -   KCONFIG_CONFIG=$(CURDIR)/shim.config \
> > -   DESTDIR=$(CURDIR)
> > +   KCONFIG_CONFIG=$(CURDIR)/shim.config
> > +   ln -sf $(D)/xen/xen xen-shim
> > +   ln -sf $(D)/xen/xen-syms xen-shim-syms
> 
> This might be fine for developer builds, but it will break RPM (and
> probably DEB) packages.
> 
> They are separate files, and need copying into place, to avoid
> interacting with later rebuilds of Xen.

I'm not sure I follow, interacting with rebuilds in which way?

The target of those symlinks is a file in $(D)/xen/, which is already
xen-shim firmware specific (rebuilds of top level xen/ are not going
to affect this binary).

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 1/5] x86/hvm: Don't shadow the domain parameter in hvm_save_cpu_msrs()

[Roger Pau Monné]

On Tue, Feb 20, 2018 at 11:58:39AM +, Andrew Cooper wrote:
> c/s d2f86bf604 which introduced "struct hvm_save_descriptor *d" accidentally
> ended up shadowing the "struct domain *d" function parameter.  Rename the
> former to desc.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

Would be nice to enable -Wshadow but that requires a lot more of work.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v2] build: remove shim related targets

[Wei Liu]

On Tue, Feb 20, 2018 at 02:37:54PM +, Roger Pau Monne wrote:
>  xen-shim: $(D) shim-olddefconfig
> - $(MAKE) -C $(D)/xen install-shim \
> + $(MAKE) -C $(D)/xen build \
>   XEN_CONFIG_EXPERT=y \
> - KCONFIG_CONFIG=$(CURDIR)/shim.config \
> - DESTDIR=$(CURDIR)
> + KCONFIG_CONFIG=$(CURDIR)/shim.config
> + ln -sf $(D)/xen/xen xen-shim
> + ln -sf $(D)/xen/xen-syms xen-shim-syms

I'm not sure this is right -- do you get to install the shim to DESTDIR
like this?

Wei.

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

Re: [Xen-devel] [PATCH v2] build: remove shim related targets

[Andrew Cooper]

On 20/02/18 14:37, Roger Pau Monne wrote:
> diff --git a/tools/firmware/xen-dir/Makefile b/tools/firmware/xen-dir/Makefile
> index 7fd36a0e15..01a2850194 100644
> --- a/tools/firmware/xen-dir/Makefile
> +++ b/tools/firmware/xen-dir/Makefile
> @@ -48,13 +48,14 @@ shim-%config: $(D) FORCE
>   KCONFIG_CONFIG=$(CURDIR)/shim.config
>  
>  xen-shim: $(D) shim-olddefconfig
> - $(MAKE) -C $(D)/xen install-shim \
> + $(MAKE) -C $(D)/xen build \
>   XEN_CONFIG_EXPERT=y \
> - KCONFIG_CONFIG=$(CURDIR)/shim.config \
> - DESTDIR=$(CURDIR)
> + KCONFIG_CONFIG=$(CURDIR)/shim.config
> + ln -sf $(D)/xen/xen xen-shim
> + ln -sf $(D)/xen/xen-syms xen-shim-syms

This might be fine for developer builds, but it will break RPM (and
probably DEB) packages.

They are separate files, and need copying into place, to avoid
interacting with later rebuilds of Xen.

~Andrew

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

Re: [Xen-devel] [OSSTEST PATCH v2 00/19] Upgrade to Stretch

[Wei Liu]

On Tue, Feb 20, 2018 at 01:38:12PM +, Julien Grall wrote:
> Hi Wei,
> 
> On 31/10/17 13:51, Wei Liu wrote:
> > First version of this series can be found at [0].
> > 
> > This version contains workaround for Arndale boards. They are now 
> > functional.
> 
> I need the following patch [1] to use that branch on Arm64 boxes.
> 
> Also, on Thunder-X I needed a hack to keep the interface name
> consistent between the installer and Debian (see discussion on
> patch #7). Looking at the discussion I am not sure what is the
> way forward to fix it.

IIRC Ian suggested you copy one of the udev rules from Jessie's d-i to
the initrd osstest generated for stretch, and perhaps copy it to the
installed OS as well. I can't remember which files and don't have a
jessie system to hand.

Ian?

> 
> Cheers,
> 
> [1]
> 
> commit 26badf528e343d3fc540b61490011d391f2360a8
> Author: Julien Grall 
> Date:   Tue Feb 20 11:54:51 2018 +
> 
> stretch: Use chainloading when booting using GRUB on Arm64
> 
> The GRUB package in Stretch is not able to boot Xen on Arm64.
> Use chainloading as we did for Jessie for the time being.
> 
> Note that a bug has been filled on Debian to integrate Xen
> pactches for the next release (see [1]).
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884770
> 
> Signed-off-by: Julien Grall 
> 
> diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
> index b2d5007..2a2efa0 100644
> --- a/Osstest/Debian.pm
> +++ b/Osstest/Debian.pm
> @@ -437,7 +437,7 @@ sub setupboot_grub2 () {
>  # Grub2 on Jessie/arm* doesn't do multiboot, so we must chainload.

Please also update the comment here.

Wei.

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

[Xen-devel] [PATCH v2] build: remove shim related targets

[Roger Pau Monne]

There's no need to have shim specific targets, so just use the regular
xen makefile targets in order to build the shim binary.

When the shim is build as part of the firmware directory install the
stripped Xen binary to the firmware directory and place a binary with
symbols in the debug directory.

The objcopy step of the shim build is also removed in this patch:
since the shim is booted in PVH mode there's no need for the resulting
binary to be in elf32 format. Xen can load PVH kernels with either a
32 or 64bit elf header.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
---
Changes since v1:
 - Copy a shim binary with symbols to the debug dir.
 - Use ln to link xen-shim and xen-shim-syms instead of cp.
 - Expand commit message to explain the reason for dropping the
   objcopy step.
---
 tools/firmware/Makefile |  4 
 tools/firmware/xen-dir/Makefile |  9 +
 xen/Makefile| 16 +++-
 xen/arch/x86/Makefile   | 12 +++-
 4 files changed, 15 insertions(+), 26 deletions(-)

diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index b2f011df49..5a7cf7766d 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -8,6 +8,7 @@ endif
 # hvmloader is a 32-bit protected mode binary.
 TARGET  := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
+DEBG_DIR := $(DESTDIR)$(DEBUG_DIR)$(XENFIRMWAREDIR)
 
 SUBDIRS-y :=
 SUBDIRS-$(CONFIG_OVMF) += ovmf-dir
@@ -46,6 +47,7 @@ endif
 .PHONY: install
 install: all
[ -d $(INST_DIR) ] || $(INSTALL_DIR) $(INST_DIR)
+   [ -d $(DEBG_DIR) ] || $(INSTALL_DIR) $(DEBG_DIR)
[ ! -e $(TARGET) ] || $(INSTALL_DATA) $(TARGET) $(INST_DIR)
 ifeq ($(CONFIG_SEABIOS),y)
$(INSTALL_DATA) seabios-dir/out/bios.bin $(INST_DIR)/seabios.bin
@@ -55,6 +57,7 @@ ifeq ($(CONFIG_OVMF),y)
 endif
 ifeq ($(CONFIG_PV_SHIM),y)
$(INSTALL_DATA) xen-dir/xen-shim $(INST_DIR)/xen-shim
+   $(INSTALL_DATA) xen-dir/xen-shim-syms $(DEBG_DIR)/xen-shim-syms
 endif
 
 .PHONY: uninstall
@@ -68,6 +71,7 @@ ifeq ($(CONFIG_OVMF),y)
 endif
 ifeq ($(CONFIG_PV_SHIM),y)
rm -f $(INST_DIR)/xen-shim
+   rm -f $(DEBG_DIR)/xen-shim-syms
 endif
 
 .PHONY: clean
diff --git a/tools/firmware/xen-dir/Makefile b/tools/firmware/xen-dir/Makefile
index 7fd36a0e15..01a2850194 100644
--- a/tools/firmware/xen-dir/Makefile
+++ b/tools/firmware/xen-dir/Makefile
@@ -48,13 +48,14 @@ shim-%config: $(D) FORCE
KCONFIG_CONFIG=$(CURDIR)/shim.config
 
 xen-shim: $(D) shim-olddefconfig
-   $(MAKE) -C $(D)/xen install-shim \
+   $(MAKE) -C $(D)/xen build \
XEN_CONFIG_EXPERT=y \
-   KCONFIG_CONFIG=$(CURDIR)/shim.config \
-   DESTDIR=$(CURDIR)
+   KCONFIG_CONFIG=$(CURDIR)/shim.config
+   ln -sf $(D)/xen/xen xen-shim
+   ln -sf $(D)/xen/xen-syms xen-shim-syms
 
 .PHONY: distclean clean
 distclean clean:
-   rm -f xen-shim *.old
+   rm -f xen-shim xen-shim-syms *.old
rm -rf $(D)
rm -f linkfarm.stamp*
diff --git a/xen/Makefile b/xen/Makefile
index 027c5adfdd..044e7c82a3 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -37,10 +37,10 @@ default: build
 .PHONY: dist
 dist: install
 
-build install build-shim:: include/config/auto.conf
+build install:: include/config/auto.conf
 
-.PHONY: build install uninstall clean distclean cscope TAGS tags MAP gtags 
tests install-shim build-shim
-build install uninstall debug clean distclean cscope TAGS tags MAP gtags tests 
install-shim build-shim::
+.PHONY: build install uninstall clean distclean cscope TAGS tags MAP gtags 
tests
+build install uninstall debug clean distclean cscope TAGS tags MAP gtags 
tests::
 ifneq ($(XEN_TARGET_ARCH),x86_32)
$(MAKE) -f Rules.mk _$@
 else
@@ -80,13 +80,6 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
fi; \
fi
 
-.PHONY: _build-shim
-_build-shim: $(TARGET)-shim
-
-.PHONY: _install-shim
-_install-shim: build-shim
-   $(INSTALL_DATA) $(TARGET)-shim $(DESTDIR)
-
 .PHONY: _tests
 _tests:
$(MAKE) -f $(BASEDIR)/Rules.mk -C test tests
@@ -151,9 +144,6 @@ $(TARGET): delete-unfresh-files
$(MAKE) -f $(BASEDIR)/Rules.mk include/asm-$(TARGET_ARCH)/asm-offsets.h
$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) $(TARGET)
 
-$(TARGET)-shim: $(TARGET)
-   $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) $(TARGET)-shim
-
 # drivers/char/console.o contains static banner/compile info. Blow it away.
 # Don't refresh these files during e.g., 'sudo make install'
 .PHONY: delete-unfresh-files
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 389096139c..5563c813dd 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -78,12 +78,12 @@ efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h 
-o \
   -O $(

[Xen-devel] [PATCH v5 2/5] build: filter out command line assembler arguments

[Roger Pau Monne]

If the assembler is not used. This happens when using cc -E or cc -S
for example. GCC will just ignore the -Wa,... when the assembler is
not called, but clang will complain loudly and fail.

Also enable passing -Wa,-I$(BASEDIR)/include to clang now that it's
safe to do so.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Changes since v4:
 - Also add the filter to the tree rules near the end of xen/Rules.mk.

Changes since v3:
 - Filter using '-Wa,%' instead of '-Wa%' so that -Wall is not
   matched.
 - Pass -Wa,-I$(BASEDIR)/include to clang also.
---
 xen/Rules.mk  | 6 +++---
 xen/arch/x86/Makefile | 6 +++---
 xen/arch/x86/Rules.mk | 5 +
 xen/include/Makefile  | 2 +-
 4 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index da3c35ba36..2918019b92 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -208,13 +208,13 @@ $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): 
%.init.o: %.o Makefile
$(OBJCOPY) $(foreach s,$(SPECIAL_DATA_SECTIONS),--rename-section 
.$(s)=.init.$(s)) $< $@
 
 %.i: %.c Makefile
-   $(CPP) $(CFLAGS) $< -o $@
+   $(CPP) $(filter-out -Wa$(comma)%,$(CFLAGS)) $< -o $@
 
 %.s: %.c Makefile
-   $(CC) $(CFLAGS) -S $< -o $@
+   $(CC) $(filter-out -Wa$(comma)%,$(CFLAGS)) -S $< -o $@
 
 # -std=gnu{89,99} gets confused by # as an end-of-line comment marker
 %.s: %.S Makefile
-   $(CPP) $(AFLAGS) $< -o $@
+   $(CPP) $(filter-out -Wa$(comma)%,$(AFLAGS)) $< -o $@
 
 -include $(DEPS_INCLUDE)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d903b7abb9..389096139c 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -215,15 +215,15 @@ efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o: 
$(BASEDIR)/arch/x86/ef
 efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o: ;
 
 asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
-   $(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
+   $(CC) $(filter-out -Wa$(comma)% -flto,$(CFLAGS)) -S -o $@ $<
 
 xen.lds: xen.lds.S
-   $(CC) -P -E -Ui386 $(AFLAGS) -o $@ $<
+   $(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(AFLAGS)) -o $@ $<
sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
mv -f .xen.lds.d.new .xen.lds.d
 
 efi.lds: xen.lds.S
-   $(CC) -P -E -Ui386 -DEFI $(AFLAGS) -o $@ $<
+   $(CC) -P -E -Ui386 -DEFI $(filter-out -Wa$(comma)%,$(AFLAGS)) -o $@ $<
sed -e 's/efi\.lds\.o:/efi\.lds:/g' <.$(@F).d >.$(@F).d.new
mv -f .$(@F).d.new .$(@F).d
 
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 56b2ea8356..1dc5c3785a 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -42,8 +42,5 @@ CFLAGS += -DCONFIG_INDIRECT_THUNK
 export CONFIG_INDIRECT_THUNK=y
 endif
 
-# Set up the assembler include path properly for older GCC toolchains.  Clang
-# objects to the agument being passed however.
-ifneq ($(clang),y)
+# Set up the assembler include path properly for older toolchains.
 CFLAGS += -Wa,-I$(BASEDIR)/include
-endif
diff --git a/xen/include/Makefile b/xen/include/Makefile
index 19066a33a0..69052ade24 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -65,7 +65,7 @@ compat/%.h: compat/%.i Makefile 
$(BASEDIR)/tools/compat-build-header.py
mv -f $@.new $@
 
 compat/%.i: compat/%.c Makefile
-   $(CPP) $(filter-out -M% %.d -include %/include/xen/config.h,$(CFLAGS)) 
$(cppflags-y) -o $@ $<
+   $(CPP) $(filter-out -Wa$(comma)% -M% %.d -include 
%/include/xen/config.h,$(CFLAGS)) $(cppflags-y) -o $@ $<
 
 compat/%.c: public/%.h xlat.lst Makefile 
$(BASEDIR)/tools/compat-build-source.py
mkdir -p $(@D)
-- 
2.16.1


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

[Xen-devel] [PATCH v5 1/5] build: do not hardcode AFLAGS for as-insn tests

[Roger Pau Monne]

Hardcoding as-insn to use AFLAGS is not correct. For once the test is
performed using a C file with inline assembly, and secondly the flags
used can be passed by the caller together with the CC.

Fix as-insn-check to pass the flags given as parameter to the test.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 Config.mk | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Config.mk b/Config.mk
index 51adc27d83..407472c3fc 100644
--- a/Config.mk
+++ b/Config.mk
@@ -157,9 +157,9 @@ ifndef XEN_HAS_CHECKPOLICY
 endif
 
 # as-insn: Check whether assembler supports an instruction.
-# Usage: cflags-y += $(call as-insn "insn",option-yes,option-no)
+# Usage: cflags-y += $(call as-insn CC FLAGS,"insn",option-yes,option-no)
 as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
-   | $(1) $(filter-out -M% %.d -include 
%/include/xen/config.h,$(AFLAGS)) \
+   | $(filter-out -M% %.d -include 
%/include/xen/config.h,$(1)) \
   -c -x c -o /dev/null - 2>&1),$(4),$(3))
 
 # as-insn-check: Add an option to compilation flags, but only if insn is
@@ -167,7 +167,7 @@ as-insn = $(if $(shell echo 'void _(void) { asm volatile ( 
$(2) ); }' \
 # Usage: $(call as-insn-check CFLAGS,CC,"nop",-DHAVE_GAS_NOP)
 as-insn-check = $(eval $(call as-insn-check-closure,$(1),$(2),$(3),$(4)))
 define as-insn-check-closure
-ifeq ($$(call as-insn,$$($(2)),$(3),y,n),y)
+ifeq ($$(call as-insn,$$($(2)) $$($(1)),$(3),y,n),y)
 $(1) += $(4)
 endif
 endef
-- 
2.16.1


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

[Xen-devel] [PATCH v5 0/5] clang improvements

[Roger Pau Monne]

Hello,

The following series re-enable the integrated clang assembler when the
features required in order to build Xen are available.

This series has been tested with clang 6, clang 3.5, gcc 6 and gcc 7
with indirect branch support.

Thanks, Roger.

Roger Pau Monne (5):
  build: do not hardcode AFLAGS for as-insn tests
  build: filter out command line assembler arguments
  x86/clang: restore integrated assembler usage with indirect thunks
  x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK
  build/clang: add a check whether the assembler supports .skip with
labels

 Config.mk   | 15 ---
 xen/Rules.mk| 14 +-
 xen/arch/x86/Makefile   |  6 +++---
 xen/arch/x86/Rules.mk   | 17 ++---
 xen/include/Makefile|  2 +-
 xen/include/asm-x86/asm_defns.h |  3 +++
 6 files changed, 38 insertions(+), 19 deletions(-)

-- 
2.16.1


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

[Xen-devel] [PATCH v5 3/5] x86/clang: restore integrated assembler usage with indirect thunks

[Roger Pau Monne]

If the required features are met by the integrated clang assembler
(support for .includes and propagation of .macro-s between asm()-s)
do not disable it.

Only disable the integrated assembler for assembly files, like it was
done prior to "x86: Support indirect thunks from assembly code".

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Changes since v4:
 - Do not use else ifeq on the same line to be compatible with make
   3.8.
 - Modify as-insn-check to allow adding flags if the test case fails.

Changes since v3:
 - Do not modify how the thunk is included, clang upstream (and 6) has
   been fixed to propagate .macro-s between asm()-s.

Changes since v1:
 - Use as-insn to check if the assembler supports .include.
 - Open code a check for whether the assembler forgets .macro-s
   between asm()-s.
---
 Config.mk |  9 +
 xen/Rules.mk  |  5 +++--
 xen/arch/x86/Rules.mk | 14 ++
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/Config.mk b/Config.mk
index 407472c3fc..8d6d984488 100644
--- a/Config.mk
+++ b/Config.mk
@@ -162,13 +162,14 @@ as-insn = $(if $(shell echo 'void _(void) { asm volatile 
( $(2) ); }' \
| $(filter-out -M% %.d -include 
%/include/xen/config.h,$(1)) \
   -c -x c -o /dev/null - 2>&1),$(4),$(3))
 
-# as-insn-check: Add an option to compilation flags, but only if insn is
-#supported by assembler.
-# Usage: $(call as-insn-check CFLAGS,CC,"nop",-DHAVE_GAS_NOP)
-as-insn-check = $(eval $(call as-insn-check-closure,$(1),$(2),$(3),$(4)))
+# as-insn-check: Conditionally add an option to compilation flags
+# Usage: $(call as-insn-check CFLAGS,CC,"nop",-DHAVE_GAS_NOP,-DNO_GAS_NOP)
+as-insn-check = $(eval $(call as-insn-check-closure,$(1),$(2),$(3),$(4),$(5)))
 define as-insn-check-closure
 ifeq ($$(call as-insn,$$($(2)) $$($(1)),$(3),y,n),y)
 $(1) += $(4)
+else
+$(1) += $(5)
 endif
 endef
 
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 2918019b92..7adf757fb6 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -70,8 +70,9 @@ endif
 
 AFLAGS-y+= -D__ASSEMBLY__
 
-# Clang's built-in assembler can't handle embedded .include's
-CFLAGS-$(clang) += -no-integrated-as
+# Older clang's built-in assembler doesn't understand .skip with labels:
+# https://bugs.llvm.org/show_bug.cgi?id=27369
+AFLAGS-$(clang) += -no-integrated-as
 
 ALL_OBJS := $(ALL_OBJS-y)
 
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 1dc5c3785a..cee83d392e 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -44,3 +44,17 @@ endif
 
 # Set up the assembler include path properly for older toolchains.
 CFLAGS += -Wa,-I$(BASEDIR)/include
+
+ifeq ($(clang),y)
+# Check whether clang asm()-s support .include.
+$(call as-insn-check,CFLAGS,CC,".include \"asm/indirect_thunk_asm.h\"",, \
+ -no-integrated-as)
+# Check whether clang keeps .macro-s between asm()-s:
+# https://bugs.llvm.org/show_bug.cgi?id=36110
+ifeq ($(if $(shell echo 'void _(void) { asm volatile ( ".macro FOO\n.endm" 
); \
+asm volatile ( ".macro FOO\n.endm" 
); }' \
+   | $(CC) $(filter-out -M% %.d -include 
%/include/xen/config.h,$(CFLAGS)) \
+   -c -x c -o /dev/null - 2>&1),n,y),y)
+CFLAGS += -no-integrated-as
+endif
+endif
-- 
2.16.1


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

[Xen-devel] [PATCH v5 4/5] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

[Roger Pau Monne]

When indirect_thunk_asm.h is instantiated directly into assembly files
CONFIG_INDIRECT_THUNK might not be defined, and thus using .if against
it is wrong.

Add a check to define CONFIG_INDIRECT_THUNK to 0 if not defined, so
that using .if CONFIG_INDIRECT_THUNK is always correct.

This suppresses the following clang error:

:8:9: error: expected absolute expression
.if CONFIG_INDIRECT_THUNK == 1
^
:1:1: note: while in macro instantiation
INDIRECT_BRANCH call %rdx
^
entry.S:589:9: note: while in macro instantiation
INDIRECT_CALL %rdx
^

Note that this is a preparatory patch in order to enable clang's
integrated assembler, the integrated assembler is not yet enabled for
assembly files.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v4:
 - Define CONFIG_INDIRECT_THUNK if not defined using an equation.
---
 xen/include/asm-x86/asm_defns.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/include/asm-x86/asm_defns.h b/xen/include/asm-x86/asm_defns.h
index 6fc13d39d8..ebd2c88a1f 100644
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -15,6 +15,9 @@
 #include 
 
 #ifdef __ASSEMBLY__
+#ifndef CONFIG_INDIRECT_THUNK
+.equ CONFIG_INDIRECT_THUNK, 0
+#endif
 # include 
 #else
 asm ( "\t.equ CONFIG_INDIRECT_THUNK, "
-- 
2.16.1


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

[Xen-devel] [PATCH v5 5/5] build/clang: add a check whether the assembler supports .skip with labels

[Roger Pau Monne]

Or else disable the integrated assembler for assembly files. This is
relevant for older clang versions which integrated assembler don't
support .skip with labels.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/Rules.mk | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 7adf757fb6..92102e36d9 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -72,7 +72,10 @@ AFLAGS-y+= -D__ASSEMBLY__
 
 # Older clang's built-in assembler doesn't understand .skip with labels:
 # https://bugs.llvm.org/show_bug.cgi?id=27369
-AFLAGS-$(clang) += -no-integrated-as
+ifeq ($(clang),y)
+$(call as-insn-check,AFLAGS,CC,".L0:\n.L1:\n.skip (.L1 - .L0)",, \
+ -no-integrated-as)
+endif
 
 ALL_OBJS := $(ALL_OBJS-y)
 
-- 
2.16.1


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

Re: [Xen-devel] [OSSTEST PATCH v2 00/19] Upgrade to Stretch

[Julien Grall]

Hi Wei,

On 31/10/17 13:51, Wei Liu wrote:
> First version of this series can be found at [0].
> 
> This version contains workaround for Arndale boards. They are now functional.

I need the following patch [1] to use that branch on Arm64 boxes.

Also, on Thunder-X I needed a hack to keep the interface name
consistent between the installer and Debian (see discussion on
patch #7). Looking at the discussion I am not sure what is the
way forward to fix it.

Cheers,

[1]

commit 26badf528e343d3fc540b61490011d391f2360a8
Author: Julien Grall 
Date:   Tue Feb 20 11:54:51 2018 +

stretch: Use chainloading when booting using GRUB on Arm64

The GRUB package in Stretch is not able to boot Xen on Arm64.
Use chainloading as we did for Jessie for the time being.

Note that a bug has been filled on Debian to integrate Xen
pactches for the next release (see [1]).

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884770

Signed-off-by: Julien Grall 

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index b2d5007..2a2efa0 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -437,7 +437,7 @@ sub setupboot_grub2 () {
 # Grub2 on Jessie/arm* doesn't do multiboot, so we must chainload.
 my $need_uefi_chainload =
 get_host_property($ho, "firmware", "") eq "uefi" &&
-$ho->{Suite} =~ m/jessie/ && $r{arch} =~ m/^arm/;
+$ho->{Suite} =~ m/jessie|stretch/ && $r{arch} =~ m/^arm/;
 
 my $parsemenu= sub {
 my $f= bl_getmenu_open($ho, $rmenu, "$stash/$ho->{Name}--grub.cfg.1");

> 
> A bunch of test cases failed:
> 
> 1. Rumpkernel tests -- I've sent an email to Antti for advice.
> 2. Windows tests -- They don't look different from normal flights.
> 3. memdisk-try-append -- Osstest couldn't find some file. I don't think it is
> related to the code I modified.
> 4. guest-localmigrate/x10 for xl-qcow2 test -- Guest kernel bug.
> 5. nested hvm amd, pvhv2 -- Expected failure.
> 
> Example flight:
> http://logs.test-lab.xenproject.org/osstest/logs/115404/
> 
> The armhf d-i failure is fixed with an additional patch ("Skip bootloader
> installaion for arm32 on Stretch) on top of the code for 15404, in:
> 
> http://logs.test-lab.xenproject.org/osstest/logs/115404/
> 
> Cc: Julien Grall 
> 
> [0] <20171020103840.32762-1-wei.l...@citrix.com>
> 
> Wei Liu (19):
>gitignore: ignore vim swap file
>ts-xen-build-prep: only install w3c-dtd-xhtml for suites ts-xen-build-prep: install packages for suites >jessie
>ts-xen-install: install some packages on stretch
>Debian.pm: use sysvinit-core instead of systemd
>ts-leak-check: suppress systemd-shim, which leaks in stretch
>ts-host-install: don't use the new nic naming scheme
>ts-guests-nbd-mirror: use target_{get,put}file_root to transfter cfg
>ts-debian-fixup: merge origin extra= to our own
>ts-debian-fixup: use correct resume device
>ts-debian-hvm-install: disable new nic naming scheme
>ts-xen-build-prep: install e2fslibs-dev
>TestSupport: add dpkg option when installing packages
>ts-guests-nbd-mirror: make it work with stretch
>Add clk_ignore_unused for stretch for arm hosts
>Set mac address in interfaces(5) if force-mac-address is set
>Skip bootloader installation for arm32 in Stretch
>make-flight: don't test pvgrub for Xen XXX
>Switch to Debian Stretch
> 
>   .gitignore |  1 +
>   Osstest.pm |  2 +-
>   Osstest/Debian.pm  | 19 --
>   Osstest/TestSupport.pm |  3 ++-
>   make-flight| 17 +++-
>   production-config  |  2 ++
>   ts-debian-fixup| 14 -
>   ts-debian-hvm-install  | 13 
>   ts-guests-nbd-mirror   | 54 
> --
>   ts-host-install|  4 
>   ts-leak-check  |  1 +
>   ts-xen-build-prep  | 15 +-
>   ts-xen-install |  3 +++
>   13 files changed, 135 insertions(+), 13 deletions(-)
> 

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v4 3/4] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

[Roger Pau Monné]

On Tue, Feb 20, 2018 at 05:53:08AM -0700, Jan Beulich wrote:
> >>> On 20.02.18 at 13:42,  wrote:
> > On Tue, Feb 20, 2018 at 05:32:17AM -0700, Jan Beulich wrote:
> >> >>> On 20.02.18 at 12:22,  wrote:
> >> > On Tue, Feb 20, 2018 at 04:13:42AM -0700, Jan Beulich wrote:
> >> >> >>> On 20.02.18 at 12:01,  wrote:
> >> >> > --- a/xen/include/asm-x86/asm_defns.h
> >> >> > +++ b/xen/include/asm-x86/asm_defns.h
> >> >> > @@ -15,6 +15,9 @@
> >> >> >  #include 
> >> >> > 
> >> >> >  #ifdef __ASSEMBLY__
> >> >> > +#ifndef CONFIG_INDIRECT_THUNK
> >> >> > +.equ CONFIG_INDIRECT_THUNK, 0
> >> >> > +#endif
> >> >> >  # include 
> >> >> >  #else
> >> >> >  asm ( "\t.equ CONFIG_INDIRECT_THUNK, "
> >> >> > 
> >> >> > It's fairly similar to my first approach, but at least "#ifdef
> >> >> > CONFIG_INDIRECT_THUNK" will still work as expected after this fix.
> >> >> 
> >> >> I've used something similar in backports to old versions, so I
> >> >> wonder whether what you quote above is right: Assembly files
> >> >> don't get handed to clang anyway iirc, so the change would
> >> >> seem to be needed in the #else part of the conditional.
> >> > 
> >> > Assembly files do get handed to clang, from xen/Rules.mk:
> >> > 
> >> > %.o: %.S Makefile
> >> >  $(CC) $(AFLAGS) -c $< -o $@
> >> > 
> >> > Xen doesn't call as directly to compile those, or am I missing
> >> > something?
> >> 
> >> Oh, I was referring to the -mno-integrated-as (or whatever it's
> >> called) option. "Handed to clang" wasn't the best way to put it,
> >> I agree. But it's clang's integrated assembler which the problem
> >> is with.
> > 
> > Oh, I see. You are right, this is just a preparatory change for patch
> > 4, which does enable clang's integrated assembler if the right
> > features are present.
> > 
> > Let me know if you think the above chunk is acceptable.
> 
> It is certainly acceptable if it helps; you now apparently agreeing
> I'm more confused though by this question. Iirc you don't enable
> the integrated assembler for assembly sources, but only for C ones.

So at this point the integrated assembler is only enabled for C
sources.

In patch 4 I enable the integrated assembler for everything if
possible, but in order to enable it I need to solve this issue
first. I can merge patches 3 and 4 if it's going to be clearer.

Hope this help shed some light.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 3/4] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

[Jan Beulich]

>>> On 20.02.18 at 13:42,  wrote:
> On Tue, Feb 20, 2018 at 05:32:17AM -0700, Jan Beulich wrote:
>> >>> On 20.02.18 at 12:22,  wrote:
>> > On Tue, Feb 20, 2018 at 04:13:42AM -0700, Jan Beulich wrote:
>> >> >>> On 20.02.18 at 12:01,  wrote:
>> >> > --- a/xen/include/asm-x86/asm_defns.h
>> >> > +++ b/xen/include/asm-x86/asm_defns.h
>> >> > @@ -15,6 +15,9 @@
>> >> >  #include 
>> >> > 
>> >> >  #ifdef __ASSEMBLY__
>> >> > +#ifndef CONFIG_INDIRECT_THUNK
>> >> > +.equ CONFIG_INDIRECT_THUNK, 0
>> >> > +#endif
>> >> >  # include 
>> >> >  #else
>> >> >  asm ( "\t.equ CONFIG_INDIRECT_THUNK, "
>> >> > 
>> >> > It's fairly similar to my first approach, but at least "#ifdef
>> >> > CONFIG_INDIRECT_THUNK" will still work as expected after this fix.
>> >> 
>> >> I've used something similar in backports to old versions, so I
>> >> wonder whether what you quote above is right: Assembly files
>> >> don't get handed to clang anyway iirc, so the change would
>> >> seem to be needed in the #else part of the conditional.
>> > 
>> > Assembly files do get handed to clang, from xen/Rules.mk:
>> > 
>> > %.o: %.S Makefile
>> >$(CC) $(AFLAGS) -c $< -o $@
>> > 
>> > Xen doesn't call as directly to compile those, or am I missing
>> > something?
>> 
>> Oh, I was referring to the -mno-integrated-as (or whatever it's
>> called) option. "Handed to clang" wasn't the best way to put it,
>> I agree. But it's clang's integrated assembler which the problem
>> is with.
> 
> Oh, I see. You are right, this is just a preparatory change for patch
> 4, which does enable clang's integrated assembler if the right
> features are present.
> 
> Let me know if you think the above chunk is acceptable.

It is certainly acceptable if it helps; you now apparently agreeing
I'm more confused though by this question. Iirc you don't enable
the integrated assembler for assembly sources, but only for C ones.

Jan


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

Re: [Xen-devel] [PATCH v4 3/4] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

[Roger Pau Monné]

On Tue, Feb 20, 2018 at 05:32:17AM -0700, Jan Beulich wrote:
> >>> On 20.02.18 at 12:22,  wrote:
> > On Tue, Feb 20, 2018 at 04:13:42AM -0700, Jan Beulich wrote:
> >> >>> On 20.02.18 at 12:01,  wrote:
> >> > --- a/xen/include/asm-x86/asm_defns.h
> >> > +++ b/xen/include/asm-x86/asm_defns.h
> >> > @@ -15,6 +15,9 @@
> >> >  #include 
> >> > 
> >> >  #ifdef __ASSEMBLY__
> >> > +#ifndef CONFIG_INDIRECT_THUNK
> >> > +.equ CONFIG_INDIRECT_THUNK, 0
> >> > +#endif
> >> >  # include 
> >> >  #else
> >> >  asm ( "\t.equ CONFIG_INDIRECT_THUNK, "
> >> > 
> >> > It's fairly similar to my first approach, but at least "#ifdef
> >> > CONFIG_INDIRECT_THUNK" will still work as expected after this fix.
> >> 
> >> I've used something similar in backports to old versions, so I
> >> wonder whether what you quote above is right: Assembly files
> >> don't get handed to clang anyway iirc, so the change would
> >> seem to be needed in the #else part of the conditional.
> > 
> > Assembly files do get handed to clang, from xen/Rules.mk:
> > 
> > %.o: %.S Makefile
> > $(CC) $(AFLAGS) -c $< -o $@
> > 
> > Xen doesn't call as directly to compile those, or am I missing
> > something?
> 
> Oh, I was referring to the -mno-integrated-as (or whatever it's
> called) option. "Handed to clang" wasn't the best way to put it,
> I agree. But it's clang's integrated assembler which the problem
> is with.

Oh, I see. You are right, this is just a preparatory change for patch
4, which does enable clang's integrated assembler if the right
features are present.

Let me know if you think the above chunk is acceptable.

Thanks, Roger.

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

[Xen-devel] Ping: [PATCH v2] x86/mm: Suppresses vm_events caused by page-walks

[Alexandru Stefan ISAILA]

Any thoughts are appreciated.

> This patch is adding a way to enable/disable nested pagefault
> events. It introduces the xc_monitor_nested_pagefault function
> and adds the nested_pagefault_disabled in the monitor structure.
> This is needed by the introspection so it will only get gla
> faults and not get spammed with other faults.
> In p2m_set_ad_bits the v->arch.sse_pg_dirty.eip and
> v->arch.sse_pg_dirty.gla are used to mark that this is the
> second time a fault occurs and the dirty bit is set.
>
> Signed-off-by: Alexandru Isaila 
>
> ---
> Changes since V1:
> - Rb V1
> - Add comment in domctl.h
> ---
>  tools/libxc/include/xenctrl.h |  2 ++
>  tools/libxc/xc_monitor.c  | 14 ++
>  xen/arch/x86/mm/mem_access.c  | 27 +++
>  xen/arch/x86/monitor.c| 13 +
>  xen/include/asm-x86/domain.h  |  6 ++
>  xen/include/asm-x86/monitor.h |  3 ++-
>  xen/include/public/domctl.h   |  2 ++
>  7 files changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/tools/libxc/include/xenctrl.h
> b/tools/libxc/include/xenctrl.h
> index 09e1363..112c974 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2056,6 +2056,8 @@ int xc_monitor_descriptor_access(xc_interface
> *xch, uint32_t domain_id,
>   bool enable);
>  int xc_monitor_guest_request(xc_interface *xch, uint32_t domain_id,
>   bool enable, bool sync, bool
> allow_userspace);
> +int xc_monitor_nested_pagefault(xc_interface *xch, uint32_t
> domain_id,
> +bool disable);
>  int xc_monitor_debug_exceptions(xc_interface *xch, uint32_t
> domain_id,
>  bool enable, bool sync);
>  int xc_monitor_cpuid(xc_interface *xch, uint32_t domain_id, bool
> enable);
> diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
> index 0233b87..e96c56d 100644
> --- a/tools/libxc/xc_monitor.c
> +++ b/tools/libxc/xc_monitor.c
> @@ -163,6 +163,20 @@ int xc_monitor_guest_request(xc_interface *xch,
> uint32_t domain_id, bool enable,
>  return do_domctl(xch, &domctl);
>  }
>
> +int xc_monitor_nested_pagefault(xc_interface *xch, uint32_t
> domain_id,
> +bool disable)
> +{
> +DECLARE_DOMCTL;
> +
> +domctl.cmd = XEN_DOMCTL_monitor_op;
> +domctl.domain = domain_id;
> +domctl.u.monitor_op.op = disable ? XEN_DOMCTL_MONITOR_OP_ENABLE
> +: XEN_DOMCTL_MONITOR_OP_DISABLE;
> +domctl.u.monitor_op.event =
> XEN_DOMCTL_MONITOR_EVENT_NESTED_PAGEFAULT;
> +
> +return do_domctl(xch, &domctl);
> +}
> +
>  int xc_monitor_emulate_each_rep(xc_interface *xch, uint32_t
> domain_id,
>  bool enable)
>  {
> diff --git a/xen/arch/x86/mm/mem_access.c
> b/xen/arch/x86/mm/mem_access.c
> index c0cd017..07a334b 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -137,6 +137,23 @@ bool p2m_mem_access_emulate_check(struct vcpu
> *v,
>  return violation;
>  }
>
> +static void p2m_set_ad_bits(struct vcpu *v, paddr_t ga)
> +{
> +struct hvm_hw_cpu ctxt;
> +uint32_t pfec = 0;
> +
> +hvm_funcs.save_cpu_ctxt(v, &ctxt);
> +
> +if ( guest_cpu_user_regs()->eip == v->arch.pg_dirty.eip
> + && ga == v->arch.pg_dirty.gla )
> +pfec = PFEC_write_access;
> +
> +paging_ga_to_gfn_cr3(v, ctxt.cr3, ga, &pfec, NULL);
> +
> +v->arch.pg_dirty.eip = guest_cpu_user_regs()->eip;
> +v->arch.pg_dirty.gla = ga;
> +}
> +
>  bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
>struct npfec npfec,
>vm_event_request_t **req_ptr)
> @@ -208,6 +225,16 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned
> long gla,
>  }
>  }
>
> +if ( vm_event_check_ring(d->vm_event_monitor) &&
> + d->arch.monitor.nested_pagefault_disabled &&
> + npfec.kind != npfec_kind_with_gla ) /* don't send a
> mem_event */
> +{
> +v->arch.vm_event->emulate_flags = 0;
> +p2m_set_ad_bits(v, gla);
> +
> +return true;
> +}
> +
>  *req_ptr = NULL;
>  req = xzalloc(vm_event_request_t);
>  if ( req )
> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
> index f229e69..e35b619 100644
> --- a/xen/arch/x86/monitor.c
> +++ b/xen/arch/x86/monitor.c
> @@ -241,6 +241,19 @@ int arch_monitor_domctl_event(struct domain *d,
>  break;
>  }
>
> +case XEN_DOMCTL_MONITOR_EVENT_NESTED_PAGEFAULT:
> +{
> +bool old_status = ad->monitor.nested_pagefault_disabled;
> +
> +if ( unlikely(old_status == requested_status) )
> +return -EEXIST;
> +
> +domain_pause(d);
> +ad->monitor.nested_pagefault_disabled = requested_status;
> +domain_unpause(d);
> +break;
> +}
> +
>  case XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS:
>  {
>  bool old_status = ad->mo

Re: [Xen-devel] [PATCH v4 3/4] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

[Jan Beulich]

>>> On 20.02.18 at 12:22,  wrote:
> On Tue, Feb 20, 2018 at 04:13:42AM -0700, Jan Beulich wrote:
>> >>> On 20.02.18 at 12:01,  wrote:
>> > --- a/xen/include/asm-x86/asm_defns.h
>> > +++ b/xen/include/asm-x86/asm_defns.h
>> > @@ -15,6 +15,9 @@
>> >  #include 
>> > 
>> >  #ifdef __ASSEMBLY__
>> > +#ifndef CONFIG_INDIRECT_THUNK
>> > +.equ CONFIG_INDIRECT_THUNK, 0
>> > +#endif
>> >  # include 
>> >  #else
>> >  asm ( "\t.equ CONFIG_INDIRECT_THUNK, "
>> > 
>> > It's fairly similar to my first approach, but at least "#ifdef
>> > CONFIG_INDIRECT_THUNK" will still work as expected after this fix.
>> 
>> I've used something similar in backports to old versions, so I
>> wonder whether what you quote above is right: Assembly files
>> don't get handed to clang anyway iirc, so the change would
>> seem to be needed in the #else part of the conditional.
> 
> Assembly files do get handed to clang, from xen/Rules.mk:
> 
> %.o: %.S Makefile
>   $(CC) $(AFLAGS) -c $< -o $@
> 
> Xen doesn't call as directly to compile those, or am I missing
> something?

Oh, I was referring to the -mno-integrated-as (or whatever it's
called) option. "Handed to clang" wasn't the best way to put it,
I agree. But it's clang's integrated assembler which the problem
is with.

Jan


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

[Xen-devel] [PATCH 3/5] x86/time: Rework pv_soft_rdtsc() to aid further cleanup

[Andrew Cooper]

Having pv_soft_rdtsc() emulate all parts of an rdtscp is awkward, and gets in
the way of some intended cleanup.

 * Drop the rdtscp parameter and always make the caller responsible for ecx
   updates when appropriate.
 * Switch the function from being void, and return the main timestamp in the
   return value.

The regs parameter is still needed, but only for the stats collection, once
again bringing into question their utility.  The parameter can however switch
to being const.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Konrad Rzeszutek Wilk 
---
 xen/arch/x86/pv/emul-inv-op.c  |  7 ++-
 xen/arch/x86/pv/emul-priv-op.c | 12 
 xen/arch/x86/time.c|  8 ++--
 xen/include/asm-x86/time.h |  2 +-
 4 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/pv/emul-inv-op.c b/xen/arch/x86/pv/emul-inv-op.c
index f894417..b1916b4 100644
--- a/xen/arch/x86/pv/emul-inv-op.c
+++ b/xen/arch/x86/pv/emul-inv-op.c
@@ -46,6 +46,7 @@ static int emulate_invalid_rdtscp(struct cpu_user_regs *regs)
 char opcode[3];
 unsigned long eip, rc;
 struct vcpu *v = current;
+struct domain *currd = v->domain;
 
 eip = regs->rip;
 if ( (rc = copy_from_user(opcode, (char *)eip, sizeof(opcode))) != 0 )
@@ -56,7 +57,11 @@ static int emulate_invalid_rdtscp(struct cpu_user_regs *regs)
 if ( memcmp(opcode, "\xf\x1\xf9", sizeof(opcode)) )
 return 0;
 eip += sizeof(opcode);
-pv_soft_rdtsc(v, regs, 1);
+
+msr_split(regs, pv_soft_rdtsc(v, regs));
+regs->rcx = ((currd->arch.tsc_mode == TSC_MODE_PVRDTSCP)
+ ? currd->arch.incarnation : 0);
+
 pv_emul_instruction_done(regs, eip);
 return EXCRET_fault_fixed;
 }
diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 17aaf97..d4d64f2 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -1374,10 +1374,14 @@ int pv_emulate_privileged_op(struct cpu_user_regs *regs)
 case X86EMUL_OKAY:
 if ( ctxt.tsc & TSC_BASE )
 {
-if ( ctxt.tsc & TSC_AUX )
-pv_soft_rdtsc(curr, regs, 1);
-else if ( currd->arch.vtsc )
-pv_soft_rdtsc(curr, regs, 0);
+if ( currd->arch.vtsc || (ctxt.tsc & TSC_AUX) )
+{
+msr_split(regs, pv_soft_rdtsc(curr, regs));
+
+if ( ctxt.tsc & TSC_AUX )
+regs->rcx = ((currd->arch.tsc_mode == TSC_MODE_PVRDTSCP)
+ ? currd->arch.incarnation : 0);
+}
 else
 msr_split(regs, rdtsc());
 }
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index c90524d..c4ca515 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -2024,7 +2024,7 @@ u64 gtsc_to_gtime(struct domain *d, u64 tsc)
 return time;
 }
 
-void pv_soft_rdtsc(struct vcpu *v, struct cpu_user_regs *regs, int rdtscp)
+uint64_t pv_soft_rdtsc(struct vcpu *v, const struct cpu_user_regs *regs)
 {
 s_time_t now = get_s_time();
 struct domain *d = v->domain;
@@ -2045,11 +2045,7 @@ void pv_soft_rdtsc(struct vcpu *v, struct cpu_user_regs 
*regs, int rdtscp)
 
 spin_unlock(&d->arch.vtsc_lock);
 
-msr_split(regs, gtime_to_gtsc(d, now));
-
-if ( rdtscp )
- regs->rcx =
- (d->arch.tsc_mode == TSC_MODE_PVRDTSCP) ? d->arch.incarnation : 0;
+return gtime_to_gtsc(d, now);
 }
 
 bool clocksource_is_tsc(void)
diff --git a/xen/include/asm-x86/time.h b/xen/include/asm-x86/time.h
index 046302e..3bac74c 100644
--- a/xen/include/asm-x86/time.h
+++ b/xen/include/asm-x86/time.h
@@ -56,7 +56,7 @@ uint64_t ns_to_acpi_pm_tick(uint64_t ns);
 
 uint64_t tsc_ticks2ns(uint64_t ticks);
 
-void pv_soft_rdtsc(struct vcpu *v, struct cpu_user_regs *regs, int rdtscp);
+uint64_t pv_soft_rdtsc(struct vcpu *v, const struct cpu_user_regs *regs);
 u64 gtime_to_gtsc(struct domain *d, u64 time);
 u64 gtsc_to_gtime(struct domain *d, u64 tsc);
 
-- 
2.1.4


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

[Xen-devel] [PATCH 1/5] x86/hvm: Don't shadow the domain parameter in hvm_save_cpu_msrs()

[Andrew Cooper]

c/s d2f86bf604 which introduced "struct hvm_save_descriptor *d" accidentally
ended up shadowing the "struct domain *d" function parameter.  Rename the
former to desc.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
---
 xen/arch/x86/hvm/hvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 91bc3e8..5d39210 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1338,7 +1338,7 @@ static int hvm_save_cpu_msrs(struct domain *d, 
hvm_domain_context_t *h)
 
 for_each_vcpu ( d, v )
 {
-struct hvm_save_descriptor *d = _p(&h->data[h->cur]);
+struct hvm_save_descriptor *desc = _p(&h->data[h->cur]);
 struct hvm_msr *ctxt;
 unsigned int i;
 
@@ -1386,7 +1386,7 @@ static int hvm_save_cpu_msrs(struct domain *d, 
hvm_domain_context_t *h)
 if ( ctxt->count )
 {
 /* Rewrite length to indicate how much space we actually used. */
-d->length = HVM_CPU_MSR_SIZE(ctxt->count);
+desc->length = HVM_CPU_MSR_SIZE(ctxt->count);
 h->cur += HVM_CPU_MSR_SIZE(ctxt->count);
 }
 else
-- 
2.1.4


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

[Xen-devel] [PATCH 4/5] x86/pv: Remove deferred RDTSC{, P} handling in pv_emulate_privileged_op()

[Andrew Cooper]

The handling of RDTSCP for PV guests has been broken (AFAICT forever).

To start with, RDTSCP is hidden from PV guests so the MSR_TSC_AUX path should
be unreachable.  However, this appears to be a "feature" of TSC_MODE_PVRDTSCP,
and the emulator doesn't perform appropriate feature checking.  (Conversely,
we unilaterally advertise RDPID which uses the same path, but it should never
trap on #GP to arrive here in the first place).

A PV guest typically can see RDTSCP in native CPUID, so userspace will
probably end up using it.  On a capable pipeline (without TSD, see below), it
will execute normally and return non-virtualised data.

When a virtual TSC mode is not specified for the domain, CR4.TSD is left
clear, so executing RDTSCP will execute without trapping.  However, a guest
kernel may set TSD itself, at which point the emulator should not suddenly
switch to virtualised TSC mode and start handing out differently-scaled
values.

Drop all the deferral logic, and return scaled or raw TSC values depending
only on currd->arch.vtsc.  This changes the exact moment at which the
timestamp is taken, but that doesn't matter from the guests point of view, and
is consistent with the HVM side of things.  It also means that RDTSC and
RDTSCP are now consistent WRT handing out native or virtualised timestamps.

The MSR_TSC_AUX case unconditionally returns the migration incarnation or
zero, depending on TSC_MODE_PVRDTSCP, which is faster than re-reading it out
of hardware.

This is a behavioural change for guests, but the semantics are rather more
sane.  It lays groundwork for further fixes.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Konrad Rzeszutek Wilk 
---
 xen/arch/x86/pv/emul-priv-op.c | 35 +--
 1 file changed, 5 insertions(+), 30 deletions(-)

diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index d4d64f2..4e3641d 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -60,9 +60,6 @@ struct priv_op_ctxt {
 } cs;
 char *io_emul_stub;
 unsigned int bpmatch;
-unsigned int tsc;
-#define TSC_BASE 1
-#define TSC_AUX 2
 };
 
 /* I/O emulation support. Helper routines for, and type of, the stack stub. */
@@ -843,8 +840,7 @@ static inline bool is_cpufreq_controller(const struct 
domain *d)
 static int read_msr(unsigned int reg, uint64_t *val,
 struct x86_emulate_ctxt *ctxt)
 {
-struct priv_op_ctxt *poc = container_of(ctxt, struct priv_op_ctxt, ctxt);
-const struct vcpu *curr = current;
+struct vcpu *curr = current;
 const struct domain *currd = curr->domain;
 bool vpmu_msr = false;
 int ret;
@@ -880,20 +876,13 @@ static int read_msr(unsigned int reg, uint64_t *val,
 *val = curr->arch.pv_vcpu.gs_base_user;
 return X86EMUL_OKAY;
 
-/*
- * In order to fully retain original behavior, defer calling
- * pv_soft_rdtsc() until after emulation. This may want/need to be
- * reconsidered.
- */
 case MSR_IA32_TSC:
-poc->tsc |= TSC_BASE;
-goto normal;
+*val = currd->arch.vtsc ? pv_soft_rdtsc(curr, ctxt->regs) : rdtsc();
+return X86EMUL_OKAY;
 
 case MSR_TSC_AUX:
-poc->tsc |= TSC_AUX;
-if ( cpu_has_rdtscp )
-goto normal;
-*val = 0;
+*val = (uint32_t)((currd->arch.tsc_mode == TSC_MODE_PVRDTSCP)
+  ? currd->arch.incarnation : 0);
 return X86EMUL_OKAY;
 
 case MSR_EFER:
@@ -1372,20 +1361,6 @@ int pv_emulate_privileged_op(struct cpu_user_regs *regs)
 switch ( rc )
 {
 case X86EMUL_OKAY:
-if ( ctxt.tsc & TSC_BASE )
-{
-if ( currd->arch.vtsc || (ctxt.tsc & TSC_AUX) )
-{
-msr_split(regs, pv_soft_rdtsc(curr, regs));
-
-if ( ctxt.tsc & TSC_AUX )
-regs->rcx = ((currd->arch.tsc_mode == TSC_MODE_PVRDTSCP)
- ? currd->arch.incarnation : 0);
-}
-else
-msr_split(regs, rdtsc());
-}
-
 if ( ctxt.ctxt.retire.singlestep )
 ctxt.bpmatch |= DR_STEP;
 if ( ctxt.bpmatch )
-- 
2.1.4


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

[Xen-devel] [RFC PATCH 0/5] x86: Multiple fixes to MSR_TSC_AUX and RDTSCP handling for guests

[Andrew Cooper]

This rats nest was discovered when finding that MSR_TSC_AUX leaked into PV
guests.  It is RFC because I haven't done extensive testing on the result, and
because there are some functional changes for the virtualised TSC modes.

Andrew Cooper (5):
  x86/hvm: Don't shadow the domain parameter in hvm_save_cpu_msrs()
  x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV context
  x86/time: Rework pv_soft_rdtsc() to aid further cleanup
  x86/pv: Remove deferred RDTSC{,P} handling in pv_emulate_privileged_op()
  x86: Rework MSR_TSC_AUX handling from scratch.

 xen/arch/x86/domain.c   |  5 ++-
 xen/arch/x86/domctl.c   | 15 -
 xen/arch/x86/hvm/hvm.c  | 51 -
 xen/arch/x86/hvm/svm/svm.c  |  4 +--
 xen/arch/x86/hvm/vmx/vmx.c  |  4 +--
 xen/arch/x86/msr.c  | 18 ++
 xen/arch/x86/pv/emul-inv-op.c   |  5 ++-
 xen/arch/x86/pv/emul-priv-op.c  | 30 ++---
 xen/arch/x86/time.c | 19 +++
 xen/arch/x86/x86_emulate/x86_emulate.c  |  1 +
 xen/include/asm-x86/hvm/hvm.h   |  6 
 xen/include/asm-x86/hvm/vcpu.h  |  1 -
 xen/include/asm-x86/msr.h   | 25 --
 xen/include/asm-x86/time.h  |  2 +-
 xen/include/public/arch-x86/cpufeatureset.h |  2 +-
 xen/include/public/arch-x86/hvm/save.h  |  2 ++
 xen/tools/gen-cpuid.py  |  3 ++
 17 files changed, 123 insertions(+), 70 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 2/5] x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV context

[Andrew Cooper]

If the CPU pipeline supports RDTSCP or RDPID, a guest can observe the value in
MSR_TSC_AUX, irrespective of whether the relevant CPUID features are
advertised/hidden.

At the moment, paravirt_ctxt_switch_to() only writes to MSR_TSC_AUX if
TSC_MODE_PVRDTSCP mode is enabled, but this is not the default mode.
Therefore, default PV guests can read the value from a previously scheduled
HVM vcpu, or TSC_MODE_PVRDTSCP-enabled PV guest.

Alter the PV path to always write to MSR_TSC_AUX, using 0 in the common case.

To amortise overhead cost, introduce wrmsr_tsc_aux() which performs a lazy
update of the MSR, and use this function consistently across the codebase.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Konrad Rzeszutek Wilk 

N.B. This has been deemed not a security issue, because the MSR doesn't store
any sensitive information.
---
 xen/arch/x86/domain.c  |  6 +++---
 xen/arch/x86/hvm/hvm.c |  2 +-
 xen/arch/x86/hvm/svm/svm.c |  2 +-
 xen/arch/x86/hvm/vmx/vmx.c |  2 +-
 xen/arch/x86/msr.c |  2 ++
 xen/include/asm-x86/msr.h  | 16 ++--
 6 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index f93327b..9c3527f 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1533,9 +1533,9 @@ void paravirt_ctxt_switch_to(struct vcpu *v)
 if ( unlikely(v->arch.debugreg[7] & DR7_ACTIVE_MASK) )
 activate_debugregs(v);
 
-if ( (v->domain->arch.tsc_mode ==  TSC_MODE_PVRDTSCP) &&
- boot_cpu_has(X86_FEATURE_RDTSCP) )
-write_rdtscp_aux(v->domain->arch.incarnation);
+if ( cpu_has_rdtscp )
+wrmsr_tsc_aux(v->domain->arch.tsc_mode == TSC_MODE_PVRDTSCP
+  ? v->domain->arch.incarnation : 0);
 }
 
 /* Update per-VCPU guest runstate shared memory area (if registered). */
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 5d39210..0539551 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3579,7 +3579,7 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 v->arch.hvm_vcpu.msr_tsc_aux = (uint32_t)msr_content;
 if ( cpu_has_rdtscp
  && (v->domain->arch.tsc_mode != TSC_MODE_PVRDTSCP) )
-wrmsrl(MSR_TSC_AUX, (uint32_t)msr_content);
+wrmsr_tsc_aux(msr_content);
 break;
 
 case MSR_IA32_APICBASE:
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 9f58afc..f53f430 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1093,7 +1093,7 @@ static void svm_ctxt_switch_to(struct vcpu *v)
 svm_tsc_ratio_load(v);
 
 if ( cpu_has_rdtscp )
-wrmsrl(MSR_TSC_AUX, hvm_msr_tsc_aux(v));
+wrmsr_tsc_aux(hvm_msr_tsc_aux(v));
 }
 
 static void noreturn svm_do_resume(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 5cd689e..31acb0e 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -618,7 +618,7 @@ static void vmx_restore_guest_msrs(struct vcpu *v)
 }
 
 if ( cpu_has_rdtscp )
-wrmsrl(MSR_TSC_AUX, hvm_msr_tsc_aux(v));
+wrmsr_tsc_aux(hvm_msr_tsc_aux(v));
 }
 
 void vmx_update_cpu_exec_control(struct vcpu *v)
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 7875d9c..7ba9a10 100644
--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 
+DEFINE_PER_CPU(uint32_t, tsc_aux);
+
 struct msr_domain_policy __read_mostly hvm_max_msr_domain_policy,
  __read_mostly  pv_max_msr_domain_policy;
 
diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
index 928f1cc..9475a71 100644
--- a/xen/include/asm-x86/msr.h
+++ b/xen/include/asm-x86/msr.h
@@ -115,8 +115,6 @@ static inline uint64_t rdtsc_ordered(void)
 __write_tsc(val);   \
 })
 
-#define write_rdtscp_aux(val) wrmsr(MSR_TSC_AUX, (val), 0)
-
 #define rdpmc(counter,low,high) \
  __asm__ __volatile__("rdpmc" \
  : "=a" (low), "=d" (high) \
@@ -210,6 +208,20 @@ static inline void write_efer(uint64_t val)
 
 DECLARE_PER_CPU(u32, ler_msr);
 
+DECLARE_PER_CPU(uint32_t, tsc_aux);
+
+/* Lazy update of MSR_TSC_AUX */
+static inline void wrmsr_tsc_aux(uint32_t val)
+{
+uint32_t *this_tsc_aux = &this_cpu(tsc_aux);
+
+if ( *this_tsc_aux != val )
+{
+wrmsr(MSR_TSC_AUX, val, 0);
+*this_tsc_aux = val;
+}
+}
+
 /* MSR policy object for shared per-domain MSRs */
 struct msr_domain_policy
 {
-- 
2.1.4


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

[Xen-devel] [PATCH 5/5] x86: Rework MSR_TSC_AUX handling from scratch.

[Andrew Cooper]

There are many problems with MSR_TSC_AUX handling.

To being with, the RDPID instruction reads MSR_TSC_AUX, but it is only the
RDTSCP feature which enumerates the MSR.  Therefore, RDPID functionally
depends on RDTSCP.

For PV guests, we hide RDTSCP but advertise RDPID.  We also silently drop
writes to MSR_TSC_AUX, which is very antisocial.  Therefore, enable RDTSCP for
PV guests, which in turn allows RDPID to work.

To support RDTSCP properly for PV guests, the MSR_TSC_AUX handling is moved
into the generic MSR policy infrastructure, and becomes common.  One
improvement is that we will now reject invalid values, rather than silently
truncating an accepting them.  This also causes the emulator to reject RDTSCP
for guests without the features.

One complication is TSC_MODE_PVRDTSCP, in which Xen takes control of
MSR_TSC_AUX and the reported value is actually the migration incarnation.  The
previous behaviour of this mode was to silently drop writes, but as it is a
break in the x86 ABI to start with, switch the semantics to be more sane, and
have TSC_MODE_PVRDTSCP make the MSR properly read-only.

With PV guests getting to use MSR_TSC_AUX properly now, the MSR needs
migrating.  Cope with it the common migration logic.  Care must be taken
however to avoid sending the MSR if TSC_MODE_PVRDTSCP is active, as the
receiving side will reject the guest_wrmsr().

What remains is that tsc_set_info() need to broadcast d->arch.incarnation to
all vCPUs MSR block if in TSC_MODE_PVRDTSCP, so the context switching and
emulation code functions correctly.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Konrad Rzeszutek Wilk 
---
 xen/arch/x86/domain.c   |  3 +-
 xen/arch/x86/domctl.c   | 15 -
 xen/arch/x86/hvm/hvm.c  | 47 -
 xen/arch/x86/hvm/svm/svm.c  |  4 +--
 xen/arch/x86/hvm/vmx/vmx.c  |  4 +--
 xen/arch/x86/msr.c  | 16 ++
 xen/arch/x86/pv/emul-inv-op.c   |  4 +--
 xen/arch/x86/pv/emul-priv-op.c  |  5 ---
 xen/arch/x86/time.c | 11 +++
 xen/arch/x86/x86_emulate/x86_emulate.c  |  1 +
 xen/include/asm-x86/hvm/hvm.h   |  6 
 xen/include/asm-x86/hvm/vcpu.h  |  1 -
 xen/include/asm-x86/msr.h   |  9 ++
 xen/include/public/arch-x86/cpufeatureset.h |  2 +-
 xen/include/public/arch-x86/hvm/save.h  |  2 ++
 xen/tools/gen-cpuid.py  |  3 ++
 16 files changed, 96 insertions(+), 37 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 9c3527f..144d6f0 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1534,8 +1534,7 @@ void paravirt_ctxt_switch_to(struct vcpu *v)
 activate_debugregs(v);
 
 if ( cpu_has_rdtscp )
-wrmsr_tsc_aux(v->domain->arch.tsc_mode == TSC_MODE_PVRDTSCP
-  ? v->domain->arch.incarnation : 0);
+wrmsr_tsc_aux(v->arch.msr->tsc_aux);
 }
 
 /* Update per-VCPU guest runstate shared memory area (if registered). */
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 8fbbf3a..979afdf 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1249,6 +1249,7 @@ long arch_do_domctl(
 static const uint32_t msrs_to_send[] = {
 MSR_SPEC_CTRL,
 MSR_INTEL_MISC_FEATURES_ENABLES,
+MSR_TSC_AUX,
 };
 uint32_t nr_msrs = ARRAY_SIZE(msrs_to_send);
 
@@ -1284,7 +1285,18 @@ long arch_do_domctl(
 for ( j = 0; j < ARRAY_SIZE(msrs_to_send); ++j )
 {
 uint64_t val;
-int rc = guest_rdmsr(v, msrs_to_send[j], &val);
+int rc;
+
+/*
+ * Skip MSR_TSC_AUX if using TSC_MODE_PVRDTSCP.  In this
+ * case, the MSR is read-only, and should be rejected if
+ * seen on the restore side.
+ */
+if ( msrs_to_send[j] == MSR_TSC_AUX &&
+ d->arch.tsc_mode == TSC_MODE_PVRDTSCP )
+continue;
+
+rc = guest_rdmsr(v, msrs_to_send[j], &val);
 
 /*
  * It is the programmers responsibility to ensure that
@@ -1373,6 +1385,7 @@ long arch_do_domctl(
 {
 case MSR_SPEC_CTRL:
 case MSR_INTEL_MISC_FEATURES_ENABLES:
+case MSR_TSC_AUX:
 if ( guest_wrmsr(v, msr.index, msr.value) != X86EMUL_OKAY )
 break;
 continue;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 0539551..ab24f87 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -792,7 +792,7 @@

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

[osstest service owner]

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

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  a44f1697968e04fcc6145e3bd51c748b57047240
baseline version:
 xen  8f9ccfe93570ecae18d9cc224931787d0bca9c66

Last test of basis   119669  2018-02-19 18:07:17 Z0 days
Testing same since   119721  2018-02-20 10:01:08 Z0 days1 attempts


People who touched revisions under test:
  Igor Druzhinin 
  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
   8f9ccfe935..a44f169796  a44f1697968e04fcc6145e3bd51c748b57047240 -> smoke

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

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

[Julien Grall]

Hi Stefano,

On 19/02/18 21:58, Stefano Stabellini wrote:

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 2184cb9..8997904 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1007,7 +1007,12 @@ Control Xens use of the APEI Hardware Error Source 
Table, should one be found.
  
  Say yes at your own risk if you want to enable heterogenous computing

  (such as big.LITTLE). This may result to an unstable and insecure
-platform. When the option is disabled (default), CPUs that are not
+platform, unless you manually specify the cpu affinity of all domains so
+that all vcpus are scheduled on the same class of pcpus (big or LITTLE
+but not both). vcpu migration between big cores and LITTLE cores is not
+supported. See docs/misc/arm/big.LITTLE.txt for more information.
+
+When the hmp-unsafe option is disabled (default), CPUs that are not
  identical to the boot CPU will be parked and not used by Xen.
  
  ### hpetbroadcast

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 122c0b5..d04b7c7 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -266,7 +266,7 @@ void __init smp_init_cpus(void)
  
  if ( opt_hmp_unsafe )

  warning_add("WARNING: HMP COMPUTING HAS BEEN ENABLED.\n"
-"It has implications on the security and stability of the 
system.\n");
+"It has implications on the security and stability of the 
system, unless the cpu affinity of all domains is specified.\n");


The warning message will not be print nicely on serial. Please make sure 
it is split at 72 characters.



  }
  
  int __init

@@ -308,13 +308,14 @@ void start_secondary(unsigned long boot_phys_offset,
  /*
   * Currently Xen assumes the platform has only one kind of CPUs.
   * This assumption does not hold on big.LITTLE platform and may
- * result to instability and insecure platform. Better to park them
- * for now.
+ * result to instability and insecure platform (unless cpu affinity
+ * is manually specified for all domains). Better to park them for
+ * now.
   */
  if ( !opt_hmp_unsafe &&
   current_cpu_data.midr.bits != boot_cpu_data.midr.bits )
  {
-printk(XENLOG_ERR "CPU%u MIDR (0x%x) does not match boot CPU MIDR 
(0x%x).\n",
+printk(XENLOG_ERR "CPU%u MIDR (0x%x) does not match boot CPU MIDR (0x%x), 
disable cpu (see big.LITTLE.txt under docs/).\n",


Same here.


 smp_processor_id(), current_cpu_data.midr.bits,
 boot_cpu_data.midr.bits);
  stop_cpu();



Cheers,

--
Julien Grall

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

Re: [Xen-devel] RTDS with extra time issue

[Andrii Anisov]

Hello Dario,


On 16.02.18 20:37, Dario Faggioli wrote:

And what is it that is running in DomR, the same thing as before, when
the load was synthetic?

For sure I compare apples to apples.


And in any case, is it, in its turn (I mean the
workload running in DomR) a synthetic real-time load, or is it a real
real-time application?
Real-time domain is synthetic, though. I'm using LITMUS-RT system for 
the DomR. In particular with amount of work based configuration [1] 
introduced recently.



If the latter, are you sure the misses are not due to the fact that,
for instance, the rt app does not always behave as measured/expected,
when computing the parameters?
Even for the synthetic rt workload some deviations in execution time are 
noticed (~0.5%). But with no IRQ extensive load in application domains, 
no DL misses are noticed in RT domain.



Well this provides some ground for another my concern about XEN
scheduling approach. My doubt is that scheduling is done within
softirq,
so all time spent with pcpu for exception itself and possible timer
actions is accounted for the vcpu which context was interrupted.

I am not sure I fully understand this.
My idea is to charge time spent in hypervisor from current vcpu budget, 
except serving that vcpu hypercalls and handling interrupts targeted 
current vcpu. Same as you expressed:



Because if DomX was running, and we entered Xen because an interrupt
arrived to deal with a timer or whatever from DomY, then I agree it's
not fair to charge DomX for that. But, OTOH, if we are in Xen because
DomX itself called an hypercall, then it is indeed ok to charge DomX.

For RT scheduling this would make big difference.


If you're worried about some kind of overhead may be consuming some of
your real-time reservation, try to increase the reservation itself a
bit, and see if the misses disappear.
Its not about overhead but unfair time accounting. And this unfairness 
is pretty arbitrary, depends on other domains activity.



One difference could be that Linux can be configured to be fully
preemptible --even the kernel-- while Xen is not. But I don't think
this is what you're hinting at, is it?

No, it is not.
If we are speaking about Linux, it much closer to 
CONFIG_IRQ_TIME_ACCOUNTING [1].



And note that this does not have much to do with how schedule() gets
called. :-)
In current implementation it does matter *when* `schedule()` is called. 
Because time accounting is done by passing `now` time value to 
`sched->do_schedule()` right in `schedule()`.


[1] https://github.com/LITMUS-RT/liblitmus/pull/3
[2] https://lkml.org/lkml/2011/2/10/135

--

*Andrii Anisov*



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

Re: [Xen-devel] [PATCH] build: remove shim related targets

[Wei Liu]

On Tue, Feb 20, 2018 at 11:29:58AM +, Wei Liu wrote:
> On Tue, Feb 20, 2018 at 11:26:44AM +, Roger Pau Monné wrote:
> > On Tue, Feb 20, 2018 at 11:17:47AM +, Wei Liu wrote:
> > > On Tue, Feb 20, 2018 at 08:23:51AM +, Roger Pau Monne wrote:
> > > > There's no need to have shim specific targets, so just use the regular
> > > > xen makefile targets in order to build the shim binary.
> > > > 
> > > > When the shim is build as part of the firmware directory use the
> > > > xen-syms as the shim binary.
> > > > 
> > > > Signed-off-by: Roger Pau Monné 
> > > > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> > > > index 389096139c..5563c813dd 100644
> > > > --- a/xen/arch/x86/Makefile
> > > > +++ b/xen/arch/x86/Makefile
> > > > @@ -78,12 +78,12 @@ efi-y := $(shell if [ ! -r 
> > > > $(BASEDIR)/include/xen/compile.h -o \
> > > >-O $(BASEDIR)/include/xen/compile.h ]; then \
> > > >   echo '$(TARGET).efi'; fi)
> > > >  
> > > > -shim-$(CONFIG_PVH_GUEST) := $(TARGET)-shim
> > > > -
> > > >  ifneq ($(build_id_linker),)
> > > >  notes_phdrs = --notes
> > > >  else
> > > > -notes_phdrs =
> > > > +ifeq ($(CONFIG_PVH_GUEST),y)
> > > > +notes_phdrs = --notes
> > > > +endif
> > > >  endif
> > > >  
> > > 
> > > The manual suggests following syntax is supported:
> > > 
> > > 
> > >   conditional-directive-one
> > >   text-if-one-is-true
> > >   else conditional-directive-two
> > >   text-if-two-is-true
> > >   else
> > >   text-if-one-and-two-are-false
> > >   endif
> > > 
> > > I slightly prefer
> > > 
> > >ifneq build_id_linker
> > >notes_phdrs = ...
> > >else if CONFIG_PVH_GUEST
> > >notes_phdrs = ...
> > >else
> > >notes_phdrs =
> > >endif
> > 
> > Is this supported by make 3.80?
> > 
> > Jan pointed out in another thread that using "else if" on a single
> > line is not supported by 3.80:
> > 
> > https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01659.html
> > 

Actually, see

https://www.cl.cam.ac.uk/teaching/1011/UnixTools/make.pdf


http://www.delorie.com/gnu/docs/make/make_77.html

Make 3.82 manual supports that syntax. But 3.80 doesn't.

Wei.

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

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: read cacheline size when needed

[Julien Grall]

Hi Stefano,

On 19/02/18 21:58, Stefano Stabellini wrote:

On big.LITTLE systems the cacheline size might differ between big and
LITTLE cores. Instead of reading the cacheline size once at boot,
read it as needed from the system registers.

Suggested-by: Julien Grall 
Signed-off-by: Stefano Stabellini 
---
  xen/arch/arm/arm32/head.S  |  9 +++--
  xen/arch/arm/arm64/head.S  | 10 --
  xen/arch/arm/setup.c   | 17 -
  xen/include/asm-arm/page.h | 17 +++--
  4 files changed, 30 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index 43374e7..db470ad 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -504,8 +504,13 @@ ENTRY(relocate_xen)
  dsb/* So the CPU issues all writes to the range */
  
  mov   r5, r4

-ldr   r6, =cacheline_bytes /* r6 := step */
-ldr   r6, [r6]
+mov   r6, #0


Comments in the code would be nice to know what you exactly do. Also in 
that case, it would make sense to have a macro as this may be useful in 
other places.



+mcr   CP32(r6, CSSELR_EL1)


Please use 32-bit naming in the 32-bit code.



+mrc   CP32(r6, CSSELR_EL1)


The size of the cache is read using CSSIDR_EL1. But it looks like the 
way we get the cache line size in Xen is fragile.


We are retrieving the cache line size of Level 1 and assume this will be 
valid for all the other caches. Indeed cache maintenance ops may 
propagate to other caches depending the target (Point of Coherency vs 
Point of Unification).


Looking at the ARM ARM "Cache hierarchy abstraction for address-based 
operations" (D3-2061 DDI 0487C.a), CTR_EL0/CTR will holds the minimum 
line lenght values for the data caches. The value will be the most 
efficient address stride to use to apply a sequence of VA-based 
maintenance instructions to a range of VAs.


So it would be best and safer for Xen to use CTR/CTLR_EL0.DminLine.


+and   r6, r6, #0x7
+add   r6, r6, #4
+mov   r7, #1
+lsl   r6, r7, r6
  mov   r7, r3
  
  1:  mcr   CP32(r7, DCCMVAC)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index fa0ef70..edea300 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -631,8 +631,14 @@ ENTRY(relocate_xen)
  dsb   sy/* So the CPU issues all writes to the range */
  
  mov   x9, x3

-ldr   x10, =cacheline_bytes /* x10 := step */
-ldr   x10, [x10]
+
+mov   x10, #0
+msr   CSSELR_EL1, x10
+mrs   x10, CSSELR_EL1
+and   x10, x10, #0x7
+add   x10, x10, #4
+mov   x11, #1
+lsl   x10, x11, x10


Please use dcache_line_size macro (see cache.S).


  mov   x11, x2
  
  1:  dccvac, x11

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 032a6a8..4754c95 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -680,21 +680,6 @@ static void __init setup_mm(unsigned long dtb_paddr, 
size_t dtb_size)
  }
  #endif
  
-size_t __read_mostly cacheline_bytes;

-
-/* Very early check of the CPU cache properties */
-void __init setup_cache(void)
-{
-uint32_t ccsid;
-
-/* Read the cache size ID register for the level-0 data cache */
-WRITE_SYSREG32(0, CSSELR_EL1);
-ccsid = READ_SYSREG32(CCSIDR_EL1);
-
-/* Low 3 bits are log2(cacheline size in words) - 2. */
-cacheline_bytes = 1U << (4 + (ccsid & 0x7));
-}
-
  /* C entry point for boot CPU */
  void __init start_xen(unsigned long boot_phys_offset,
unsigned long fdt_paddr,
@@ -708,8 +693,6 @@ void __init start_xen(unsigned long boot_phys_offset,
  struct domain *dom0;
  struct xen_arch_domainconfig config;
  
-setup_cache();

-
  percpu_init_areas();
  set_processor_id(0); /* needed early, for smp_processor_id() */
  
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h

index d948250..791e22e 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -133,8 +133,6 @@
  
  /* Architectural minimum cacheline size is 4 32-bit words. */

  #define MIN_CACHELINE_BYTES 16
-/* Actual cacheline size on the boot CPU. */
-extern size_t cacheline_bytes;
  
  #define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
  
@@ -142,9 +140,22 @@ extern size_t cacheline_bytes;

   * if 'range' is large enough we might want to use model-specific
   * full-cache flushes. */
  
+static inline size_t read_cacheline_size(void)

+{
+uint32_t ccsid;
+
+/* Read the cache size ID register for the level-0 data cache */
+WRITE_SYSREG32(0, CSSELR_EL1);
+ccsid = READ_SYSREG32(CCSIDR_EL1);
+
+/* Low 3 bits are log2(cacheline size in words) - 2. */
+return (size_t) (1U << (4 + (ccsid & 0x7)));


See my remark above regarding the cacheline size.


+}
+
  static inline int invalidate_dcache_va_range(const void *p, unsigned long 
size)
  {
  const void *end = p

Re: [Xen-devel] [PATCH] build: remove shim related targets

[Wei Liu]

On Tue, Feb 20, 2018 at 11:26:44AM +, Roger Pau Monné wrote:
> On Tue, Feb 20, 2018 at 11:17:47AM +, Wei Liu wrote:
> > On Tue, Feb 20, 2018 at 08:23:51AM +, Roger Pau Monne wrote:
> > > There's no need to have shim specific targets, so just use the regular
> > > xen makefile targets in order to build the shim binary.
> > > 
> > > When the shim is build as part of the firmware directory use the
> > > xen-syms as the shim binary.
> > > 
> > > Signed-off-by: Roger Pau Monné 
> > > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> > > index 389096139c..5563c813dd 100644
> > > --- a/xen/arch/x86/Makefile
> > > +++ b/xen/arch/x86/Makefile
> > > @@ -78,12 +78,12 @@ efi-y := $(shell if [ ! -r 
> > > $(BASEDIR)/include/xen/compile.h -o \
> > >-O $(BASEDIR)/include/xen/compile.h ]; then \
> > >   echo '$(TARGET).efi'; fi)
> > >  
> > > -shim-$(CONFIG_PVH_GUEST) := $(TARGET)-shim
> > > -
> > >  ifneq ($(build_id_linker),)
> > >  notes_phdrs = --notes
> > >  else
> > > -notes_phdrs =
> > > +ifeq ($(CONFIG_PVH_GUEST),y)
> > > +notes_phdrs = --notes
> > > +endif
> > >  endif
> > >  
> > 
> > The manual suggests following syntax is supported:
> > 
> > 
> >   conditional-directive-one
> >   text-if-one-is-true
> >   else conditional-directive-two
> >   text-if-two-is-true
> >   else
> >   text-if-one-and-two-are-false
> >   endif
> > 
> > I slightly prefer
> > 
> >ifneq build_id_linker
> >notes_phdrs = ...
> >else if CONFIG_PVH_GUEST
> >notes_phdrs = ...
> >else
> >notes_phdrs =
> >endif
> 
> Is this supported by make 3.80?
> 
> Jan pointed out in another thread that using "else if" on a single
> line is not supported by 3.80:
> 
> https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01659.html
> 

Oh if there is a such reason then it is fine to keep the code as-is.
I don't have make 3.8 around to try it out.

Wei.

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

Re: [Xen-devel] [PATCH] build: remove shim related targets

[Roger Pau Monné]

On Tue, Feb 20, 2018 at 11:17:47AM +, Wei Liu wrote:
> On Tue, Feb 20, 2018 at 08:23:51AM +, Roger Pau Monne wrote:
> > There's no need to have shim specific targets, so just use the regular
> > xen makefile targets in order to build the shim binary.
> > 
> > When the shim is build as part of the firmware directory use the
> > xen-syms as the shim binary.
> > 
> > Signed-off-by: Roger Pau Monné 
> > diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> > index 389096139c..5563c813dd 100644
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -78,12 +78,12 @@ efi-y := $(shell if [ ! -r 
> > $(BASEDIR)/include/xen/compile.h -o \
> >-O $(BASEDIR)/include/xen/compile.h ]; then \
> >   echo '$(TARGET).efi'; fi)
> >  
> > -shim-$(CONFIG_PVH_GUEST) := $(TARGET)-shim
> > -
> >  ifneq ($(build_id_linker),)
> >  notes_phdrs = --notes
> >  else
> > -notes_phdrs =
> > +ifeq ($(CONFIG_PVH_GUEST),y)
> > +notes_phdrs = --notes
> > +endif
> >  endif
> >  
> 
> The manual suggests following syntax is supported:
> 
> 
>   conditional-directive-one
>   text-if-one-is-true
>   else conditional-directive-two
>   text-if-two-is-true
>   else
>   text-if-one-and-two-are-false
>   endif
> 
> I slightly prefer
> 
>ifneq build_id_linker
>notes_phdrs = ...
>else if CONFIG_PVH_GUEST
>notes_phdrs = ...
>else
>notes_phdrs =
>endif

Is this supported by make 3.80?

Jan pointed out in another thread that using "else if" on a single
line is not supported by 3.80:

https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01659.html

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 3/4] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

[Roger Pau Monné]

On Tue, Feb 20, 2018 at 04:13:42AM -0700, Jan Beulich wrote:
> >>> On 20.02.18 at 12:01,  wrote:
> > --- a/xen/include/asm-x86/asm_defns.h
> > +++ b/xen/include/asm-x86/asm_defns.h
> > @@ -15,6 +15,9 @@
> >  #include 
> > 
> >  #ifdef __ASSEMBLY__
> > +#ifndef CONFIG_INDIRECT_THUNK
> > +.equ CONFIG_INDIRECT_THUNK, 0
> > +#endif
> >  # include 
> >  #else
> >  asm ( "\t.equ CONFIG_INDIRECT_THUNK, "
> > 
> > It's fairly similar to my first approach, but at least "#ifdef
> > CONFIG_INDIRECT_THUNK" will still work as expected after this fix.
> 
> I've used something similar in backports to old versions, so I
> wonder whether what you quote above is right: Assembly files
> don't get handed to clang anyway iirc, so the change would
> seem to be needed in the #else part of the conditional.

Assembly files do get handed to clang, from xen/Rules.mk:

%.o: %.S Makefile
$(CC) $(AFLAGS) -c $< -o $@

Xen doesn't call as directly to compile those, or am I missing
something?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH] build: remove shim related targets

[Wei Liu]

On Tue, Feb 20, 2018 at 08:23:51AM +, Roger Pau Monne wrote:
> There's no need to have shim specific targets, so just use the regular
> xen makefile targets in order to build the shim binary.
> 
> When the shim is build as part of the firmware directory use the
> xen-syms as the shim binary.
> 
> Signed-off-by: Roger Pau Monné 
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index 389096139c..5563c813dd 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -78,12 +78,12 @@ efi-y := $(shell if [ ! -r 
> $(BASEDIR)/include/xen/compile.h -o \
>-O $(BASEDIR)/include/xen/compile.h ]; then \
>   echo '$(TARGET).efi'; fi)
>  
> -shim-$(CONFIG_PVH_GUEST) := $(TARGET)-shim
> -
>  ifneq ($(build_id_linker),)
>  notes_phdrs = --notes
>  else
> -notes_phdrs =
> +ifeq ($(CONFIG_PVH_GUEST),y)
> +notes_phdrs = --notes
> +endif
>  endif
>  

The manual suggests following syntax is supported:


  conditional-directive-one
  text-if-one-is-true
  else conditional-directive-two
  text-if-two-is-true
  else
  text-if-one-and-two-are-false
  endif

I slightly prefer

   ifneq build_id_linker
   notes_phdrs = ...
   else if CONFIG_PVH_GUEST
   notes_phdrs = ...
   else
   notes_phdrs =
   endif

Wei.

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

Re: [Xen-devel] [PATCH v4 3/4] x86: fix indirect thunk usage of CONFIG_INDIRECT_THUNK

[Jan Beulich]

>>> On 20.02.18 at 12:01,  wrote:
> --- a/xen/include/asm-x86/asm_defns.h
> +++ b/xen/include/asm-x86/asm_defns.h
> @@ -15,6 +15,9 @@
>  #include 
> 
>  #ifdef __ASSEMBLY__
> +#ifndef CONFIG_INDIRECT_THUNK
> +.equ CONFIG_INDIRECT_THUNK, 0
> +#endif
>  # include 
>  #else
>  asm ( "\t.equ CONFIG_INDIRECT_THUNK, "
> 
> It's fairly similar to my first approach, but at least "#ifdef
> CONFIG_INDIRECT_THUNK" will still work as expected after this fix.

I've used something similar in backports to old versions, so I
wonder whether what you quote above is right: Assembly files
don't get handed to clang anyway iirc, so the change would
seem to be needed in the #else part of the conditional.

Jan


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