[Xen-devel] [PATCH v2 1/2] x86/mm: fix a potential race condition in map_pages_to_xen().

[Yu Zhang]

From: Min He 

In map_pages_to_xen(), a L2 page table entry may be reset to point to
a superpage, and its corresponding L1 page table need be freed in such
scenario, when these L1 page table entries are mapping to consecutive
page frames and having the same mapping flags.

However, variable `pl1e` is not protected by the lock before L1 page table
is enumerated. A race condition may happen if this code path is invoked
simultaneously on different CPUs.

For example, `pl1e` value on CPU0 may hold an obsolete value, pointing
to a page which has just been freed on CPU1. Besides, before this page
is reused, it will still be holding the old PTEs, referencing consecutive
page frames. Consequently the `free_xen_pagetable(l2e_to_l1e(ol2e))` will
be triggered on CPU0, resulting the unexpected free of a normal page.

This patch fixes the potential race condition by protecting the `pl1e`
with the lock, and checking the PSE flag of the `pl2e`.

Note: PSE flag of `pl3e` is also checked before its re-consolidation,
for the same reason we do for `pl2e` - we cannot presume the contents
of the target superpage.

Signed-off-by: Min He 
Signed-off-by: Yi Zhang 
Signed-off-by: Yu Zhang 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

Changes in v2:
According to comments from Jan Beulich,
  - check PSE of pl2e and pl3e, and skip the re-consolidation if set.
  - commit message changes, e.g. add "From :" tag etc.
  - code style changes.
  - introduce a seperate patch to resolve the similar issue in
modify_xen_mappings().
---
 xen/arch/x86/mm.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index a20fdca..47855fb 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4844,9 +4844,19 @@ int map_pages_to_xen(
 {
 unsigned long base_mfn;
 
-pl1e = l2e_to_l1e(*pl2e);
 if ( locking )
 spin_lock(_pgdir_lock);
+
+/* Skip the re-consolidation if it's done on another CPU. */
+if ( l2e_get_flags(*pl2e) & _PAGE_PSE )
+{
+if ( locking )
+spin_unlock(_pgdir_lock);
+goto check_l3;
+}
+
+ol2e = *pl2e;
+pl1e = l2e_to_l1e(ol2e);
 base_mfn = l1e_get_pfn(*pl1e) & ~(L1_PAGETABLE_ENTRIES - 1);
 for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++, pl1e++ )
 if ( (l1e_get_pfn(*pl1e) != (base_mfn + i)) ||
@@ -4854,7 +4864,6 @@ int map_pages_to_xen(
 break;
 if ( i == L1_PAGETABLE_ENTRIES )
 {
-ol2e = *pl2e;
 l2e_write_atomic(pl2e, l2e_from_pfn(base_mfn,
 l1f_to_lNf(flags)));
 if ( locking )
@@ -4880,6 +4889,15 @@ int map_pages_to_xen(
 
 if ( locking )
 spin_lock(_pgdir_lock);
+
+/* Skip the re-consolidation if it's done on another CPU. */
+if ( l3e_get_flags(*pl3e) & _PAGE_PSE )
+{
+if ( locking )
+spin_unlock(_pgdir_lock);
+continue;
+}
+
 ol3e = *pl3e;
 pl2e = l3e_to_l2e(ol3e);
 base_mfn = l2e_get_pfn(*pl2e) & ~(L2_PAGETABLE_ENTRIES *
-- 
2.5.0


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

[Xen-devel] [PATCH v2 2/2] x86/mm: fix a potential race condition in modify_xen_mappings().

[Yu Zhang]

In modify_xen_mappings(), a L1/L2 page table may be freed,
if all entries of this page table are empty. Corresponding
L2/L3 PTE will need be cleared in such scenario.

However, logic to enumerate the L1/L2 page table and to reset
the corresponding L2/L3 PTE need to be protected with spinlock.
Otherwise, the paging structure may be freed more than once, if
the same routine is invoked simultaneously on different CPUs.

Signed-off-by: Yu Zhang 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/mm.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 47855fb..c07c528 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5097,6 +5097,17 @@ int modify_xen_mappings(unsigned long s, unsigned long 
e, unsigned int nf)
  */
 if ( (nf & _PAGE_PRESENT) || ((v != e) && (l1_table_offset(v) != 
0)) )
 continue;
+if ( locking )
+spin_lock(_pgdir_lock);
+
+/* L2E may be cleared on another CPU. */
+if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
+{
+if ( locking )
+spin_unlock(_pgdir_lock);
+goto check_l3;
+}
+
 pl1e = l2e_to_l1e(*pl2e);
 for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++ )
 if ( l1e_get_intpte(pl1e[i]) != 0 )
@@ -5105,11 +5116,16 @@ int modify_xen_mappings(unsigned long s, unsigned long 
e, unsigned int nf)
 {
 /* Empty: zap the L2E and free the L1 page. */
 l2e_write_atomic(pl2e, l2e_empty());
+if ( locking )
+spin_unlock(_pgdir_lock);
 flush_area(NULL, FLUSH_TLB_GLOBAL); /* flush before free */
 free_xen_pagetable(pl1e);
 }
+else if ( locking )
+spin_unlock(_pgdir_lock);
 }
 
+check_l3:
 /*
  * If we are not destroying mappings, or not done with the L3E,
  * skip the empty check.
@@ -5117,6 +5133,17 @@ int modify_xen_mappings(unsigned long s, unsigned long 
e, unsigned int nf)
 if ( (nf & _PAGE_PRESENT) ||
  ((v != e) && (l2_table_offset(v) + l1_table_offset(v) != 0)) )
 continue;
+if ( locking )
+spin_lock(_pgdir_lock);
+
+/* L3E may be cleared on another CPU. */
+if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) )
+{
+if ( locking )
+spin_unlock(_pgdir_lock);
+continue;
+}
+
 pl2e = l3e_to_l2e(*pl3e);
 for ( i = 0; i < L2_PAGETABLE_ENTRIES; i++ )
 if ( l2e_get_intpte(pl2e[i]) != 0 )
@@ -5125,9 +5152,13 @@ int modify_xen_mappings(unsigned long s, unsigned long 
e, unsigned int nf)
 {
 /* Empty: zap the L3E and free the L2 page. */
 l3e_write_atomic(pl3e, l3e_empty());
+if ( locking )
+spin_unlock(_pgdir_lock);
 flush_area(NULL, FLUSH_TLB_GLOBAL); /* flush before free */
 free_xen_pagetable(pl2e);
 }
+else if ( locking )
+spin_unlock(_pgdir_lock);
 }
 
 flush_area(NULL, FLUSH_TLB_GLOBAL);
-- 
2.5.0


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

[Xen-devel] Macvtap on Xen 4.6.6-3.el7

[Naveen Mamindlapalli]

Hi All,

Does Xen Hypervisor support attaching macvtap interface to Xen guest VM?

I am getting following errors when I tried to add interface type =
'direct' in the
guest xml file and start guest VM using virt-manager.

Error starting domain: unsupported configuration: unsupported
interface type direct
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 124, in tmpcb
callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn
ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1489, in startup
self._backend.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1035, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: unsupported configuration: unsupported interface type direct

Guest VM XML file (interface details):

  
  
  
  


[root@hyd1560 ~]# xl info
host   : hyd1560
release: 4.9.58-29.el7.x86_64
version: #1 SMP Mon Oct 23 17:24:36 UTC 2017
machine: x86_64
nr_cpus: 8
max_cpu_id : 7
nr_nodes   : 1
cores_per_socket   : 4
threads_per_core   : 2
cpu_mhz: 3917
hw_caps:
bfebfbff:2c100800::7f00:77fafbff::0121:029c6fbf
virt_caps  : hvm hvm_directio
total_memory   : 16214
free_memory: 13946
sharing_freed_memory   : 0
sharing_used_memory: 0
outstanding_claims : 0
free_cpus  : 0
xen_major  : 4
xen_minor  : 6
xen_extra  : .6-3.el7
xen_version: 4.6.6-3.el7
xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler  : credit
xen_pagesize   : 4096
platform_params: virt_start=0x8000
xen_changeset  : Tue Sep 12 12:14:32 2017 +0100 git:1f48d44-dirty
xen_commandline: placeholder dom0_mem=2048M,max:4096M cpuinfo
com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all
cc_compiler: gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)
cc_compile_by  : mockbuild
cc_compile_domain  : centos.org
cc_compile_date: Tue Sep 12 12:35:50 UTC 2017
xend_config_format : 4


Please let me know if I am doing anything wrong with my configuration.

Thanks and Regards,
Naveen

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail in 115663 
pass in 115707
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail in 115692 pass 
in 115707
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeat  fail pass in 115663
 test-amd64-amd64-xl-qcow219 guest-start/debian.repeat  fail pass in 115692

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop  fail blocked in 114507
 test-amd64-amd64-xl-qemuu-ws16-amd64 13 guest-saverestore fail in 115692 
blocked in 114507
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 115692 like 
114507
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114507
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114507
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114507
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114507
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114507
 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-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-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-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuub0fbe46ad82982b289a44ee2495b59b0bad8a842
baseline version:
 qemuuf90ea7ba7c5ae7010ee0ce062207ae42530f57d6

Last test of basis   114507  2017-10-15 01:03:38 Z   26 days
Failing since114546  2017-10-16 12:16:28 Z   24 days   64 attempts
Testing same since   115657  2017-11-08 01:28:35 Z2 days5 attempts


People who touched revisions under test:
  Aaron Lindsay 
  Alberto Garcia 
  Aleksandr Bezzubikov 
  Alex Bennée 
  Alexey Kardashevskiy 
  Alexey Perevalov 
  Alistair Francis 
  Amarnath Valluri 
  Andreas Färber 
  Andrew Baumann 
  Anthoine Bourgeois 
  Anthony PERARD 
  Artyom Tarasenko 
  Bishara AbuHattoum 

[Xen-devel] [linux-linus test] 115706: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-xsm  broken
 test-amd64-i386-libvirt-xsm   4 host-install(4)broken REGR. vs. 115643
 test-amd64-amd64-xl-pvhv2-amd 20 guest-start/debian.repeat fail REGR. vs. 
115643
 test-amd64-amd64-xl-qcow2   19 guest-start/debian.repeat fail REGR. vs. 115643
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 115643

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 115643
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115643
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115643
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 115643
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115643
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 115643
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 115643
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 115643
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 115643
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeatfail  like 115643
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-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-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-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  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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail 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-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linuxd93d4ce103fdd6c6689e94cfbd0316b027d6ead2
baseline version:
 linuxe4880bc5dfb1f02b152e62a894b5c6f3e995b3cf

Last test of basis   115643  2017-11-07 12:06:20 Z2 days
Failing since115658  2017-11-08 02:33:06 Z2 days4 attempts
Testing same since   115706  2017-11-09 18:45:47 Z0 days1 attempts


People who touched revisions under test:
  Andrey Konovalov 
  Bjorn Andersson 
  Bjørn Mork 
  Borislav Petkov 
  Colin Ian King 
  Cong Wang 
  David Howells 
  David S. Miller 
  Eric Biggers 
  Florian Westphal 
  Ganesh Goudar 

[Xen-devel] [qemu-upstream-unstable test] 115703: regressions - trouble: broken/fail/pass

[osstest service owner]

flight 115703 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115703/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-raw   broken
 test-amd64-i386-xl-raw4 host-install(4)broken REGR. vs. 114457
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs. 
114457
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 114457
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 114457

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

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

version targeted for testing:
 qemuub79708a8ed1b3d18bee67baeaf33b3fa529493e2
baseline version:
 qemuu5cd7ce5dde3f228b3b669ed9ca432f588947bd40

Last test of basis   114457  2017-10-13 09:14:56 Z   27 days
Testing same since   115703  2017-11-09 16:18:53 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Michael Tokarev 
  Roger Pau Monne 
  Roger Pau Monné 
  Stefano Stabellini 

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

[Xen-devel] [linux-3.18 test] 115698: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 115495

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   6 xen-install  fail in 115688 pass in 115698
 test-amd64-amd64-examine4 memdisk-try-append fail in 115688 pass in 115698
 test-amd64-i386-xl-xsm 20 guest-start/debian.repeat fail in 115688 pass in 
115698
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 
115688
 test-amd64-amd64-xl-qcow219 guest-start/debian.repeat  fail pass in 115688

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeatfail like 115495
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 115495
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115495
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115495
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 115495
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 115495
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115495
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 115495
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeatfail  like 115495
 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-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-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-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-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-xl  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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop 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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux943dc0b3ef9f0168494d6dca305cd0cf53a0b3d4
baseline version:
 linux4f823316dac3de3463dfbea2be3812102a76e246

Last test of basis   115495  2017-11-02 19:35:18 Z7 days
Testing same since   115673  2017-11-08 09:43:38 Z1 days3 attempts


People who touched revisions under test:

Re: [Xen-devel] [PATCH v2] x86/hvm: do not register hpet mmio during s3 cycle

[Eric Chanudet]

On 09/11/17 at 01:55am, Jan Beulich wrote:
>Perhaps my prior reply was ambiguous: By "inlining" I meant literally
>inlining it
My apologies for the clumsiness, I can resend a v3 right away.

Thanks,

-- 
Eric Chanudet
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v8 0/5] x86/xen: pvclock vdso support

[Boris Ostrovsky]

On 11/08/2017 12:19 PM, Joao Martins wrote:
> Hey,
>
> This is take 8 for vdso for Xen. PVCLOCK_TSC_STABLE_BIT can be set starting 
> Xen
>  4.8 which is required for vdso time related calls. In order to have it on, 
> you
> need to have the hypervisor clocksource be TSC e.g. with the following boot
> params "clocksource=tsc tsc=stable:socket".
>
> Series is structured as following:
>
> Patch 1 probes for kvm guest in ptp_kvm in the event having
> pvclock_pvti_cpu0_va() moved to common pvclock (on the next patch)
> Patch 2 streamlines pvti page get/set in pvclock for both of its users
> Patch 3,4 registers the pvti page on Xen and sets it in pvclock accordingly
> Patch 5 adds a file to KVM/Xen maintainers for tracking pvclock ABI changes.
>
> All patches appear to be Acked by its respective maintainers.
>
> The difference to v7 is adding the Acks on patches 1 and 2 plus the adjustment
> from Thomas to rename the getter function. (Changelog in individual patches)
>
> Thanks,
> Joao
>
> Joao Martins (5):
>   ptp_kvm: probe for kvm guest availability
>   x86/pvclock: add setter for pvclock_pvti_cpu0_va
>   x86/xen/time: set pvclock flags on xen_time_init()
>   x86/xen/time: setup vcpu 0 time info page
>   MAINTAINERS: xen, kvm: track pvclock-abi.h changes
>
>  MAINTAINERS|  2 +
>  arch/x86/entry/vdso/vma.c  |  2 +-
>  arch/x86/include/asm/pvclock.h | 19 +
>  arch/x86/kernel/kvmclock.c |  7 +--
>  arch/x86/kernel/pvclock.c  | 14 ++
>  arch/x86/xen/suspend.c |  4 ++
>  arch/x86/xen/time.c| 97 
> ++
>  arch/x86/xen/xen-ops.h |  2 +
>  drivers/ptp/ptp_kvm.c  |  5 ++-
>  include/xen/interface/vcpu.h   | 42 ++
>  10 files changed, 177 insertions(+), 17 deletions(-)
>


Applied to for-linus-4.15.

-boris

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

[Xen-devel] [linux-4.1 test] 115693: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 114665
 test-amd64-i386-libvirt-qcow2 18 guest-start.2   fail REGR. vs. 114665

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

Last test of basis   114665  2017-10-17 22:46:39 Z   22 days
Testing same since   115693  2017-11-09 08:22:41 Z0 days1 attempts


People who touched revisions under test:
  Adrian Salido 
  Afzal Mohammed 
  Al Viro 
  Alan Stern 
  Alden Tondettar 
  Alexander Potapenko 
  Alexandre Belloni 
  Alexei Starovoitov 
  Alexey Kodanev 
  Andreas Engel 
  Andreas Gruenbacher 
  Andreas Klinger 
  Andrew Gabbasov 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  3b2966e72c414592cd2c86c21a0d4664cf627b9c
baseline version:
 xen  9862926902ba035a3741afdf03da40a4d4b57a6f

Last test of basis   115676  2017-11-08 13:09:40 Z1 days
Testing same since   115704  2017-11-09 18:22:55 Z0 days1 attempts


People who touched revisions under test:
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  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 osst...@xenbits.xen.org:/home/xen/git/xen.git
   9862926..3b2966e  3b2966e72c414592cd2c86c21a0d4664cf627b9c -> smoke

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs. 
114507

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail in 115663 
pass in 115692
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeat  fail pass in 115663

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 13 guest-saverestore fail blocked in 
114507
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail in 115663 blocked in 
114507
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114507
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114507
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 114507
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114507
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114507
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114507
 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-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-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-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuub0fbe46ad82982b289a44ee2495b59b0bad8a842
baseline version:
 qemuuf90ea7ba7c5ae7010ee0ce062207ae42530f57d6

Last test of basis   114507  2017-10-15 01:03:38 Z   25 days
Failing since114546  2017-10-16 12:16:28 Z   24 days   63 attempts
Testing same since   115657  2017-11-08 01:28:35 Z1 days4 attempts


People who touched revisions under test:
  Aaron Lindsay 
  Alberto Garcia 
  Aleksandr Bezzubikov 
  Alex Bennée 
  Alexey Kardashevskiy 
  Alexey Perevalov 
  Alistair Francis 
  Amarnath Valluri 
  Andreas Färber 
  Andrew Baumann 
  Anthoine Bourgeois 
  Anthony PERARD 
  Artyom Tarasenko 
  Bishara AbuHattoum 
  Carlo 

Re: [Xen-devel] [BUG] blkback reporting incorrect number of sectors, unable to boot

[Mike Reardon]

On Thu, Nov 9, 2017 at 10:03 AM, Roger Pau Monné 
wrote:

> On Thu, Nov 09, 2017 at 08:15:52AM -0700, Mike Reardon wrote:
> > On Thu, Nov 9, 2017 at 2:30 AM, Roger Pau Monné 
> > wrote:
> >
> > > Please try to avoid top-posting.
> > >
> > > On Wed, Nov 08, 2017 at 08:27:17PM -0700, Mike Reardon wrote:
> > > > So am I correct in reading this that for at least the foreseeable
> future
> > > > storage using 4k sector sizes is not gonna happen?  I'm just trying
> to
> > > > figure out if I need to get some different hardware.
> > >
> > > Have you tried to use qdisk instead of blkback for the storage
> > > backend?
> > >
> > > You will have to change your disk configuration line to add
> > > backendtype=qdisk.
> > >
> > > Roger.
> > >
> >
> > Sorry I didn't realize my client was defaulting to top post.
> >
> > If I add that to the disk config line, the system just hangs on the ovmf
> > bios screen.  This appears in the qemu-dm log:
> >
> >
> > xen be: qdisk-51712: xen be: qdisk-51712: error: Failed to get "write"
> lock
> > error: Failed to get "write" lock
> > xen be: qdisk-51712: xen be: qdisk-51712: initialise() failed
> > initialise() failed
>
> Hm, that doesn't seem related to the issue at hand. Adding Anthony and
> Stefano (the QEMU maintainers).
>
> Is there a know issue when booting a HVM guest with qdisk and UEFI?
>
> Roger.
>

So I added the disk to a domU that was running Windows and not using UEFI
and it appears to be working as expected.  The disk shows up, I can
read/write to the disk just fine.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   7 xen-boot fail REGR. vs. 115643

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

version targeted for testing:
 linux87df26175e67c26ccdd3a002fbbb8cde78e28a19
baseline version:
 linuxe4880bc5dfb1f02b152e62a894b5c6f3e995b3cf

Last test of basis   115643  2017-11-07 12:06:20 Z2 days
Failing since115658  2017-11-08 02:33:06 Z1 days3 attempts
Testing same since   115690  2017-11-09 05:54:34 Z0 days1 attempts


People who touched revisions under test:
  Borislav Petkov 
  Colin Ian King 
  David Howells 
  Eric Biggers 
  Hannes Reinecke 
  James Morris 
  Jiri Kosina 
  John Johansen 
  Linus Torvalds 
  Martin K. Petersen 
  Tejun Heo 

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

Re: [Xen-devel] [PATCH v2 2/5] x86: add enum for hypervisors to replace x86_hyper

[Xavier Deguillard]

Hello Juergen,

The changes to vmw_balloon.c looks good.

Acked-by: Xavier Deguillard 

Xavier

On Thu, Nov 09, 2017 at 02:27:36PM +0100, Juergen Gross wrote:
> The x86_hyper pointer is only used for checking whether a virtual
> device is supporting the hypervisor the system is running on.
> 
> Use an enum for that purpose instead and drop the x86_hyper pointer.
> 
> Cc: k...@microsoft.com
> Cc: haiya...@microsoft.com
> Cc: sthem...@microsoft.com
> Cc: akata...@vmware.com
> Cc: pbonz...@redhat.com
> Cc: rkrc...@redhat.com
> Cc: boris.ostrov...@oracle.com
> Cc: de...@linuxdriverproject.org
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: k...@vger.kernel.org
> Cc: xen-de...@lists.xenproject.org
> Cc: linux-graphics-maintai...@vmware.com
> Cc: pv-driv...@vmware.com
> Cc: dmitry.torok...@gmail.com
> Cc: xdeguill...@vmware.com
> Cc: moltm...@vmware.com
> Cc: a...@arndb.de
> Cc: gre...@linuxfoundation.org
> Cc: linux-in...@vger.kernel.org
> 
> Signed-off-by: Juergen Gross 
> ---
>  arch/x86/hyperv/hv_init.c |  2 +-
>  arch/x86/include/asm/hypervisor.h | 23 ++-
>  arch/x86/kernel/cpu/hypervisor.c  | 12 +---
>  arch/x86/kernel/cpu/mshyperv.c|  4 ++--
>  arch/x86/kernel/cpu/vmware.c  |  4 ++--
>  arch/x86/kernel/kvm.c |  4 ++--
>  arch/x86/xen/enlighten_hvm.c  |  4 ++--
>  arch/x86/xen/enlighten_pv.c   |  4 ++--
>  drivers/hv/vmbus_drv.c|  2 +-
>  drivers/input/mouse/vmmouse.c | 10 --
>  drivers/misc/vmw_balloon.c|  2 +-
>  11 files changed, 40 insertions(+), 31 deletions(-)
> 
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index a5db63f728a2..a0b86cf486e0 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -113,7 +113,7 @@ void hyperv_init(void)
>   u64 guest_id;
>   union hv_x64_msr_hypercall_contents hypercall_msr;
>  
> - if (x86_hyper != _hyper_ms_hyperv)
> + if (x86_hyper_type != X86_HYPER_MS_HYPERV)
>   return;
>  
>   /* Allocate percpu VP index */
> diff --git a/arch/x86/include/asm/hypervisor.h 
> b/arch/x86/include/asm/hypervisor.h
> index 0eca7239a7aa..1b0a5abcd8ae 100644
> --- a/arch/x86/include/asm/hypervisor.h
> +++ b/arch/x86/include/asm/hypervisor.h
> @@ -29,6 +29,16 @@
>  /*
>   * x86 hypervisor information
>   */
> +
> +enum x86_hypervisor_type {
> + X86_HYPER_NATIVE = 0,
> + X86_HYPER_VMWARE,
> + X86_HYPER_MS_HYPERV,
> + X86_HYPER_XEN_PV,
> + X86_HYPER_XEN_HVM,
> + X86_HYPER_KVM,
> +};
> +
>  struct hypervisor_x86 {
>   /* Hypervisor name */
>   const char  *name;
> @@ -36,6 +46,9 @@ struct hypervisor_x86 {
>   /* Detection routine */
>   uint32_t(*detect)(void);
>  
> + /* Hypervisor type */
> + enum x86_hypervisor_type type;
> +
>   /* init time callbacks */
>   struct x86_hyper_init init;
>  
> @@ -43,15 +56,7 @@ struct hypervisor_x86 {
>   struct x86_hyper_runtime runtime;
>  };
>  
> -extern const struct hypervisor_x86 *x86_hyper;
> -
> -/* Recognized hypervisors */
> -extern const struct hypervisor_x86 x86_hyper_vmware;
> -extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
> -extern const struct hypervisor_x86 x86_hyper_xen_pv;
> -extern const struct hypervisor_x86 x86_hyper_xen_hvm;
> -extern const struct hypervisor_x86 x86_hyper_kvm;
> -
> +extern enum x86_hypervisor_type x86_hyper_type;
>  extern void init_hypervisor_platform(void);
>  #else
>  static inline void init_hypervisor_platform(void) { }
> diff --git a/arch/x86/kernel/cpu/hypervisor.c 
> b/arch/x86/kernel/cpu/hypervisor.c
> index 6c1bf092..bea8d3e24f50 100644
> --- a/arch/x86/kernel/cpu/hypervisor.c
> +++ b/arch/x86/kernel/cpu/hypervisor.c
> @@ -26,6 +26,12 @@
>  #include 
>  #include 
>  
> +extern const struct hypervisor_x86 x86_hyper_vmware;
> +extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
> +extern const struct hypervisor_x86 x86_hyper_xen_pv;
> +extern const struct hypervisor_x86 x86_hyper_xen_hvm;
> +extern const struct hypervisor_x86 x86_hyper_kvm;
> +
>  static const __initconst struct hypervisor_x86 * const hypervisors[] =
>  {
>  #ifdef CONFIG_XEN_PV
> @@ -41,8 +47,8 @@ static const __initconst struct hypervisor_x86 * const 
> hypervisors[] =
>  #endif
>  };
>  
> -const struct hypervisor_x86 *x86_hyper;
> -EXPORT_SYMBOL(x86_hyper);
> +enum x86_hypervisor_type x86_hyper_type;
> +EXPORT_SYMBOL(x86_hyper_type);
>  
>  static inline const struct hypervisor_x86 * __init
>  detect_hypervisor_vendor(void)
> @@ -87,6 +93,6 @@ void __init init_hypervisor_platform(void)
>   copy_array(>init, _init.hyper, sizeof(h->init));
>   copy_array(>runtime, _platform.hyper, sizeof(h->runtime));
>  
> - x86_hyper = h;
> + x86_hyper_type = h->type;
>   x86_init.hyper.init_platform();
>  }
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index 6bb84d655e4b..85eb5fc180c8 

Re: [Xen-devel] [BUG] blkback reporting incorrect number of sectors, unable to boot

[Anthony PERARD]

On Thu, Nov 09, 2017 at 05:03:18PM +, Roger Pau Monné wrote:
> On Thu, Nov 09, 2017 at 08:15:52AM -0700, Mike Reardon wrote:
> > On Thu, Nov 9, 2017 at 2:30 AM, Roger Pau Monné 
> > wrote:
> > 
> > > Please try to avoid top-posting.
> > >
> > > On Wed, Nov 08, 2017 at 08:27:17PM -0700, Mike Reardon wrote:
> > > > So am I correct in reading this that for at least the foreseeable future
> > > > storage using 4k sector sizes is not gonna happen?  I'm just trying to
> > > > figure out if I need to get some different hardware.
> > >
> > > Have you tried to use qdisk instead of blkback for the storage
> > > backend?
> > >
> > > You will have to change your disk configuration line to add
> > > backendtype=qdisk.
> > >
> > > Roger.
> > >
> > 
> > Sorry I didn't realize my client was defaulting to top post.
> > 
> > If I add that to the disk config line, the system just hangs on the ovmf
> > bios screen.  This appears in the qemu-dm log:
> > 
> > 
> > xen be: qdisk-51712: xen be: qdisk-51712: error: Failed to get "write" lock
> > error: Failed to get "write" lock
> > xen be: qdisk-51712: xen be: qdisk-51712: initialise() failed
> > initialise() failed

:(, I never saw those error messages, maybe we should increase the
verbosity of the qemu backends.

> Hm, that doesn't seem related to the issue at hand. Adding Anthony and
> Stefano (the QEMU maintainers).
> 
> Is there a know issue when booting a HVM guest with qdisk and UEFI?

I know of the issue, I don't know what to do about it yet.

The problem is that QEMU 4.10 have a lock on the disk image. When
booting an HVM guest with a qdisk backend, the disk is open twice, but
can only be locked once, so when the pv disk is been initialized, the
initialisation kind of fail.
Unfortunatly, OVMF will wait indefinitly until the PV disk is
initialized.

-- 
Anthony PERARD

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

Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

[Andrii Anisov]

Dear Oleksandr,


Please consider my `Reviewed-by: Andrii Anisov ` 
for all patches.


What you missed after extracting this stuff from github.


On 09.11.17 19:09, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 


--

*Andrii Anisov*



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

[Xen-devel] [RFC PATCH 31/31] xen/arm: Enable CPUFreq on ARM

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index d46b98c..edd12f8 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -23,6 +23,8 @@ config ARM
select HAS_PASSTHROUGH
select HAS_PDX
select VIDEO
+   select HAS_CPUFREQ
+   select HAS_PM
 
 config ARCH_DEFCONFIG
string
-- 
2.7.4


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

Re: [Xen-devel] [RFC PATCH 07/31] xenpm: Clarify xenpm usage

[Wei Liu]

On Thu, Nov 09, 2017 at 07:09:57PM +0200, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko 
> 
> CPU frequencies are in kHz. So, correct displayed text.
> 
> Signed-off-by: Oleksandr Tyshchenko 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> ---
>  tools/misc/xenpm.c | 6 +++---

Acked-by: Wei Liu 

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

[Xen-devel] [RFC PATCH 23/31] xen/arm: Add Xen changes to mailbox infrastructure

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Modify the direct ported mailbox infrastructure to be
functional inside Xen.

Include "wrappers.h" which contains all required things the direct
ported code relies on.

Important note: the usage of dummy "wait-for-completion" based on
busy loop restricts us from using timer based polling.
So, prevent mailbox controllers (which need polling timer involved)
from being registered.

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/cpufreq/mailbox.c| 51 +--
 xen/arch/arm/cpufreq/mailbox.h| 14 +
 xen/arch/arm/cpufreq/mailbox_client.h | 18 +++
 xen/arch/arm/cpufreq/mailbox_controller.h | 22 +
 4 files changed, 102 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/cpufreq/mailbox.c b/xen/arch/arm/cpufreq/mailbox.c
index 537f4f6..7a34e36 100644
--- a/xen/arch/arm/cpufreq/mailbox.c
+++ b/xen/arch/arm/cpufreq/mailbox.c
@@ -7,8 +7,16 @@
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
+ *
+ * Based on Linux drivers/mailbox/mailbox.c
+ * => commit b7133d6fcd9a9eb4633357d4a27430d4e0c794ad
+ *
+ * Xen modification:
+ * Oleksandr Tyshchenko 
+ * Copyright (C) 2017 EPAM Systems Inc.
  */
 
+#if 0
 #include 
 #include 
 #include 
@@ -20,8 +28,16 @@
 #include 
 #include 
 #include 
+#endif
+
+#include 
+#include 
+#include 
 
 #include "mailbox.h"
+#include "mailbox_client.h"
+#include "mailbox_controller.h"
+#include "wrappers.h"
 
 static LIST_HEAD(mbox_cons);
 static DEFINE_MUTEX(con_mutex);
@@ -85,9 +101,11 @@ static void msg_submit(struct mbox_chan *chan)
 exit:
spin_unlock_irqrestore(>lock, flags);
 
+#if 0 /* We don't support timer based polling. */
if (!err && (chan->txdone_method & TXDONE_BY_POLL))
/* kick start the timer immediately to avoid delays */
hrtimer_start(>mbox->poll_hrt, 0, HRTIMER_MODE_REL);
+#endif
 }
 
 static void tx_tick(struct mbox_chan *chan, int r)
@@ -114,6 +132,7 @@ static void tx_tick(struct mbox_chan *chan, int r)
complete(>tx_complete);
 }
 
+#if 0 /* We don't support timer based polling. */
 static enum hrtimer_restart txdone_hrtimer(struct hrtimer *hrtimer)
 {
struct mbox_controller *mbox =
@@ -139,6 +158,7 @@ static enum hrtimer_restart txdone_hrtimer(struct hrtimer 
*hrtimer)
}
return HRTIMER_NORESTART;
 }
+#endif
 
 /**
  * mbox_chan_received_data - A way for controller driver to push data
@@ -374,7 +394,7 @@ struct mbox_chan *mbox_request_channel_byname(struct 
mbox_client *cl,
  const char *name)
 {
struct device_node *np = cl->dev->of_node;
-   struct property *prop;
+   const struct property *prop;
const char *mbox_name;
int index = 0;
 
@@ -452,13 +472,26 @@ int mbox_controller_register(struct mbox_controller *mbox)
if (!mbox || !mbox->dev || !mbox->ops || !mbox->num_chans)
return -EINVAL;
 
+   /*
+* Unfortunately, here we have to prevent some controllers (which need
+* polling timer involved) from being registered. The possible 
controller
+* must have both TX-Done and RX-Done irqs or to be completely 
synchronous.
+*/
+   if (!mbox->rxdone_auto) {
+   dev_err(mbox->dev, "rx polling method is not supported\n");
+   return -EINVAL;
+   }
+
if (mbox->txdone_irq)
txdone = TXDONE_BY_IRQ;
-   else if (mbox->txdone_poll)
-   txdone = TXDONE_BY_POLL;
+   else if (mbox->txdone_poll) {
+   dev_err(mbox->dev, "tx polling method is not supported\n");
+   return -EINVAL;
+   }
else /* It has to be ACK then */
txdone = TXDONE_BY_ACK;
 
+#if 0 /* We don't support timer based polling. */
if (txdone == TXDONE_BY_POLL) {
 
if (!mbox->ops->last_tx_done) {
@@ -470,6 +503,7 @@ int mbox_controller_register(struct mbox_controller *mbox)
 HRTIMER_MODE_REL);
mbox->poll_hrt.function = txdone_hrtimer;
}
+#endif
 
for (i = 0; i < mbox->num_chans; i++) {
struct mbox_chan *chan = >chans[i];
@@ -509,9 +543,20 @@ void mbox_controller_unregister(struct mbox_controller 
*mbox)
for (i = 0; i < mbox->num_chans; i++)
mbox_free_channel(>chans[i]);
 
+#if 0 /* We don't support timer based polling. */
if (mbox->txdone_poll)
hrtimer_cancel(>poll_hrt);
+#endif
 
mutex_unlock(_mutex);
 }
 EXPORT_SYMBOL_GPL(mbox_controller_unregister);
+
+/*
+ * Local variables:
+ * mode: C
+ * 

[Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Hi, all.

The purpose of this RFC patch series is to add CPUFreq support to Xen on ARM.
Motivation of hypervisor based CPUFreq is to enable one of the main PM 
use-cases in virtualized system powered by Xen hypervisor. Rationale behind 
this activity is that CPU virtualization is done by hypervisor and the guest OS 
doesn't actually know anything about physical CPUs because it is running on 
virtual CPUs. It is quite clear that a decision about frequency change should 
be taken by hypervisor as only it has information about actual CPU load. 
Although these required components (CPUFreq core, governors, etc) already exist 
in Xen, it is worth to mention that they are ACPI specific. So, a part of the 
current patch series makes them more generic in order to make possible a 
CPUFreq usage on architectures without ACPI support in.
But, the main question we have to answer is about frequency changing interface 
in virtualized system. The frequency changing interface and all dependent 
components which needed CPUFreq to be functional on ARM are not present in Xen 
these days. The list of required components is quite big and may change across 
different ARM SoC vendors. As an example, the following components are involved 
in DVFS on Renesas Salvator-X board which has R-Car Gen3 SoC installed: generic 
clock, regulator and thermal frameworks, Vendor’s CPG, PMIC, AVS, THS drivers, 
i2c support, etc.

We were considering a few possible approaches of hypervisor based CPUFreqs on 
ARM and came to conclusion to base this solution on popular at the moment, 
already upstreamed to Linux, ARM System Control and Power Interface(SCPI) 
protocol [1]. We chose SCPI protocol instead of newer ARM System Control and 
Management Interface (SCMI) protocol [2] since it is widely spread in Linux, 
there are good examples how to use it, the range of capabilities it has is 
enough for implementing hypervisor based CPUFreq and, what is more, upstream 
Linux support for SCMI is missed so far, but SCMI could be used as well.

Briefly speaking, the SCPI protocol is used between the System Control 
Processor(SCP) and the Application Processors(AP). The mailbox feature provides 
a mechanism for inter-processor communication between SCP and AP. The main 
purpose of SCP is to offload different PM related tasks from AP and one of the 
services that SCP provides is Dynamic voltage and frequency scaling (DVFS), it 
is what we actually need for CPUFreq. I will describe this approach in details 
down the text.

Let me explain a bit more what these possible approaches are:

1. “Xen+hwdom” solution.
GlobalLogic team proposed split model [3], where “hwdom-cpufreq” frontend 
driver in Xen interacts with the “xen-cpufreq” backend driver in Linux hwdom 
(possibly dom0) in order to scale physical CPUs. This solution hasn’t been 
accepted by Xen community yet and seems it is not going to be accepted without 
taking into the account still unanswered major questions and proving that 
“all-in-Xen” solution, which Xen community considered as more architecturally 
cleaner option, would be unworkable in practice.
The other reasons why we decided not to stick to this approach are complex 
communication interface between Xen and hwdom: event channel, hypercalls, 
syscalls, passing CPU info via DT, etc and possible synchronization issues with 
a proposed solution.
Although it is worth to mention that the beauty of this approach was that there 
wouldn’t be a need to port a lot of things to Xen. All frequency changing 
interface and all dependent components which needed CPUFreq to be functional 
were already in place.
Although this approach is not used, still I picked a few already acked patches 
which made ACPI specific CPUFreq stuff more generic.

2. “all-in-Xen” solution.
This implies that all CPUFreq related stuff should be located in Xen.
Community considered this solution as more architecturally cleaner option than 
“Xen+hwdom” one. No layering violation comparing with the previous approach 
(letting guest OS manage one or more physical CPUs is more of a layering 
violation).
This solution looks better, but to be honest, we are not in favor of this 
solution as well. We expect enormous developing effort to get this support in 
(the scope of required components looks unreal) and maintain it. So, we decided 
not to stick to this approach as well.

3. “Xen+SCP(ARM TF)” solution.
It is yet another solution based on ARM SCPI protocol. The generic idea here is 
that there is a firmware, which being a server runs on some dedicated IP core 
(server), provides different PM services (DVFS, sensors, etc). On the other 
side there is a CPUFreq driver in Xen, which is running on the AP (client), 
consumes these services. CPUFreq driver neither changes the CPU 
frequency/voltage by itself nor cooperates with Linux in order to do such job. 
It just communicates with SCP directly using SCPI protocol. As I said before, 

[Xen-devel] [RFC PATCH 19/31] xen/arm: Introduce ARM SMC based mailbox

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

This code is completely borrowed from the patch series for Linux
which hasn't been upstreamed yet:
[PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox
https://lkml.org/lkml/2017/7/23/129

I am very excited about the idea described it a link above.
This solution lets us (who plays with ARM based SoCs with
Security Extensions enabled, but without possibility to involve
some standalone co-prossesor to control PM) have SCPI based CPUFreq
in Xen on ARM with a minimal cost.

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Andre Przywara 
---
 xen/arch/arm/cpufreq/arm-smc-mailbox.c | 155 +
 1 file changed, 155 insertions(+)
 create mode 100644 xen/arch/arm/cpufreq/arm-smc-mailbox.c

diff --git a/xen/arch/arm/cpufreq/arm-smc-mailbox.c 
b/xen/arch/arm/cpufreq/arm-smc-mailbox.c
new file mode 100644
index 000..d7b61a7
--- /dev/null
+++ b/xen/arch/arm/cpufreq/arm-smc-mailbox.c
@@ -0,0 +1,155 @@
+/*
+ *  Copyright (C) 2016,2017 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This device provides a mechanism for emulating a mailbox by using
+ * smc calls, allowing a "mailbox" consumer to sit in firmware running
+ * on the same core.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ARM_SMC_MBOX_USE_HVC   BIT(0)
+
+struct arm_smc_chan_data {
+   u32 function_id;
+   u32 flags;
+};
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+   struct arm_smc_chan_data *chan_data = link->con_priv;
+   u32 function_id = chan_data->function_id;
+   struct arm_smccc_res res;
+   u32 msg = *(u32 *)data;
+
+   if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
+   arm_smccc_hvc(function_id, msg, 0, 0, 0, 0, 0, 0, );
+   else
+   arm_smccc_smc(function_id, msg, 0, 0, 0, 0, 0, 0, );
+
+   mbox_chan_received_data(link, (void *)res.a0);
+
+   return 0;
+}
+
+/* This mailbox is synchronous, so we are always done. */
+static bool arm_smc_last_tx_done(struct mbox_chan *link)
+{
+   return true;
+}
+
+static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
+   .send_data  = arm_smc_send_data,
+   .last_tx_done   = arm_smc_last_tx_done
+};
+
+static int arm_smc_mbox_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct mbox_controller *mbox;
+   struct arm_smc_chan_data *chan_data;
+   const char *method;
+   bool use_hvc = false;
+   int ret, i;
+
+   ret = of_property_count_elems_of_size(dev->of_node, "arm,func-ids",
+ sizeof(u32));
+   if (ret < 0)
+   return ret;
+
+   if (!of_property_read_string(dev->of_node, "method", )) {
+   if (!strcmp("hvc", method)) {
+   use_hvc = true;
+   } else if (!strcmp("smc", method)) {
+   use_hvc = false;
+   } else {
+   dev_warn(dev, "invalid \"method\" property: %s\n",
+method);
+
+   return -EINVAL;
+   }
+   }
+
+   mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+   if (!mbox)
+   return -ENOMEM;
+
+   mbox->num_chans = ret;
+   mbox->chans = devm_kcalloc(dev, mbox->num_chans, sizeof(*mbox->chans),
+  GFP_KERNEL);
+   if (!mbox->chans)
+   return -ENOMEM;
+
+   chan_data = devm_kcalloc(dev, mbox->num_chans, sizeof(*chan_data),
+GFP_KERNEL);
+   if (!chan_data)
+   return -ENOMEM;
+
+   for (i = 0; i < mbox->num_chans; i++) {
+   u32 function_id;
+
+   ret = of_property_read_u32_index(dev->of_node,
+"arm,func-ids", i,
+_id);
+   if (ret)
+   return ret;
+
+   chan_data[i].function_id = function_id;
+   if (use_hvc)
+   chan_data[i].flags |= ARM_SMC_MBOX_USE_HVC;
+   mbox->chans[i].con_priv = _data[i];
+   }
+
+   mbox->txdone_poll = true;
+   mbox->txdone_irq = false;
+   mbox->txpoll_period = 1;
+   mbox->ops = _smc_mbox_chan_ops;
+   mbox->dev = dev;
+
+   ret = mbox_controller_register(mbox);
+   if (ret)
+   return ret;
+
+   platform_set_drvdata(pdev, mbox);
+   dev_info(dev, "ARM SMC mailbox enabled with %d chan%s.\n",
+mbox->num_chans, mbox->num_chans == 1 ? "" : "s");
+
+   

[Xen-devel] [RFC PATCH 17/31] xen/arm: Add ARM System Control and Power Interface (SCPI) protocol

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

This code is completely borrowed from the Linux. Please see:
http://elixir.free-electrons.com/linux/v4.14-rc6/source/drivers/firmware/arm_scpi.c
http://elixir.free-electrons.com/linux/v4.14-rc6/source/include/linux/scpi_protocol.h

Bindings are here:
http://elixir.free-electrons.com/linux/v4.14-rc6/source/Documentation/devicetree/bindings/arm/arm,scpi.txt

Recent protocol version you can find here:
http://infocenter.arm.com/help/topic/com.arm.doc.dui0922g/scp_message_interface_v1_2_DUI0922G_en.pdf

I port this protocol with having CPUFreq on ARM in mind.

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/cpufreq/arm_scpi.c  | 1085 ++
 xen/arch/arm/cpufreq/scpi_protocol.h |   84 +++
 2 files changed, 1169 insertions(+)
 create mode 100644 xen/arch/arm/cpufreq/arm_scpi.c
 create mode 100644 xen/arch/arm/cpufreq/scpi_protocol.h

diff --git a/xen/arch/arm/cpufreq/arm_scpi.c b/xen/arch/arm/cpufreq/arm_scpi.c
new file mode 100644
index 000..7da9f1b
--- /dev/null
+++ b/xen/arch/arm/cpufreq/arm_scpi.c
@@ -0,0 +1,1085 @@
+/*
+ * System Control and Power Interface (SCPI) Message Protocol driver
+ *
+ * SCPI Message Protocol is used between the System Control Processor(SCP)
+ * and the Application Processors(AP). The Message Handling Unit(MHU)
+ * provides a mechanism for inter-processor communication between SCP's
+ * Cortex M3 and AP.
+ *
+ * SCP offers control and management of the core/cluster power states,
+ * various power domain DVFS including the core/cluster, certain system
+ * clocks configuration, thermal sensors and many others.
+ *
+ * Copyright (C) 2015 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program. If not, see .
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMD_ID_SHIFT   0
+#define CMD_ID_MASK0x7f
+#define CMD_TOKEN_ID_SHIFT 8
+#define CMD_TOKEN_ID_MASK  0xff
+#define CMD_DATA_SIZE_SHIFT16
+#define CMD_DATA_SIZE_MASK 0x1ff
+#define CMD_LEGACY_DATA_SIZE_SHIFT 20
+#define CMD_LEGACY_DATA_SIZE_MASK  0x1ff
+#define PACK_SCPI_CMD(cmd_id, tx_sz)   \
+   cmd_id) & CMD_ID_MASK) << CMD_ID_SHIFT) |   \
+   (((tx_sz) & CMD_DATA_SIZE_MASK) << CMD_DATA_SIZE_SHIFT))
+#define ADD_SCPI_TOKEN(cmd, token) \
+   ((cmd) |= (((token) & CMD_TOKEN_ID_MASK) << CMD_TOKEN_ID_SHIFT))
+#define PACK_LEGACY_SCPI_CMD(cmd_id, tx_sz)\
+   cmd_id) & CMD_ID_MASK) << CMD_ID_SHIFT) |  \
+   (((tx_sz) & CMD_LEGACY_DATA_SIZE_MASK) << CMD_LEGACY_DATA_SIZE_SHIFT))
+
+#define CMD_SIZE(cmd)  (((cmd) >> CMD_DATA_SIZE_SHIFT) & CMD_DATA_SIZE_MASK)
+#define CMD_LEGACY_SIZE(cmd)   (((cmd) >> CMD_LEGACY_DATA_SIZE_SHIFT) & \
+   CMD_LEGACY_DATA_SIZE_MASK)
+#define CMD_UNIQ_MASK  (CMD_TOKEN_ID_MASK << CMD_TOKEN_ID_SHIFT | CMD_ID_MASK)
+#define CMD_XTRACT_UNIQ(cmd)   ((cmd) & CMD_UNIQ_MASK)
+
+#define SCPI_SLOT  0
+
+#define MAX_DVFS_DOMAINS   8
+#define MAX_DVFS_OPPS  16
+#define DVFS_LATENCY(hdr)  (le32_to_cpu(hdr) >> 16)
+#define DVFS_OPP_COUNT(hdr)((le32_to_cpu(hdr) >> 8) & 0xff)
+
+#define PROTOCOL_REV_MINOR_BITS16
+#define PROTOCOL_REV_MINOR_MASK((1U << PROTOCOL_REV_MINOR_BITS) - 1)
+#define PROTOCOL_REV_MAJOR(x)  ((x) >> PROTOCOL_REV_MINOR_BITS)
+#define PROTOCOL_REV_MINOR(x)  ((x) & PROTOCOL_REV_MINOR_MASK)
+
+#define FW_REV_MAJOR_BITS  24
+#define FW_REV_MINOR_BITS  16
+#define FW_REV_PATCH_MASK  ((1U << FW_REV_MINOR_BITS) - 1)
+#define FW_REV_MINOR_MASK  ((1U << FW_REV_MAJOR_BITS) - 1)
+#define FW_REV_MAJOR(x)((x) >> FW_REV_MAJOR_BITS)
+#define FW_REV_MINOR(x)(((x) & FW_REV_MINOR_MASK) >> 
FW_REV_MINOR_BITS)
+#define FW_REV_PATCH(x)((x) & FW_REV_PATCH_MASK)
+
+#define MAX_RX_TIMEOUT (msecs_to_jiffies(30))
+
+enum scpi_error_codes {
+   SCPI_SUCCESS = 0, /* Success */
+   SCPI_ERR_PARAM = 1, /* Invalid parameter(s) */
+   SCPI_ERR_ALIGN = 2, /* Invalid 

[Xen-devel] [RFC PATCH 18/31] xen/arm: Add mailbox infrastructure

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

The mailbox feature is used by the SCPI protocol for inter-processor
communication between System Control Processor(SCP) and Application
Processor(s) (AP). Existing SCPI implementation uses mailbox feature
in common with shared memory region. Actually the mailbox purpose
is to signal a request for some action to be taken by SCP.

This code is completely borrowed from the Linux.
Please see:
http://elixir.free-electrons.com/linux/v4.14-rc6/source/drivers/mailbox/mailbox.c
http://elixir.free-electrons.com/linux/v4.14-rc6/source/drivers/mailbox/mailbox.h
http://elixir.free-electrons.com/linux/v4.14-rc6/source/include/linux/mailbox_client.h
http://elixir.free-electrons.com/linux/v4.14-rc6/source/include/linux/mailbox_controller.h

It is an open question where the common mailbox stuff should be located.

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/cpufreq/mailbox.c| 517 ++
 xen/arch/arm/cpufreq/mailbox.h|  14 +
 xen/arch/arm/cpufreq/mailbox_client.h |  51 +++
 xen/arch/arm/cpufreq/mailbox_controller.h | 134 
 4 files changed, 716 insertions(+)
 create mode 100644 xen/arch/arm/cpufreq/mailbox.c
 create mode 100644 xen/arch/arm/cpufreq/mailbox.h
 create mode 100644 xen/arch/arm/cpufreq/mailbox_client.h
 create mode 100644 xen/arch/arm/cpufreq/mailbox_controller.h

diff --git a/xen/arch/arm/cpufreq/mailbox.c b/xen/arch/arm/cpufreq/mailbox.c
new file mode 100644
index 000..537f4f6
--- /dev/null
+++ b/xen/arch/arm/cpufreq/mailbox.c
@@ -0,0 +1,517 @@
+/*
+ * Mailbox: Common code for Mailbox controllers and users
+ *
+ * Copyright (C) 2013-2014 Linaro Ltd.
+ * Author: Jassi Brar 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mailbox.h"
+
+static LIST_HEAD(mbox_cons);
+static DEFINE_MUTEX(con_mutex);
+
+static int add_to_rbuf(struct mbox_chan *chan, void *mssg)
+{
+   int idx;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+
+   /* See if there is any space left */
+   if (chan->msg_count == MBOX_TX_QUEUE_LEN) {
+   spin_unlock_irqrestore(>lock, flags);
+   return -ENOBUFS;
+   }
+
+   idx = chan->msg_free;
+   chan->msg_data[idx] = mssg;
+   chan->msg_count++;
+
+   if (idx == MBOX_TX_QUEUE_LEN - 1)
+   chan->msg_free = 0;
+   else
+   chan->msg_free++;
+
+   spin_unlock_irqrestore(>lock, flags);
+
+   return idx;
+}
+
+static void msg_submit(struct mbox_chan *chan)
+{
+   unsigned count, idx;
+   unsigned long flags;
+   void *data;
+   int err = -EBUSY;
+
+   spin_lock_irqsave(>lock, flags);
+
+   if (!chan->msg_count || chan->active_req)
+   goto exit;
+
+   count = chan->msg_count;
+   idx = chan->msg_free;
+   if (idx >= count)
+   idx -= count;
+   else
+   idx += MBOX_TX_QUEUE_LEN - count;
+
+   data = chan->msg_data[idx];
+
+   if (chan->cl->tx_prepare)
+   chan->cl->tx_prepare(chan->cl, data);
+   /* Try to submit a message to the MBOX controller */
+   err = chan->mbox->ops->send_data(chan, data);
+   if (!err) {
+   chan->active_req = data;
+   chan->msg_count--;
+   }
+exit:
+   spin_unlock_irqrestore(>lock, flags);
+
+   if (!err && (chan->txdone_method & TXDONE_BY_POLL))
+   /* kick start the timer immediately to avoid delays */
+   hrtimer_start(>mbox->poll_hrt, 0, HRTIMER_MODE_REL);
+}
+
+static void tx_tick(struct mbox_chan *chan, int r)
+{
+   unsigned long flags;
+   void *mssg;
+
+   spin_lock_irqsave(>lock, flags);
+   mssg = chan->active_req;
+   chan->active_req = NULL;
+   spin_unlock_irqrestore(>lock, flags);
+
+   /* Submit next message */
+   msg_submit(chan);
+
+   if (!mssg)
+   return;
+
+   /* Notify the client */
+   if (chan->cl->tx_done)
+   chan->cl->tx_done(chan->cl, mssg, r);
+
+   if (r != -ETIME && chan->cl->tx_block)
+   complete(>tx_complete);
+}
+
+static enum hrtimer_restart txdone_hrtimer(struct hrtimer *hrtimer)
+{
+   struct mbox_controller *mbox =
+   container_of(hrtimer, struct mbox_controller, poll_hrt);
+   bool txdone, resched = false;
+   int i;
+
+   for (i = 0; i < mbox->num_chans; i++) {
+   struct mbox_chan *chan = >chans[i];
+
+   if (chan->active_req && chan->cl) {
+ 

[Xen-devel] [RFC PATCH 12/31] xen/device-tree: Add dt_property_read_string_helper and friends

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

This is a port from Linux.

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/common/device_tree.c  | 27 +++
 xen/include/xen/device_tree.h | 81 +++
 2 files changed, 108 insertions(+)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 7b4cad3..827eadd 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -260,6 +260,33 @@ int dt_property_read_string(const struct dt_device_node 
*np,
 return 0;
 }
 
+int dt_property_read_string_helper(const struct dt_device_node *np,
+   const char *propname, const char **out_strs,
+   size_t sz, int skip)
+{
+const struct dt_property *prop = dt_find_property(np, propname, NULL);
+int l = 0, i = 0;
+const char *p, *end;
+
+if ( !prop )
+return -EINVAL;
+if ( !prop->value )
+return -ENODATA;
+p = prop->value;
+end = p + prop->length;
+
+for ( i = 0; p < end && (!out_strs || i < skip + sz); i++, p += l )
+{
+l = strnlen(p, end - p) + 1;
+if ( p + l > end )
+return -EILSEQ;
+if ( out_strs && i >= skip )
+*out_strs++ = p;
+}
+i -= skip;
+return i <= 0 ? -ENODATA : i;
+}
+
 const char *dt_property_next_string(const struct dt_property *prop,
 const char *cur)
 {
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index e2d7346..7e51a7a 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -440,6 +440,87 @@ int dt_property_read_string(const struct dt_device_node 
*np,
 const char *propname, const char **out_string);
 
 /**
+ * dt_property_read_string_helper() - Utility helper for parsing string 
properties
+ * @np:   device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ * @out_strs: output array of string pointers.
+ * @sz:   number of array elements to read.
+ * @skip: Number of strings to skip over at beginning of list.
+ *
+ * Don't call this function directly. It is a utility helper for the
+ * dt_property_read_string*() family of functions.
+ */
+int dt_property_read_string_helper(const struct dt_device_node *np,
+   const char *propname, const char **out_strs,
+   size_t sz, int skip);
+
+/**
+ * dt_property_read_string_array() - Read an array of strings from a multiple
+ *   strings property.
+ * @np:   device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ * @out_strs: output array of string pointers.
+ * @sz:   number of array elements to read.
+ *
+ * Search for a property in a device tree node and retrieve a list of
+ * terminated string values (pointer to data, not a copy) in that property.
+ *
+ * If @out_strs is NULL, the number of strings in the property is returned.
+ */
+static inline int dt_property_read_string_array(const struct dt_device_node 
*np,
+const char *propname,
+const char **out_strs,
+size_t sz)
+{
+   return dt_property_read_string_helper(np, propname, out_strs, sz, 0);
+}
+
+/**
+ * dt_property_count_strings() - Find and return the number of strings from a
+ *   multiple strings property.
+ * @np:   device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ *
+ * Search for a property in a device tree node and retrieve the number of null
+ * terminated string contain in it. Returns the number of strings on
+ * success, -EINVAL if the property does not exist, -ENODATA if property
+ * does not have a value, and -EILSEQ if the string is not null-terminated
+ * within the length of the property data.
+ */
+static inline int dt_property_count_strings(const struct dt_device_node *np,
+const char *propname)
+{
+   return dt_property_read_string_helper(np, propname, NULL, 0, 0);
+}
+
+/**
+ * dt_property_read_string_index() - Find and read a string from a multiple
+ *   strings property.
+ * @np: device node from which the property value is to be read.
+ * @propname:   name of the property to be searched.
+ * @index:  index of the string in the list of strings
+ * @out_string: pointer to null terminated return string, modified only if
+ *  return value is 0.
+ *
+ * Search for a property in a device tree node and retrieve a null
+ * terminated 

[Xen-devel] [RFC PATCH 15/31] xen/arm: Store device-tree node per cpu

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/smpboot.c| 5 +
 xen/include/xen/device_tree.h | 2 ++
 2 files changed, 7 insertions(+)

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 32e8722..caa126e 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -39,6 +39,7 @@ cpumask_t cpu_present_map;
 cpumask_t cpu_possible_map;
 
 struct cpuinfo_arm cpu_data[NR_CPUS];
+struct dt_device_node *cpu_dt_nodes[NR_CPUS];
 
 /* CPU logical map: map xen cpuid to an MPIDR */
 register_t __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
@@ -110,6 +111,8 @@ static void __init dt_smp_init_cpus(void)
 
 mpidr = boot_cpu_data.mpidr.bits & MPIDR_HWID_MASK;
 
+memset(cpu_dt_nodes, 0, sizeof(cpu_dt_nodes));
+
 if ( !cpus )
 {
 printk(XENLOG_WARNING "WARNING: Can't find /cpus in the device tree.\n"
@@ -211,6 +214,8 @@ static void __init dt_smp_init_cpus(void)
 break;
 }
 
+cpu_dt_nodes[i] = cpu;
+
 if ( (rc = arch_cpu_init(i, cpu)) < 0 )
 {
 printk("cpu%d init failed (hwid %"PRIregister"): %d\n", i, hwid, 
rc);
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 7e51a7a..98933f7 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -920,6 +920,8 @@ int dt_count_phandle_with_args(const struct dt_device_node 
*np,
const char *list_name,
const char *cells_name);
 
+extern struct dt_device_node *cpu_dt_nodes[];
+
 #ifdef CONFIG_DEVICE_TREE_DEBUG
 #define dt_dprintk(fmt, args...)  \
 printk(XENLOG_DEBUG fmt, ## args)
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 13/31] xen/arm: Add driver_data field to struct device

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/include/asm-arm/device.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 6734ae8..3e2f34a 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -20,6 +20,7 @@ struct device
 struct dt_device_node *of_node; /* Used by drivers imported from Linux */
 #endif
 struct dev_archdata archdata;
+void *driver_data;
 };
 
 typedef struct device device_t;
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 26/31] xen/arm: Don't set txdone_poll flag for ARM SMC mailbox

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Don't set txdone_poll flag resulting in TXDONE_BY_POLL method.
It is not optimal to use this method along with the dummy
last_tx_done(), since the controller is completely synchronous.
What is more the TXDONE_BY_POLL method is prohibited because of
involving timer based polling.

This change leads to using TXDONE_BY_ACK method and as the result
the client (SCPI protocol) explicitly ticks the TX state machine.

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Andre Przywara 
---
 xen/arch/arm/cpufreq/arm-smc-mailbox.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/xen/arch/arm/cpufreq/arm-smc-mailbox.c 
b/xen/arch/arm/cpufreq/arm-smc-mailbox.c
index 65d183e..c9fea49 100644
--- a/xen/arch/arm/cpufreq/arm-smc-mailbox.c
+++ b/xen/arch/arm/cpufreq/arm-smc-mailbox.c
@@ -100,15 +100,8 @@ static int arm_smc_send_data(struct mbox_chan *link, void 
*data)
return 0;
 }
 
-/* This mailbox is synchronous, so we are always done. */
-static bool arm_smc_last_tx_done(struct mbox_chan *link)
-{
-   return true;
-}
-
 static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
.send_data  = arm_smc_send_data,
-   .last_tx_done   = arm_smc_last_tx_done
 };
 
 static int arm_smc_mbox_probe(struct platform_device *pdev)
@@ -171,9 +164,8 @@ static int arm_smc_mbox_probe(struct platform_device *pdev)
mbox->chans[i].con_priv = _data[i];
}
 
-   mbox->txdone_poll = true;
+   mbox->txdone_poll = false;
mbox->txdone_irq = false;
-   mbox->txpoll_period = 1;
/*
 * We don't have RX-done irq, but always have received data in hand 
since
 * mailbox is synchronous.
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 08/31] xen/device-tree: Add dt_count_phandle_with_args helper

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.

Signed-off-by: Oleksandr Tyshchenko 
Reviewed-by: Julien Grall 

---
   Changes in v1:
  - Add Julien's reviewed-by

   Changes in v2:
  -
---
 xen/common/device_tree.c  |  7 +++
 xen/include/xen/device_tree.h | 19 +++
 2 files changed, 26 insertions(+)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 7b009ea..60b0095 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -1663,6 +1663,13 @@ int dt_parse_phandle_with_args(const struct 
dt_device_node *np,
 index, out_args);
 }
 
+int dt_count_phandle_with_args(const struct dt_device_node *np,
+   const char *list_name,
+   const char *cells_name)
+{
+return __dt_parse_phandle_with_args(np, list_name, cells_name, 0, -1, 
NULL);
+}
+
 /**
  * unflatten_dt_node - Alloc and populate a device_node from the flat tree
  * @fdt: The parent device tree blob
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 0aecbe0..738f1b6 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -764,6 +764,25 @@ int dt_parse_phandle_with_args(const struct dt_device_node 
*np,
const char *cells_name, int index,
struct dt_phandle_args *out_args);
 
+/**
+ * dt_count_phandle_with_args() - Find the number of phandles references in a 
property
+ * @np: pointer to a device tree node containing a list
+ * @list_name: property name that contains a list
+ * @cells_name: property name that specifies phandles' arguments count
+ *
+ * Returns the number of phandle + argument tuples within a property. It
+ * is a typical pattern to encode a list of phandle and variable
+ * arguments into a single property. The number of arguments is encoded
+ * by a property in the phandle-target node. For example, a gpios
+ * property would contain a list of GPIO specifies consisting of a
+ * phandle and 1 or more arguments. The number of arguments are
+ * determined by the #gpio-cells property in the node pointed to by the
+ * phandle.
+ */
+int dt_count_phandle_with_args(const struct dt_device_node *np,
+   const char *list_name,
+   const char *cells_name);
+
 #ifdef CONFIG_DEVICE_TREE_DEBUG
 #define dt_dprintk(fmt, args...)  \
 printk(XENLOG_DEBUG fmt, ## args)
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 25/31] xen/arm: Use non-blocking mode for SCPI protocol

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Don't block until data is transmitted.
As we are limited to use only two methods TXDONE_BY_IRQ and TXDONE_BY_ACK,
there are two possible scenario:
- If the mailbox controller has TX-done irq it definitely knows when
  transmitted data has been sent and it is responsible for calling
  mbox_chan_txdone() to signal framework about TX-done.
- If controller can't generate TX-Done irq the client has to signal
  TX-done by itself.

So, in case of "ARM SMC mailbox" we explicitly tick the TX state machine
by calling mbox_client_txdone().

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/cpufreq/arm_scpi.c | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/cpufreq/arm_scpi.c b/xen/arch/arm/cpufreq/arm_scpi.c
index 553a516..51a9742 100644
--- a/xen/arch/arm/cpufreq/arm_scpi.c
+++ b/xen/arch/arm/cpufreq/arm_scpi.c
@@ -530,7 +530,7 @@ static void put_scpi_xfer(struct scpi_xfer *t, struct 
scpi_chan *ch)
 static int scpi_send_message(u8 idx, void *tx_buf, unsigned int tx_len,
 void *rx_buf, unsigned int rx_len)
 {
-   int ret;
+   int ret, ret2;
u8 chan;
u8 cmd;
struct scpi_xfer *msg;
@@ -566,21 +566,37 @@ static int scpi_send_message(u8 idx, void *tx_buf, 
unsigned int tx_len,
reinit_completion(>done);
 
ret = mbox_send_message(scpi_chan->chan, msg);
-   if (ret < 0 || !rx_buf)
+   if (ret < 0 || !rx_buf) {
+   /* mbox_send_message returns non-negative value on success */
+   ret2 = ret < 0 ? ret : 0;
goto out;
+   }
 
if (!wait_for_completion_timeout(>done, MAX_RX_TIMEOUT))
ret = -ETIMEDOUT;
else
/* first status word */
ret = msg->status;
+
+   /* SCPI error codes > 0, translate them to Linux scale */
+   ret2 = ret > 0 ? scpi_to_linux_errno(ret) : ret;
+
+   /*
+* If the mailbox controller has TX-done irq it definitely knows when
+* transmitted data has been sent and it is responsible for calling
+* mbox_chan_txdone() to signal framework about TX-done.
+* If controller can't generate TX-Done irq the client has to signal
+* TX-done by itself.
+*/
+   if (!scpi_chan->chan->mbox->txdone_irq)
+   mbox_client_txdone(scpi_chan->chan, ret2);
+
 out:
if (ret < 0 && rx_buf) /* remove entry from the list if timed-out */
scpi_process_cmd(scpi_chan, msg->cmd);
 
put_scpi_xfer(msg, scpi_chan);
-   /* SCPI error codes > 0, translate them to Linux scale*/
-   return ret > 0 ? scpi_to_linux_errno(ret) : ret;
+   return ret2;
 }
 
 static u32 scpi_get_version(void)
@@ -1026,9 +1042,9 @@ static int scpi_probe(struct platform_device *pdev)
cl->dev = dev;
cl->rx_callback = scpi_handle_remote_msg;
cl->tx_prepare = scpi_tx_prepare;
-   cl->tx_block = true;
-   cl->tx_tout = 20;
-   cl->knows_txdone = false; /* controller can't ack */
+   /* Use non-blocking mode for client */
+   cl->tx_block = false;
+   cl->knows_txdone = true;
 
INIT_LIST_HEAD(>rx_pending);
INIT_LIST_HEAD(>xfers_list);
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 30/31] xen/arm: Build CPUFreq components

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/Makefile | 1 +
 xen/arch/arm/cpufreq/Makefile | 5 +
 2 files changed, 6 insertions(+)
 create mode 100644 xen/arch/arm/cpufreq/Makefile

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 282d2c2..fe98570 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -3,6 +3,7 @@ subdir-$(CONFIG_ARM_64) += arm64
 subdir-y += platforms
 subdir-$(CONFIG_ARM_64) += efi
 subdir-$(CONFIG_ACPI) += acpi
+subdir-$(CONFIG_HAS_CPUFREQ) += cpufreq
 
 obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o
 obj-y += bootfdt.init.o
diff --git a/xen/arch/arm/cpufreq/Makefile b/xen/arch/arm/cpufreq/Makefile
new file mode 100644
index 000..9880208
--- /dev/null
+++ b/xen/arch/arm/cpufreq/Makefile
@@ -0,0 +1,5 @@
+obj-y += cpufreq_if.o
+obj-y += scpi_cpufreq.o
+obj-y += arm_scpi.o
+obj-y += mailbox.o
+obj-y += arm-smc-mailbox.o
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 04/31] cpufreq: make turbo settings to be configurable

[Oleksandr Tyshchenko]

From: Oleksandr Dmytryshyn 

This settings is not needed for some architectures.
So make it to be configurable and use it for x86
architecture.

This is a rebased version of the original patch:
https://lists.xen.org/archives/html/xen-devel/2014-11/msg00942.html

Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Oleksandr Tyshchenko 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/x86/Kconfig  |  1 +
 xen/drivers/cpufreq/Kconfig   |  3 +++
 xen/drivers/cpufreq/utility.c | 11 ++-
 xen/drivers/pm/stat.c |  6 ++
 xen/include/xen/cpufreq.h |  6 ++
 5 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 86c8eca..c1eac1d 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -24,6 +24,7 @@ config X86
select NUMA
select VGA
select HAS_PM
+   select HAS_CPU_TURBO
 
 config ARCH_DEFCONFIG
string
diff --git a/xen/drivers/cpufreq/Kconfig b/xen/drivers/cpufreq/Kconfig
index cce80f4..427ea2a 100644
--- a/xen/drivers/cpufreq/Kconfig
+++ b/xen/drivers/cpufreq/Kconfig
@@ -1,3 +1,6 @@
 
 config HAS_CPUFREQ
bool
+
+config HAS_CPU_TURBO
+   bool
diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
index a687e5a..25bf983 100644
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -209,7 +209,9 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy 
*policy,
 {
 unsigned int min_freq = ~0;
 unsigned int max_freq = 0;
+#ifdef CONFIG_HAS_CPU_TURBO
 unsigned int second_max_freq = 0;
+#endif
 unsigned int i;
 
 for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
@@ -221,6 +223,7 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy 
*policy,
 if (freq > max_freq)
 max_freq = freq;
 }
+#ifdef CONFIG_HAS_CPU_TURBO
 for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
 unsigned int freq = table[i].frequency;
 if (freq == CPUFREQ_ENTRY_INVALID || freq == max_freq)
@@ -234,9 +237,13 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy 
*policy,
 printk("max_freq: %usecond_max_freq: %u\n",
max_freq, second_max_freq);
 
+policy->cpuinfo.second_max_freq = second_max_freq;
+#else /* !CONFIG_HAS_CPU_TURBO */
+if (cpufreq_verbose)
+printk("max_freq: %u\n", max_freq);
+#endif /* CONFIG_HAS_CPU_TURBO */
 policy->min = policy->cpuinfo.min_freq = min_freq;
 policy->max = policy->cpuinfo.max_freq = max_freq;
-policy->cpuinfo.second_max_freq = second_max_freq;
 
 if (policy->min == ~0)
 return -EINVAL;
@@ -390,6 +397,7 @@ int cpufreq_driver_getavg(unsigned int cpu, unsigned int 
flag)
 return policy->cur;
 }
 
+#ifdef CONFIG_HAS_CPU_TURBO
 int cpufreq_update_turbo(int cpuid, int new_state)
 {
 struct cpufreq_policy *policy;
@@ -430,6 +438,7 @@ int cpufreq_get_turbo_status(int cpuid)
 policy = per_cpu(cpufreq_cpu_policy, cpuid);
 return policy && policy->turbo == CPUFREQ_TURBO_ENABLED;
 }
+#endif /* CONFIG_HAS_CPU_TURBO */
 
 /*
  * POLICY*
diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
index 2dbde1c..133e64d 100644
--- a/xen/drivers/pm/stat.c
+++ b/xen/drivers/pm/stat.c
@@ -290,7 +290,11 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
 >u.get_para.u.ondemand.sampling_rate,
 >u.get_para.u.ondemand.up_threshold);
 }
+#ifdef CONFIG_HAS_CPU_TURBO
 op->u.get_para.turbo_enabled = cpufreq_get_turbo_status(op->cpuid);
+#else
+op->u.get_para.turbo_enabled = 0;
+#endif
 
 return ret;
 }
@@ -473,6 +477,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
 break;
 }
 
+#ifdef CONFIG_HAS_CPU_TURBO
 case XEN_SYSCTL_pm_op_enable_turbo:
 {
 ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_ENABLED);
@@ -484,6 +489,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
 ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_DISABLED);
 break;
 }
+#endif /* CONFIG_HAS_CPU_TURBO */
 
 default:
 printk("not defined sub-hypercall @ do_pm_op\n");
diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
index 30c70c9..2e0c16a 100644
--- a/xen/include/xen/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -39,7 +39,9 @@ extern struct acpi_cpufreq_data *cpufreq_drv_data[NR_CPUS];
 
 struct cpufreq_cpuinfo {
 unsigned intmax_freq;
+#ifdef CONFIG_HAS_CPU_TURBO
 unsigned intsecond_max_freq;/* P1 if Turbo Mode is on */
+#endif
 unsigned intmin_freq;
 unsigned int

[Xen-devel] [RFC PATCH 20/31] xen/arm: Add common header file wrappers.h

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

This header file is intended to keep various Linux2Xen wrappers,
define-s, stubs which used by all direct ported CPUfreq components.

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/cpufreq/wrappers.h | 239 
 1 file changed, 239 insertions(+)
 create mode 100644 xen/arch/arm/cpufreq/wrappers.h

diff --git a/xen/arch/arm/cpufreq/wrappers.h b/xen/arch/arm/cpufreq/wrappers.h
new file mode 100644
index 000..284faa4
--- /dev/null
+++ b/xen/arch/arm/cpufreq/wrappers.h
@@ -0,0 +1,239 @@
+/*
+ * xen/arch/arm/cpufreq/wrappers.h
+ *
+ * This header file contains Linux2Xen wrappers, define-s, different stubs
+ * which used by all direct ported CPUfreq components.
+ *
+ * Oleksandr Tyshchenko 
+ * Copyright (c) 2017 EPAM Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ */
+
+#ifndef __ARCH_ARM_CPUFREQ_WRAPPERS_H__
+#define __ARCH_ARM_CPUFREQ_WRAPPERS_H__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Xen doesn't have mutex, so use spinlock instead. */
+#define mutexspinlock
+#define mutex_lock   spin_lock
+#define mutex_unlock spin_unlock
+#define mutex_init   spin_lock_init
+#define DEFINE_MUTEX DEFINE_SPINLOCK
+
+/* Aliases to Xen allocation helpers. */
+#define devm_kmalloc(dev, size, flags)_xmalloc(size, sizeof(void *))
+#define devm_kzalloc(dev, size, flags)_xzalloc(size, sizeof(void *))
+#define devm_kcalloc(dev, n, size, flags) _xzalloc_array(size, sizeof(void *), 
n)
+#define kmalloc(size, flags)  _xmalloc(size, sizeof(void *))
+#define kcalloc(size, n, flags)   _xzalloc_array(size, sizeof(void *), 
n)
+#define devm_kfree(dev, p)xfree(p)
+#define kfree xfree
+
+/* Aliases to Xen device tree helpers. */
+#define device_node dt_device_node
+#define platform_device dt_device_node
+#define of_device_iddt_device_match
+#define of_match_node   dt_match_node
+#define of_property_count_elems_of_size dt_property_count_elems_of_size
+#define of_property_read_u32_index  dt_property_read_u32_index
+#define of_property_for_each_string dt_property_for_each_string
+#define of_parse_phandle_with_args  dt_parse_phandle_with_args
+#define of_count_phandle_with_args  dt_count_phandle_with_args
+#define of_property_read_string dt_property_read_string
+#define of_parse_phandledt_parse_phandle
+#define of_phandle_args dt_phandle_args
+#define of_get_property dt_get_property
+#define propertydt_property
+
+static inline const struct of_device_id *of_match_device(
+const struct of_device_id *matches, const struct device *dev)
+{
+if ( !matches || !dev->of_node )
+return NULL;
+
+return of_match_node(matches, dev->of_node);
+}
+
+/* Stuff to deal with device address ranges. */
+struct resource
+{
+u64 start;
+u64 size;
+};
+
+#define resource_size(res) (res)->size;
+
+static inline int of_address_to_resource(struct device_node *node, int index,
+ struct resource *res)
+{
+return dt_device_get_address(node, index, >start, >size);
+}
+
+typedef u64 resource_size_t;
+
+#define devm_ioremap(dev, addr, size) ioremap_nocache(addr, size)
+#define devm_iounmap(dev, addr)   iounmap(addr)
+
+/* Device logger functions */
+#define dev_print(dev, lvl, fmt, ...)\
+printk(lvl "scpi: %s: " fmt, dt_node_full_name(dev_to_dt(dev)), ## 
__VA_ARGS__)
+
+#define dev_info(dev, fmt, ...) dev_print(dev, XENLOG_INFO, fmt, ## 
__VA_ARGS__)
+#define dev_dbg(dev, fmt, ...)  dev_print(dev, XENLOG_DEBUG, fmt, ## 
__VA_ARGS__)
+#define dev_warn(dev, fmt, ...) dev_print(dev, XENLOG_WARNING, fmt, ## 
__VA_ARGS__)
+#define dev_err(dev, fmt, ...)  dev_print(dev, XENLOG_ERR, fmt, ## __VA_ARGS__)
+
+#define pr_debug  printk
+#define _dev_info dev_info
+
+/* Helpers to get/set driver specific info. */
+static inline void platform_set_drvdata(struct platform_device *pdev, void 
*data)
+{
+pdev->dev.driver_data = data;
+}
+
+static inline void *platform_get_drvdata(const struct platform_device *pdev)
+{
+

[Xen-devel] [RFC PATCH 28/31] xen/arm: Introduce SCPI based CPUFreq driver

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

This patch adds a CPUFreq driver for controlling CPUs DVFS feature
provided by System Control Processor (SCP) using SCPI protocol
for inter-processor communication.

The important point is that unlike Linux Xen doesn't have
clock infrastructure and clocks for the CPUs (DVFS clocks)
provided by SCP are managed by this driver directly using
DVFS operations over power domains the controlled CPUs are part of.

Non-arch specific driver code is mostly borrowed from
the x86 ACPI CPUFreq.

Most important TODOs regarding the whole patch series:
1. Handle devm in the direct ported code. Currently, in case of any
   errors previously allocated resources are left unfreed.
2. Thermal management integration.
3. Don't pass CPUFreq related nodes to dom0. Xen owns SCPI completely.
4. Handle CPU_TURBO frequencies.

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/cpufreq/scpi_cpufreq.c | 328 
 1 file changed, 328 insertions(+)
 create mode 100644 xen/arch/arm/cpufreq/scpi_cpufreq.c

diff --git a/xen/arch/arm/cpufreq/scpi_cpufreq.c 
b/xen/arch/arm/cpufreq/scpi_cpufreq.c
new file mode 100644
index 000..bcd8889
--- /dev/null
+++ b/xen/arch/arm/cpufreq/scpi_cpufreq.c
@@ -0,0 +1,328 @@
+/*
+ * xen/arch/arm/cpufreq/scpi_cpufreq.c
+ *
+ * SCPI based CPUFreq driver
+ *
+ * Based on Xen arch/x86/acpi/cpufreq/cpufreq.c
+ *
+ * Oleksandr Tyshchenko 
+ * Copyright (c) 2017 EPAM Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "scpi_protocol.h"
+
+extern struct device *get_cpu_device(unsigned int cpu);
+
+struct scpi_cpufreq_data
+{
+struct processor_performance *perf;
+struct cpufreq_frequency_table *freq_table;
+struct scpi_dvfs_info *info; /* DVFS capabilities of the CPU's power 
domain */
+int domain; /* power domain id this CPU belongs to */
+};
+
+static struct scpi_cpufreq_data *cpufreq_driver_data[NR_CPUS];
+
+static struct cpufreq_driver scpi_cpufreq_driver;
+
+static struct scpi_ops *scpi_ops;
+
+static unsigned int scpi_cpufreq_get(unsigned int cpu)
+{
+struct scpi_cpufreq_data *data;
+struct cpufreq_policy *policy;
+const struct scpi_opp *opp;
+int idx;
+
+if ( cpu >= nr_cpu_ids || !cpu_online(cpu) )
+return 0;
+
+policy = per_cpu(cpufreq_cpu_policy, cpu);
+if ( !policy || !(data = cpufreq_driver_data[policy->cpu]) ||
+ !data->info )
+return 0;
+
+idx = scpi_ops->dvfs_get_idx(data->domain);
+if ( idx < 0 )
+return 0;
+
+opp = data->info->opps + idx;
+
+/* Convert Hz -> kHz */
+return opp->freq / 1000;
+}
+
+static int scpi_cpufreq_target(struct cpufreq_policy *policy,
+   unsigned int target_freq, unsigned int relation)
+{
+struct scpi_cpufreq_data *data = cpufreq_driver_data[policy->cpu];
+struct processor_performance *perf;
+struct cpufreq_freqs freqs;
+cpumask_t online_policy_cpus;
+unsigned int next_state = 0; /* Index into freq_table */
+unsigned int next_perf_state = 0; /* Index into perf table */
+unsigned int j;
+int result;
+const struct scpi_opp *opp;
+int idx, max_opp;
+
+if ( unlikely(!data) || !data->perf || !data->freq_table || !data->info )
+return -ENODEV;
+
+perf = data->perf;
+result = cpufreq_frequency_table_target(policy,
+data->freq_table,
+target_freq,
+relation, _state);
+if ( unlikely(result) )
+return -ENODEV;
+
+cpumask_and(_policy_cpus, _online_map, policy->cpus);
+
+next_perf_state = data->freq_table[next_state].index;
+if ( perf->state == next_perf_state )
+{
+if ( unlikely(policy->resume) )
+policy->resume = 0;
+else
+return 0;
+}
+
+/* Convert MHz -> kHz */
+freqs.old = perf->states[perf->state].core_frequency * 1000;
+freqs.new = data->freq_table[next_state].frequency;
+
+/* Find corresponding index */
+max_opp = data->info->count;
+opp = data->info->opps;
+for ( idx = 

[Xen-devel] [RFC PATCH 29/31] xen/arm: Introduce CPUFreq Interface component

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

This patch adds an interface component which performs following steps:
1. Initialize everything needed SCPI based CPUFreq driver to be functional
   (SCPI Message protocol, mailbox to communicate with SCP, etc).
   Also preliminary check if SCPI DVFS clock nodes offered by SCP are
   present in a device tree.
2. Register SCPI based CPUFreq driver.
3. Populate CPUs. Get DVFS info (OPP list and the latency information)
   for all DVFS capable CPUs using SCPI protocol, convert these capabilities
   into PM data the CPUFreq framework expects to see followed by
   uploading it.

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/cpufreq/cpufreq_if.c | 522 ++
 1 file changed, 522 insertions(+)
 create mode 100644 xen/arch/arm/cpufreq/cpufreq_if.c

diff --git a/xen/arch/arm/cpufreq/cpufreq_if.c 
b/xen/arch/arm/cpufreq/cpufreq_if.c
new file mode 100644
index 000..2451d00
--- /dev/null
+++ b/xen/arch/arm/cpufreq/cpufreq_if.c
@@ -0,0 +1,522 @@
+/*
+ * xen/arch/arm/cpufreq/cpufreq_if.c
+ *
+ * CPUFreq interface component
+ *
+ * Oleksandr Tyshchenko 
+ * Copyright (c) 2017 EPAM Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "scpi_protocol.h"
+
+/*
+ * TODO:
+ * 1. Add __init to required funcs
+ * 2. Put get_cpu_device() into common place
+ */
+
+static struct scpi_ops *scpi_ops;
+
+extern int scpi_cpufreq_register_driver(void);
+
+#define dev_name(dev) dt_node_full_name(dev_to_dt(dev))
+
+struct device *get_cpu_device(unsigned int cpu)
+{
+if ( cpu < nr_cpu_ids && cpu_possible(cpu) )
+return dt_to_dev(cpu_dt_nodes[cpu]);
+else
+return NULL;
+}
+
+static bool is_dvfs_capable(unsigned int cpu)
+{
+static const struct dt_device_match scpi_dvfs_clock_match[] =
+{
+DT_MATCH_COMPATIBLE("arm,scpi-dvfs-clocks"),
+{ /* sentinel */ },
+};
+struct device *cpu_dev;
+struct dt_phandle_args clock_spec;
+struct scpi_dvfs_info *info;
+u32 domain;
+int i, ret, count;
+
+cpu_dev = get_cpu_device(cpu);
+if ( !cpu_dev )
+{
+printk("cpu%d: failed to get device\n", cpu);
+return false;
+}
+
+/* First of all find a clock node this CPU is a consumer of */
+ret = dt_parse_phandle_with_args(cpu_dev->of_node,
+ "clocks",
+ "#clock-cells",
+ 0,
+ _spec);
+if ( ret )
+{
+printk("cpu%d: failed to get clock node\n", cpu);
+return false;
+}
+
+/* Make sure it is an available DVFS clock node */
+if ( !dt_match_node(scpi_dvfs_clock_match, clock_spec.np) ||
+ !dt_device_is_available(clock_spec.np) )
+{
+printk("cpu%d: clock node '%s' is either non-DVFS or non-available\n",
+   cpu, dev_name(_spec.np->dev));
+return false;
+}
+
+/*
+ * Actually we already have a power domain id this CPU belongs to,
+ * it is a stored in args[0] CPU clock specifier, so we could ask SCP
+ * to provide its DVFS info. But we want to dig a little bit deeper
+ * to make sure that everything is correct.
+ */
+
+/* Check how many clock ids a DVFS clock node has */
+ret = dt_property_count_elems_of_size(clock_spec.np,
+  "clock-indices",
+  sizeof(u32));
+if ( ret < 0 )
+{
+printk("cpu%d: failed to get clock-indices count in '%s'\n",
+   cpu, dev_name(_spec.np->dev));
+return false;
+}
+count = ret;
+
+/* Check if a clock id the CPU clock specifier points to is present */
+for ( i = 0; i < count; i++ )
+{
+ret = dt_property_read_u32_index(clock_spec.np,
+ "clock-indices",
+ i,
+ );
+if ( ret )
+{
+printk("cpu%d: failed to get clock index in '%s'\n",
+   cpu, dev_name(_spec.np->dev));
+return false;
+}
+
+

[Xen-devel] [RFC PATCH 27/31] cpufreq: hack: perf->states isn't a real guest handle on ARM

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

This patch is just a temp solution to highlight a problem which
should be resolved in a proper way.

set_px_pminfo() is intended to be called from platform hypercall
where "perf" argument was entirely filled in by hwdom.

But unlike x86 we don't get this info from hwdom on ARM,
we get it from other sources (device tree + firmware). In order to
retain function interface, we emulate receiving hypercall and
pass argument which function expects to see. Although "perf->states"
looks like a guest handle it is not a real handle and we can't use
copy_from_guest() over it. As only scpi-cpufreq sets XEN_PX_DATA flag
use it as an indicator to do memcpy.

Signed-off-by: Oleksandr Tyshchenko 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/drivers/cpufreq/cpufreq.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index 64e1ae7..1022cd1 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -558,11 +558,22 @@ int set_px_pminfo(uint32_t acpi_id, struct 
xen_processor_performance *dom0_px_in
 ret = -ENOMEM;
 goto out;
 }
-if ( copy_from_guest(pxpt->states, dom0_px_info->states,
- dom0_px_info->state_count) )
+
+if ( dom0_px_info->flags == XEN_PX_DATA )
 {
-ret = -EFAULT;
-goto out;
+struct xen_processor_px *states = (dom0_px_info->states).p;
+
+memcpy(pxpt->states, states,
+   dom0_px_info->state_count * sizeof(struct 
xen_processor_px));
+}
+else
+{
+if ( copy_from_guest(pxpt->states, dom0_px_info->states,
+ dom0_px_info->state_count) )
+{
+ret = -EFAULT;
+goto out;
+}
 }
 pxpt->state_count = dom0_px_info->state_count;
 
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 24/31] xen/arm: Add Xen changes to ARM SMC based mailbox

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Modify the direct ported ARM SMC based mailbox to be
functional inside Xen.

Include "wrappers.h" which contains all required things the direct
ported code relies on.

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Andre Przywara 
---
 xen/arch/arm/cpufreq/arm-smc-mailbox.c | 101 +
 1 file changed, 101 insertions(+)

diff --git a/xen/arch/arm/cpufreq/arm-smc-mailbox.c 
b/xen/arch/arm/cpufreq/arm-smc-mailbox.c
index d7b61a7..65d183e 100644
--- a/xen/arch/arm/cpufreq/arm-smc-mailbox.c
+++ b/xen/arch/arm/cpufreq/arm-smc-mailbox.c
@@ -8,14 +8,73 @@
  * This device provides a mechanism for emulating a mailbox by using
  * smc calls, allowing a "mailbox" consumer to sit in firmware running
  * on the same core.
+ *
+ * Based on patch series which hasn't reach upstream yet:
+ * => https://lkml.org/lkml/2017/7/23/129
+ *[PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox
+ *
+ * Xen modification:
+ * Oleksandr Tyshchenko 
+ * Copyright (C) 2017 EPAM Systems Inc.
  */
 
+#if 0
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#endif
+
+#include 
+#include 
+#include 
+
+#include "mailbox_controller.h"
+#include "wrappers.h"
+
+/*
+ * TODO:
+ * 1. Add releasing resources since devm.
+ */
+
+struct arm_smccc_res {
+   unsigned long a0;
+   unsigned long a1;
+   unsigned long a2;
+   unsigned long a3;
+};
+
+/* This is just to align interfaces. */
+static inline void arm_smccc_smc(unsigned long a0, unsigned long a1,
+   unsigned long a2, unsigned long a3, unsigned long a4,
+   unsigned long a5, unsigned long a6, unsigned long a7,
+   struct arm_smccc_res *res)
+{
+   register_t ret[4] = { 0 };
+
+   call_smccc_smc(a0, a1, a2, a3, a4, a5, a6, a7, ret);
+
+   res->a0 = ret[0];
+   res->a1 = ret[1];
+   res->a2 = ret[2];
+   res->a3 = ret[3];
+}
+
+static inline void arm_smccc_hvc(unsigned long a0, unsigned long a1,
+   unsigned long a2, unsigned long a3, unsigned long a4,
+   unsigned long a5, unsigned long a6, unsigned long a7,
+   struct arm_smccc_res *res)
+{
+   /*
+* We should never get here since the "use_hvc" flag is always false
+* (smc is only allowed method).
+   */
+   BUG();
+}
+
+/* Start of Linux code */
 
 #define ARM_SMC_MBOX_USE_HVC   BIT(0)
 
@@ -69,6 +128,9 @@ static int arm_smc_mbox_probe(struct platform_device *pdev)
if (!of_property_read_string(dev->of_node, "method", )) {
if (!strcmp("hvc", method)) {
use_hvc = true;
+
+   dev_warn(dev,"method must be smc\n");
+   return -EINVAL;
} else if (!strcmp("smc", method)) {
use_hvc = false;
} else {
@@ -112,6 +174,11 @@ static int arm_smc_mbox_probe(struct platform_device *pdev)
mbox->txdone_poll = true;
mbox->txdone_irq = false;
mbox->txpoll_period = 1;
+   /*
+* We don't have RX-done irq, but always have received data in hand 
since
+* mailbox is synchronous.
+*/
+   mbox->rxdone_auto = true;
mbox->ops = _smc_mbox_chan_ops;
mbox->dev = dev;
 
@@ -126,6 +193,7 @@ static int arm_smc_mbox_probe(struct platform_device *pdev)
return ret;
 }
 
+#if 0
 static int arm_smc_mbox_remove(struct platform_device *pdev)
 {
struct mbox_controller *mbox = platform_get_drvdata(pdev);
@@ -133,6 +201,7 @@ static int arm_smc_mbox_remove(struct platform_device *pdev)
mbox_controller_unregister(mbox);
return 0;
 }
+#endif
 
 static const struct of_device_id arm_smc_mbox_of_match[] = {
{ .compatible = "arm,smc-mbox", },
@@ -140,6 +209,7 @@ static const struct of_device_id arm_smc_mbox_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, arm_smc_mbox_of_match);
 
+#if 0
 static struct platform_driver arm_smc_mbox_driver = {
.driver = {
.name = "arm-smc-mbox",
@@ -153,3 +223,34 @@ module_platform_driver(arm_smc_mbox_driver);
 MODULE_AUTHOR("Andre Przywara ");
 MODULE_DESCRIPTION("Generic ARM smc mailbox driver");
 MODULE_LICENSE("GPL v2");
+#endif
+
+/* End of Linux code */
+
+static int __init arm_smc_mbox_init(struct dt_device_node *dev,
+   const void *data)
+{
+   int ret;
+
+   ret = arm_smc_mbox_probe(dev);
+   if (ret) {
+   dev_err(>dev, "failed to init ARM SMC mailbox (%d)\n", 
ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+DT_DEVICE_START(arm_smc_mbox, "ARM SMC mailbox", DEVICE_MAILBOX)
+   .dt_match = arm_smc_mbox_of_match,
+   .init = arm_smc_mbox_init,
+DT_DEVICE_END

[Xen-devel] [RFC PATCH 10/31] xen/device-tree: Add dt_property_read_u32_index helper

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

This is a port from Linux.

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/common/device_tree.c  | 52 +++
 xen/include/xen/device_tree.h | 20 +
 2 files changed, 72 insertions(+)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 08f8072..0fa654e 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -176,6 +176,58 @@ bool_t dt_property_read_u32(const struct dt_device_node 
*np,
 return 1;
 }
 
+/**
+ * dt_find_property_value_of_size
+ *
+ * @np:   device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ * @min:  minimum allowed length of property value
+ * @max:  maximum allowed length of property value (0 means unlimited)
+ * @len:  if !=NULL, actual length is written to here
+ *
+ * Search for a property in a device node and valid the requested size.
+ * Returns the property value on success, -EINVAL if the property does not
+ * exist, -ENODATA if property does not have a value, and -EOVERFLOW if the
+ * property data is too small or too large.
+ */
+static void *dt_find_property_value_of_size(const struct dt_device_node *np,
+const char *propname,
+u32 min, u32 max, size_t *len)
+{
+const struct dt_property *prop = dt_find_property(np, propname, NULL);
+
+if ( !prop )
+return ERR_PTR(-EINVAL);
+if ( !prop->value )
+return ERR_PTR(-ENODATA);
+if ( prop->length < min )
+return ERR_PTR(-EOVERFLOW);
+if ( max && prop->length > max )
+return ERR_PTR(-EOVERFLOW);
+
+if ( len )
+*len = prop->length;
+
+return prop->value;
+}
+
+int dt_property_read_u32_index(const struct dt_device_node *np,
+   const char *propname,
+   u32 index, u32 *out_value)
+{
+const u32 *val =
+dt_find_property_value_of_size(np, propname,
+   ((index + 1) * sizeof(*out_value)),
+   0,
+   NULL);
+
+if ( IS_ERR(val) )
+return PTR_ERR(val);
+
+*out_value = be32_to_cpup(((__be32 *)val) + index);
+
+return 0;
+}
 
 bool_t dt_property_read_u64(const struct dt_device_node *np,
  const char *name, u64 *out_value)
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 9e0931c..87b4b67 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -374,6 +374,26 @@ const struct dt_property *dt_find_property(const struct 
dt_device_node *np,
  */
 bool_t dt_property_read_u32(const struct dt_device_node *np,
 const char *name, u32 *out_value);
+
+/**
+ * dt_property_read_u32_index - Find and read a u32 from a multi-value 
property.
+ *
+ * @np:device node from which the property value is to be read.
+ * @propname:  name of the property to be searched.
+ * @index: index of the u32 in the list of values
+ * @out_value: pointer to return value, modified only if no error.
+ *
+ * Search for a property in a device node and read nth 32-bit value from
+ * it. Returns 0 on success, -EINVAL if the property does not exist,
+ * -ENODATA if property does not have a value, and -EOVERFLOW if the
+ * property data isn't large enough.
+ *
+ * The out_value is modified only if a valid u32 value can be decoded.
+ */
+int dt_property_read_u32_index(const struct dt_device_node *np,
+   const char *propname,
+   u32 index, u32 *out_value);
+
 /**
  * dt_property_read_u64 - Helper to read a u64 property.
  * @np: node to get the value
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 21/31] xen/arm: Add rxdone_auto flag to mbox_controller structure

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

This patch adds a flag which indicates if mailbox controller doesn't
need to poll for received data. It either has RX done irq for signaling
when received data are ready or received data 'appears' right after
transmitted data has been sent (synchronous case).

The purpose of this flag is to help framework to recognize
and then restrict a registration of controllers which need to use
timer based polling for received data.

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/cpufreq/mailbox_controller.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/arm/cpufreq/mailbox_controller.h 
b/xen/arch/arm/cpufreq/mailbox_controller.h
index 74deadb..05c6e45 100644
--- a/xen/arch/arm/cpufreq/mailbox_controller.h
+++ b/xen/arch/arm/cpufreq/mailbox_controller.h
@@ -64,6 +64,10 @@ struct mbox_chan_ops {
  * @txdone_poll:   If the controller can read but not report the TX
  * done. Ex, some register shows the TX status but
  * no interrupt rises. Ignored if 'txdone_irq' is set.
+ * @rxdone_auto:   Indicates if controller doesn't need to poll for
+ * received data. It either has RX done irq for signaling 
when
+ * received data are ready or received data 'appears' 
right after
+ * transmitted data has been sent (synchronous case).
  * @txpoll_period: If 'txdone_poll' is in effect, the API polls for
  * last TX's status after these many millisecs
  * @of_xlate:  Controller driver specific mapping of channel via DT
@@ -78,6 +82,7 @@ struct mbox_controller {
int num_chans;
bool txdone_irq;
bool txdone_poll;
+   bool rxdone_auto;
unsigned txpoll_period;
struct mbox_chan *(*of_xlate)(struct mbox_controller *mbox,
  const struct of_phandle_args *sp);
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 16/31] arm: add SMC wrapper that is compatible with SMCCC

[Oleksandr Tyshchenko]

From: Volodymyr Babchuk 

Existing SMC wrapper call_smc() allows only 4 parameters and
returns only one value. This is enough for existing
use in PSCI code, but TEE mediator will need a call that is
fully compatible with ARM SMCCC.
This patch adds this call for both arm32 and arm64.

There was similar patch by Edgar E. Iglesias ([1]), but looks
like it is abandoned.

[1] https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00636.html

CC: "Edgar E. Iglesias" 

Signed-off-by: Volodymyr Babchuk 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/arm32/Makefile |  1 +
 xen/arch/arm/arm32/smc.S| 32 
 xen/arch/arm/arm64/Makefile |  1 +
 xen/arch/arm/arm64/smc.S| 29 +
 xen/include/asm-arm/processor.h |  4 
 5 files changed, 67 insertions(+)
 create mode 100644 xen/arch/arm/arm32/smc.S
 create mode 100644 xen/arch/arm/arm64/smc.S

diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index 0ac254f..a2362f3 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -8,6 +8,7 @@ obj-y += insn.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
 obj-y += proc-v7.o proc-caxx.o
 obj-y += smpboot.o
+obj-y += smc.o
 obj-y += traps.o
 obj-y += vfp.o
 
diff --git a/xen/arch/arm/arm32/smc.S b/xen/arch/arm/arm32/smc.S
new file mode 100644
index 000..1cc9528
--- /dev/null
+++ b/xen/arch/arm/arm32/smc.S
@@ -0,0 +1,32 @@
+/*
+ * xen/arch/arm/arm32/smc.S
+ *
+ * Wrapper for Secure Monitors Calls
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+/*
+ * void call_smccc_smc(register_t a0, register_t a1, register_t a2,
+ * register_t a3, register_t a4, register_t a5,
+ * register_t a6, register_t a7, register_t res[4])
+ */
+ENTRY(call_smccc_smc)
+mov r12, sp
+push{r4-r7}
+ldm r12, {r4-r7}
+smc #0
+pop {r4-r7}
+ldr r12, [sp, #(4 * 4)]
+stm r12, {r0-r3}
+bx  lr
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 149b6b3..7831dc1 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -8,5 +8,6 @@ obj-y += entry.o
 obj-y += insn.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o
 obj-y += smpboot.o
+obj-y += smc.o
 obj-y += traps.o
 obj-y += vfp.o
diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S
new file mode 100644
index 000..aa44fba
--- /dev/null
+++ b/xen/arch/arm/arm64/smc.S
@@ -0,0 +1,29 @@
+/*
+ * xen/arch/arm/arm64/smc.S
+ *
+ * Wrapper for Secure Monitors Calls
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+/*
+ * void call_smccc_smc(register_t a0, register_t a1, register_t a2,
+ * register_t a3, register_t a4, register_t a5,
+ * register_t a6, register_t a7, register_t res[4])
+ */
+ENTRY(call_smccc_smc)
+smc #0
+ldr x4, [sp]
+stp x0, x1, [x4, 0]
+stp x2, x3, [x4, 16]
+ret
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 9f7a42f..4ce5bb6 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -786,6 +786,10 @@ void vcpu_regs_user_to_hyp(struct vcpu *vcpu,
 int call_smc(register_t function_id, register_t arg0, register_t arg1,
  register_t arg2);
 
+void call_smccc_smc(register_t a0, register_t a1, register_t a2,
+register_t a3, register_t a4, register_t a5,
+register_t a6, register_t a7, register_t res[4]);
+
 void do_trap_hyp_serror(struct cpu_user_regs *regs);
 
 void do_trap_guest_serror(struct cpu_user_regs *regs);
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 06/31] cpufreq: make cpufreq driver more generalizable

[Oleksandr Tyshchenko]

From: Oleksandr Dmytryshyn 

First implementation of the cpufreq driver has been
written with x86 in mind. This patch makes possible
the cpufreq driver be working on both x86 and arm
architectures.

This is a rebased version of the original patch:
https://lists.xen.org/archives/html/xen-devel/2014-11/msg00932.html

Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Oleksandr Tyshchenko 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/drivers/cpufreq/cpufreq.c| 81 +---
 xen/include/public/platform.h|  1 +
 xen/include/xen/processor_perf.h |  6 +++
 3 files changed, 82 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index ab909e2..64e1ae7 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -42,7 +42,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 static unsigned int __read_mostly usr_min_freq;
@@ -206,6 +205,7 @@ int cpufreq_add_cpu(unsigned int cpu)
 } else {
 /* domain sanity check under whatever coordination type */
 firstcpu = cpumask_first(cpufreq_dom->map);
+#ifdef CONFIG_ACPI
 if ((perf->domain_info.coord_type !=
 processor_pminfo[firstcpu]->perf.domain_info.coord_type) ||
 (perf->domain_info.num_processors !=
@@ -221,6 +221,19 @@ int cpufreq_add_cpu(unsigned int cpu)
 );
 return -EINVAL;
 }
+#else /* !CONFIG_ACPI */
+if ((perf->domain_info.num_processors !=
+processor_pminfo[firstcpu]->perf.domain_info.num_processors)) {
+
+printk(KERN_WARNING "cpufreq fail to add CPU%d:"
+   "incorrect num processors (%"PRIu64"), "
+   "expect(%"PRIu64")\n",
+   cpu, perf->domain_info.num_processors,
+   processor_pminfo[firstcpu]->perf.domain_info.num_processors
+);
+return -EINVAL;
+}
+#endif /* CONFIG_ACPI */
 }
 
 if (!domexist || hw_all) {
@@ -380,6 +393,7 @@ int cpufreq_del_cpu(unsigned int cpu)
 return 0;
 }
 
+#ifdef CONFIG_ACPI
 static void print_PCT(struct xen_pct_register *ptr)
 {
 printk("\t_PCT: descriptor=%d, length=%d, space_id=%d, "
@@ -387,12 +401,14 @@ static void print_PCT(struct xen_pct_register *ptr)
ptr->descriptor, ptr->length, ptr->space_id, ptr->bit_width,
ptr->bit_offset, ptr->reserved, ptr->address);
 }
+#endif /* CONFIG_ACPI */
 
 static void print_PSS(struct xen_processor_px *ptr, int count)
 {
 int i;
 printk("\t_PSS: state_count=%d\n", count);
 for (i=0; inum_entries, ptr->revision, ptr->domain, ptr->coord_type,
ptr->num_processors);
+#else /* !CONFIG_ACPI */
+printk("\t_PSD:  domain=%"PRId64" num_processors=%"PRId64"\n",
+   ptr->domain, ptr->num_processors);
+#endif /* CONFIG_ACPI */
 }
 
 static void print_PPC(unsigned int platform_limit)
@@ -418,13 +445,53 @@ static void print_PPC(unsigned int platform_limit)
 printk("\t_PPC: %d\n", platform_limit);
 }
 
+static inline bool is_pss_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+return px->flags & XEN_PX_PSS;
+#else
+return px->flags == XEN_PX_DATA;
+#endif
+}
+
+static inline bool is_psd_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+return px->flags & XEN_PX_PSD;
+#else
+return px->flags == XEN_PX_DATA;
+#endif
+}
+
+static inline bool is_ppc_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+return px->flags & XEN_PX_PPC;
+#else
+return px->flags == XEN_PX_DATA;
+#endif
+}
+
+static inline bool is_all_data(struct xen_processor_performance *px)
+{
+#ifdef CONFIG_ACPI
+return px->flags == ( XEN_PX_PCT | XEN_PX_PSS | XEN_PX_PSD | XEN_PX_PPC );
+#else
+return px->flags == XEN_PX_DATA;
+#endif
+}
+
 int set_px_pminfo(uint32_t acpi_id, struct xen_processor_performance 

[Xen-devel] [RFC PATCH 14/31] xen/arm: Add DEVICE_MAILBOX device class

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/include/asm-arm/device.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 3e2f34a..e8ce338 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -36,6 +36,7 @@ enum device_class
 DEVICE_SERIAL,
 DEVICE_IOMMU,
 DEVICE_GIC,
+DEVICE_MAILBOX,
 /* Use for error */
 DEVICE_UNKNOWN,
 };
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 22/31] xen/arm: Add Xen changes to SCPI protocol

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

Modify the direct ported SCPI Message Protocol driver to be
functional inside Xen.

As SCPI Message protocol driver expects mailbox to be registed,
find and initialize mailbox before probing it.

Include "wrappers.h" which contains all required things the direct
ported code relies on.

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/arch/arm/cpufreq/arm_scpi.c  | 90 
 xen/arch/arm/cpufreq/scpi_protocol.h | 32 +
 2 files changed, 122 insertions(+)

diff --git a/xen/arch/arm/cpufreq/arm_scpi.c b/xen/arch/arm/cpufreq/arm_scpi.c
index 7da9f1b..553a516 100644
--- a/xen/arch/arm/cpufreq/arm_scpi.c
+++ b/xen/arch/arm/cpufreq/arm_scpi.c
@@ -23,8 +23,16 @@
  *
  * You should have received a copy of the GNU General Public License along
  * with this program. If not, see .
+ *
+ * Based on Linux drivers/firmware/arm_scpi.c
+ * => commit 0d30176819c8738b012ec623c7b3db19df818e70
+ *
+ * Xen modification:
+ * Oleksandr Tyshchenko 
+ * Copyright (C) 2017 EPAM Systems Inc.
  */
 
+#if 0
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
@@ -44,6 +52,22 @@
 #include 
 #include 
 #include 
+#endif
+
+#include 
+#include 
+#include 
+#include 
+
+#include "scpi_protocol.h"
+#include "mailbox_client.h"
+#include "mailbox_controller.h"
+#include "wrappers.h"
+
+/*
+ * TODO:
+ * 1. Add releasing resources since devm.
+ */
 
 #define CMD_ID_SHIFT   0
 #define CMD_ID_MASK0x7f
@@ -859,6 +883,7 @@ static int scpi_init_versions(struct scpi_drvinfo *info)
return ret;
 }
 
+#if 0
 static ssize_t protocol_version_show(struct device *dev,
 struct device_attribute *attr, char *buf)
 {
@@ -888,6 +913,7 @@ static struct attribute *versions_attrs[] = {
NULL,
 };
 ATTRIBUTE_GROUPS(versions);
+#endif
 
 static void
 scpi_free_channels(struct device *dev, struct scpi_chan *pchan, int count)
@@ -909,8 +935,10 @@ static int scpi_remove(struct platform_device *pdev)
 
scpi_info = NULL; /* stop exporting SCPI ops through get_scpi_ops */
 
+#if 0
of_platform_depopulate(dev);
sysfs_remove_groups(>kobj, versions_groups);
+#endif
scpi_free_channels(dev, info->channels, info->num_chans);
platform_set_drvdata(pdev, NULL);
 
@@ -1055,11 +1083,15 @@ err:
  FW_REV_PATCH(scpi_info->firmware_version));
scpi_info->scpi_ops = _ops;
 
+#if 0
ret = sysfs_create_groups(>kobj, versions_groups);
if (ret)
dev_err(dev, "unable to create sysfs version group\n");
 
return of_platform_populate(dev->of_node, NULL, NULL, dev);
+#else
+   return 0;
+#endif
 }
 
 static const struct of_device_id scpi_of_match[] = {
@@ -1070,6 +1102,7 @@ static const struct of_device_id scpi_of_match[] = {
 
 MODULE_DEVICE_TABLE(of, scpi_of_match);
 
+#if 0
 static struct platform_driver scpi_driver = {
.driver = {
.name = "scpi_protocol",
@@ -1083,3 +1116,60 @@ module_platform_driver(scpi_driver);
 MODULE_AUTHOR("Sudeep Holla ");
 MODULE_DESCRIPTION("ARM SCPI mailbox protocol driver");
 MODULE_LICENSE("GPL v2");
+#endif
+
+static struct device *scpi_dev;
+
+struct device *get_scpi_dev(void)
+{
+   return scpi_dev;
+}
+
+int __init scpi_init(void)
+{
+   struct dt_device_node *scpi, *mbox;
+   bool has_mbox = false;
+   int ret = -ENODEV;
+
+   scpi = dt_find_matching_node(NULL, scpi_of_match);
+   if (!scpi) {
+   printk("failed to find SCPI node in the device tree\n");
+   return -ENXIO;
+   }
+
+   /* At first find and initialize mailbox to communicate with SCP */
+   dt_for_each_device_node(dt_host, mbox) {
+   ret = device_init(mbox, DEVICE_MAILBOX, NULL);
+   if (!ret) {
+   has_mbox = true;
+   break;
+   }
+   }
+
+   if (!has_mbox) {
+   dev_err(>dev, "failed to init Mailbox interface (%d)\n", 
ret);
+   return ret;
+   }
+
+   ret = scpi_probe(scpi);
+   if (ret) {
+   /* TODO Do we need to deinit mailbox? */
+   dev_err(>dev, "failed to init SCPI Message Protocol 
(%d)\n", ret);
+   return ret;
+   }
+
+   scpi_dev = >dev;
+
+   /* TODO Do we need to mark device as used by Xen? */
+
+   return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 8
+ * indent-tabs-mode: t
+ * End:
+ */
diff --git a/xen/arch/arm/cpufreq/scpi_protocol.h 
b/xen/arch/arm/cpufreq/scpi_protocol.h
index 327d656..0f6dab3 100644
--- a/xen/arch/arm/cpufreq/scpi_protocol.h
+++ b/xen/arch/arm/cpufreq/scpi_protocol.h
@@ -14,8 

[Xen-devel] [RFC PATCH 01/31] cpufreq: move cpufreq.h file to the xen/include/xen location

[Oleksandr Tyshchenko]

From: Oleksandr Dmytryshyn 

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

This is a rebased version of the original patch:
https://lists.xen.org/archives/html/xen-devel/2014-11/msg00938.html

Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Oleksandr Tyshchenko 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 MAINTAINERS  |   1 +
 xen/arch/x86/acpi/cpu_idle.c |   2 +-
 xen/arch/x86/acpi/cpufreq/cpufreq.c  |   2 +-
 xen/arch/x86/acpi/cpufreq/powernow.c |   2 +-
 xen/arch/x86/acpi/power.c|   2 +-
 xen/arch/x86/cpu/mwait-idle.c|   2 +-
 xen/drivers/acpi/pmstat.c|   2 +-
 xen/drivers/cpufreq/cpufreq.c|   2 +-
 xen/drivers/cpufreq/cpufreq_misc_governors.c |   2 +-
 xen/drivers/cpufreq/cpufreq_ondemand.c   |   4 +-
 xen/drivers/cpufreq/utility.c|   2 +-
 xen/include/acpi/cpufreq/cpufreq.h   | 245 --
 xen/include/xen/cpufreq.h| 248 +++
 13 files changed, 260 insertions(+), 256 deletions(-)
 delete mode 100644 xen/include/acpi/cpufreq/cpufreq.h
 create mode 100644 xen/include/xen/cpufreq.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 5b9e123..524e067 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -295,6 +295,7 @@ X:  xen/arch/x86/acpi/boot.c
 X: xen/arch/x86/acpi/lib.c
 F: xen/drivers/cpufreq/
 F: xen/include/acpi/cpufreq/
+F: xen/include/xen/cpufreq.h
 
 PUBLIC I/O INTERFACES AND PV DRIVERS DESIGNS
 M:  Konrad Rzeszutek Wilk 
diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 482b8a7..c66622e 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -49,7 +49,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c 
b/xen/arch/x86/acpi/cpufreq/cpufreq.c
index 1f8d02a..bd82025 100644
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -41,7 +41,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 enum {
 UNDEFINED_CAPABLE = 0,
diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c 
b/xen/arch/x86/acpi/cpufreq/powernow.c
index 8f1ac74..79f55a3 100644
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -35,7 +35,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #define CPUID_FREQ_VOLT_CAPABILITIES0x8007
 #define CPB_CAPABLE 0x0200
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 1e4e568..beebd5a 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -28,7 +28,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 uint32_t system_reset_counter = 1;
 
diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
index 762dff1..29f0286 100644
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -58,7 +58,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #define MWAIT_IDLE_VERSION "0.4.1"
 #undef PREFIX
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
index 2a6c4c7..2dbde1c 100644
--- a/xen/drivers/acpi/pmstat.c
+++ b/xen/drivers/acpi/pmstat.c
@@ -38,7 +38,7 @@
 #include 
 
 #include 
-#include 
+#include 
 #include 
 
 DEFINE_PER_CPU_READ_MOSTLY(struct pm_px *, cpufreq_statistic_data);
diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index 212f48f..ab909e2 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -43,7 +43,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 static unsigned int __read_mostly usr_min_freq;
 static unsigned int __read_mostly usr_max_freq;
diff --git a/xen/drivers/cpufreq/cpufreq_misc_governors.c 
b/xen/drivers/cpufreq/cpufreq_misc_governors.c
index 746bbcd..4a5510c 100644
--- a/xen/drivers/cpufreq/cpufreq_misc_governors.c
+++ b/xen/drivers/cpufreq/cpufreq_misc_governors.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 /*
  * cpufreq userspace governor
diff --git a/xen/drivers/cpufreq/cpufreq_ondemand.c 
b/xen/drivers/cpufreq/cpufreq_ondemand.c
index fe6c63d..1c384ec 100644
--- a/xen/drivers/cpufreq/cpufreq_ondemand.c
+++ b/xen/drivers/cpufreq/cpufreq_ondemand.c
@@ -1,5 +1,5 @@
 /*
- *  xen/arch/x86/acpi/cpufreq/cpufreq_ondemand.c
+ *  xen/drivers/cpufreq/cpufreq_ondemand.c
  *
  *  Copyright (C)  2001 Russell King
  *(C)  2003 Venkatesh Pallipadi .
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 

[Xen-devel] [RFC PATCH 02/31] pm: move processor_perf.h file to the xen/include/xen location

[Oleksandr Tyshchenko]

From: Oleksandr Dmytryshyn 

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

This is a rebased version of the original patch:
https://lists.xen.org/archives/html/xen-devel/2014-11/msg00934.html

Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Oleksandr Tyshchenko 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 MAINTAINERS   |  2 +-
 xen/arch/x86/platform_hypercall.c |  2 +-
 xen/include/acpi/cpufreq/processor_perf.h | 63 ---
 xen/include/xen/cpufreq.h |  2 +-
 xen/include/xen/processor_perf.h  | 63 +++
 5 files changed, 66 insertions(+), 66 deletions(-)
 delete mode 100644 xen/include/acpi/cpufreq/processor_perf.h
 create mode 100644 xen/include/xen/processor_perf.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 524e067..9794a81 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -294,8 +294,8 @@ F:  xen/arch/x86/acpi/
 X: xen/arch/x86/acpi/boot.c
 X: xen/arch/x86/acpi/lib.c
 F: xen/drivers/cpufreq/
-F: xen/include/acpi/cpufreq/
 F: xen/include/xen/cpufreq.h
+F: xen/include/xen/processor_perf.h
 
 PUBLIC I/O INTERFACES AND PV DRIVERS DESIGNS
 M:  Konrad Rzeszutek Wilk 
diff --git a/xen/arch/x86/platform_hypercall.c 
b/xen/arch/x86/platform_hypercall.c
index ebc2f39..17c8304 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -25,7 +25,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/acpi/cpufreq/processor_perf.h 
b/xen/include/acpi/cpufreq/processor_perf.h
deleted file mode 100644
index d8a1ba6..000
--- a/xen/include/acpi/cpufreq/processor_perf.h
+++ /dev/null
@@ -1,63 +0,0 @@
-#ifndef __XEN_PROCESSOR_PM_H__
-#define __XEN_PROCESSOR_PM_H__
-
-#include 
-#include 
-#include 
-
-#define XEN_PX_INIT 0x8000
-
-int powernow_cpufreq_init(void);
-unsigned int powernow_register_driver(void);
-unsigned int get_measured_perf(unsigned int cpu, unsigned int flag);
-void cpufreq_residency_update(unsigned int, uint8_t);
-void cpufreq_statistic_update(unsigned int, uint8_t, uint8_t);
-int  cpufreq_statistic_init(unsigned int);
-void cpufreq_statistic_exit(unsigned int);
-void cpufreq_statistic_reset(unsigned int);
-
-int  cpufreq_limit_change(unsigned int);
-
-int  cpufreq_add_cpu(unsigned int);
-int  cpufreq_del_cpu(unsigned int);
-
-struct processor_performance {
-uint32_t state;
-uint32_t platform_limit;
-struct xen_pct_register control_register;
-struct xen_pct_register status_register;
-uint32_t state_count;
-struct xen_processor_px *states;
-struct xen_psd_package domain_info;
-uint32_t shared_type;
-
-uint32_t init;
-};
-
-struct processor_pminfo {
-uint32_t acpi_id;
-uint32_t id;
-struct processor_performanceperf;
-};
-
-extern struct processor_pminfo *processor_pminfo[NR_CPUS];
-
-struct px_stat {
-uint8_t total;/* total Px states */
-uint8_t usable;   /* usable Px states */
-uint8_t last; /* last Px state */
-uint8_t cur;  /* current Px state */
-uint64_t *trans_pt;   /* Px transition table */
-pm_px_val_t *pt;
-};
-
-struct pm_px {
-struct px_stat u;
-uint64_t prev_state_wall;
-uint64_t prev_idle_wall;
-};
-
-DECLARE_PER_CPU(struct pm_px *, cpufreq_statistic_data);
-
-int cpufreq_cpu_init(unsigned int cpuid);
-#endif /* __XEN_PROCESSOR_PM_H__ */
diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
index ed38a6c..30c70c9 100644
--- a/xen/include/xen/cpufreq.h
+++ b/xen/include/xen/cpufreq.h
@@ -21,7 +21,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 DECLARE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
 
diff --git a/xen/include/xen/processor_perf.h b/xen/include/xen/processor_perf.h
new file mode 100644
index 000..d8a1ba6
--- /dev/null
+++ b/xen/include/xen/processor_perf.h
@@ -0,0 +1,63 @@
+#ifndef __XEN_PROCESSOR_PM_H__
+#define __XEN_PROCESSOR_PM_H__
+
+#include 
+#include 
+#include 
+
+#define XEN_PX_INIT 0x8000
+
+int powernow_cpufreq_init(void);
+unsigned int powernow_register_driver(void);
+unsigned int get_measured_perf(unsigned int cpu, unsigned int flag);
+void cpufreq_residency_update(unsigned int, uint8_t);
+void cpufreq_statistic_update(unsigned int, uint8_t, uint8_t);
+int  cpufreq_statistic_init(unsigned int);
+void cpufreq_statistic_exit(unsigned int);
+void cpufreq_statistic_reset(unsigned int);
+
+int  cpufreq_limit_change(unsigned int);
+
+int  cpufreq_add_cpu(unsigned int);
+int  cpufreq_del_cpu(unsigned int);
+
+struct processor_performance {
+uint32_t state;
+ 

[Xen-devel] [RFC PATCH 11/31] xen/device-tree: Add dt_property_count_elems_of_size helper

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

This is a port from Linux.

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/common/device_tree.c  | 20 
 xen/include/xen/device_tree.h | 15 +++
 2 files changed, 35 insertions(+)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 0fa654e..7b4cad3 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -278,6 +278,26 @@ const char *dt_property_next_string(const struct 
dt_property *prop,
 return curv;
 }
 
+int dt_property_count_elems_of_size(const struct dt_device_node *np,
+const char *propname, int elem_size)
+{
+const struct dt_property *prop = dt_find_property(np, propname, NULL);
+
+if ( !prop )
+return -EINVAL;
+if ( !prop->value )
+return -ENODATA;
+
+if ( prop->length % elem_size != 0 )
+{
+printk("%s: size of %s is not a multiple of %d\n", np->full_name,
+   propname, elem_size);
+return -EINVAL;
+}
+
+return prop->length / elem_size;
+}
+
 bool_t dt_device_is_compatible(const struct dt_device_node *device,
const char *compat)
 {
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 87b4b67..e2d7346 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -461,6 +461,21 @@ const char *dt_property_next_string(const struct 
dt_property *prop,
 s = dt_property_next_string(prop, s))
 
 /**
+ * dt_property_count_elems_of_size - Count the number of elements in a property
+ *
+ * @np:device node from which the property value is to be read.
+ * @propname:  name of the property to be searched.
+ * @elem_size: size of the individual element
+ *
+ * Search for a property in a device node and count the number of elements of
+ * size elem_size in it. Returns number of elements on sucess, -EINVAL if the
+ * property does not exist or its length does not match a multiple of elem_size
+ * and -ENODATA if the property does not have a value.
+ */
+int dt_property_count_elems_of_size(const struct dt_device_node *np,
+const char *propname, int elem_size);
+
+/**
  * Checks if the given "compat" string matches one of the strings in
  * the device's "compatible" property
  */
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 05/31] pmstat: make pmstat functions more generalizable

[Oleksandr Tyshchenko]

From: Oleksandr Dmytryshyn 

ACPI-specific parts are moved under appropriate ifdefs.
Now pmstat functions can be used in ARM platform.

This is a rebased version of the original patch:
https://lists.xen.org/archives/html/xen-devel/2014-11/msg00941.html

Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Oleksandr Tyshchenko 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/drivers/pm/stat.c| 8 +++-
 xen/include/xen/pmstat.h | 2 ++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
index 133e64d..986ba41 100644
--- a/xen/drivers/pm/stat.c
+++ b/xen/drivers/pm/stat.c
@@ -35,7 +35,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -132,6 +131,8 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
 break;
 }
 
+/* For now those operations can be used only when ACPI is enabled */
+#ifdef CONFIG_ACPI
 case PMSTAT_get_max_cx:
 {
 op->u.getcx.nr = pmstat_get_cx_nr(op->cpuid);
@@ -150,6 +151,7 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
 ret = pmstat_reset_cx_stat(op->cpuid);
 break;
 }
+#endif /* CONFIG_ACPI */
 
 default:
 printk("not defined sub-hypercall @ do_get_pm_info\n");
@@ -465,6 +467,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
 break;
 }
 
+#ifdef CONFIG_ACPI
 case XEN_SYSCTL_pm_op_get_max_cstate:
 {
 op->u.get_max_cstate = acpi_get_cstate_limit();
@@ -476,6 +479,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
 acpi_set_cstate_limit(op->u.set_max_cstate);
 break;
 }
+#endif /* CONFIG_ACPI */
 
 #ifdef CONFIG_HAS_CPU_TURBO
 case XEN_SYSCTL_pm_op_enable_turbo:
@@ -500,6 +504,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
 return ret;
 }
 
+#ifdef CONFIG_ACPI
 int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
 {
 u32 bits[3];
@@ -530,3 +535,4 @@ int acpi_set_pdc_bits(u32 acpi_id, 
XEN_GUEST_HANDLE_PARAM(uint32) pdc)
 
 return ret;
 }
+#endif /* CONFIG_ACPI */
diff --git a/xen/include/xen/pmstat.h b/xen/include/xen/pmstat.h
index 266bc16..a870c8a 100644
--- a/xen/include/xen/pmstat.h
+++ b/xen/include/xen/pmstat.h
@@ -6,10 +6,12 @@
 #include/* for struct pm_cx_stat */
 
 int set_px_pminfo(uint32_t cpu, struct xen_processor_performance *perf);
+#ifdef CONFIG_ACPI
 long set_cx_pminfo(uint32_t cpu, struct xen_processor_power *power);
 uint32_t pmstat_get_cx_nr(uint32_t cpuid);
 int pmstat_get_cx_stat(uint32_t cpuid, struct pm_cx_stat *stat);
 int pmstat_reset_cx_stat(uint32_t cpuid);
+#endif
 
 int do_get_pm_info(struct xen_sysctl_get_pmstat *op);
 int do_pm_op(struct xen_sysctl_pm_op *op);
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 09/31] xen/device-tree: Add dt_property_for_each_string macros

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

This is a port from Linux.

Signed-off-by: Oleksandr Tyshchenko 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/common/device_tree.c  | 18 ++
 xen/include/xen/device_tree.h | 21 +
 2 files changed, 39 insertions(+)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 60b0095..08f8072 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -208,6 +208,24 @@ int dt_property_read_string(const struct dt_device_node 
*np,
 return 0;
 }
 
+const char *dt_property_next_string(const struct dt_property *prop,
+const char *cur)
+{
+const void *curv = cur;
+
+if ( !prop )
+return NULL;
+
+if ( !cur )
+return prop->value;
+
+curv += strlen(cur) + 1;
+if ( curv >= prop->value + prop->length )
+return NULL;
+
+return curv;
+}
+
 bool_t dt_device_is_compatible(const struct dt_device_node *device,
const char *compat)
 {
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 738f1b6..9e0931c 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -420,6 +420,27 @@ int dt_property_read_string(const struct dt_device_node 
*np,
 const char *propname, const char **out_string);
 
 /**
+ * dt_property_for_each_string - Iterate over an array of strings within
+ * a property with a given name for a given node.
+ *
+ * Example:
+ *
+ * struct dt_property *prop;
+ * const char *s;
+ *
+ * dt_property_for_each_string(np, "propname", prop, s)
+ * printk("String value: %s\n", s);
+ */
+const char *dt_property_next_string(const struct dt_property *prop,
+const char *cur);
+
+#define dt_property_for_each_string(np, propname, prop, s)\
+for (prop = dt_find_property(np, propname, NULL), \
+s = dt_property_next_string(prop, NULL);  \
+s;\
+s = dt_property_next_string(prop, s))
+
+/**
  * Checks if the given "compat" string matches one of the strings in
  * the device's "compatible" property
  */
-- 
2.7.4


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

[Xen-devel] [RFC PATCH 03/31] pmstat: move pmstat.c file to the xen/drivers/pm/stat.c location

[Oleksandr Tyshchenko]

From: Oleksandr Dmytryshyn 

Cpufreq driver should be more generalizable (not ACPI-specific).
Thus this file should be placed to more convenient location.

This is a rebased version of the original patch:
https://lists.xen.org/archives/html/xen-devel/2014-11/msg00935.html

Signed-off-by: Oleksandr Dmytryshyn 
Signed-off-by: Oleksandr Tyshchenko 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 MAINTAINERS   |   1 +
 xen/arch/x86/Kconfig  |   1 +
 xen/common/sysctl.c   |   2 +-
 xen/drivers/Kconfig   |   2 +
 xen/drivers/Makefile  |   1 +
 xen/drivers/acpi/Makefile |   1 -
 xen/drivers/acpi/pmstat.c | 526 --
 xen/drivers/pm/Kconfig|   3 +
 xen/drivers/pm/Makefile   |   1 +
 xen/drivers/pm/stat.c | 526 ++
 10 files changed, 536 insertions(+), 528 deletions(-)
 delete mode 100644 xen/drivers/acpi/pmstat.c
 create mode 100644 xen/drivers/pm/Kconfig
 create mode 100644 xen/drivers/pm/Makefile
 create mode 100644 xen/drivers/pm/stat.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9794a81..87ade6f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -294,6 +294,7 @@ F:  xen/arch/x86/acpi/
 X: xen/arch/x86/acpi/boot.c
 X: xen/arch/x86/acpi/lib.c
 F: xen/drivers/cpufreq/
+F: xen/drivers/pm/
 F: xen/include/xen/cpufreq.h
 F: xen/include/xen/processor_perf.h
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 30c2769..86c8eca 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -23,6 +23,7 @@ config X86
select HAS_PDX
select NUMA
select VGA
+   select HAS_PM
 
 config ARCH_DEFCONFIG
string
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index a6882d1..ac96347 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -171,7 +171,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 op->u.availheap.avail_bytes <<= PAGE_SHIFT;
 break;
 
-#if defined (CONFIG_ACPI) && defined (CONFIG_HAS_CPUFREQ)
+#if defined (CONFIG_HAS_PM) && defined (CONFIG_HAS_CPUFREQ)
 case XEN_SYSCTL_get_pmstat:
 ret = do_get_pm_info(>u.get_pmstat);
 break;
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index bc3a54f..ddaec11 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -12,4 +12,6 @@ source "drivers/pci/Kconfig"
 
 source "drivers/video/Kconfig"
 
+source "drivers/pm/Kconfig"
+
 endmenu
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index 1939180..dd0b496 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -4,3 +4,4 @@ subdir-$(CONFIG_HAS_PCI) += pci
 subdir-$(CONFIG_HAS_PASSTHROUGH) += passthrough
 subdir-$(CONFIG_ACPI) += acpi
 subdir-$(CONFIG_VIDEO) += video
+subdir-$(CONFIG_HAS_PM) += pm
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index 444b11d..6f6470a 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -5,7 +5,6 @@ subdir-$(CONFIG_X86) += apei
 obj-bin-y += tables.init.o
 obj-$(CONFIG_NUMA) += numa.o
 obj-y += osl.o
-obj-$(CONFIG_HAS_CPUFREQ) += pmstat.o
 
 obj-$(CONFIG_X86) += hwregs.o
 obj-$(CONFIG_X86) += reboot.o
diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
deleted file mode 100644
index 2dbde1c..000
--- a/xen/drivers/acpi/pmstat.c
+++ /dev/null
@@ -1,526 +0,0 @@
-/*
-#  pmstat.c - Power Management statistic information (Px/Cx/Tx, etc.)
-#
-#  Copyright (c) 2008, Liu Jinsong 
-#
-# This program is free software; you can redistribute it and/or modify it 
-# under the terms of the GNU General Public License as published by the Free 
-# Software Foundation; either version 2 of the License, or (at your option) 
-# any later version.
-#
-# This program is distributed in the hope that it will be useful, but WITHOUT 
-# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 
-# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for 
-# more details.
-#
-# You should have received a copy of the GNU General Public License along with
-# this program; If not, see .
-#
-# The full GNU General Public License is included in this distribution in the
-# file called LICENSE.
-#
-*/
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-
-DEFINE_PER_CPU_READ_MOSTLY(struct pm_px *, cpufreq_statistic_data);
-
-/*
- * Get PM statistic info
- */
-int do_get_pm_info(struct 

[Xen-devel] [RFC PATCH 07/31] xenpm: Clarify xenpm usage

[Oleksandr Tyshchenko]

From: Oleksandr Tyshchenko 

CPU frequencies are in kHz. So, correct displayed text.

Signed-off-by: Oleksandr Tyshchenko 
CC: Ian Jackson 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 tools/misc/xenpm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index 762311e..37da1d8 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -48,11 +48,11 @@ void show_help(void)
 " get-cpufreq-average   [cpuid]   average cpu frequency since 
last invocation\n"
 " for CPU  or all\n"
 " get-cpufreq-para  [cpuid]   list cpu freq parameter of 
CPU  or all\n"
-" set-scaling-maxfreq   [cpuid]   set max cpu frequency  
on CPU \n"
+" set-scaling-maxfreq   [cpuid]  set max cpu frequency  
on CPU \n"
 " or all CPUs\n"
-" set-scaling-minfreq   [cpuid]   set min cpu frequency  
on CPU \n"
+" set-scaling-minfreq   [cpuid]  set min cpu frequency  
on CPU \n"
 " or all CPUs\n"
-" set-scaling-speed [cpuid]  set scaling speed on CPU 
 or all\n"
+" set-scaling-speed [cpuid]  set scaling speed  on 
CPU  or all\n"
 " it is used in userspace 
governor.\n"
 " set-scaling-governor  [cpuid]  set scaling governor on CPU 
 or all\n"
 " as 
userspace/performance/powersave/ondemand\n"
-- 
2.7.4


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

Re: [Xen-devel] [BUG] blkback reporting incorrect number of sectors, unable to boot

[Roger Pau Monné]

On Thu, Nov 09, 2017 at 08:15:52AM -0700, Mike Reardon wrote:
> On Thu, Nov 9, 2017 at 2:30 AM, Roger Pau Monné 
> wrote:
> 
> > Please try to avoid top-posting.
> >
> > On Wed, Nov 08, 2017 at 08:27:17PM -0700, Mike Reardon wrote:
> > > So am I correct in reading this that for at least the foreseeable future
> > > storage using 4k sector sizes is not gonna happen?  I'm just trying to
> > > figure out if I need to get some different hardware.
> >
> > Have you tried to use qdisk instead of blkback for the storage
> > backend?
> >
> > You will have to change your disk configuration line to add
> > backendtype=qdisk.
> >
> > Roger.
> >
> 
> Sorry I didn't realize my client was defaulting to top post.
> 
> If I add that to the disk config line, the system just hangs on the ovmf
> bios screen.  This appears in the qemu-dm log:
> 
> 
> xen be: qdisk-51712: xen be: qdisk-51712: error: Failed to get "write" lock
> error: Failed to get "write" lock
> xen be: qdisk-51712: xen be: qdisk-51712: initialise() failed
> initialise() failed

Hm, that doesn't seem related to the issue at hand. Adding Anthony and
Stefano (the QEMU maintainers).

Is there a know issue when booting a HVM guest with qdisk and UEFI?

Roger.

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

Re: [Xen-devel] [PATCH v2] x86/pvh: Do not add DSDT and FACS to PVH dom0 XSDT

[Roger Pau Monné]

On Thu, Nov 09, 2017 at 10:37:53AM -0500, Boris Ostrovsky wrote:
> These tables are pointed to from FADT. Adding them will
> result in duplicate entries in the guest's tables.
> 
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Roger Pau Monné 

Thanks, roger.

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

Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths

[Jan Beulich]

>>> On 09.11.17 at 15:16,  wrote:
> On Thu, 2017-11-09 at 06:08 -0700, Jan Beulich wrote:
>> Tasklets already take care of this by
>> calling sync_local_execstate() before calling the handler. But
>> for softirqs this isn't really an option; I'm surprised to see that
>> tasklet code does this independently of what kind of tasklet that
>> is. 
>>
> Good point. Weird indeed.
> 
>> Softirq tasklets aren't used very often, so I wonder if we have
>> a latent bug here. Otoh, if this was actually fine, adding a similar
>> call to rcu_do_batch() (or its caller) would be an option, I think.
>> 
> We can have a look.

I'm sorry for the noise here - I've once again forgotten that
sync_local_execstate() does nothing if a lazy switch hasn't
happened already. Hence leaving the potentially bad
performance effect aside, doing the same for RCU (or more
generally softirqs) would be an option.

Jan


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

Re: [Xen-devel] [PATCH v3 for-next 0/4] xen: Convert __page_to_mfn and _mfn_to_page to use typesafe MFN

[Jan Beulich]

>>> On 09.11.17 at 16:48,  wrote:
> On 09/11/17 15:47, Jan Beulich wrote:
> On 09.11.17 at 16:39,  wrote:
>>> What I meant is you would replace the 4 occurrences by
>>> mfn_to_page(_mfn(...)). If you are happy with that, then fine.
>> 
>> Oh, sure, that's a fine intermediate state, which we have all over
>> the place right now. It's clear that it'll take a while to fully carry
>> through typesafeness to everywhere.
> 
> Would you be fine with other part of Xen too? If so, I can have a go at 
> removing completely __page_to_mfn/__mfn_to_page.

Oh, if you want to go that extra mile, that's certainly fine with me.

Jan


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

Re: [Xen-devel] [PATCH v2] x86/pvh: Do not add DSDT and FACS to PVH dom0 XSDT

[Andrew Cooper]

On 09/11/17 15:47, Jan Beulich wrote:
 On 09.11.17 at 16:37,  wrote:
>> These tables are pointed to from FADT. Adding them will
>> result in duplicate entries in the guest's tables.
>>
>> Signed-off-by: Boris Ostrovsky 
> Reviewed-by: Jan Beulich 
>
>

Pulled into x86-next, thanks.

~Andrew

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

Re: [Xen-devel] [PATCH v3 for-next 0/4] xen: Convert __page_to_mfn and _mfn_to_page to use typesafe MFN

[Julien Grall]

Hi Jan,

On 09/11/17 15:47, Jan Beulich wrote:

On 09.11.17 at 16:39,  wrote:

On 09/11/17 15:36, Jan Beulich wrote:

On 09.11.17 at 16:20,  wrote:

I had a look at the files that needs to convert. It seems there are few
files with page_to_mfn/mfn_to_page re-defined but no callers:
- arch/x86/mm/hap/nested_hap.c
- arch/x86/mm/p2m-pt.c
- arch/x86/pv/traps.c
- arch/x86/pv/mm.c
- arch/x86/pv/iret.c

Those can be fixed now. That leave the following files:
- arch/x86/mm/p2m-ept.c
In that file, the override prevents all the caller to use the
construction mfn_to_page(_mfn(...)) as it mostly deals with hardware.


I'm not clear what you're trying to tell me here. The file has a total
for four mfn_to_page() uses - if overrides don't help (and perhaps
regardless of if they do), I think it wouldn't be very difficult to simply
change the four places. And note that plain staging has no override
there right now.

Because the plain staging still has page_to_mfn() not using typesafe...
You would need to override it even I follow your suggestion.

What I meant is you would replace the 4 occurrences by
mfn_to_page(_mfn(...)). If you are happy with that, then fine.


Oh, sure, that's a fine intermediate state, which we have all over
the place right now. It's clear that it'll take a while to fully carry
through typesafeness to everywhere.


Would you be fine with other part of Xen too? If so, I can have a go at 
removing completely __page_to_mfn/__mfn_to_page.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] x86/pvh: Do not add DSDT and FACS to PVH dom0 XSDT

[Jan Beulich]

>>> On 09.11.17 at 16:37,  wrote:
> These tables are pointed to from FADT. Adding them will
> result in duplicate entries in the guest's tables.
> 
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v3 for-next 0/4] xen: Convert __page_to_mfn and _mfn_to_page to use typesafe MFN

[Jan Beulich]

>>> On 09.11.17 at 16:39,  wrote:
> On 09/11/17 15:36, Jan Beulich wrote:
> On 09.11.17 at 16:20,  wrote:
>>> I had a look at the files that needs to convert. It seems there are few
>>> files with page_to_mfn/mfn_to_page re-defined but no callers:
>>> - arch/x86/mm/hap/nested_hap.c
>>> - arch/x86/mm/p2m-pt.c
>>> - arch/x86/pv/traps.c
>>> - arch/x86/pv/mm.c
>>> - arch/x86/pv/iret.c
>>>
>>> Those can be fixed now. That leave the following files:
>>> - arch/x86/mm/p2m-ept.c
>>> In that file, the override prevents all the caller to use the
>>> construction mfn_to_page(_mfn(...)) as it mostly deals with hardware.
>> 
>> I'm not clear what you're trying to tell me here. The file has a total
>> for four mfn_to_page() uses - if overrides don't help (and perhaps
>> regardless of if they do), I think it wouldn't be very difficult to simply
>> change the four places. And note that plain staging has no override
>> there right now.
> Because the plain staging still has page_to_mfn() not using typesafe... 
> You would need to override it even I follow your suggestion.
> 
> What I meant is you would replace the 4 occurrences by 
> mfn_to_page(_mfn(...)). If you are happy with that, then fine.

Oh, sure, that's a fine intermediate state, which we have all over
the place right now. It's clear that it'll take a while to fully carry
through typesafeness to everywhere.

Jan


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

Re: [Xen-devel] [PATCH v3 for-next 0/4] xen: Convert __page_to_mfn and _mfn_to_page to use typesafe MFN

[Julien Grall]

Hi,

On 09/11/17 15:36, Jan Beulich wrote:

On 09.11.17 at 16:20,  wrote:

I had a look at the files that needs to convert. It seems there are few
files with page_to_mfn/mfn_to_page re-defined but no callers:
- arch/x86/mm/hap/nested_hap.c
- arch/x86/mm/p2m-pt.c
- arch/x86/pv/traps.c
- arch/x86/pv/mm.c
- arch/x86/pv/iret.c

Those can be fixed now. That leave the following files:
- arch/x86/mm/p2m-ept.c
In that file, the override prevents all the caller to use the
construction mfn_to_page(_mfn(...)) as it mostly deals with hardware.


I'm not clear what you're trying to tell me here. The file has a total
for four mfn_to_page() uses - if overrides don't help (and perhaps
regardless of if they do), I think it wouldn't be very difficult to simply
change the four places. And note that plain staging has no override
there right now.
Because the plain staging still has page_to_mfn() not using typesafe... 
You would need to override it even I follow your suggestion.


What I meant is you would replace the 4 occurrences by 
mfn_to_page(_mfn(...)). If you are happy with that, then fine.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 for-next 0/4] xen: Convert __page_to_mfn and _mfn_to_page to use typesafe MFN

[Jan Beulich]

>>> On 09.11.17 at 16:20,  wrote:
> I had a look at the files that needs to convert. It seems there are few 
> files with page_to_mfn/mfn_to_page re-defined but no callers:
>   - arch/x86/mm/hap/nested_hap.c
>   - arch/x86/mm/p2m-pt.c
>   - arch/x86/pv/traps.c
>   - arch/x86/pv/mm.c
>   - arch/x86/pv/iret.c
> 
> Those can be fixed now. That leave the following files:
>   - arch/x86/mm/p2m-ept.c
>   In that file, the override prevents all the caller to use the 
> construction mfn_to_page(_mfn(...)) as it mostly deals with hardware.

I'm not clear what you're trying to tell me here. The file has a total
for four mfn_to_page() uses - if overrides don't help (and perhaps
regardless of if they do), I think it wouldn't be very difficult to simply
change the four places. And note that plain staging has no override
there right now.

Jan


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

[Xen-devel] [PATCH v2] x86/pvh: Do not add DSDT and FACS to PVH dom0 XSDT

[Boris Ostrovsky]

These tables are pointed to from FADT. Adding them will
result in duplicate entries in the guest's tables.

Signed-off-by: Boris Ostrovsky 
---
Changes in v2:
* Merge (pvh_acpi_table_allowed(sig) && pvh_acpi_table_in_xsdt(sig)) into
  a single call
* Make this call return a boolean expression as opposed to explicit true/false

 xen/arch/x86/hvm/dom0_build.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index a67071c..cfcf461 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -818,6 +818,17 @@ static bool __init pvh_acpi_table_allowed(const char *sig)
 return true;
 }
 
+static bool __init pvh_acpi_xsdt_table_allowed(const char *sig)
+{
+/*
+ * DSDT and FACS are pointed to from FADT and thus don't belong
+ * in XSDT.
+ */
+return pvh_acpi_table_allowed(sig) &&
+   strncmp(sig, ACPI_SIG_DSDT, ACPI_NAME_SIZE) &&
+   strncmp(sig, ACPI_SIG_FACS, ACPI_NAME_SIZE);
+}
+
 static int __init pvh_setup_acpi_xsdt(struct domain *d, paddr_t madt_addr,
   paddr_t *addr)
 {
@@ -841,7 +852,7 @@ static int __init pvh_setup_acpi_xsdt(struct domain *d, 
paddr_t madt_addr,
 {
 const char *sig = acpi_gbl_root_table_list.tables[i].signature.ascii;
 
-if ( pvh_acpi_table_allowed(sig) )
+if ( pvh_acpi_xsdt_table_allowed(sig) )
 num_tables++;
 }
 
@@ -888,7 +899,7 @@ static int __init pvh_setup_acpi_xsdt(struct domain *d, 
paddr_t madt_addr,
 {
 const char *sig = acpi_gbl_root_table_list.tables[i].signature.ascii;
 
-if ( pvh_acpi_table_allowed(sig) )
+if ( pvh_acpi_xsdt_table_allowed(sig) )
 xsdt->table_offset_entry[j++] =
 acpi_gbl_root_table_list.tables[i].address;
 }
-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH 1/2 v2] xen: Add support for initializing 16550 UART using ACPI

[Jan Beulich]

>>> On 09.11.17 at 16:07,  wrote:
> On Thu, Nov 09, 2017 at 06:18:21AM -0700, Jan Beulich wrote:
>> >>> On 09.11.17 at 12:31,  wrote:
>> > On Thu, Nov 09, 2017 at 03:49:23PM +0530, Bhupinder Thakur wrote:
>> >> +static int ns16550_init_dt(struct ns16550 *uart,
>> >> +   const struct dt_device_node *dev)
>> >> +{
>> >> +return -EINVAL;
>> >> +}
>> >> +#endif
>> >> +
>> >> +#ifdef CONFIG_ACPI
>> >> +#include 
>> > 
>> > Please place the include at the top of the file, together with the
>> > other ones.
>> 
>> I disagree here, at least as long as that header isn't itself expanding
>> to nothing (or only stubs) when !CONFIG_ACPI.
> 
> The header already has a CONFIG_ACPI guard inside, but it doesn't
> cover the full content, so my suggestion was to move the include to
> the top of the file, but keeping the CONFIG_ACPI guards around it.

Ah, I see. I'd then still prefer one less #ifdef by keeping it where it
is, but that's a matter of taste I admit.

Jan


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

Re: [Xen-devel] [PATCH v3 for-next 0/4] xen: Convert __page_to_mfn and _mfn_to_page to use typesafe MFN

[Julien Grall]

Hi Jan,

On 06/11/17 12:44, Jan Beulich wrote:

On 06.11.17 at 13:16,  wrote:




On 06/11/17 12:11, Jan Beulich wrote:

On 06.11.17 at 12:47,  wrote:

Hi Jan,

On 06/11/17 11:37, Jan Beulich wrote:

On 01.11.17 at 15:03,  wrote:

Most of the users of page_to_mfn and mfn_to_page are either overriding
the macros to make them work with mfn_t or use mfn_x/_mfn becaue the rest
of the function use mfn_t.

So I think it is time to make __page_to_mfn and __mfn_to_page using typesafe
MFN.


I have to admit that I still find the overall goal confusing: Afaict
the double-underscore-prefixed versions exist only to allow
easily overriding the non-prefixed ones. Hence the first and
foremost goal ought to be to convert everyone to using the
non-prefixed versions. Files wanting to avoid the typed forms
could then continue to use / be switched to the prefixed ones.

What you're doing here is producing a mess: The prefixed
versions should never have been touched in the first place.
And iirc this was discussed before, with the suggestion to use
overrides (for the non-prefixed versions) to limit overall patch
size.


At the end of the discussion in the previous version, you were happy
with the modification done here (see [1]).


  From the angle looked at it back then I indeed was, but I'm looking
at this from a slightly different angle now with the reply above.


Overall, I think this is an improvement compare to what we have today.
Because we enforce the use of MFN typesafe by default. The developer
would have to override the helpers if he wants to to use the
non-typesafe version.

With your suggestion here, you would just keep the override around even
when they are not necessary. They will have to be dropped at some point,
so why not now?


Why would we keep the overrides in place once no longer needed?
All I'm asking for is that the double-underscore prefixed macros be
left alone, and the non-prefixed versions be converted to be
type-safe by default (with the option to override). That'll allow the
prefixed variants to go way altogether once all code was switched
to typesafe, no longer requiring any overrides.


If you left the double-underscore alone, then you can't convert headers
using them to typesafe. This is because they can't use the non-prefixed
version as they may be override.

So what you are suggesting here is will avoid converting those headers
until someone step up and finish to convert all the source to MFN
typesafe. Personally, I find quite silly to have to delay that...


Hmm, I see your point, but if we went the route you suggest,
what would be the steps to reach the ultimate result I've
described (the prefixed variants gone)? I seems to me that
this would require touching a lot of code a second time that is
being touched now, or is going to be touched as further
conversion happens.


We would indeed need to modify the headers to use 
page_to_mfn/mfn_to_page instead of __page_to_mfn/__mfn_to_page. Those 
headers are:

- asm-arm/mm.h
- xen/domain_page.h
- asm-x86/mm.h
- asm-x86/page.h
- asm-x86/p2m.h

I had a look at the files that needs to convert. It seems there are few 
files with page_to_mfn/mfn_to_page re-defined but no callers:

- arch/x86/mm/hap/nested_hap.c
- arch/x86/mm/p2m-pt.c
- arch/x86/pv/traps.c
- arch/x86/pv/mm.c
- arch/x86/pv/iret.c

Those can be fixed now. That leave the following files:
- arch/x86/mm/p2m-ept.c
		In that file, the override prevents all the caller to use the 
construction mfn_to_page(_mfn(...)) as it mostly deals with hardware.

- arch/x86/x86_64/mm.c
This is could be done without too much trouble.
- arch/x86/pv/dom0_build.c
It would need a bit of rework to get the code MFN typesafe in a 
neat way.
- drivers/passthrough/amd/iommu_map.c
It would need a bit of rework to get the code MFN typesafe in a 
neat way.
- common/trace.c
		I think it should be ok. Though I am bit surprised to see uint32_t 
been used for MFN...

- common/memory.c
It would need a bit of rework to get the code MFN typesafe in a 
neat way.
- common/page_alloc.c
This is could be done without too much trouble.
- common/grant_table.c
It would need a bit of rework to get the code MFN typesafe in a 
neat way.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [BUG] blkback reporting incorrect number of sectors, unable to boot

[Mike Reardon]

On Thu, Nov 9, 2017 at 2:30 AM, Roger Pau Monné 
wrote:

> Please try to avoid top-posting.
>
> On Wed, Nov 08, 2017 at 08:27:17PM -0700, Mike Reardon wrote:
> > So am I correct in reading this that for at least the foreseeable future
> > storage using 4k sector sizes is not gonna happen?  I'm just trying to
> > figure out if I need to get some different hardware.
>
> Have you tried to use qdisk instead of blkback for the storage
> backend?
>
> You will have to change your disk configuration line to add
> backendtype=qdisk.
>
> Roger.
>

Sorry I didn't realize my client was defaulting to top post.

If I add that to the disk config line, the system just hangs on the ovmf
bios screen.  This appears in the qemu-dm log:


xen be: qdisk-51712: xen be: qdisk-51712: error: Failed to get "write" lock
error: Failed to get "write" lock
xen be: qdisk-51712: xen be: qdisk-51712: initialise() failed
initialise() failed
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2 v2] xen: Add support for initializing 16550 UART using ACPI

[Roger Pau Monné]

On Thu, Nov 09, 2017 at 06:18:21AM -0700, Jan Beulich wrote:
> >>> On 09.11.17 at 12:31,  wrote:
> > On Thu, Nov 09, 2017 at 03:49:23PM +0530, Bhupinder Thakur wrote:
> >> +static int ns16550_init_dt(struct ns16550 *uart,
> >> +   const struct dt_device_node *dev)
> >> +{
> >> +return -EINVAL;
> >> +}
> >> +#endif
> >> +
> >> +#ifdef CONFIG_ACPI
> >> +#include 
> > 
> > Please place the include at the top of the file, together with the
> > other ones.
> 
> I disagree here, at least as long as that header isn't itself expanding
> to nothing (or only stubs) when !CONFIG_ACPI.

The header already has a CONFIG_ACPI guard inside, but it doesn't
cover the full content, so my suggestion was to move the include to
the top of the file, but keeping the CONFIG_ACPI guards around it.

Roger.

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

Re: [Xen-devel] [PATCH] VMX: sync CPU state upon vCPU destruction

[Dario Faggioli]

On Thu, 2017-11-09 at 07:49 -0700, Jan Beulich wrote:
> See the code comment being added for why we need this.
> 
> Reported-by: Igor Druzhinin 
> Signed-off-by: Jan Beulich 
> 
Reviewed-by: Dario Faggioli 

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli

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

Re: [Xen-devel] Unable to create guest PV domain on OMAP5432

[Andrii Anisov]

Hello Jayadev,

Please see my comments inlined:


On 08.11.17 07:17, Jayadev Kumaran wrote:

Hello all,

I'm trying to implement Xen hypervisor support on OMAP5432.I have 
followed the steps as in 
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM 
for the initial setup. I'm able to see the domain 0 successfully up.


/root@omap5-evm:~# /etc/init.d/xencommons start
Starting /usr/local/sbin/xenstored...
Setting domain 0 name, domid and JSON config...
Done setting up Dom0
Starting xenconsoled...
Starting QEMU as disk backend for dom0
/
Never used QEMU as disk backend on ARM. We are using raw partition for a 
disk.


/root@omap5-evm:~# xl list
NameID   Mem VCPUs  
State   Time(s)
Domain-0 0   512 2 r-  
11.5

/
I have used the below configuration file for creating a guest domain.
"
name = "ubuntu"

kernel = "/home/root/ubuntu/vmlinuz"
ramdisk = "/home/root/ubuntu/initrd.gz"
#bootloader = "/usr/lib/xen-4.4/bin/pygrub"

memory = 1024
vcpus = 1

device_model_version = 'qemu-xen-traditional'

I would suggest to run the stuff without this line.


disk = [
 '/dev/vg0/domu0,raw,xvda,rw'

Do you really have "/dev/vg0/domu0" in your dom0?

   ]

"

But when I try to create the guest domain using xl create command,I 
get the below error.


/root@omap5-evm:/# xl create -d -c /etc/xen/config.d/ubuntu.cfg/
Please try adding ` xl - create -d -c /etc/xen/config.d/ubuntu.cfg` 
for getting more output./

/

/
Parsing config from /etc/xen/config.d/ubuntu.cfg
{
"c_info": {
"type": "pv",
"name": "ubuntu",
"uuid": "d7dd7835-61e3-46ce-b76f-140c0f9673fe",
"run_hotplug_scripts": "True"
},
"b_info": {
"max_vcpus": 1,
"avail_vcpus": [
0
],
"max_memkb": 1048576,
"target_memkb": 1048576,
"shadow_memkb": 9216,
"device_model_version": "qemu_xen_traditional",
"sched_params": {

},
"claim_mode": "True",
"kernel": "/home/root/ubuntu/vmlinuz",
"ramdisk": "/home/root/ubuntu/initrd.gz",
"type.pv": {

},
"arch_arm": {

}
},
"disks": [
{
"pdev_path": "/dev/vg0/domu0",
"vdev": "xvda",
"format": "raw",
"readwrite": 1
}
],
"on_reboot": "restart",
"on_soft_reset": "soft_reset"
}
(XEN) grant_table.c:1688:d0v0 Expanding d4 grant table from 0 to 1 frames
(XEN) memory.c:238:d0v0 Could not allocate order=18 extent: id=4 
memflags=0xc0 (0 of 1)
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: 
/etc/xen/scripts/block add [1612] exited with error status 1
libxl: error: libxl_create.c:1278:domcreate_launch_dm: Domain 4:unable 
to add disk devices
libxl: error: libxl_domain.c:1000:libxl__destroy_domid: Domain 
4:Non-existant domain
libxl: error: libxl_domain.c:959:domain_destroy_callback: Domain 
4:Unable to destroy guest
libxl: error: libxl_domain.c:886:domain_destroy_cb: Domain 
4:Destruction of domain failed

/
Any input would be highly appreciated


BTW, what is your dom0 system? Does it have bash?
Long time ago, we had busybox in dom0, and used 
https://marc.info/?l=xen-devel=146358920813936=4 to workaround block 
device creation issues.


--

*Andrii Anisov*



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

[Xen-devel] [PATCH] VMX: sync CPU state upon vCPU destruction

[Jan Beulich]

See the code comment being added for why we need this.

Reported-by: Igor Druzhinin 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -479,7 +479,13 @@ static void vmx_vcpu_destroy(struct vcpu
  * we should disable PML manually here. Note that vmx_vcpu_destroy is 
called
  * prior to vmx_domain_destroy so we need to disable PML for each vcpu
  * separately here.
+ *
+ * Before doing that though, flush all state for the vCPU previously having
+ * run on the current CPU, so that this flushing of state won't happen from
+ * the TLB flush IPI handler behind the back of a vmx_vmcs_enter() /
+ * vmx_vmcs_exit() section.
  */
+sync_local_execstate();
 vmx_vcpu_disable_pml(v);
 vmx_destroy_vmcs(v);
 passive_domain_destroy(v);




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

Re: [Xen-devel] [PATCH v2] x86/hvm: do not register hpet mmio during s3 cycle

[Jan Beulich]

>>> On 09.11.17 at 15:42,  wrote:
> Hi,
> 
> On 09/11/17 08:55, Jan Beulich wrote:
> On 08.11.17 at 20:46,  wrote:
>>> Do it once at domain creation (hpet_init).
>>>
>>> Sleep -> Resume cycles will end up crashing an HVM guest with hpet as
>>> the sequence during resume takes the path:
>>> -> hvm_s3_suspend
>>>-> hpet_reset
>>>  -> hpet_deinit
>>>  -> hpet_init
>>>-> register_mmio_handler
>>>  -> hvm_next_io_handler
>>>
>>> register_mmio_handler will use a new io handler each time, until
>>> eventually it reaches NR_IO_HANDLERS, then hvm_next_io_handler calls
>>> domain_crash.
>>>
>>> Signed-off-by: Eric Chanudet 
>>>
>>> ---
>>> v2:
>>>* make hpet_reinit static inline (one call site in this file)
>> 
>> Perhaps my prior reply was ambiguous: By "inlining" I meant
>> literally inlining it (i.e. dropping the standalone function
>> altogether). Static functions outside of header files should not
>> normally be marked "inline" explicitly - it should be the compiler
>> to make that decision.
>> 
>> As doing the adjustment it relatively simple, I wouldn't mind
>> doing so while committing, saving another round trip. With
>> that adjustment (or at the very least with the "inline" dropped)
>> Reviewed-by: Jan Beulich 
> 
> What would be the risk to get this patch in Xen 4.10?

Close to none, I would say. Of course, if there really was
something wrong with the code restructuring to fix the bug,
basically all HVM guests would be hosed HPET-wise.

Jan


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

Re: [Xen-devel] [PATCH for-4.10] libevtchn: fix build on non-Linux hosts

[Julien Grall]

Hi,

On 08/11/17 12:56, Wei Liu wrote:

On Wed, Nov 08, 2017 at 12:52:57PM +, Roger Pau Monne wrote:

Non-Linux hosts (where osdep_evtchn_restrict is not yet supported)
made use of errno without including errno.h, fix this by including the
header.

Signed-off-by: Roger Pau Monné 


Acked-by: Wei Liu 


Release-acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] x86/hvm: do not register hpet mmio during s3 cycle

[Julien Grall]

Hi,

On 09/11/17 08:55, Jan Beulich wrote:

On 08.11.17 at 20:46,  wrote:

Do it once at domain creation (hpet_init).

Sleep -> Resume cycles will end up crashing an HVM guest with hpet as
the sequence during resume takes the path:
-> hvm_s3_suspend
   -> hpet_reset
 -> hpet_deinit
 -> hpet_init
   -> register_mmio_handler
 -> hvm_next_io_handler

register_mmio_handler will use a new io handler each time, until
eventually it reaches NR_IO_HANDLERS, then hvm_next_io_handler calls
domain_crash.

Signed-off-by: Eric Chanudet 

---
v2:
   * make hpet_reinit static inline (one call site in this file)


Perhaps my prior reply was ambiguous: By "inlining" I meant
literally inlining it (i.e. dropping the standalone function
altogether). Static functions outside of header files should not
normally be marked "inline" explicitly - it should be the compiler
to make that decision.

As doing the adjustment it relatively simple, I wouldn't mind
doing so while committing, saving another round trip. With
that adjustment (or at the very least with the "inline" dropped)
Reviewed-by: Jan Beulich 


What would be the risk to get this patch in Xen 4.10?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths

[Jan Beulich]

>>> On 09.11.17 at 15:16,  wrote:
> Ah, yes, my bad! What if I take vcpu_migrate() out of the above exec-
> trace (which is what I wanted to do in my email already)?
> 
> pCPU1
> =
> current == vCPU1
> context_switch(next == idle)
> !! __context_switch() is skipped
> anything_that_uses_or_touches_context()
> 
> Point being, is the underlying and general "issue" here, really bound
> to migrations, or is it something intrinsic of lazy context switch? I'm
> saying it's the latter.

The general issue doesn't require vcpu_migrate(), I agree. The
specific VMX issue here does, though.

Thing is - I'm not convinced there's a general issue here in the first
place: Asynchronous code isn't supposed to modify state behind
the back of synchronous code. It just so happens that VMX code is
structured to violate that assumption when PML is in use.

> That being said, sure it makes sense to assume that, if we migrated the
> vCPU from pCPU1 to pCPU2, it's highly unlikely that it will resume the
> execution on pCPU1, and hence there is no point in leaving its context
> there, and we could very well sync. It's a reasonable best-effort
> measure, but can we rely on it for correctness? I don't think we can.

We can't right now, but code (from an abstract pov at least)
could be structured so we could rely on it.

> And generalizing the idea enough that we could then rely on it for
> correctness, tends to be close enough to not doing lazy context switch
> at all, I think.

I don't think so, no - we could still leave state in hardware in
anticipation that no other non-idle vCPU would be scheduled
on the local CPU. That's something that ought to help in
particular pinned vCPU-s.

>> The problem is with tasklet / softirq
>> (and hence also RCU) work. 
>>
> Yes.
> 
>> Tasklets already take care of this by
>> calling sync_local_execstate() before calling the handler. But
>> for softirqs this isn't really an option; I'm surprised to see that
>> tasklet code does this independently of what kind of tasklet that
>> is. 
>>
> Good point. Weird indeed.

I've added an item to my todo list to see whether I can figure
whether this is an okay thing to do.

>> Softirq tasklets aren't used very often, so I wonder if we have
>> a latent bug here. Otoh, if this was actually fine, adding a similar
>> call to rcu_do_batch() (or its caller) would be an option, I think.
>> 
> We can have a look.
> 
> What about the effect on performance, though?
> 
> I mean, assuming that lazy context switch does a good job, with respect
> to that, by avoiding synching in enough case where it is actually not
> necessary, how do things change if we start to sync at any softirq,
> even when the handler would have not required that?

I wasn't suggesting this for softirqs, but only (if at all) for RCU. But
yes, there would a performance hit from this; not sure how small
or large. But as you can see, for tasklets the hit is taken
unconditionally.

Jan


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

Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov

[Julien Grall]

On 09/11/17 14:36, Julien Grall wrote:

Hi Roger,

On 09/11/17 09:27, Roger Pau Monné wrote:

On Thu, Nov 09, 2017 at 12:22:49AM +, Hao, Xudong wrote:
Qemu-xen didn't have commit a80363, so I report this issue to ask 
for sync up
with qemu upstream. Last mail I mean I usually used Qemu Xen tree to 
do test,

and found out this issue.

Before requesting the backport, have you tested whether it fixes 
your issues?




Yes, Luwei (Cced) tested it with pass result.


In which case requesting a backport would be in place on the grounds
that's a bug fix.

The patch in question fixes a bug mostly seen when doing
PCI-passthrough of devices that support MSI-X interrupts to Windows
guest (and Windows attempts to setup the interrupts using MSI-X). It
doesn't manifest on Linux or FreeBSD because these OSes use a
different dance to setup MSI-X interrupts, and thus are not affected.
It's likely that other OSes with different MSI-X implementations are
able to trigger that bug. The result of not having the patch is that
interrupts of passed through devices will stay masked, thus
preventing the device from working (unless polling mode only is
used).

Pros:
  - It fixes a bug.
  - The patch is not very big or intrusive.

Cons:
  - It hasn't been tested as it's not in qemu-xen.
  - Only Windows is affected by the bug AFAIK.

IMHO, iff the backport is accepted it should be performed ASAP, so
that the patch can be properly tested before the release.


Thank you for the detailed explanation :). On a previous e-mail Stefano 
were happy with the backport. So:


Release-acked-by: Julien Grall 


Note that I think we would need to update xen also to point to the 
commit with this backport included.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov

[Julien Grall]

Hi Roger,

On 09/11/17 09:27, Roger Pau Monné wrote:

On Thu, Nov 09, 2017 at 12:22:49AM +, Hao, Xudong wrote:

Qemu-xen didn't have commit a80363, so I report this issue to ask for sync up
with qemu upstream. Last mail I mean I usually used Qemu Xen tree to do test,
and found out this issue.

Before requesting the backport, have you tested whether it fixes your issues?



Yes, Luwei (Cced) tested it with pass result.


In which case requesting a backport would be in place on the grounds
that's a bug fix.

The patch in question fixes a bug mostly seen when doing
PCI-passthrough of devices that support MSI-X interrupts to Windows
guest (and Windows attempts to setup the interrupts using MSI-X). It
doesn't manifest on Linux or FreeBSD because these OSes use a
different dance to setup MSI-X interrupts, and thus are not affected.
It's likely that other OSes with different MSI-X implementations are
able to trigger that bug. The result of not having the patch is that
interrupts of passed through devices will stay masked, thus
preventing the device from working (unless polling mode only is
used).

Pros:
  - It fixes a bug.
  - The patch is not very big or intrusive.

Cons:
  - It hasn't been tested as it's not in qemu-xen.
  - Only Windows is affected by the bug AFAIK.

IMHO, iff the backport is accepted it should be performed ASAP, so
that the patch can be properly tested before the release.


Thank you for the detailed explanation :). On a previous e-mail Stefano 
were happy with the backport. So:


Release-acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths

[Dario Faggioli]

On Thu, 2017-11-09 at 06:08 -0700, Jan Beulich wrote:
> > > > On 09.11.17 at 12:01,  wrote:
> > 
> > pCPU1
> > =
> > current == vCPU1
> > context_switch(next == idle)
> > !! __context_switch() is skipped
> > vcpu_migrate(vCPU1)
> > anything_that_uses_or_touches_context()
> > 
> > So, it must be anything_that_uses_or_touches_context() --knowing it
> > will be reading or touching the pCPU context-- that syncs the
> > state,
> > before using or touching it (which is, e.g., what Jan's patch
> > does).
> 
> Well, generally after the vcpu_migrate(vCPU1) above we expect
> nothing to happen at all on the pCPU, until another (non-idle)
> vCPU gets scheduled onto it. 
>
Ah, yes, my bad! What if I take vcpu_migrate() out of the above exec-
trace (which is what I wanted to do in my email already)?

pCPU1
=
current == vCPU1
context_switch(next == idle)
!! __context_switch() is skipped
anything_that_uses_or_touches_context()

Point being, is the underlying and general "issue" here, really bound
to migrations, or is it something intrinsic of lazy context switch? I'm
saying it's the latter.

That being said, sure it makes sense to assume that, if we migrated the
vCPU from pCPU1 to pCPU2, it's highly unlikely that it will resume the
execution on pCPU1, and hence there is no point in leaving its context
there, and we could very well sync. It's a reasonable best-effort
measure, but can we rely on it for correctness? I don't think we can.

And generalizing the idea enough that we could then rely on it for
correctness, tends to be close enough to not doing lazy context switch
at all, I think.

> The problem is with tasklet / softirq
> (and hence also RCU) work. 
>
Yes.

> Tasklets already take care of this by
> calling sync_local_execstate() before calling the handler. But
> for softirqs this isn't really an option; I'm surprised to see that
> tasklet code does this independently of what kind of tasklet that
> is. 
>
Good point. Weird indeed.

> Softirq tasklets aren't used very often, so I wonder if we have
> a latent bug here. Otoh, if this was actually fine, adding a similar
> call to rcu_do_batch() (or its caller) would be an option, I think.
> 
We can have a look.

What about the effect on performance, though?

I mean, assuming that lazy context switch does a good job, with respect
to that, by avoiding synching in enough case where it is actually not
necessary, how do things change if we start to sync at any softirq,
even when the handler would have not required that?

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli

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

[Xen-devel] [PATCH v2 2/5] x86: add enum for hypervisors to replace x86_hyper

[Juergen Gross]

The x86_hyper pointer is only used for checking whether a virtual
device is supporting the hypervisor the system is running on.

Use an enum for that purpose instead and drop the x86_hyper pointer.

Cc: k...@microsoft.com
Cc: haiya...@microsoft.com
Cc: sthem...@microsoft.com
Cc: akata...@vmware.com
Cc: pbonz...@redhat.com
Cc: rkrc...@redhat.com
Cc: boris.ostrov...@oracle.com
Cc: de...@linuxdriverproject.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: k...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
Cc: linux-graphics-maintai...@vmware.com
Cc: pv-driv...@vmware.com
Cc: dmitry.torok...@gmail.com
Cc: xdeguill...@vmware.com
Cc: moltm...@vmware.com
Cc: a...@arndb.de
Cc: gre...@linuxfoundation.org
Cc: linux-in...@vger.kernel.org

Signed-off-by: Juergen Gross 
---
 arch/x86/hyperv/hv_init.c |  2 +-
 arch/x86/include/asm/hypervisor.h | 23 ++-
 arch/x86/kernel/cpu/hypervisor.c  | 12 +---
 arch/x86/kernel/cpu/mshyperv.c|  4 ++--
 arch/x86/kernel/cpu/vmware.c  |  4 ++--
 arch/x86/kernel/kvm.c |  4 ++--
 arch/x86/xen/enlighten_hvm.c  |  4 ++--
 arch/x86/xen/enlighten_pv.c   |  4 ++--
 drivers/hv/vmbus_drv.c|  2 +-
 drivers/input/mouse/vmmouse.c | 10 --
 drivers/misc/vmw_balloon.c|  2 +-
 11 files changed, 40 insertions(+), 31 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index a5db63f728a2..a0b86cf486e0 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -113,7 +113,7 @@ void hyperv_init(void)
u64 guest_id;
union hv_x64_msr_hypercall_contents hypercall_msr;
 
-   if (x86_hyper != _hyper_ms_hyperv)
+   if (x86_hyper_type != X86_HYPER_MS_HYPERV)
return;
 
/* Allocate percpu VP index */
diff --git a/arch/x86/include/asm/hypervisor.h 
b/arch/x86/include/asm/hypervisor.h
index 0eca7239a7aa..1b0a5abcd8ae 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -29,6 +29,16 @@
 /*
  * x86 hypervisor information
  */
+
+enum x86_hypervisor_type {
+   X86_HYPER_NATIVE = 0,
+   X86_HYPER_VMWARE,
+   X86_HYPER_MS_HYPERV,
+   X86_HYPER_XEN_PV,
+   X86_HYPER_XEN_HVM,
+   X86_HYPER_KVM,
+};
+
 struct hypervisor_x86 {
/* Hypervisor name */
const char  *name;
@@ -36,6 +46,9 @@ struct hypervisor_x86 {
/* Detection routine */
uint32_t(*detect)(void);
 
+   /* Hypervisor type */
+   enum x86_hypervisor_type type;
+
/* init time callbacks */
struct x86_hyper_init init;
 
@@ -43,15 +56,7 @@ struct hypervisor_x86 {
struct x86_hyper_runtime runtime;
 };
 
-extern const struct hypervisor_x86 *x86_hyper;
-
-/* Recognized hypervisors */
-extern const struct hypervisor_x86 x86_hyper_vmware;
-extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
-extern const struct hypervisor_x86 x86_hyper_xen_pv;
-extern const struct hypervisor_x86 x86_hyper_xen_hvm;
-extern const struct hypervisor_x86 x86_hyper_kvm;
-
+extern enum x86_hypervisor_type x86_hyper_type;
 extern void init_hypervisor_platform(void);
 #else
 static inline void init_hypervisor_platform(void) { }
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 6c1bf092..bea8d3e24f50 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -26,6 +26,12 @@
 #include 
 #include 
 
+extern const struct hypervisor_x86 x86_hyper_vmware;
+extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
+extern const struct hypervisor_x86 x86_hyper_xen_pv;
+extern const struct hypervisor_x86 x86_hyper_xen_hvm;
+extern const struct hypervisor_x86 x86_hyper_kvm;
+
 static const __initconst struct hypervisor_x86 * const hypervisors[] =
 {
 #ifdef CONFIG_XEN_PV
@@ -41,8 +47,8 @@ static const __initconst struct hypervisor_x86 * const 
hypervisors[] =
 #endif
 };
 
-const struct hypervisor_x86 *x86_hyper;
-EXPORT_SYMBOL(x86_hyper);
+enum x86_hypervisor_type x86_hyper_type;
+EXPORT_SYMBOL(x86_hyper_type);
 
 static inline const struct hypervisor_x86 * __init
 detect_hypervisor_vendor(void)
@@ -87,6 +93,6 @@ void __init init_hypervisor_platform(void)
copy_array(>init, _init.hyper, sizeof(h->init));
copy_array(>runtime, _platform.hyper, sizeof(h->runtime));
 
-   x86_hyper = h;
+   x86_hyper_type = h->type;
x86_init.hyper.init_platform();
 }
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 6bb84d655e4b..85eb5fc180c8 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -254,9 +254,9 @@ static void __init ms_hyperv_init_platform(void)
 #endif
 }
 
-const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
+const __initconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
.name   = "Microsoft Hyper-V",
.detect = ms_hyperv_platform,
+   .type

[Xen-devel] [PATCH v2 5/5] x86/xen: use guest_late_init to detect Xen PVH guest

[Juergen Gross]

In case we are booted via the default boot entry by a generic loader
like grub or OVMF it is necessary to distinguish between a HVM guest
with a device model supporting legacy devices and a PVH guest without
device model.

PVH guests will always have x86_platform.legacy.no_vga set and
x86_platform.legacy.rtc cleared, while both won't be true for HVM
guests.

Test for both conditions in the guest_late_init hook and set xen_pvh
to true if they are met.

Move some of the early PVH initializations to the new hook in order
to avoid duplicated code.

Cc: boris.ostrov...@oracle.com
Cc: xen-de...@lists.xenproject.org

Signed-off-by: Juergen Gross 
---
 arch/x86/xen/enlighten_hvm.c | 24 ++--
 arch/x86/xen/enlighten_pvh.c |  9 -
 2 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 754d5391d9fa..826898701045 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -1,3 +1,4 @@
+#include 
 #include 
 #include 
 #include 
@@ -188,8 +189,6 @@ static void __init xen_hvm_guest_init(void)
xen_hvm_init_time_ops();
xen_hvm_init_mmu_ops();
 
-   if (xen_pvh_domain())
-   machine_ops.emergency_restart = xen_emergency_restart;
 #ifdef CONFIG_KEXEC_CORE
machine_ops.shutdown = xen_hvm_shutdown;
machine_ops.crash_shutdown = xen_hvm_crash_shutdown;
@@ -226,6 +225,26 @@ static uint32_t __init xen_platform_hvm(void)
return xen_cpuid_base();
 }
 
+static __init void xen_hvm_guest_late_init(void)
+{
+#ifdef CONFIG_XEN_PVH
+   /* Test for PVH domain (PVH boot path taken overrides ACPI flags). */
+   if (!xen_pvh &&
+   (x86_platform.legacy.rtc || !x86_platform.legacy.no_vga))
+   return;
+
+   /* PVH detected. */
+   xen_pvh = true;
+
+   /* Make sure we don't fall back to (default) ACPI_IRQ_MODEL_PIC. */
+   if (!nr_ioapics && acpi_irq_model == ACPI_IRQ_MODEL_PIC)
+   acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
+
+   machine_ops.emergency_restart = xen_emergency_restart;
+   pv_info.name = "Xen PVH";
+#endif
+}
+
 const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = {
.name   = "Xen HVM",
.detect = xen_platform_hvm,
@@ -233,5 +252,6 @@ const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = 
{
.init.init_platform = xen_hvm_guest_init,
.init.x2apic_available  = xen_x2apic_para_available,
.init.init_mem_mapping  = xen_hvm_init_mem_mapping,
+   .init.guest_late_init   = xen_hvm_guest_late_init,
.runtime.pin_vcpu   = xen_pin_vcpu,
 };
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 7bd3ee08393e..436c4f003e17 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -25,13 +25,6 @@ struct boot_params pvh_bootparams 
__attribute__((section(".data")));
 struct hvm_start_info pvh_start_info;
 unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
 
-static void xen_pvh_arch_setup(void)
-{
-   /* Make sure we don't fall back to (default) ACPI_IRQ_MODEL_PIC. */
-   if (nr_ioapics == 0)
-   acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
-}
-
 static void __init init_pvh_bootparams(void)
 {
struct xen_memory_map memmap;
@@ -102,6 +95,4 @@ void __init xen_prepare_pvh(void)
wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
 
init_pvh_bootparams();
-
-   x86_init.oem.arch_setup = xen_pvh_arch_setup;
 }
-- 
2.12.3


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

[Xen-devel] [PATCH v2 1/5] x86: merge x86_hyper into x86_platform and x86_init

[Juergen Gross]

Instead of x86_hyper being either NULL on bare metal or a pointer to a
struct hypervisor_x86 in case of the kernel running as a guest merge
the struct into x86_platform and x86_init.

This will remove the need for wrappers making it hard to find out what
is being called. With dummy functions added for all callbacks testing
for a NULL function pointer can be removed, too.

Cc: k...@microsoft.com
Cc: haiya...@microsoft.com
Cc: sthem...@microsoft.com
Cc: akata...@vmware.com
Cc: pbonz...@redhat.com
Cc: rkrc...@redhat.com
Cc: boris.ostrov...@oracle.com
Cc: ru...@rustcorp.com.au
Cc: de...@linuxdriverproject.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: k...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org

Suggested-by: Ingo Molnar 
Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/hypervisor.h | 25 --
 arch/x86/include/asm/x86_init.h   | 24 +
 arch/x86/kernel/apic/apic.c   |  2 +-
 arch/x86/kernel/cpu/hypervisor.c  | 54 +++
 arch/x86/kernel/cpu/mshyperv.c|  2 +-
 arch/x86/kernel/cpu/vmware.c  |  4 +--
 arch/x86/kernel/kvm.c |  2 +-
 arch/x86/kernel/x86_init.c|  9 +++
 arch/x86/mm/init.c|  2 +-
 arch/x86/xen/enlighten_hvm.c  |  8 +++---
 arch/x86/xen/enlighten_pv.c   |  2 +-
 include/linux/hypervisor.h|  8 --
 12 files changed, 81 insertions(+), 61 deletions(-)

diff --git a/arch/x86/include/asm/hypervisor.h 
b/arch/x86/include/asm/hypervisor.h
index 0ead9dbb9130..0eca7239a7aa 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -23,6 +23,7 @@
 #ifdef CONFIG_HYPERVISOR_GUEST
 
 #include 
+#include 
 #include 
 
 /*
@@ -35,17 +36,11 @@ struct hypervisor_x86 {
/* Detection routine */
uint32_t(*detect)(void);
 
-   /* Platform setup (run once per boot) */
-   void(*init_platform)(void);
+   /* init time callbacks */
+   struct x86_hyper_init init;
 
-   /* X2APIC detection (run once per boot) */
-   bool(*x2apic_available)(void);
-
-   /* pin current vcpu to specified physical cpu (run rarely) */
-   void(*pin_vcpu)(int);
-
-   /* called during init_mem_mapping() to setup early mappings. */
-   void(*init_mem_mapping)(void);
+   /* runtime callbacks */
+   struct x86_hyper_runtime runtime;
 };
 
 extern const struct hypervisor_x86 *x86_hyper;
@@ -58,17 +53,7 @@ extern const struct hypervisor_x86 x86_hyper_xen_hvm;
 extern const struct hypervisor_x86 x86_hyper_kvm;
 
 extern void init_hypervisor_platform(void);
-extern bool hypervisor_x2apic_available(void);
-extern void hypervisor_pin_vcpu(int cpu);
-
-static inline void hypervisor_init_mem_mapping(void)
-{
-   if (x86_hyper && x86_hyper->init_mem_mapping)
-   x86_hyper->init_mem_mapping();
-}
 #else
 static inline void init_hypervisor_platform(void) { }
-static inline bool hypervisor_x2apic_available(void) { return false; }
-static inline void hypervisor_init_mem_mapping(void) { }
 #endif /* CONFIG_HYPERVISOR_GUEST */
 #endif /* _ASM_X86_HYPERVISOR_H */
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 8a1ebf9540dd..ad15a0fda917 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -115,6 +115,18 @@ struct x86_init_pci {
 };
 
 /**
+ * struct x86_hyper_init - x86 hypervisor init functions
+ * @init_platform: platform setup
+ * @x2apic_available:  X2APIC detection
+ * @init_mem_mapping:  setup early mappings during init_mem_mapping()
+ */
+struct x86_hyper_init {
+   void (*init_platform)(void);
+   bool (*x2apic_available)(void);
+   void (*init_mem_mapping)(void);
+};
+
+/**
  * struct x86_init_ops - functions for platform specific setup
  *
  */
@@ -127,6 +139,7 @@ struct x86_init_ops {
struct x86_init_timers  timers;
struct x86_init_iommu   iommu;
struct x86_init_pci pci;
+   struct x86_hyper_init   hyper;
 };
 
 /**
@@ -200,6 +213,15 @@ struct x86_legacy_features {
 };
 
 /**
+ * struct x86_hyper_runtime - x86 hypervisor specific runtime callbacks
+ *
+ * @pin_vcpu:  pin current vcpu to specified physical cpu (run rarely)
+ */
+struct x86_hyper_runtime {
+   void (*pin_vcpu)(int cpu);
+};
+
+/**
  * struct x86_platform_ops - platform specific runtime functions
  * @calibrate_cpu: calibrate CPU
  * @calibrate_tsc: calibrate TSC, if different from CPU
@@ -218,6 +240,7 @@ struct x86_legacy_features {
  * possible in x86_early_init_platform_quirks() by
  * only using the current x86_hardware_subarch
  * semantics.
+ * @hyper: x86 hypervisor specific runtime callbacks
  */
 struct x86_platform_ops {
   

[Xen-devel] [PATCH v2 0/5] x86/xen: support booting PVH guest via standard boot path

[Juergen Gross]

Booting a Xen PVH guest requires a special boot entry as it is
mandatory to setup some Xen-specific interfaces rather early. When grub
or OVMF are used as boot loaders, however, those will fill the boot
parameters in zeropage and there is no longer a need to do something
PVH specific in the early boot path.

This patch series adds support for that scenario by identifying PVH
environment and doing the required init steps via Xen hooks instead of
using a dedicated boot entry.

The dedicated entry is still mandatory for support of Dom0 running in
PVH mode as in this case there is no grub or OVMF involved for filling
in the boot parameters.

Changes in V2:
- added new patches 1 and 2

Cc: k...@microsoft.com
Cc: haiya...@microsoft.com
Cc: sthem...@microsoft.com
Cc: akata...@vmware.com
Cc: pbonz...@redhat.com
Cc: rkrc...@redhat.com
Cc: boris.ostrov...@oracle.com
Cc: ru...@rustcorp.com.au
Cc: de...@linuxdriverproject.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: k...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
Cc: linux-graphics-maintai...@vmware.com
Cc: pv-driv...@vmware.com
Cc: dmitry.torok...@gmail.com
Cc: xdeguill...@vmware.com
Cc: moltm...@vmware.com
Cc: a...@arndb.de
Cc: gre...@linuxfoundation.org
Cc: linux-in...@vger.kernel.org
Cc: r...@rjwysocki.net
Cc: len.br...@intel.com
Cc: pa...@ucw.cz
Cc: linux...@vger.kernel.org

Juergen Gross (5):
  x86: merge x86_hyper into x86_platform and x86_init
  x86: add enum for hypervisors to replace x86_hyper
  x86/acpi: add test for ACPI_FADT_NO_VGA
  x86: add guest_late_init hook to hypervisor_x86 structure
  x86/xen: use guest_late_init to detect Xen PVH guest

 arch/x86/hyperv/hv_init.c |  2 +-
 arch/x86/include/asm/hypervisor.h | 46 +++-
 arch/x86/include/asm/kvm_para.h   |  2 --
 arch/x86/include/asm/x86_init.h   | 27 +
 arch/x86/kernel/acpi/boot.c   |  5 +++
 arch/x86/kernel/apic/apic.c   |  2 +-
 arch/x86/kernel/cpu/hypervisor.c  | 64 +--
 arch/x86/kernel/cpu/mshyperv.c|  6 ++--
 arch/x86/kernel/cpu/vmware.c  |  8 ++---
 arch/x86/kernel/kvm.c |  9 +++---
 arch/x86/kernel/setup.c   |  2 +-
 arch/x86/kernel/x86_init.c| 10 ++
 arch/x86/mm/init.c|  2 +-
 arch/x86/xen/enlighten_hvm.c  | 36 +-
 arch/x86/xen/enlighten_pv.c   |  6 ++--
 arch/x86/xen/enlighten_pvh.c  |  9 --
 drivers/hv/vmbus_drv.c|  2 +-
 drivers/input/mouse/vmmouse.c | 10 +++---
 drivers/misc/vmw_balloon.c|  2 +-
 include/linux/hypervisor.h|  8 +++--
 20 files changed, 153 insertions(+), 105 deletions(-)

-- 
2.12.3


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

Re: [Xen-devel] [PATCH 1/2 v2] xen: Add support for initializing 16550 UART using ACPI

[Jan Beulich]

>>> On 09.11.17 at 12:31,  wrote:
> On Thu, Nov 09, 2017 at 03:49:23PM +0530, Bhupinder Thakur wrote:
>> +static int ns16550_init_dt(struct ns16550 *uart,
>> +   const struct dt_device_node *dev)
>> +{
>> +return -EINVAL;
>> +}
>> +#endif
>> +
>> +#ifdef CONFIG_ACPI
>> +#include 
> 
> Please place the include at the top of the file, together with the
> other ones.

I disagree here, at least as long as that header isn't itself expanding
to nothing (or only stubs) when !CONFIG_ACPI.

Jan


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

[Xen-devel] Xen Nested Virtualization for HyperPlatform

[Kangjie Xi]

Hi,

I am researching
HyperPlatform(https://github.com/tandasat/HyperPlatform) recently, it
is a thin hypervisor based on Intel VT-x and EPT technology, it can't
create a new virtual machine but just turns the already running
Windows OS into its guest VM.

HyperPlatform works very well in VMware VM with Intel VT-x/EPT
enabled, however can't run in Xen VM with nested virtualizaiton, after
loading HyperPlatform, the VM hangs or BSOD.

I debug it with serial console and printk, add the following printks
to function nestedhvm_hap_nested_page_fault(), which will be called by
EPT violation exit handler.

...
  212 /* walk the L1 P2M table */
  213 rv = nestedhap_walk_L1_p2m(v, *L2_gpa, _gpa,
_order_21, _21,
  214 access_r, access_w, access_x);
+ 215 gdprintk(XENLOG_ERR, "nestedhap_walk_L1_p2m, rv: %d, L2_gpa:
%lx, L1_gpa: %lx\n", rv, *L2_gpa, L1_gpa);
...
  230 /* ==> we have to walk L0 P2M */
  231 rv = nestedhap_walk_L0_p2m(p2m, L1_gpa, _gpa,
  232 _10, _10, _order_10,
  233 access_r, access_w, access_x);
+ 234 gdprintk(XENLOG_ERR, "nestedhap_walk_L0_p2m, rv: %d, L1_gpa:
%lx, L0_gpa: %lx\n", rv, L1_gpa, L0_gpa);
...

The serial console output:

...
(XEN) nested_hap.c:215:d1v0 nestedhap_walk_L1_p2m, rv: 0, L2_gpa:
f100, L1_gpa: f100
(XEN) nested_hap.c:234:d1v0 nestedhap_walk_L0_p2m, rv: 3, L1_gpa:
f100, L0_gpa: 0
...
(XEN) nested_hap.c:215:d1v0 nestedhap_walk_L1_p2m, rv: 0, L2_gpa:
f1001000, L1_gpa: f1001000
(XEN) nested_hap.c:234:d1v0 nestedhap_walk_L0_p2m, rv: 3, L1_gpa:
f1001000, L0_gpa: 0
...

There are many "rv: 3", which is NESTEDHVM_PAGEFAULT_L0_ERROR,
returned by read-only check conditon:

170if ( access_w && p2m_is_readonly(*p2mt) )
171   goto out;

The address 0xf10 is the VM's display memory address
(0xF100-0xF1FF).

Is it a I/O virtualization error or MMIO error? Any idea to fix it?


Thanks

-Xi Kangjie

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

Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths

[Jan Beulich]

>>> On 09.11.17 at 12:01,  wrote:
> Anyway, as I was trying to explain replaying to Jan, although in this
> situation the issue manifests as a consequence of vCPU migration, I
> think it is indeed more general, as in, without even the need to
> consider a second pCPU:
> 
> pCPU1
> =
> current == vCPU1
> context_switch(next == idle)
> !! __context_switch() is skipped
> vcpu_migrate(vCPU1)
> anything_that_uses_or_touches_context()
> 
> So, it must be anything_that_uses_or_touches_context() --knowing it
> will be reading or touching the pCPU context-- that syncs the state,
> before using or touching it (which is, e.g., what Jan's patch does).

Well, generally after the vcpu_migrate(vCPU1) above we expect
nothing to happen at all on the pCPU, until another (non-idle)
vCPU gets scheduled onto it. The problem is with tasklet / softirq
(and hence also RCU) work. Tasklets already take care of this by
calling sync_local_execstate() before calling the handler. But
for softirqs this isn't really an option; I'm surprised to see that
tasklet code does this independently of what kind of tasklet that
is. Softirq tasklets aren't used very often, so I wonder if we have
a latent bug here. Otoh, if this was actually fine, adding a similar
call to rcu_do_batch() (or its caller) would be an option, I think.

Jan


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

Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths

[Jan Beulich]

>>> On 09.11.17 at 11:36,  wrote:
> Well, I'm afraid I only see two solutions:
> 1) we get rid of lazy context switch;
> 2) whatever it is that is happening at point c above, it needs to be 
>aware that we use lazy context switch, and make sure to sync the 
>context before playing with or altering it;

3) Better centralize the updating of v->processor, so that it becomes
reasonable to sync state there. Igor's idea of flushing state once it
is known (or at least pretty certain) that the vCPU won't run on the
prior pCPU next time it gets scheduled is certainly a reasonable one.
It just doesn't fit well with how the individual schedulers currently
behave.

Jan


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

Re: [Xen-devel] [PATCH] x86/mm: fix a potential race condition in map_pages_to_xen().

[Jan Beulich]

>>> On 09.11.17 at 11:24,  wrote:
> On 11/9/2017 5:19 PM, Jan Beulich wrote:
>> 2) Is your change actually enough to take care of all forms of the
>> race you describe? In particular, isn't it necessary to re-check PSE
>> after having taken the lock, in case another CPU has just finished
>> doing the re-consolidation?
> 
> Good question. :-)
> 
> I'd thought of checking the PSE for pl2e, and dropped that. My understanding
> was below:
> After the lock is taken, pl2e will be pointing to either a L1 page table 
> in normal
> cases; or to a superpage if another CPU has just finished the 
> re-consolidation
> and released the lock. And for the latter scenario, l1e_get_pfn(*pl1e) 
> shall not
> be equal to (base_mfn + i), and will not jump out the the loop.
> 
> But after second thought, above understanding is based on assumption of the
> contents of the target superpage. No matter how small the chance is, we can
> not make such assumption.
> 
> So my suggestion is we add the check the PSE and if it is set, "goto 
> check_l3".
> Is this reasonable to you?

Yes; for the L3 case it'll be a simple "continue" afaict.

>> 3) What about the empty checks in modify_xen_mappings()?
> 
> Oh. Thanks for the remind.
> Just had a look. It seems pl1e or pl2e may be freed more than once for the
> empty & free checks, due to lack of protection.
> So we'd better add a lock too, right?

Yes, I think so.

Jan


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

Re: [Xen-devel] [PATCH] mini-os: add a coding style file

[Wei Liu]

On Thu, Nov 09, 2017 at 01:35:49PM +0100, Juergen Gross wrote:
> On 09/11/17 13:31, Wei Liu wrote:
> > On Thu, Nov 09, 2017 at 01:10:12PM +0100, Juergen Gross wrote:
> >> Since carving out Mini-OS from the Xen repository there hasn't been a
> >> description of the preferred coding style. Copy the Xen CODING_STYLE
> >> file.
> >>
> > 
> > I welcome such addition. I have no opinion in actual style used though.
> > I just want consistency. :-)
> 
> Is this an Ack?
> 

Yes.

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] mini-os: add a coding style file

[Juergen Gross]

On 09/11/17 13:31, Wei Liu wrote:
> On Thu, Nov 09, 2017 at 01:10:12PM +0100, Juergen Gross wrote:
>> Since carving out Mini-OS from the Xen repository there hasn't been a
>> description of the preferred coding style. Copy the Xen CODING_STYLE
>> file.
>>
> 
> I welcome such addition. I have no opinion in actual style used though.
> I just want consistency. :-)

Is this an Ack?


Juergen

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

Re: [Xen-devel] [PATCH] mini-os: add a coding style file

[Wei Liu]

On Thu, Nov 09, 2017 at 01:10:12PM +0100, Juergen Gross wrote:
> Since carving out Mini-OS from the Xen repository there hasn't been a
> description of the preferred coding style. Copy the Xen CODING_STYLE
> file.
> 

I welcome such addition. I have no opinion in actual style used though.
I just want consistency. :-)

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

[Xen-devel] [linux-3.18 test] 115688: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 115495

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   6 xen-installfail pass in 115673
 test-amd64-amd64-examine  4 memdisk-try-append fail pass in 115673
 test-amd64-i386-xl-xsm   20 guest-start/debian.repeat  fail pass in 115673

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

version targeted for testing:
 linux943dc0b3ef9f0168494d6dca305cd0cf53a0b3d4
baseline version:
 linux4f823316dac3de3463dfbea2be3812102a76e246

Last test of basis   115495  2017-11-02 19:35:18 Z6 days
Testing same since   115673  2017-11-08 09:43:38 Z1 days2 attempts


People who touched revisions under test:
  Alexander Boyko 
  Andrew Morton 
  Andy Shevchenko 
  Arnd Bergmann 

[Xen-devel] [PATCH] mini-os: add a coding style file

[Juergen Gross]

Since carving out Mini-OS from the Xen repository there hasn't been a
description of the preferred coding style. Copy the Xen CODING_STYLE
file.

Signed-off-by: Juergen Gross 
---
 CODING_STYLE | 109 +++
 1 file changed, 109 insertions(+)
 create mode 100644 CODING_STYLE

diff --git a/CODING_STYLE b/CODING_STYLE
new file mode 100644
index 000..539aa60
--- /dev/null
+++ b/CODING_STYLE
@@ -0,0 +1,109 @@
+Coding Style for Mini-OS
+
+
+Indentation
+---
+
+Indenting uses spaces, not tabs - in contrast to Linux.  An indent
+level consists of four spaces.  Code within blocks is indented by one
+extra indent level.  The enclosing braces of a block are indented the
+same as the code _outside_ the block.  e.g.
+
+void fun(void)
+{
+/* One level of indent. */
+
+{
+/* A second level of indent. */
+}
+}
+
+White space
+---
+
+Space characters are used to spread out logical statements, such as in
+the condition of an if or while.  Spaces are placed between the
+keyword and the brackets surrounding the condition, between the
+brackets and the condition itself, and around binary operators (except
+the structure access operators, '.' and '->'). e.g.
+
+if ( (wibble & wombat) == 42 )
+{
+...
+
+There should be no trailing white space at the end of lines (including
+after the opening /* of a comment block).
+
+Line Length
+---
+
+Lines should be less than 80 characters in length.  Long lines should
+be split at sensible places and the trailing portions indented.
+
+User visible strings (e.g., printk() messages) should not be split so
+they can searched for more easily.
+
+Bracing
+---
+
+Braces ('{' and '}') are usually placed on a line of their own, except
+for the do/while loop.  This is unlike the Linux coding style and
+unlike K  do/while loops are an exception. e.g.:
+
+if ( condition )
+{
+/* Do stuff. */
+}
+else
+{
+/* Other stuff. */
+}
+
+while ( condition )
+{
+/* Do stuff. */
+}
+
+do {
+/* Do stuff. */
+} while ( condition );
+
+etc.
+
+Braces should be omitted for blocks with a single statement. e.g.,
+
+if ( condition )
+single_statement();
+
+Comments
+
+
+Only C style /* ... */ comments are to be used.  C++ style // comments
+should not be used.  Multi-word comments should begin with a capital
+letter.  Comments containing a single sentence may end with a full
+stop; comments containing several sentences must have a full stop
+after each sentence.
+
+Multi-line comment blocks should start and end with comment markers on
+separate lines and each line should begin with a leading '*'.
+
+/*
+ * Example, multi-line comment block.
+ *
+ * Note beginning and end markers on separate lines and leading '*'.
+ */
+
+Emacs local variables
+-
+
+A comment block containing local variables for emacs is permitted at
+the end of files.  It should be:
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.12.3


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

Re: [Xen-devel] [PATCH 1/2 v2] xen: Add support for initializing 16550 UART using ACPI

[Roger Pau Monné]

On Thu, Nov 09, 2017 at 03:49:23PM +0530, Bhupinder Thakur wrote:
> Currently, Xen supports only DT based initialization of 16550 UART.
> This patch adds support for initializing 16550 UART using ACPI SPCR table.
> 
> This patch also makes the uart initialization code common between DT and
> ACPI based initialization.
> 
> Signed-off-by: Bhupinder Thakur 
> ---
> TBD:
> There was one review comment from Julien about how the uart->io_size is being 
> calculated. Currently, I am calulating the io_size based on address of the 
> last
> UART register. 
> 
> pci_uart_config also calcualates the uart->io_size like this:
> 
> uart->io_size = max(8U << param->reg_shift,
>  param->uart_offset);
> 
> I am not sure whether we can use similar logic for calculating uart->io_size.
> 
> Changes since v1:
> - Reused common code between DT and ACPI based initializations
> 
> 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 
> CC: Julien Grall 
> 
>  xen/drivers/char/ns16550.c  | 132 
> 
>  xen/include/xen/8250-uart.h |   1 +
>  2 files changed, 121 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
> index e0f8199..cf42fce 100644
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -1463,18 +1463,13 @@ void __init ns16550_init(int index, struct 
> ns16550_defaults *defaults)
>  }
>  
>  #ifdef CONFIG_HAS_DEVICE_TREE
> -static int __init ns16550_uart_dt_init(struct dt_device_node *dev,
> -   const void *data)
> +static int ns16550_init_dt(struct ns16550 *uart,
> +   const struct dt_device_node *dev)

Why are you dropping the __init attribute?

>  {
> -struct ns16550 *uart;
> -int res;
> +int res = 0;
>  u32 reg_shift, reg_width;
>  u64 io_size;
>  
> -uart = _com[0];
> -
> -ns16550_init_common(uart);
> -
>  uart->baud  = BAUD_AUTO;
>  uart->data_bits = 8;
>  uart->parity= UART_PARITY_NONE;
> @@ -1510,18 +1505,103 @@ static int __init ns16550_uart_dt_init(struct 
> dt_device_node *dev,
>  
>  uart->dw_usr_bsy = dt_device_is_compatible(dev, "snps,dw-apb-uart");
>  
> +return res;
> +}
> +#else
> +static int ns16550_init_dt(struct ns16550 *uart,
> +   const struct dt_device_node *dev)
> +{
> +return -EINVAL;
> +}
> +#endif
> +
> +#ifdef CONFIG_ACPI
> +#include 

Please place the include at the top of the file, together with the
other ones.

> +static int ns16550_init_acpi(struct ns16550 *uart,
> + const void *data)
> +{
> +struct acpi_table_spcr *spcr = NULL;
> +int status = 0;

I don't think you need to initialize any of those two variables. Or
do:

int status = acpi_get_table(ACPI_SIG_SPCR, 0,
(struct acpi_table_header **));

if ( ... )


> +status = acpi_get_table(ACPI_SIG_SPCR, 0,
> +(struct acpi_table_header **));
> +
> +if ( ACPI_FAILURE(status) )
> +{
> +printk("ns16550: Failed to get SPCR table\n");
> +return -EINVAL;
> +}
> +
> +uart->baud  = BAUD_AUTO;
> +uart->data_bits = 8;
> +uart->parity= spcr->parity;
> +uart->stop_bits = spcr->stop_bits;
> +uart->io_base = spcr->serial_port.address;
> +uart->irq = spcr->interrupt;
> +uart->reg_width = spcr->serial_port.bit_width / 8;
> +uart->reg_shift = 0;
> +uart->io_size = UART_MAX_REG << uart->reg_shift;

You seem to align some of the '=' above but not all, please do either
one, but consistently.

> +
> +irq_set_type(spcr->interrupt, spcr->interrupt_type);
> +
> +return 0;
> +}
> +#else
> +static int ns16550_init_acpi(struct ns16550 *uart,
> + const void *data)
> +{
> +return -EINVAL;
> +}
> +#endif
> +
> +static int ns16550_uart_init(struct ns16550 **puart,
> + const void *data, bool acpi)
> +{
> +struct ns16550 *uart = _com[0];
> +
> +*puart = uart;
> +
> +ns16550_init_common(uart);
> +
> +return ( acpi ) ? ns16550_init_acpi(uart, data)
  ^ unneeded parentheses.

> +: ns16550_init_dt(uart, data);
> +}
> +
> +static void ns16550_vuart_init(struct ns16550 *uart)
> +{
> +#ifdef CONFIG_ARM
>  uart->vuart.base_addr = uart->io_base;
>  uart->vuart.size = uart->io_size;
> -uart->vuart.data_off = UART_THR  -uart->vuart.status_off = UART_LSR -uart->vuart.status = UART_LSR_THRE|UART_LSR_TEMT;
> +uart->vuart.data_off = 

[Xen-devel] [linux-4.9 test] 115686: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 115671 
pass in 115686
 test-amd64-amd64-xl-credit2  18 guest-localmigrate/x10 fail pass in 115671

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 115613

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail in 115671 like 
115597
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail in 115671 like 115613
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 115566
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeatfail  like 115582
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeatfail like 115613
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115613
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 115613
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115613
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115613
 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-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-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-i386-libvirt-qcow2 12 migrate-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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-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:
 linux5caae9d1419914177994363218616b869659e871
baseline version:
 linux06b639e5a1a665ba6c959398ea0e6171c162028b

Last test of basis   115613  2017-11-06 11:54:23 Z2 days
Testing same since   115671  2017-11-08 09:38:13 Z1 days2 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Aditya Pandit 

Re: [Xen-devel] [Qemu-devel] [PATCH v3] xen-disk: use an IOThread per instance

[Stefan Hajnoczi]

On Thu, Nov 09, 2017 at 09:30:45AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Stefan Hajnoczi [mailto:stefa...@gmail.com]
> > Sent: 08 November 2017 17:42
> > To: Paul Durrant 
> > Cc: qemu-de...@nongnu.org; xen-de...@lists.xenproject.org; Anthony
> > Perard ; Kevin Wolf ;
> > Stefano Stabellini ; Max Reitz 
> > Subject: Re: [Qemu-devel] [PATCH v3] xen-disk: use an IOThread per
> > instance
> > 
> > On Tue, Nov 07, 2017 at 05:46:53AM -0500, Paul Durrant wrote:
> > > This patch allocates an IOThread object for each xen_disk instance and
> > > sets the AIO context appropriately on connect. This allows processing
> > > of I/O to proceed in parallel.
> > >
> > > The patch also adds tracepoints into xen_disk to make it possible to
> > > follow the state transtions of an instance in the log.
> > 
> > virtio-blk and virtio-scsi allow the user to specify an IOThread object.
> > This allows users to configure the device<->IOThread mapping any way
> > they like (e.g. 1:1, M:N).  Are you sure you want to hard-code the
> > IOThread mapping?
> 
> Stefan,
> 
>   Realistically it's the only option at the moment. Xen PV backends are not 
> configured bu QAPI... so no ability to control them from the command line or 
> QMP. This is something I seriously intend to address in the near future but, 
> for now, I simply want to unlock the performance boost that IOThread can 
> provide.

Okay.

Stefan


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 for-next 6/9] kconfig/gcov: rename to coverage

[Roger Pau Monne]

So it can be used by both gcc and clang. Just add the Kconfig option
and modify the makefiles so the llvm coverage specific code can be
added in a follow up patch.

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 v1:
 - Use a choice in kconfig to select code coverage technology.
 - Compile coverage.c regardless of selected code coverage technology.
 - Introduce an unimplemented sysctl_cov_op function if
   CONFIG_COVERAGE is not set.
---
 docs/misc/coverage.markdown  | 2 +-
 xen/Kconfig.debug| 7 +++
 xen/Rules.mk | 6 +-
 xen/common/Makefile  | 2 +-
 xen/common/coverage/Makefile | 5 -
 xen/common/sysctl.c  | 2 --
 xen/include/xen/coverage.h   | 7 ++-
 7 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/docs/misc/coverage.markdown b/docs/misc/coverage.markdown
index b47aba2648..430cd27b2f 100644
--- a/docs/misc/coverage.markdown
+++ b/docs/misc/coverage.markdown
@@ -10,7 +10,7 @@ down your hypervisor.
 
 ## Enable coverage
 
-Test coverage support can be turned on compiling Xen with the `CONFIG_GCOV`
+Test coverage support can be turned on compiling Xen with the `CONFIG_COVERAGE`
 option set to `y`.
 
 Change your `.config` or run `make -C xen menuconfig`.
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 7bb0465b5d..153d68fed3 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -28,12 +28,11 @@ config FRAME_POINTER
  maybe slower, but it gives very useful debugging information
  in case of any Xen bugs.
 
-config GCOV
-   bool "Gcov Support"
+config COVERAGE
+   bool "Code coverage support"
depends on !LIVEPATCH
-   select SUPPRESS_DUPLICATE_SYMBOL_WARNINGS
---help---
- Enable gcov (a test coverage program in GCC) support.
+ Enable code coverage support.
 
  If unsure, say N here.
 
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 2659f8a4d1..d1b72e24ab 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -115,9 +115,13 @@ subdir-all := $(subdir-y) $(subdir-n)
 
 $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += 
-DINIT_SECTIONS_ONLY
 
-ifeq ($(CONFIG_GCOV),y)
+ifeq ($(CONFIG_COVERAGE),y)
+ifeq ($(clang),y)
+$(filter-out %.init.o $(nogcov-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += 
-fprofile-instr-generate -fcoverage-mapping
+else
 $(filter-out %.init.o $(nogcov-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += 
-fprofile-arcs -ftest-coverage
 endif
+endif
 
 ifeq ($(CONFIG_UBSAN),y)
 $(filter-out %.init.o $(noubsan-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS 
+= -fsanitize=undefined
diff --git a/xen/common/Makefile b/xen/common/Makefile
index ad181636f6..3a349f478b 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -74,7 +74,7 @@ tmem-y := tmem.o tmem_xen.o tmem_control.o
 tmem-$(CONFIG_COMPAT) += compat/tmem_xen.o
 obj-$(CONFIG_TMEM) += $(tmem-y)
 
-subdir-$(CONFIG_GCOV) += coverage
+subdir-$(CONFIG_COVERAGE) += coverage
 subdir-$(CONFIG_UBSAN) += ubsan
 
 subdir-y += libelf
diff --git a/xen/common/coverage/Makefile b/xen/common/coverage/Makefile
index 5387bc6429..1039a160c4 100644
--- a/xen/common/coverage/Makefile
+++ b/xen/common/coverage/Makefile
@@ -1,6 +1,9 @@
-obj-y += coverage.o gcov_base.o gcov.o
+obj-y += coverage.o
+ifneq ($(clang),y)
+obj-y += gcov_base.o gcov.o
 obj-y += $(call cc-ifversion,lt,0x040700, \
gcc_3_4.o, $(call cc-ifversion,lt,0x040900, \
gcc_4_7.o, $(call cc-ifversion,lt,0x05, \
gcc_4_9.o, $(call cc-ifversion,lt,0x07, \
gcc_5.o, gcc_7.o
+endif
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index f2ae6295ff..8e83c33a16 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -396,12 +396,10 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 }
 break;
 
-#ifdef CONFIG_GCOV
 case XEN_SYSCTL_coverage_op:
 ret = sysctl_cov_op(>u.coverage_op);
 copyback = 1;
 break;
-#endif
 
 #ifdef CONFIG_HAS_PCI
 case XEN_SYSCTL_pcitopoinfo:
diff --git a/xen/include/xen/coverage.h b/xen/include/xen/coverage.h
index daddef37d3..098f116760 100644
--- a/xen/include/xen/coverage.h
+++ b/xen/include/xen/coverage.h
@@ -1,9 +1,14 @@
 #ifndef _XEN_COV_H
 #define _XEN_COV_H
 
-#ifdef CONFIG_GCOV
+#ifdef CONFIG_COVERAGE
 #include 
 int sysctl_cov_op(struct xen_sysctl_coverage_op *op);
+#else
+static inline int sysctl_cov_op(void *unused)
+{
+return -ENOSYS;
+}
 #endif
 
 #endif /* _XEN_GCOV_H */
-- 
2.13.6 (Apple Git-96)


___
Xen-devel mailing list
Xen-devel@lists.xen.org

[Xen-devel] [PATCH v2 for-next 7/9] coverage: introduce support for llvm profiling

[Roger Pau Monne]

Introduce the functionality in order to fill the hooks of the
cov_sysctl_ops struct. Note that the functionality is still not wired
into the build system.

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 
---
Note that the file that contains the helpers is under a BSD 2-clause
license. This is done so it can be shared with other OSes that use the
llvm/clang compiler.
---
Changes since v1:
 - Include private coverage.h header.
 - Define LLVM_PROFILE_MAGIC based on the bitness of the arch.
 - Add a comment regarding __llvm_profile_runtime.
 - Constify data/names extern symbols.
 - Use defines instead of variables to store the addresses of the
   external symbols.
 - Parenthesize size in APPEND_TO_BUFFER.
 - Use >= for minor version check.
 - Use sizeof(header).
---
 xen/common/coverage/Makefile |   2 +
 xen/common/coverage/llvm.c   | 154 +++
 xen/include/public/sysctl.h  |   6 ++
 3 files changed, 162 insertions(+)
 create mode 100644 xen/common/coverage/llvm.c

diff --git a/xen/common/coverage/Makefile b/xen/common/coverage/Makefile
index 1039a160c4..46c78d1086 100644
--- a/xen/common/coverage/Makefile
+++ b/xen/common/coverage/Makefile
@@ -6,4 +6,6 @@ obj-y += $(call cc-ifversion,lt,0x040700, \
gcc_4_7.o, $(call cc-ifversion,lt,0x05, \
gcc_4_9.o, $(call cc-ifversion,lt,0x07, \
gcc_5.o, gcc_7.o
+else
+obj-y += llvm.o
 endif
diff --git a/xen/common/coverage/llvm.c b/xen/common/coverage/llvm.c
new file mode 100644
index 00..889699a9a0
--- /dev/null
+++ b/xen/common/coverage/llvm.c
@@ -0,0 +1,154 @@
+/*
+ * Copyright (C) 2017 Citrix Systems R
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+
+#include "coverage.h"
+
+#ifndef __clang__
+#error "LLVM coverage selected without clang compiler"
+#endif
+
+#if BITS_PER_LONG == 64
+#define LLVM_PROFILE_MAGIC (((uint64_t)255 << 56) | ((uint64_t)'l' << 48) | \
+((uint64_t)'p' << 40) | ((uint64_t)'r' << 32) | ((uint64_t)'o' << 24) | \
+((uint64_t)'f' << 16) | ((uint64_t)'r' << 8)  | ((uint64_t)129))
+#else
+#define LLVM_PROFILE_MAGIC (((uint64_t)255 << 56) | ((uint64_t)'l' << 48) | \
+((uint64_t)'p' << 40) | ((uint64_t)'r' << 32) | ((uint64_t)'o' << 24) | \
+((uint64_t)'f' << 16) | ((uint64_t)'R' << 8)  | ((uint64_t)129)
+#endif
+
+#if __clang_major__ >= 4 || (__clang_major__ == 3 && __clang_minor__ >= 9)
+#define LLVM_PROFILE_VERSION4
+#define LLVM_PROFILE_NUM_KINDS  2
+#else
+#error "clang version not supported with coverage"
+#endif
+
+struct llvm_profile_data {
+uint64_t name_ref;
+uint64_t function_hash;
+void *counter;
+void *function;
+void *values;
+uint32_t nr_counters;
+uint16_t nr_value_sites[LLVM_PROFILE_NUM_KINDS];
+};
+
+struct llvm_profile_header {
+uint64_t magic;
+uint64_t version;
+uint64_t data_size;
+uint64_t counters_size;
+uint64_t names_size;
+uint64_t counters_delta;
+uint64_t names_delta;
+uint64_t value_kind_last;
+};
+
+/*
+ * Since Xen uses the llvm code coverage support without the run time library
+ * __llvm_profile_runtime must be defined according to the docs at:
+ *
+ * https://clang.llvm.org/docs/SourceBasedCodeCoverage.html
+ */
+int __llvm_profile_runtime;
+
+extern const struct llvm_profile_data 

[Xen-devel] [PATCH v2 for-next 4/9] gcov: introduce hooks for the sysctl

[Roger Pau Monne]

So that other implementations of the sysctl can be added.

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 v1:
 - Constify cov_ops.
 - Introduce a local coverage.h provate header and place the
   definition of cov_sysctl_ops there.
---
 xen/common/coverage/coverage.h | 12 
 xen/common/coverage/gcov.c | 13 ++---
 2 files changed, 22 insertions(+), 3 deletions(-)
 create mode 100644 xen/common/coverage/coverage.h

diff --git a/xen/common/coverage/coverage.h b/xen/common/coverage/coverage.h
new file mode 100644
index 00..4613d5e6c1
--- /dev/null
+++ b/xen/common/coverage/coverage.h
@@ -0,0 +1,12 @@
+#ifndef _XEN_COV_PRIV_H
+#define _XEN_COV_PRIV_H
+
+#include 
+
+struct cov_sysctl_ops {
+uint32_t (*get_size)(void);
+void (*reset_counters)(void);
+int  (*dump)(XEN_GUEST_HANDLE_PARAM(char), uint32_t *);
+};
+
+#endif
diff --git a/xen/common/coverage/gcov.c b/xen/common/coverage/gcov.c
index 798032cbbb..8627ef3355 100644
--- a/xen/common/coverage/gcov.c
+++ b/xen/common/coverage/gcov.c
@@ -22,6 +22,7 @@
 
 #include 
 
+#include "coverage.h"
 #include "gcov.h"
 
 /**
@@ -209,6 +210,12 @@ static int gcov_dump_all(XEN_GUEST_HANDLE_PARAM(char) 
buffer,
 return ret;
 }
 
+static const struct cov_sysctl_ops cov_ops = {
+.get_size = gcov_get_size,
+.reset_counters = gcov_reset_all_counters,
+.dump = gcov_dump_all,
+};
+
 int sysctl_cov_op(struct xen_sysctl_coverage_op *op)
 {
 int ret;
@@ -216,7 +223,7 @@ int sysctl_cov_op(struct xen_sysctl_coverage_op *op)
 switch ( op->cmd )
 {
 case XEN_SYSCTL_COVERAGE_get_size:
-op->size = gcov_get_size();
+op->size = cov_ops.get_size();
 ret = 0;
 break;
 
@@ -227,14 +234,14 @@ int sysctl_cov_op(struct xen_sysctl_coverage_op *op)
 
 buf = guest_handle_cast(op->buffer, char);
 
-ret = gcov_dump_all(buf, );
+ret = cov_ops.dump(buf, );
 op->size = size;
 
 break;
 }
 
 case XEN_SYSCTL_COVERAGE_reset:
-gcov_reset_all_counters();
+cov_ops.reset_counters();
 ret = 0;
 break;
 
-- 
2.13.6 (Apple Git-96)


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

[Xen-devel] [PATCH v2 for-next 2/9] gcov: rename folder and header to coverage

[Roger Pau Monne]

Preparatory change before adding llvm profiling support.
No functional change.

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 v1:
 - Rename guard in coverage.h header.
---
 xen/common/Makefile   | 2 +-
 xen/common/{gcov => coverage}/Makefile| 0
 xen/common/{gcov => coverage}/gcc_3_4.c   | 0
 xen/common/{gcov => coverage}/gcc_4_7.c   | 0
 xen/common/{gcov => coverage}/gcc_4_9.c   | 0
 xen/common/{gcov => coverage}/gcc_5.c | 0
 xen/common/{gcov => coverage}/gcc_7.c | 0
 xen/common/{gcov => coverage}/gcov.c  | 0
 xen/common/{gcov => coverage}/gcov.h  | 0
 xen/common/{gcov => coverage}/gcov_base.c | 0
 xen/common/sysctl.c   | 2 +-
 xen/include/xen/{gcov.h => coverage.h}| 4 ++--
 12 files changed, 4 insertions(+), 4 deletions(-)
 rename xen/common/{gcov => coverage}/Makefile (100%)
 rename xen/common/{gcov => coverage}/gcc_3_4.c (100%)
 rename xen/common/{gcov => coverage}/gcc_4_7.c (100%)
 rename xen/common/{gcov => coverage}/gcc_4_9.c (100%)
 rename xen/common/{gcov => coverage}/gcc_5.c (100%)
 rename xen/common/{gcov => coverage}/gcc_7.c (100%)
 rename xen/common/{gcov => coverage}/gcov.c (100%)
 rename xen/common/{gcov => coverage}/gcov.h (100%)
 rename xen/common/{gcov => coverage}/gcov_base.c (100%)
 rename xen/include/xen/{gcov.h => coverage.h} (76%)

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 66cc2c8995..ad181636f6 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -74,7 +74,7 @@ tmem-y := tmem.o tmem_xen.o tmem_control.o
 tmem-$(CONFIG_COMPAT) += compat/tmem_xen.o
 obj-$(CONFIG_TMEM) += $(tmem-y)
 
-subdir-$(CONFIG_GCOV) += gcov
+subdir-$(CONFIG_GCOV) += coverage
 subdir-$(CONFIG_UBSAN) += ubsan
 
 subdir-y += libelf
diff --git a/xen/common/gcov/Makefile b/xen/common/coverage/Makefile
similarity index 100%
rename from xen/common/gcov/Makefile
rename to xen/common/coverage/Makefile
diff --git a/xen/common/gcov/gcc_3_4.c b/xen/common/coverage/gcc_3_4.c
similarity index 100%
rename from xen/common/gcov/gcc_3_4.c
rename to xen/common/coverage/gcc_3_4.c
diff --git a/xen/common/gcov/gcc_4_7.c b/xen/common/coverage/gcc_4_7.c
similarity index 100%
rename from xen/common/gcov/gcc_4_7.c
rename to xen/common/coverage/gcc_4_7.c
diff --git a/xen/common/gcov/gcc_4_9.c b/xen/common/coverage/gcc_4_9.c
similarity index 100%
rename from xen/common/gcov/gcc_4_9.c
rename to xen/common/coverage/gcc_4_9.c
diff --git a/xen/common/gcov/gcc_5.c b/xen/common/coverage/gcc_5.c
similarity index 100%
rename from xen/common/gcov/gcc_5.c
rename to xen/common/coverage/gcc_5.c
diff --git a/xen/common/gcov/gcc_7.c b/xen/common/coverage/gcc_7.c
similarity index 100%
rename from xen/common/gcov/gcc_7.c
rename to xen/common/coverage/gcc_7.c
diff --git a/xen/common/gcov/gcov.c b/xen/common/coverage/gcov.c
similarity index 100%
rename from xen/common/gcov/gcov.c
rename to xen/common/coverage/gcov.c
diff --git a/xen/common/gcov/gcov.h b/xen/common/coverage/gcov.h
similarity index 100%
rename from xen/common/gcov/gcov.h
rename to xen/common/coverage/gcov.h
diff --git a/xen/common/gcov/gcov_base.c b/xen/common/coverage/gcov_base.c
similarity index 100%
rename from xen/common/gcov/gcov_base.c
rename to xen/common/coverage/gcov_base.c
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 08198b7150..56def766e6 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
diff --git a/xen/include/xen/gcov.h b/xen/include/xen/coverage.h
similarity index 76%
rename from xen/include/xen/gcov.h
rename to xen/include/xen/coverage.h
index ef22eafc1f..b34c304cba 100644
--- a/xen/include/xen/gcov.h
+++ b/xen/include/xen/coverage.h
@@ -1,5 +1,5 @@
-#ifndef _XEN_GCOV_H
-#define _XEN_GCOV_H
+#ifndef _XEN_COV_H
+#define _XEN_COV_H
 
 #ifdef CONFIG_GCOV
 #include 
-- 
2.13.6 (Apple Git-96)


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

[Xen-devel] [PATCH v2 for-next 5/9] coverage: introduce generic file

[Roger Pau Monne]

It will contain the generic implementation of sysctl_cov_op, which
will be shared between all the coverage implementations.

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 v1:
 - Use private coverage.h header.
 - Sort alphabetically the obj-y list.
---
 xen/common/coverage/Makefile   |  2 +-
 xen/common/coverage/coverage.c | 73 ++
 xen/common/coverage/coverage.h |  1 +
 xen/common/coverage/gcov.c | 39 +-
 4 files changed, 76 insertions(+), 39 deletions(-)
 create mode 100644 xen/common/coverage/coverage.c

diff --git a/xen/common/coverage/Makefile b/xen/common/coverage/Makefile
index a7a48494ca..5387bc6429 100644
--- a/xen/common/coverage/Makefile
+++ b/xen/common/coverage/Makefile
@@ -1,4 +1,4 @@
-obj-y += gcov_base.o gcov.o
+obj-y += coverage.o gcov_base.o gcov.o
 obj-y += $(call cc-ifversion,lt,0x040700, \
gcc_3_4.o, $(call cc-ifversion,lt,0x040900, \
gcc_4_7.o, $(call cc-ifversion,lt,0x05, \
diff --git a/xen/common/coverage/coverage.c b/xen/common/coverage/coverage.c
new file mode 100644
index 00..bd90f28663
--- /dev/null
+++ b/xen/common/coverage/coverage.c
@@ -0,0 +1,73 @@
+/*
+ * Generic functionality for coverage analysis.
+ *
+ * Copyright (C) 2017 Citrix Systems R
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "coverage.h"
+
+int sysctl_cov_op(struct xen_sysctl_coverage_op *op)
+{
+int ret;
+
+switch ( op->cmd )
+{
+case XEN_SYSCTL_COVERAGE_get_size:
+op->size = cov_ops.get_size();
+ret = 0;
+break;
+
+case XEN_SYSCTL_COVERAGE_read:
+{
+XEN_GUEST_HANDLE_PARAM(char) buf;
+uint32_t size = op->size;
+
+buf = guest_handle_cast(op->buffer, char);
+
+ret = cov_ops.dump(buf, );
+op->size = size;
+
+break;
+}
+
+case XEN_SYSCTL_COVERAGE_reset:
+cov_ops.reset_counters();
+ret = 0;
+break;
+
+default:
+ret = -EOPNOTSUPP;
+break;
+}
+
+return ret;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/coverage/coverage.h b/xen/common/coverage/coverage.h
index 4613d5e6c1..003bb76950 100644
--- a/xen/common/coverage/coverage.h
+++ b/xen/common/coverage/coverage.h
@@ -8,5 +8,6 @@ struct cov_sysctl_ops {
 void (*reset_counters)(void);
 int  (*dump)(XEN_GUEST_HANDLE_PARAM(char), uint32_t *);
 };
+extern const struct cov_sysctl_ops cov_ops;
 
 #endif
diff --git a/xen/common/coverage/gcov.c b/xen/common/coverage/gcov.c
index 8627ef3355..3cc98728bf 100644
--- a/xen/common/coverage/gcov.c
+++ b/xen/common/coverage/gcov.c
@@ -210,49 +210,12 @@ static int gcov_dump_all(XEN_GUEST_HANDLE_PARAM(char) 
buffer,
 return ret;
 }
 
-static const struct cov_sysctl_ops cov_ops = {
+const struct cov_sysctl_ops cov_ops = {
 .get_size = gcov_get_size,
 .reset_counters = gcov_reset_all_counters,
 .dump = gcov_dump_all,
 };
 
-int sysctl_cov_op(struct xen_sysctl_coverage_op *op)
-{
-int ret;
-
-switch ( op->cmd )
-{
-case XEN_SYSCTL_COVERAGE_get_size:
-op->size = cov_ops.get_size();
-ret = 0;
-break;
-
-case XEN_SYSCTL_COVERAGE_read:
-{
-XEN_GUEST_HANDLE_PARAM(char) buf;
-uint32_t size = op->size;
-
-buf = guest_handle_cast(op->buffer, char);
-
-ret = cov_ops.dump(buf, );
-op->size = size;
-
-break;
-}
-
-case XEN_SYSCTL_COVERAGE_reset:
-cov_ops.reset_counters();
-ret = 0;
-break;
-
-default:
-ret = -EOPNOTSUPP;
-break;
-}
-
-return ret;
-}
-
 /*
  * Local variables:
  * mode: C
-- 
2.13.6 (Apple Git-96)


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

[Xen-devel] [PATCH v2 for-next 8/9] xsm: add bodge when compiling with llvm coverage support

[Roger Pau Monne]

llvm coverage support seems to disable some of the optimizations
needed in order to compile xsm, and the end result is that references
to __xsm_action_mismatch_detected are left in the object files.

Since coverage support cannot be used in production, introduce
__xsm_action_mismatch_detected for llvm coverage builds.

Signed-off-by: Roger Pau Monné 
---
Cc: Daniel De Graaf 
---
Changes since v1:
 - Add inline.
 - Use CONIFG_COVERAGE and __clang__ to detect if the bodge is needed.
---
 xen/include/xsm/dummy.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index b2cd56cdc5..2c39ae2e6b 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -24,8 +24,22 @@
  * if references remain at link time.
  */
 #define LINKER_BUG_ON(x) do { if (x) __xsm_action_mismatch_detected(); } while 
(0)
+
+#if defined(CONFIG_COVERAGE) && defined(__clang__)
+/*
+ * LLVM coverage support seems to disable some of the optimizations needed in
+ * order for XSM to compile. Since coverage should not be used in production
+ * provide an implementation of __xsm_action_mismatch_detected to satisfy the
+ * linker.
+ */
+static inline void __xsm_action_mismatch_detected(void)
+{
+ASSERT_UNREACHABLE();
+}
+#else
 /* DO NOT implement this function; it is supposed to trigger link errors */
 void __xsm_action_mismatch_detected(void);
+#endif
 
 #ifdef CONFIG_XSM
 
-- 
2.13.6 (Apple Git-96)


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

[Xen-devel] [PATCH v2 for-next 3/9] gcov: rename sysctl and functions

[Roger Pau Monne]

Change gcov to cov (for internal interfaces) or coverage (for the
public ones).

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:
 - Use coverage instead of cov in the public interface.
---
 tools/misc/xencov.c | 28 ++--
 xen/common/coverage/gcov.c  |  8 
 xen/common/sysctl.c |  4 ++--
 xen/include/public/sysctl.h | 12 ++--
 xen/include/xen/coverage.h  |  2 +-
 5 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
index 4130f425dc..e5b40dba9c 100644
--- a/tools/misc/xencov.c
+++ b/tools/misc/xencov.c
@@ -26,31 +26,31 @@
 
 static xc_interface *xch = NULL;
 
-int gcov_sysctl(int op, struct xen_sysctl *sysctl,
-struct xc_hypercall_buffer *buf, uint32_t buf_size)
+int cov_sysctl(int op, struct xen_sysctl *sysctl,
+   struct xc_hypercall_buffer *buf, uint32_t buf_size)
 {
 DECLARE_HYPERCALL_BUFFER_ARGUMENT(buf);
 
 memset(sysctl, 0, sizeof(*sysctl));
-sysctl->cmd = XEN_SYSCTL_gcov_op;
+sysctl->cmd = XEN_SYSCTL_coverage_op;
 
-sysctl->u.gcov_op.cmd = op;
-sysctl->u.gcov_op.size = buf_size;
-set_xen_guest_handle(sysctl->u.gcov_op.buffer, buf);
+sysctl->u.coverage_op.cmd = op;
+sysctl->u.coverage_op.size = buf_size;
+set_xen_guest_handle(sysctl->u.coverage_op.buffer, buf);
 
 return xc_sysctl(xch, sysctl);
 }
 
-static void gcov_read(const char *fn)
+static void cov_read(const char *fn)
 {
 struct xen_sysctl sys;
 uint32_t total_len;
 DECLARE_HYPERCALL_BUFFER(uint8_t, p);
 FILE *f;
 
-if (gcov_sysctl(XEN_SYSCTL_GCOV_get_size, , NULL, 0) < 0)
+if (cov_sysctl(XEN_SYSCTL_COVERAGE_get_size, , NULL, 0) < 0)
 err(1, "getting total length");
-total_len = sys.u.gcov_op.size;
+total_len = sys.u.coverage_op.size;
 
 /* Shouldn't exceed a few hundred kilobytes */
 if (total_len > 8u * 1024u * 1024u)
@@ -61,7 +61,7 @@ static void gcov_read(const char *fn)
 err(1, "allocating buffer");
 
 memset(p, 0, total_len);
-if (gcov_sysctl(XEN_SYSCTL_GCOV_read, , HYPERCALL_BUFFER(p),
+if (cov_sysctl(XEN_SYSCTL_COVERAGE_read, , HYPERCALL_BUFFER(p),
 total_len) < 0)
 err(1, "getting gcov data");
 
@@ -82,11 +82,11 @@ static void gcov_read(const char *fn)
 xc_hypercall_buffer_free(xch, p);
 }
 
-static void gcov_reset(void)
+static void cov_reset(void)
 {
 struct xen_sysctl sys;
 
-if (gcov_sysctl(XEN_SYSCTL_GCOV_reset, , NULL, 0) < 0)
+if (cov_sysctl(XEN_SYSCTL_COVERAGE_reset, , NULL, 0) < 0)
 err(1, "resetting gcov information");
 }
 
@@ -126,9 +126,9 @@ int main(int argc, char **argv)
 err(1, "opening xc interface");
 
 if (strcmp(argv[0], "reset") == 0)
-gcov_reset();
+cov_reset();
 else if (strcmp(argv[0], "read") == 0)
-gcov_read(argc > 1 ? argv[1] : "-");
+cov_read(argc > 1 ? argv[1] : "-");
 else
 usage(1);
 
diff --git a/xen/common/coverage/gcov.c b/xen/common/coverage/gcov.c
index 283d2eec86..798032cbbb 100644
--- a/xen/common/coverage/gcov.c
+++ b/xen/common/coverage/gcov.c
@@ -209,18 +209,18 @@ static int gcov_dump_all(XEN_GUEST_HANDLE_PARAM(char) 
buffer,
 return ret;
 }
 
-int sysctl_gcov_op(struct xen_sysctl_gcov_op *op)
+int sysctl_cov_op(struct xen_sysctl_coverage_op *op)
 {
 int ret;
 
 switch ( op->cmd )
 {
-case XEN_SYSCTL_GCOV_get_size:
+case XEN_SYSCTL_COVERAGE_get_size:
 op->size = gcov_get_size();
 ret = 0;
 break;
 
-case XEN_SYSCTL_GCOV_read:
+case XEN_SYSCTL_COVERAGE_read:
 {
 XEN_GUEST_HANDLE_PARAM(char) buf;
 uint32_t size = op->size;
@@ -233,7 +233,7 @@ int sysctl_gcov_op(struct xen_sysctl_gcov_op *op)
 break;
 }
 
-case XEN_SYSCTL_GCOV_reset:
+case XEN_SYSCTL_COVERAGE_reset:
 gcov_reset_all_counters();
 ret = 0;
 break;
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 56def766e6..f2ae6295ff 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -397,8 +397,8 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 break;
 
 #ifdef CONFIG_GCOV
-case XEN_SYSCTL_gcov_op:
-ret = sysctl_gcov_op(>u.gcov_op);
+case XEN_SYSCTL_coverage_op:
+ret = sysctl_cov_op(>u.coverage_op);
 copyback = 1;
 break;
 #endif
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 6140f1a059..3566f2eb69 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -646,11 +646,11 @@ struct 

[Xen-devel] [PATCH v2 for-next 9/9] coverage: add documentation for LLVM coverage

[Roger Pau Monne]

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 v1:
 - s/gmake/make/.
 - Fix gcov section to mention CONFIG_COVERAGE instead of CONFIG_GCOV.
---
 docs/misc/coverage.markdown | 47 +
 1 file changed, 47 insertions(+)

diff --git a/docs/misc/coverage.markdown b/docs/misc/coverage.markdown
index 430cd27b2f..3554659fe4 100644
--- a/docs/misc/coverage.markdown
+++ b/docs/misc/coverage.markdown
@@ -8,6 +8,8 @@ information. Every basic block in the code will be instrumented 
by the compiler
 to compute these statistics. It should not be used in production as it slows
 down your hypervisor.
 
+# GCOV (GCC coverage)
+
 ## Enable coverage
 
 Test coverage support can be turned on compiling Xen with the `CONFIG_COVERAGE`
@@ -75,3 +77,48 @@ blob extracted from xencov!**
 * See output in a browser
 
 firefox cov/index.html
+
+# LLVM coverage
+
+## Enable coverage
+
+Coverage can be enabled using a Kconfig option, from the top-level directory
+use the following command to display the Kconfig menu:
+
+make -C xen menuconfig clang=y
+
+The code coverage option can be found inside of the "Debugging Options"
+section. After enabling it just compile Xen as you would normally do:
+
+make xen clang=y
+
+## Extract coverage data
+
+LLVM coverage can be extracted from the hypervisor using the `xencov` tool.
+The following actions are available:
+
+* `xencov read` extract data
+* `xencov reset` reset all coverage counters
+* `xencov read-reset` extract data and reset counters at the same time.
+
+## Possible use
+
+**This section is just an example on how to use these tools!**
+
+This example assumes you compiled Xen and copied the xen-syms file from
+xen/xen-syms into your current directory.
+
+* Extract the coverage data from Xen:
+
+xencov read xen.profraw
+
+* Convert the data into a profile. Note that you can merge more than one
+  profraw file into a single profdata file.
+
+llvm-profdata merge xen.profraw -o xen.profdata
+
+* Generate a HTML report of the code coverage:
+
+llvm-cov show -format=html -output-dir=cov/ xen-syms 
-instr-profile=xen.profdata
+
+* Open cov/index.html with your browser in order to display the profile.
-- 
2.13.6 (Apple Git-96)


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