[Xen-devel] [ovmf baseline-only test] 75083: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75083 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75083/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75076
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install  fail like 75076

version targeted for testing:
 ovmf 52047be0243074f50fab45650f36ae693c93d1b3
baseline version:
 ovmf cb5f4f45ce1fca390b99dae5c42b9c4c8b53deea

Last test of basis75076  2018-08-16 11:57:45 Z1 days
Testing same since75083  2018-08-17 17:55:24 Z0 days1 attempts


People who touched revisions under test:
  Bob Feng 
  Carsey, Jaben 
  Eric Dong 
  Feng, Bob C 
  hchen30 
  Hess Chen 
  Jaben Carsey 
  Laszlo Ersek 
  Liming Gao 
  Ruiyu Ni 
  Star Zeng 
  Yonghong Zhu 
  Yunhua Feng 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xensource.com/osstest/logs

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


Push not applicable.

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

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-1  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 125705
 test-xtf-amd64-amd64-2  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 125705
 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 
125705
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 
125705
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 125705
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125705
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 125705
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 125705
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125705
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125705
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125705
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 125705
 test-xtf-amd64-amd64-5   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-3   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   77 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   77 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-4   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-1   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   77 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   77 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   77 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-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-libvirt 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-multivcpu 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-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-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-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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  ef1b64877424016c90400963adff056e9199e667
baseline version:
 xen  

[Xen-devel] [qemu-upstream-unstable baseline-only test] 75079: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75079 qemu-upstream-unstable real [real]
http://osstest.xensource.com/osstest/logs/75079/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 74724
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-installfail REGR. vs. 74724

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

version targeted for testing:
 qemuu4f080070a9809bde857851e68a3aeff0c4b9b6a6
baseline version:
 qemuu43139135a8938de44f66333831d3a8655d07663a

Last test of basis74724  2018-05-18 06:50:17 Z   91 days
Testing same since75079  2018-08-17 10:55:31 Z0 days1 attempts


365 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-amd64-i386-xl-xsm   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvhv2-amdpass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 

[Xen-devel] [PATCH] xenpmd: prevent format-truncation warning with gcc 8.2 + ARM 32-bit

[Christopher Clark]

xenpmd writes battery information to xenstore, including a string with a
formatted hex value calculated from summing the lengths of four strings,
plus some constants.

Each of the four strings has a maximum length of 31 bytes, excluding the
terminating zero byte. The strings are stored in 32-byte arrays in a
struct that is zeroed before it is populated, and logic that writes to
the strings uses strncpy and explicit zero termination.

The maximum value to be supplied to the xenstore string is:
  (9 * 4) + (31 * 4) + 4 , which is 164, ie. 0xa4.

When used with this value, '%02x' will always fit within 3 bytes, but
gcc 8.2 is apparently not able to deduce this (observed when building
for a 32-bit ARM platform).

This commit assists the compiler by applying a mask (0xff) to the value,
enabling it to observe a lower maximum value and so pass the truncation
length check.

Prior to this change, building fails with the compiler warning:

| xenpmd.c: In function 'write_battery_info_to_xenstore':
| xenpmd.c:354:23: error: '%02x' directive output may be truncated
writing between 2 and 8 bytes into a region of size 3
[-Werror=format-truncation=]
|  snprintf(val, 3, "%02x",
|^~~~
| xenpmd.c:354:22: note: directive argument in the range [40, 2147483778]
|  snprintf(val, 3, "%02x",
|   ^~
| xenpmd.c:354:5: note: 'snprintf' output between 3 and 9 bytes into a
destination of size 3
|  snprintf(val, 3, "%02x",
|  ^~~~
|   (unsigned int)(9*4 +
|   
|  strlen(info->model_number) +
|  
|  strlen(info->serial_number) +
|  ~
|  strlen(info->battery_type) +
|  
|  strlen(info->oem_info) + 4));
|  
| cc1: all warnings being treated as errors

Signed-off-by: Christopher Clark 
---
 tools/xenpmd/xenpmd.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/xenpmd/xenpmd.c b/tools/xenpmd/xenpmd.c
index 56412a9..0c0787e 100644
--- a/tools/xenpmd/xenpmd.c
+++ b/tools/xenpmd/xenpmd.c
@@ -350,8 +350,10 @@ void write_battery_info_to_xenstore(struct battery_info 
*info)

 memset(val, 0, 1024);
 memset(string_info, 0, 256);
-/* write 9 dwords (so 9*4) + length of 4 strings + 4 null terminators */
-snprintf(val, 3, "%02x", 
+/* write 9 dwords (so 9*4) + length of 4 strings + 4 null terminators.
+ * mask informs the compiler that format truncation will not occur.
+ */
+snprintf(val, 3, "%02x", 0xff &
  (unsigned int)(9*4 +
 strlen(info->model_number) +
 strlen(info->serial_number) +
-- 
2.7.4


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

[Xen-devel] [xen-4.7-testing test] 125931: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 125057
 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 
125057
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. 
vs. 125057

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

version targeted for testing:
 xen  7ba1c7df881855422f9a475862565e94c8421b75
baseline version:
 xen  280a5568939c4a5832be787c8e0c23a19f30935a

Last test of basis   125057  2018-07-09 08:36:04 Z   39 days
Failing since125685  2018-07-30 12:39:38 Z   18 days   12 attempts
Testing same since   125931  2018-08-15 22:51:23 Z2 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christian Lindig 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Stefano Stabellini 
  Wei Liu 

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

Re: [Xen-devel] [PATCH v3 5/5] x86: use PDEP for PTE flags insertion when available

[Rich Persaud]

On Aug 17, 2018, at 03:24, Jan Beulich  wrote:
> 
> This replaces 5 instructions by a single one, further reducing code size,
> cache, and TLB footprint (in particular on systems supporting BMI2).

This link claims that BMI2 may be less performant/consistent on AMD Ryzen than 
Intel:
https://www.reddit.com/r/Amd/comments/60i6er/ryzen_and_bmi2_strange_behavior_and_high_latencies/

Would this patch series have any benefit to L0 hypervisors/rootkits (e.g. 
Bromium, Bareflank or similar hypervisors) which could be monitoring L1 Xen?  
Or Xen as L0 hypervisor and Hyper-V as L1 hypervisor?

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

Re: [Xen-devel] [PATCH 2/2] xen/xsm: Rename CONIFIG_XSM_POLICY to CONFIG_XSM_FLASK_POLICY

[Andrew Cooper]

On 17/08/18 19:57, Daniel De Graaf wrote:
> On 06/26/2018 07:09 AM, Andrew Cooper wrote:
>> The embedded policy is specific flask, so update the infrastructure
>> to reflect
>> this.
>>
>> Signed-off-by: Andrew Cooper 
>
> This one actually has a history of being shared between FLASK and ACM
> (the
> now-removed alternative to FLASK in earlier versions of Xen). 
> However, the
> current policy generation is very specific to FLASK, and it would be
> useful
> to allow multiple security modules to each have their own default policy.
>
> Overall, I think it's a useful change.  Is there a reason you chose the
> prefix "xsm_init_flask" over "xsm_flask_init"?  The latter may be more
> amenable to grepping.
>
> Either way,
>
> Acked-by: Daniel De Graaf 

This was some sed to begin with, which is why they ended up like that. 
I will make those adjustments.

Thanks,

~Andrew

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

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

[Stefano Stabellini]

On Fri, 17 Aug 2018, Jan Beulich wrote:
> >>> On 17.08.18 at 06:52,  wrote:
> > flight 126019 xen-unstable-smoke real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/126019/ 
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-armhf-armhf-xl  12 guest-start  fail REGR. vs. 
> > 125923
> 
> Is anyone looking into this:
> 
> libxl: error: libxl_arm.c:124:libxl__arch_domain_save_config: Unexpected gic 
> version 0
> 
> Looks like further fallout from 54ed251dc7.

Looking at 54ed251dc7, I think this line is wrong:

-memcpy(config, , sizeof(*config));

the result is not copied back to the caller.

But I can see that the following should have fixed that already:

commit effed864104ad9bee3f72a2a7d9fb2146b8bf122
Author: Roger Pau Monné 
Date:   Fri Aug 17 13:59:35 2018 +0200

libxc: copy back the result of XEN_DOMCTL_createdomain
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[Boris Ostrovsky]

On 08/15/2018 08:05 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 30 Jul 2018 19:02:10 +1000 Stephen Rothwell  
> wrote:
>> Today's linux-next merge of the akpm-current tree got a conflict in:
>>
>>   drivers/xen/gntdev.c
>>
>> between commit:
>>
>>   1d3145675538 ("xen/gntdev: Make private routines/structures accessible")
>>
>> from the xen-tip tree and commit:
>>
>>   aaefcabe9c25 ("mm, oom: distinguish blockable mode for mmu notifiers")
>>
>> from the akpm-current tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging.  You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
>>
>> -- 
>> Cheers,
>> Stephen Rothwell
>>
>> diff --cc drivers/xen/gntdev.c
>> index c866a62f766d,55b4f0e3f4d6..
>> --- a/drivers/xen/gntdev.c
>> +++ b/drivers/xen/gntdev.c
>> @@@ -479,7 -441,20 +479,20 @@@ static const struct vm_operations_struc
>>   
>>   /* -- */
>>   
>>  -static bool in_range(struct grant_map *map,
>> ++static bool in_range(struct gntdev_grant_map *map,
>> +  unsigned long start, unsigned long end)
>> + {
>> +if (!map->vma)
>> +return false;
>> +if (map->vma->vm_start >= end)
>> +return false;
>> +if (map->vma->vm_end <= start)
>> +return false;
>> + 
>> +return true;
>> + }
>> + 
>>  -static void unmap_if_in_range(struct grant_map *map,
>>  +static void unmap_if_in_range(struct gntdev_grant_map *map,
>>unsigned long start, unsigned long end)
>>   {
>>  unsigned long mstart, mend;
>> @@@ -503,15 -472,26 +510,26 @@@
>>  WARN_ON(err);
>>   }
>>   
>> - static void mn_invl_range_start(struct mmu_notifier *mn,
>> + static int mn_invl_range_start(struct mmu_notifier *mn,
>>  struct mm_struct *mm,
>> -unsigned long start, unsigned long end)
>> +unsigned long start, unsigned long end,
>> +bool blockable)
>>   {
>>  struct gntdev_priv *priv = container_of(mn, struct gntdev_priv, mn);
>>  -   struct grant_map *map;
>>  +   struct gntdev_grant_map *map;
>> +int ret = 0;
>> + 
>> +/* TODO do we really need a mutex here? */
>> +if (blockable)
>> +mutex_lock(>lock);
>> +else if (!mutex_trylock(>lock))
>> +return -EAGAIN;
>>   
>> -mutex_lock(>lock);
>>  list_for_each_entry(map, >maps, next) {
>> +if (in_range(map, start, end)) {
>> +ret = -EAGAIN;
>> +goto out_unlock;
>> +}
>>  unmap_if_in_range(map, start, end);


I think I mentioned this earlier --- this doesn't look right. Not the
conflict resolution but the original patch.

Should I send a patch against -next? Or -mm?


-boris





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

[Xen-devel] [xen-4.9-testing test] 125922: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. 
vs. 124328
 test-amd64-i386-xl-qemuu-debianhvm-amd64 17 guest-stop   fail REGR. vs. 124328
 test-amd64-amd64-xl-qemut-ws16-amd64 14 guest-localmigrate fail REGR. vs. 
124328

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 10 debian-install   fail REGR. vs. 124328

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 124328
 test-armhf-armhf-xl-rtds 17 guest-start.2   fail blocked in 124328
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail blocked in 124328
 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 
124248
 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigratefail like 124248
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124248
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 124328
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 124328
 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 124328
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 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-qemuu-win10-i386 10 windows-installfail 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-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  6c9d139cdd0289f2b35b5deea4b41b8e3e1b39b7
baseline version:
 xen  238007d6fae9447bf5e8e73d67ae9fb844e7ff2a

Last test of basis   124328  2018-06-17 23:39:07 Z   60 days
Failing since124807  2018-06-28 17:38:04 Z   50 days   31 attempts
Testing same since   125922  2018-08-15 14:57:13 Z2 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christian Lindig 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Lars Kurth 
  Paul Durrant 
  Stefano Stabellini 
  Stewart Hildebrand 
  Wei Liu 

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

Re: [Xen-devel] [PATCH v2 13/13] x86/domctl: Implement XEN_DOMCTL_get_cpu_policy

[Daniel De Graaf]

On 07/13/2018 04:03 PM, Andrew Cooper wrote:

From: Sergey Dyasli 

This finally (after literally years of work!) marks the point where the
toolstack can ask the hypervisor for the current CPUID configuration of a
specific domain.

Also extend xen-cpuid's --policy mode to be able to take a domid and dump a
specific domains CPUID and MSR policy.

Signed-off-by: Andrew Cooper 
Signed-off-by: Sergey Dyasli 


Since this is a read operation, it should have a new access vector (probably
get_cpuid) instead of sitting under set_cpuid so that it is possible to allow
viewing the policy without allowing it to be changed (useful for migration out,
introspection, or duplicating the settings on a now-protected domain).

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

Re: [Xen-devel] [PATCH v5 06/15] public / x86: introduce __HYPERCALL_iommu_op

[Daniel De Graaf]

On 08/03/2018 01:22 PM, Paul Durrant wrote:

This patch introduces the boilerplate for a new hypercall to allow a
domain to control IOMMU mappings for its own pages.
Whilst there is duplication of code between the native and compat entry
points which appears ripe for some form of combination, I think it is
better to maintain the separation as-is because the compat entry point
will necessarily gain complexity in subsequent patches.

NOTE: This hypercall is only implemented for x86 and is currently
   restricted by XSM to dom0. Its scope can be expanded in future
   if need be.

Signed-off-by: Paul Durrant 


Acked-by: Daniel De Graaf 

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

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

[osstest service owner]

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

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  b8f33431f3dd23fb43a879f4bdb4283fdc9465ad
baseline version:
 xen  29fd98e425346d9e15913eae6d079ddfc835d54c

Last test of basis   126054  2018-08-17 14:00:30 Z0 days
Testing same since   126063  2018-08-17 18:02:46 Z0 days1 attempts


People who touched revisions under test:
  Christopher Clark 
  Christopher Clark 
  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 xenbits.xen.org:/home/xen/git/xen.git
   29fd98e425..b8f33431f3  b8f33431f3dd23fb43a879f4bdb4283fdc9465ad -> smoke

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 123814
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 123814

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  bfd91dc0c40019c4b543bb704a7391faca0e1bc8
baseline version:
 libvirt  076a2b409667dd9f716a2a2085e1ffea9d58fe8b

Last test of basis   123814  2018-06-05 04:19:23 Z   73 days
Failing since123840  2018-06-06 04:19:28 Z   72 days   55 attempts
Testing same since   125925  2018-08-15 17:23:24 Z2 days1 attempts


People who touched revisions under test:
Ales Musil 
  Andrea Bolognani 
  Anya Harter 
  Bing Niu 
  Bjoern Walk 
  Bobo Du 
  Boris Fiuczynski 
  Brijesh Singh 
  Changkuo Shi 
  Chen Hanxiao 
  Christian Ehrhardt 
  Clementine Hayat 
  Cole Robinson 
  Daniel Nicoletti 
  Daniel P. Berrangé 
  Daniel Veillard 
  Eric Blake 
  Erik Skultety 
  Fabiano Fidêncio 
  Filip Alac 
  Han Han 
  intrigeri 
  intrigeri 
  Jamie Strandboge 
  Jie Wang 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Julio Faracco 
  Ján Tomko 
  Kashyap Chamarthy 
  Katerina Koukiou 
  Laine Stump 
  Laszlo Ersek 
  Luyao Huang 
  Marc Hartmayer 
  Marc Hartmayer 
  Marcos Paulo de Souza 
  Marek Marczykowski-Górecki 
  Martin Kletzander 
  Matthias Bolte 
  Michal Privoznik 
  Michal Prívozník 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 
  Pino Toscano 
  Radostin Stoyanov 
  Ramy Elkest 
  ramyelkest 
  Richard W.M. Jones 
  Roman Bogorodskiy 
  Shi Lei 
  Shichangkuo 
  Simon Kobyda 
  Stefan Bader 
  Stefan Berger 
  Sukrit Bhatnagar 
  Tomáš Golembiovský 
  w00251574 
  Weilun Zhu 
  xinhua.Cao 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 test-armhf-armhf-libvirt-raw blocked 
 test-amd64-amd64-libvirt-vhd blocked 



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

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

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

Test harness code can be found at

Re: [Xen-devel] [PATCH v2 03/21] xen: allow console_io hypercalls from certain DomUs

[Daniel De Graaf]

On 07/19/2018 05:19 AM, Julien Grall wrote:

Hi Stefano,

On 18/07/18 18:10, Stefano Stabellini wrote:

On Tue, 17 Jul 2018, Julien Grall wrote:

Hi Stefano,

On 17/07/2018 21:05, Stefano Stabellini wrote:

On Mon, 9 Jul 2018, Julien Grall wrote:

Hi,

On 07/07/18 00:11, Stefano Stabellini wrote:

Introduce an is_console option to allow certain classes of domUs to use
the Xen console. Specifically, it will be used to give console access to
all domUs started from Xen from information on device tree.

Signed-off-by: Stefano Stabellini 
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
CC: dgde...@tycho.nsa.gov
---
Changes in v2:
- introduce is_console
- remove #ifdefs
---
    xen/include/xen/sched.h | 2 ++
    xen/include/xsm/dummy.h | 2 ++
    xen/xsm/flask/hooks.c   | 5 -
    3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 99d2af2..d66cec0 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -379,6 +379,8 @@ struct domain
    bool auto_node_affinity;
    /* Is this guest fully privileged (aka dom0)? */
    bool is_privileged;
+    /* Can this guest access the Xen console? */
+    bool is_console;
    /* Is this a xenstore domain (not dom0)? */
    bool is_xenstore;
    /* Domain's VCPUs are pinned 1:1 to physical CPUs? */
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index ff6b2db..317 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -230,6 +230,8 @@ static XSM_INLINE int
xsm_memory_stat_reservation(XSM_DEFAULT_ARG struct domain
    static XSM_INLINE int xsm_console_io(XSM_DEFAULT_ARG struct domain
*d, int
cmd)
    {
    XSM_ASSERT_ACTION(XSM_OTHER);
+    if ( d->is_console )
+    return xsm_default_action(XSM_HOOK, d, NULL);


I will let Daniel commenting on this change. However ...


    #ifdef CONFIG_VERBOSE_DEBUG
    if ( cmd == CONSOLEIO_write )
    return xsm_default_action(XSM_HOOK, d, NULL);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 78bc326..2551e4e 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -443,7 +443,10 @@ static int flask_console_io(struct domain *d, int
cmd)
    return avc_unknown_permission("console_io", cmd);
    }
    -    return domain_has_xen(d, perm);
+    if ( !d->is_console )
+    return domain_has_xen(d, perm);
+    else
+    return 0;


... I don't think this change is correct. When a policy is used, the user
is
free to define what is the behavior. With your solution, you impose the
console access even if the user didn't to not give the permission.


I was hoping Daniel would advise on the best way to do things here.

I thought that the idea was that granting a domain "is_console" is
equivalent to granting a domain XEN__READCONSOLE and XEN__WRITECONSOLE
permissions.  Thus, if is_console is set, we return 0 from
flask_console_io because the permissions check succeeds.


Well, yes and no. That's equivalent when you use the dummy policy. When you
have a flask policy you want to give the control to the user.

If you look at the code there are no such as d->is_privilege in that function.
This means that the user define the policy for the hardware domain. Why would
be d->is_console different here?


You are saying that in hooks.c the check should remain exactly as is:

   return domain_has_xen(d, perm);

and d->is_console should not be tested?


Yes.


In that case, do you know if I
need to do anything special with XEN__READCONSOLE and XEN__WRITECONSOLE
permissions for the initial boot domains (such as adding those
permissions as the same time d->is_console is set)?


The main purpose of XSM is to provide a fine grain permission for the user to 
configure. For instance, a user may not console access for initial domain for 
security purpose. So you don't have anything to in the code.

However, when you have XSM enabled, you will have to write down in the policy 
that initial domains will have console access. Although, I am not sure how to 
write that in the policy.


In a security policy that wishes to make this distinction, the initial domains 
will
have distinct security labels from domains created later.  Then, those types are
allowed console_write access (along with any other special rights they may 
need).

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

Re: [Xen-devel] [PATCH v3 01/25] xen: allow console_io hypercalls from certain DomUs

[Daniel De Graaf]

On 07/31/2018 07:27 PM, Stefano Stabellini wrote:

Introduce an is_console option to allow certain classes of domUs to use
the Xen console. Specifically, it will be used to give console access to
all domUs started from Xen from information on device tree.

Signed-off-by: Stefano Stabellini 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH 2/2] xen/xsm: Add new SILO mode for XSM

[Daniel De Graaf]

On 07/24/2018 04:18 AM, Xin Li (Talons) wrote:

  Hi Daniel,

  I think the main questions here are:
  1. Do we need a separated KConfig option for SILO


Yes; I made comments on your patch doing so


  2. Can we use indirect call like "dummy_xsm_ops.grant_copy"
  Any suggestion?


It would be nice to avoid it.  Making a global dummy_xsm_grant_copy()
function would be better, though the best location of the prototype and
code isn't obvious.

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

Re: [Xen-devel] [PATCH 1/2] xen/xsm: Introduce new boot parameter xsm

[Daniel De Graaf]

On 07/02/2018 09:26 PM, Xin Li wrote:

Introduce new boot parameter xsm to choose which xsm module is enabled,
and set default to dummy.

Signed-off-by: Xin Li 


This is a change in defaults for the command line: previously, if you
compiled Xen with FLASK support, Xen defaulted to using it unless you
specified "flask=disabled" on the command line.  If we want to model the
interface after Linux, there would be a KConfig choice of the default
which can be overridden by the command line, so distributions can keep
current behavior (including making the default dummy while enabling the
other XSM modules).

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

Re: [Xen-devel] [PATCH 2/2] xen/xsm: Rename CONIFIG_XSM_POLICY to CONFIG_XSM_FLASK_POLICY

[Daniel De Graaf]

On 06/26/2018 07:09 AM, Andrew Cooper wrote:

The embedded policy is specific flask, so update the infrastructure to reflect
this.

Signed-off-by: Andrew Cooper 


This one actually has a history of being shared between FLASK and ACM (the
now-removed alternative to FLASK in earlier versions of Xen).  However, the
current policy generation is very specific to FLASK, and it would be useful
to allow multiple security modules to each have their own default policy.

Overall, I think it's a useful change.  Is there a reason you chose the
prefix "xsm_init_flask" over "xsm_flask_init"?  The latter may be more
amenable to grepping.

Either way,

Acked-by: Daniel De Graaf 

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125898
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 125898
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125898
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125898
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125898
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-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
 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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 

Re: [Xen-devel] [PATCH 1/2] xen/xsm: Rename CONFIG_FLASK_* to CONFIG_XSM_FLASK_*

[Daniel De Graaf]

On 06/26/2018 07:09 AM, Andrew Cooper wrote:

Flask is one single XSM module, and another is about to be introduced.
Properly namespace the symbols for clarity.

No functional change.

Signed-off-by: Andrew Cooper 


Acked-by: Daniel De Graaf 


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

Re: [Xen-devel] [PATCH v2 2/2] x86/spec-ctrl: add support for modifying SSBD VIA LS_CFG MSR

[Brian Woods]

On Fri, Aug 17, 2018 at 12:59:28AM -0600, Jan Beulich wrote:
> >>> On 16.08.18 at 22:02,  wrote:
> > On Wed, Aug 15, 2018 at 10:00:48AM -0600, Jan Beulich wrote:
> >> >>> On 09.08.18 at 21:42,  wrote:
> >> > --- a/xen/arch/x86/spec_ctrl.c
> >> > +++ b/xen/arch/x86/spec_ctrl.c
> >> 
> >> First of all - I'm not convinced some of the AMD specific code here
> >> wouldn't better live in cpu/amd.c.
> > 
> > Well, by that logic, a lot of the other logic could go in cpu/intel.c.
> > It has to do with SSBD and when AMD's processors support it via the
> > SPEC_CTRL MSR, the support for SSBD will get merged together in
> > spec_ctrl.c and if that's the case, it makes sense to have all the SSBD
> > code together. IMO
> 
> Maybe, though I'd say retpoline_safe(), should_use_eager_fpu(),
> l1tf_calculations(), and xpti_init_default() are all written in a way
> that they could be extended to other CPU vendors should it
> become known that they're also affected. I don't think we really
> know for sure whether VIA and/or Shanghai are affected. Otoh
> the code you add is not just AMD-specific, but even model-specific
> within AMD's palette.
> 
> I'd be curious to know whether Andrew has an opinion here.

Since most of the spec_ctrl code is his, his opinion here would be the
most important.

> >> > @@ -50,7 +51,16 @@ bool __initdata bsp_delay_spec_ctrl;
> >> >  uint8_t __read_mostly default_xen_spec_ctrl;
> >> >  uint8_t __read_mostly default_spec_ctrl_flags;
> >> >  
> >> > +/* for SSBD support for AMD via LS_CFG */
> >> > +#define SSBD_AMD_MAX_SOCKET 2
> >> > +struct ssbd_amd_ls_cfg_smt_status {
> >> > +spinlock_t lock;
> >> > +uint32_t mask;
> >> > +} __attribute__ ((aligned (64)));
> >> 
> >> Where's this literal 64 coming from? Do you perhaps mean
> >> SMP_CACHE_BYTES? And if this is really needed (as said before,
> >> I think the array would better be dynamically allocated than having
> >> compile time determined fixed size), then please don't open-code
> >> __aligned().
> > 
> > It's the cache coherency size.  The SMP_CACHE_BYTES is 128 bytes IIRC.
> > I was trying to save space since the struct is so small it would double
> > the size.  That can be changed though.
> 
> If SMP_CACHE_BYTES doesn't fit your need, the literal number used
> needs either an explaining comment or a suitably named #define.

I'll just use SMP_CACHE_BYTES and not worry about the extra space.

> >> > +bool __read_mostly ssbd_amd_smt_en = false;
> >> > +bool __read_mostly default_xen_ssbd_amd_ls_cfg_en = false;
> >> >  uint64_t __read_mostly ssbd_amd_ls_cfg_mask = 0ull;
> >> > +struct ssbd_amd_ls_cfg_smt_status 
> >> > *ssbd_amd_smt_status[SSBD_AMD_MAX_SOCKET] = {NULL};
> >> 
> >> Several further pointless initializers.
> > 
> > ssbd_amd_ls_cfg_mask -> needs to be initialized, due to how it gets set
> > ssbd_amd_ls_cfg_smt_status -> needs to be initialized, unless xalloc
> >   sets it as NULL on failure to alloc
> > default_xen_ssbd_amd_ls_cfg_en -> needs to be initialized of an else
> >   added to an if statement
> > ssbd_amd_smt_en -> like the above
> > 
> > If you want default_xen_ssbd_amd_ls_cfg_en and ssbd_amd_smt_en to be
> > not be initialized, I can add code to do that.
> 
> I don't understand: Add code? The initializers here are all pointless
> because the values you supply are what the variables would be
> initialized with anyway if you omitted the initializers. That's what
> the C standard specifies.

Leaving values which determine the behavior of the hypervisor to
defaults of the compiler's implementation of the standard seems like it
would be a possible source of subtle bugs when the compiler doesn't do
something just right.  I'd much rather have an initialized value or
have it set in the code before use.

If you strongly feel that they shouldn't be initialized or set in code,
I'll change them though.

> >> > +static int __init ssbd_amd_ls_cfg_init(void)
> >> > +{
> >> > +uint32_t cores_per_socket, threads_per_core;
> >> > +const struct cpuinfo_x86  *c =  _cpu_data;
> >> > +uint32_t core, socket;
> >> > +
> >> > +if ( !ssbd_amd_ls_cfg_mask ||
> >> > + !boot_cpu_has(X86_FEATURE_SSBD_AMD_LS_CFG) )
> >> > +goto ssbd_amd_ls_cfg_init_fail;
> >> 
> >> Why not simply "return"?
> > 
> > Because it forces all the failed returns down one code path.  I can
> > change it if you wish.
> 
> If any cleanup is to be done, using "goto" for this purpose is
> generally accepted (although personally I dislike "goto" in
> general). Here, however, nothing has been done yet and the
> cleanup path is non-trivial. It took me extra time to verify
> that nothing bad would happen from going that path despite
> nothing having been done before. It is far more clear to the
> reader imo if there is just "return" here.

Well, it's just a difference of opinion at this point.  I'll change it.

> >> > +default_xen_ssbd_amd_ls_cfg_en = false;
> >> > +
> >> > +

[Xen-devel] [ovmf test] 125966: all pass - PUSHED

[osstest service owner]

flight 125966 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125966/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 52047be0243074f50fab45650f36ae693c93d1b3
baseline version:
 ovmf cb5f4f45ce1fca390b99dae5c42b9c4c8b53deea

Last test of basis   125924  2018-08-15 17:10:53 Z2 days
Testing same since   125966  2018-08-16 11:44:13 Z1 days1 attempts


People who touched revisions under test:
  Bob Feng 
  Carsey, Jaben 
  Eric Dong 
  Feng, Bob C 
  hchen30 
  Hess Chen 
  Jaben Carsey 
  Laszlo Ersek 
  Liming Gao 
  Ruiyu Ni 
  Star Zeng 
  Yonghong Zhu 
  Yunhua Feng 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   cb5f4f45ce..52047be024  52047be0243074f50fab45650f36ae693c93d1b3 -> 
xen-tested-master

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

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

[osstest service owner]

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

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  29fd98e425346d9e15913eae6d079ddfc835d54c
baseline version:
 xen  3dd454c6c694409aaedd4ed075d6aeace2dd8391

Last test of basis   125923  2018-08-15 16:00:41 Z2 days
Failing since125928  2018-08-15 19:00:49 Z1 days   18 attempts
Testing same since   126054  2018-08-17 14:00:30 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christian Lindig 
  Daniel De Graaf 
  Gopalasetty, Manoj 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Paul Durrant 
  Roger Pau Monné 
  Wei Liu 
  Zhenzhong Duan 

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 xenbits.xen.org:/home/xen/git/xen.git
   3dd454c6c6..29fd98e425  29fd98e425346d9e15913eae6d079ddfc835d54c -> smoke

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

[Xen-devel] [PATCH] tools: libxl/xl: run NUMA placement even when an hard-affinity is set

[Dario Faggioli]

Right now, if either an hard or soft-affinity are explicitly specified
in a domain's config file, automatic NUMA placement is skipped. However,
automatic NUMA placement affects only the soft-affinity of the domain
which is being created.

Therefore, it is ok to let it run if an hard-affinity is specified. The
semantics will be that the best placement candidate would be found,
respecting the specified hard-affinity, i.e., using only the nodes that
contain the pcpus in the hard-affinity mask.

This is particularly helpful if global xl pinning masks are defined, as
made possible by commit aa67b97ed34279c43 ("xl.conf: Add global affinity
masks"). In fact, without this commit, defining a global affinity mask
would also mean disabling automatic placement, but that does not
necessarily have to be the case (especially in large systems).

Signed-off-by: Dario Faggioli 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: George Dunlap 
---
 tools/libxl/libxl_dom.c |   46 --
 tools/xl/xl_parse.c |6 --
 2 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index eb401cf1d6..e30e2dca9a 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -27,6 +27,8 @@
 
 #include "_paths.h"
 
+//#define DEBUG 1
+
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
 {
 libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -142,12 +144,13 @@ static int numa_place_domain(libxl__gc *gc, uint32_t 
domid,
 {
 int found;
 libxl__numa_candidate candidate;
-libxl_bitmap cpupool_nodemap;
+libxl_bitmap cpumap, cpupool_nodemap, *map;
 libxl_cpupoolinfo cpupool_info;
 int i, cpupool, rc = 0;
 uint64_t memkb;
 
 libxl__numa_candidate_init();
+libxl_bitmap_init();
 libxl_bitmap_init(_nodemap);
 libxl_cpupoolinfo_init(_info);
 
@@ -162,6 +165,38 @@ static int numa_place_domain(libxl__gc *gc, uint32_t domid,
 rc = libxl_cpupool_info(CTX, _info, cpupool);
 if (rc)
 goto out;
+map = _info.cpumap;
+
+/*
+ * If there's a well defined hard affinity mask (i.e., the same one for all
+ * the vcpus), we can try to run the placement considering only the pcpus
+ * within such mask.
+ */
+if (info->num_vcpu_hard_affinity)
+{
+#ifdef DEBUG
+int j;
+
+for (j = 0; j < info->num_vcpu_hard_affinity; j++)
+assert(libxl_bitmap_equal(>vcpu_hard_affinity[0],
+  >vcpu_hard_affinity[j], 0));
+#endif /* DEBUG */
+
+rc = libxl_bitmap_and(CTX, , >vcpu_hard_affinity[0],
+  _info.cpumap);
+if (rc)
+goto out;
+
+/*
+ * Hard affinity should _really_ contain cpus that are inside our
+ * cpupool. Anyway, if it does not, log a warning and only use the
+ * cpupool's cpus for placement.
+ */
+if (!libxl_bitmap_is_empty())
+map = 
+else
+LOG(WARN, "Hard affinity completely outside of domain's cpupool?");
+}
 
 rc = libxl_domain_need_memory(CTX, info, );
 if (rc)
@@ -174,8 +209,7 @@ static int numa_place_domain(libxl__gc *gc, uint32_t domid,
 /* Find the best candidate with enough free memory and at least
  * as much pcpus as the domain has vcpus.  */
 rc = libxl__get_numa_candidate(gc, memkb, info->max_vcpus,
-   0, 0, _info.cpumap,
-   numa_cmpf, , );
+   0, 0, map, numa_cmpf, , );
 if (rc)
 goto out;
 
@@ -206,6 +240,7 @@ static int numa_place_domain(libxl__gc *gc, uint32_t domid,
  out:
 libxl__numa_candidate_dispose();
 libxl_bitmap_dispose(_nodemap);
+libxl_bitmap_dispose();
 libxl_cpupoolinfo_dispose(_info);
 return rc;
 }
@@ -379,9 +414,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
  * reflect the placement result if that is the case
  */
 if (libxl_defbool_val(info->numa_placement)) {
-if (info->cpumap.size || info->num_vcpu_hard_affinity ||
-info->num_vcpu_soft_affinity)
-LOG(WARN, "Can't run NUMA placement, as an (hard or soft) "
+if (info->cpumap.size || info->num_vcpu_soft_affinity)
+LOG(WARN, "Can't run NUMA placement, as a soft "
   "affinity has been specified explicitly");
 else if (info->nodemap.size)
 LOG(WARN, "Can't run NUMA placement, as the domain has "
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 971ec1bc56..ad6774a7f7 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -356,7 +356,7 @@ static void parse_vcpu_affinity(libxl_domain_build_info 
*b_info,
 j++;
 }
 
-/* We have a list of cpumaps, disable automatic placement */
+/* When we have a list of cpumaps, always disable automatic placement 
*/
 

Re: [Xen-devel] [PATCH RFC 1/2] drivers/base: export lock_device_hotplug/unlock_device_hotplug

[Greg Kroah-Hartman]

On Fri, Aug 17, 2018 at 01:56:35PM +0200, David Hildenbrand wrote:
> E.g. When adding the memory block devices, we know that there won't be a
> driver to attach to (as there are no drivers for the "memory" subsystem)
> - the bus_probe_device() function that takes the device_lock() could
> pretty much be avoided for that case. But burying such special cases
> down in core driver code definitely won't make locking related to memory
> hotplug easier.

You don't have to have a driver for a device if you don't want to, or
you can just have a default one for all memory devices if you somehow
need it.  No reason to not do this if it makes things easier for you.

thanks,

greg k-h

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

Re: [Xen-devel] [PATCH v5 4/8] mm: introduce a helper to get the memory type of a page

[Roger Pau Monné]

On Fri, Aug 17, 2018 at 04:31:21AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 12:17,  wrote:
>  On 14.08.18 at 15:43,  wrote:
> >> +switch ( e820.map[i].type )
> >> +{
> >> +case E820_RAM:
> >> +return RAM_TYPE_CONVENTIONAL;
> >> +
> >> +case E820_RESERVED:
> >> +return RAM_TYPE_RESERVED;
> >> +
> >> +case E820_UNUSABLE:
> >> +return RAM_TYPE_UNUSABLE;
> >> +
> >> +case E820_ACPI:
> >> +case E820_NVS:
> >> +return RAM_TYPE_ACPI;
> >> +
> >> +default:
> >> +ASSERT_UNREACHABLE();
> >> +return -1;
> >> +}
> >> +}
> >> +
> >> +return -1;
> >> +}
> > 
> > One more case to consider: What about a page part of which is
> > a given type, and the other part of which is simply missing from
> > the E820 table? I'm uncertain whether in that case it might be a
> > good idea in general to report it as having the given type; for the
> > specific purpose you want the function for, that would imo be
> > quite helpful.
> 
> Considering RAM_TYPE_* are bit masks - perhaps the function
> should OR together all types found for the requested page, and
> let the caller go from there? And to account for my earlier remark,
> add a separate RAM_TYPE_UNKNOWN (and never have the function
> return -1 or some such; its return type then would better be
> unsigned int)?

I can do something along this lines, but then the functionality of the
existing inclusive option is likely to change on boxes having memory
types not aligned to a page boundary.

Also, we should likely discuss what to do with a page that for example
has both unusable and reserved regions. I would map it in the
inclusive case because it has a reserved region, but would like to
hear your opinion.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v2] xen: xen.lds should depend on Kconfig's auto.conf

[Wei Liu]

On Fri, Aug 17, 2018 at 10:02:58AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:04,  wrote:
> > xen.lds.S uses on some of the config options set by Kconfig.
> 
> But .xen.lds.d already has a dependency on
>  /build/xen/unstable-hg/2018-07-16-64bit/xen/include/generated/autoconf.h,
> which is a more correct dependency than auto.conf.

Hmm... in that case I'm a bit baffled why it could go out of sync. I
will try to reproduce the issue next week.

Wei.

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

Re: [Xen-devel] [PATCH v2] xen: xen.lds should depend on Kconfig's auto.conf

[Jan Beulich]

>>> On 17.08.18 at 17:04,  wrote:
> xen.lds.S uses on some of the config options set by Kconfig.

But .xen.lds.d already has a dependency on
 /build/xen/unstable-hg/2018-07-16-64bit/xen/include/generated/autoconf.h,
which is a more correct dependency than auto.conf.

Jan



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

Re: [Xen-devel] [PATCH 00/34] Make CONFIG_HVM work

[Wei Liu]

On Fri, Aug 17, 2018 at 11:55:10AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 17, 2018 at 04:12:18PM +0100, Wei Liu wrote:
> > This series goes through x86 code to make CONFIG_HVM work.
> > 
> > With this series, it is possible to build Xen with PV support only.
> > 
> > Running `xl info` on a host with PV only Xen:
> 
> 'PV only'? You mean HVM only surely?

Yes, PV only -- by setting CONFIG_HVM to n.

Making CONFIG_PV work is next, then you can have HVM only Xen.

> > xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p

Look here. :-)

Wei.

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

Re: [Xen-devel] [PATCH v3 0/5] xen/blk: persistent grant rework

[Roger Pau Monné]

On Mon, Aug 13, 2018 at 04:01:09PM +0200, Juergen Gross wrote:
> Persistent grants are used in the Xen's blkfront/blkback drivers to
> avoid mapping/unmapping of I/O buffers in the backend for each I/O.
> 
> While this speeds up processing quite a bit there are problems related
> to persistent grants in some configurations: domains with multiple
> block devices making use of persistent grants might suffer from a lack
> of grants if each of the block devices experienced a high I/O load at
> some time. This is due to the number of persistent grants per device
> only to be limited by a rather high maximum value, but never being
> released even in case of longer times without any I/O.
> 
> This series modifies xen-blkback to unmap any domU page mapped via a
> persistent grant after a timeout (default: 60 seconds). The timeout
> is set to its default value again when a persistent grant has been
> used for an I/O.
> 
> xen-blkfront is modified to scan every 10 seconds for persistent grants
> not in use by blkback any more and to remove such grants.
> 
> The last 3 patches are small cleanups of blkfront and blkback drivers.
> 
> V3:
> - patch 1: make timeout parameter static

Konrad if you are OK with this series, could you please send a pull
request to Jens?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH] x86: use VMLOAD for PV context switch

[Jan Beulich]

>>> On 17.08.18 at 16:55,  wrote:
> On Fri, Aug 17, 2018 at 01:33:43AM -0600, Jan Beulich wrote:
>> >>> On 17.08.18 at 00:04,  wrote:
>> > On Tue, Jul 10, 2018 at 04:14:11AM -0600, Jan Beulich wrote:
>> >> Having noticed that VMLOAD alone is about as fast as a single of the
>> >> involved WRMSRs, I thought it might be a reasonable idea to also use it
>> >> for PV. Measurements, however, have shown that an actual improvement can
>> >> be achieved only with an early prefetch of the VMCB (thanks to Andrew
>> >> for suggesting to try this), which I have to admit I can't really
>> >> explain. This way on my Fam15 box context switch takes over 100 clocks
>> >> less on average (the measured values are heavily varying in all cases,
>> >> though).
>> >> 
>> >> This is intentionally not using a new hvm_funcs hook: For one, this is
>> >> all about PV, and something similar can hardly be done for VMX.
>> >> Furthermore the indirect to direct call patching that is meant to be
>> >> applied to most hvm_funcs hooks would be ugly to make work with
>> >> functions having more than 6 parameters.
>> >> 
>> >> Signed-off-by: Jan Beulich 
>> > 
>> > I have confirmed it with a senior hardware engineer and using vmload in
>> > this fashion is safe and recommended for performance.  As far as using
>> > vmload with PV.
>> > 
>> > Acked-by: Brian Woods 
>> 
>> Thanks. There's another aspect in this same area that I'd like to
>> improve, and hence seek clarification on up front: Currently SVM
>> code uses two pages per CPU, one for host_vmcb and the other
>> for hsa. Afaict the two uses are entirely dis-joint: The host save
>> area looks to be simply yet another VMCB, and the parts accessed
>> during VMRUN / VM exit are fully separate from the ones used by
>> VMLOAD / VMSAVE. Therefore I think both could be folded,
>> reducing code size as well as memory (and perhaps cache) footprint.
>> 
>> I think this separation was done because the PM mentions both
>> data structures separately, but iirc there's nothing said anywhere
>> that the two structures indeed need to be distinct.
> 
> From APM Vol 2
> 
> 15.30.4 VM_HSAVE_PA MSR (C001_0117h)
> The 64-bit read/write VM_HSAVE_PA MSR holds the physical address of a
> 4KB block of memory where VMRUN saves host state, and from which
> #VMEXIT reloads host state. The VMM software is expected to set up this
> register before issuing the first VMRUN instruction. Software must not
> attempt to read or write the host save-state area directly.
> 
> Writing this MSR causes a #GP if:
> ●  any of the low 12 bits of the address written are nonzero, or
> ●  the address written is greater than or equal to the maximum
>supported physical address for this implementation.
> 
> 
> 
> It seems that the HSA is needed for the state of the guest/host.  I
> don't see how they can be folded in together.  Am I missing something?

Well, as said, the set of elements saved/loaded by VMRUN / #VMEXIT
has nothing in common with the set of elements saved/loaded by
VMSAVE / VMLOAD.

Jan


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

[Xen-devel] [distros-debian-jessie test] 75078: tolerable FAIL

[Platform Team regression test user]

flight 75078 distros-debian-jessie real [real]
http://osstest.xensource.com/osstest/logs/75078/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like 
75058

baseline version:
 flight   75058

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub fail
 test-amd64-amd64-i386-jessie-netboot-pygrub  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xensource.com/osstest/logs

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


Push not applicable.


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

Re: [Xen-devel] [PATCH 00/34] Make CONFIG_HVM work

[Konrad Rzeszutek Wilk]

On Fri, Aug 17, 2018 at 04:12:18PM +0100, Wei Liu wrote:
> This series goes through x86 code to make CONFIG_HVM work.
> 
> With this series, it is possible to build Xen with PV support only.
> 
> Running `xl info` on a host with PV only Xen:

'PV only'? You mean HVM only surely?

> 
> root@lcy2-dt108:~# xl info
> host   : lcy2-dt108
> release: 4.17.0-0.bpo.1-amd64
> version: #1 SMP Debian 4.17.8-1~bpo9+1 (2018-07-23)
> machine: x86_64
> nr_cpus: 8
> max_cpu_id : 7
> nr_nodes   : 1
> cores_per_socket   : 4
> threads_per_core   : 2
> cpu_mhz: 3504.057
> hw_caps:
> bfebfbff:77faf3ff:2c100800:0121:000f:009c6fbf::0100
> virt_caps  : hvm_directio
> total_memory   : 32589
> free_memory: 4158
> sharing_freed_memory   : 0
> sharing_used_memory: 0
> outstanding_claims : 0
> free_cpus  : 0
> xen_major  : 4
> xen_minor  : 12
> xen_extra  : -unstable
> xen_version: 4.12-unstable
> xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p
> xen_scheduler  : credit
> xen_pagesize   : 4096
> platform_params: virt_start=0x8000
> xen_changeset  : Fri Aug 17 12:53:34 2018 +0100 git:382ad34e4e
> xen_commandline: placeholder loglvl=all guest_loglvl=all
> com2=115200,8n1 ucode=scan console=com2,vga console_to_ring
> sync_console hvm_fep
> cc_compiler: gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
> cc_compile_by  : wei
> cc_compile_domain  : uk.xensource.com
> cc_compile_date: Fri Aug 17 14:41:56 BST 2018
> build_id   : 3989ecb7693aa02f6ecc748a951ed444cc70ba94
> xend_config_format : 4
> 
> The hvm_directio flag is not accurate. See the last patch for
> discussion.
> 
> The major goal at the moment is to get something that works first,
> then refine code structure later.  Currently CONFIG_HVM is littered in
> individual files. In the future some of the code could / should be
> moved to files under hvm/ for cleaner split.
> 
> I ran some basic PV / PVSHIM VM life cycle tests and XTF PV tests, all

PV or HVM?

> worked.
> 
> $ ls -l xen # PV only, non-debug
> -rwxrwxr-x 1 wei wei 1957436 Aug 17 15:32 xen
> $ ls -l xen # default build, non-debug
> -rwxrwxr-x 1 wei wei 2379388 Aug 17 15:39 xen
> 
> The PV only Xen is ~17.8% smaller in size.

Well, this is the third time you said it, so maybe you did mean PV only.?

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

Re: [Xen-devel] [PATCH 01/34] x86: fix building !CONFIG_LOCK_PROFILE

[Wei Liu]

The prefix should be "xen:", because it is common code.

Wei.

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

[Xen-devel] [PATCH 14/34] x86/pt: add HVM check to XEN_DOMCTL_unbind_pt_irq

[Wei Liu]

Its counterpart is HVM only. Add the check to help dead code
elimination to figure out the call to pt_irq_destroy_bind is not
needed when HVM is not enabled.

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

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index a8325f5..4869e88 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -715,6 +715,10 @@ long arch_do_domctl(
 struct xen_domctl_bind_pt_irq *bind = >u.bind_pt_irq;
 int irq = domain_pirq_to_irq(d, bind->machine_irq);
 
+ret = -EINVAL;
+if ( !is_hvm_domain(d) )
+break;
+
 ret = -EPERM;
 if ( irq <= 0 || !irq_access_permitted(currd, irq) )
 break;
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 27/34] x86: make hvm_inject_* functions build when !CONFIG_HVM

[Wei Liu]

They reference hvm_inject_event which is HVM code (not compiled). They
aren't used by code outside HVM code anyway.

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

diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index b3bc8d2..0444f3b 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -422,6 +422,7 @@ static inline void hvm_inject_exception(
 unsigned int vector, unsigned int type,
 unsigned int insn_len, int error_code)
 {
+#if CONFIG_HVM
 struct x86_event event = {
 .vector = vector,
 .type = type,
@@ -430,10 +431,12 @@ static inline void hvm_inject_exception(
 };
 
 hvm_inject_event();
+#endif
 }
 
 static inline void hvm_inject_hw_exception(unsigned int vector, int errcode)
 {
+#if CONFIG_HVM
 struct x86_event event = {
 .vector = vector,
 .type = X86_EVENTTYPE_HW_EXCEPTION,
@@ -441,10 +444,12 @@ static inline void hvm_inject_hw_exception(unsigned int 
vector, int errcode)
 };
 
 hvm_inject_event();
+#endif
 }
 
 static inline void hvm_inject_page_fault(int errcode, unsigned long cr2)
 {
+#if CONFIG_HVM
 struct x86_event event = {
 .vector = TRAP_page_fault,
 .type = X86_EVENTTYPE_HW_EXCEPTION,
@@ -453,6 +458,7 @@ static inline void hvm_inject_page_fault(int errcode, 
unsigned long cr2)
 };
 
 hvm_inject_event();
+#endif
 }
 
 static inline int hvm_event_pending(struct vcpu *v)
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 26/34] x86/mm/shadow: split out HVM only code

[Wei Liu]

Move the code previously enclosed in CONFIG_HVM into its own file.

Note that although some code explicitly check is_hvm_*, which hints it
can be used for PV too, I can't find a code path that would be the
case.

Signed-off-by: Wei Liu 
---
Can be squashed into previous patch if that's preferable.
---
 xen/arch/x86/mm/shadow/Makefile |   1 +-
 xen/arch/x86/mm/shadow/common.c | 542 +--
 xen/arch/x86/mm/shadow/hvm.c| 590 +-
 3 files changed, 596 insertions(+), 537 deletions(-)
 create mode 100644 xen/arch/x86/mm/shadow/hvm.c

diff --git a/xen/arch/x86/mm/shadow/Makefile b/xen/arch/x86/mm/shadow/Makefile
index bcb23d2..72658f3 100644
--- a/xen/arch/x86/mm/shadow/Makefile
+++ b/xen/arch/x86/mm/shadow/Makefile
@@ -1,5 +1,6 @@
 ifeq ($(CONFIG_SHADOW_PAGING),y)
 obj-y += common.o guest_2.o guest_3.o guest_4.o
+obj-$(CONFIG_HVM) += hvm.o
 else
 obj-y += none.o
 endif
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 4381538..aa94416 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -114,273 +114,16 @@ __initcall(shadow_audit_key_init);
 
 
 #if CONFIG_HVM
-/**/
-/* x86 emulator support for the shadow code
- */
-
-/*
- * Returns a mapped pointer to write to, or one of the following error
- * indicators.
- */
-#define MAPPING_UNHANDLEABLE ERR_PTR(~(long)X86EMUL_UNHANDLEABLE)
-#define MAPPING_EXCEPTIONERR_PTR(~(long)X86EMUL_EXCEPTION)
-#define MAPPING_SILENT_FAIL  ERR_PTR(~(long)X86EMUL_OKAY)
-static void *sh_emulate_map_dest(struct vcpu *v, unsigned long vaddr,
- unsigned int bytes,
- struct sh_emulate_ctxt *sh_ctxt);
-static void sh_emulate_unmap_dest(struct vcpu *v, void *addr,
-  unsigned int bytes,
-  struct sh_emulate_ctxt *sh_ctxt);
-
-/*
- * Callers which pass a known in-range x86_segment can rely on the return
- * pointer being valid.  Other callers must explicitly check for errors.
- */
-static struct segment_register *hvm_get_seg_reg(
-enum x86_segment seg, struct sh_emulate_ctxt *sh_ctxt)
-{
-unsigned int idx = seg;
-struct segment_register *seg_reg;
-
-if ( idx >= ARRAY_SIZE(sh_ctxt->seg_reg) )
-return ERR_PTR(-X86EMUL_UNHANDLEABLE);
-
-seg_reg = _ctxt->seg_reg[idx];
-if ( !__test_and_set_bit(idx, _ctxt->valid_seg_regs) )
-hvm_get_segment_register(current, idx, seg_reg);
-return seg_reg;
-}
-
-static int hvm_translate_virtual_addr(
+extern const struct x86_emulate_ops hvm_shadow_emulator_ops;
+extern struct segment_register *hvm_get_seg_reg(
+enum x86_segment seg, struct sh_emulate_ctxt *sh_ctxt);
+extern int hvm_translate_virtual_addr(
 enum x86_segment seg,
 unsigned long offset,
 unsigned int bytes,
 enum hvm_access_type access_type,
 struct sh_emulate_ctxt *sh_ctxt,
-unsigned long *linear)
-{
-const struct segment_register *reg;
-int okay;
-
-reg = hvm_get_seg_reg(seg, sh_ctxt);
-if ( IS_ERR(reg) )
-return -PTR_ERR(reg);
-
-okay = hvm_virtual_to_linear_addr(
-seg, reg, offset, bytes, access_type,
-hvm_get_seg_reg(x86_seg_cs, sh_ctxt), linear);
-
-if ( !okay )
-{
-/*
- * Leave exception injection to the caller for non-user segments: We
- * neither know the exact error code to be used, nor can we easily
- * determine the kind of exception (#GP or #TS) in that case.
- */
-if ( is_x86_user_segment(seg) )
-x86_emul_hw_exception(
-(seg == x86_seg_ss) ? TRAP_stack_error : TRAP_gp_fault,
-0, _ctxt->ctxt);
-return X86EMUL_EXCEPTION;
-}
-
-return 0;
-}
-
-static int
-hvm_read(enum x86_segment seg,
- unsigned long offset,
- void *p_data,
- unsigned int bytes,
- enum hvm_access_type access_type,
- struct sh_emulate_ctxt *sh_ctxt)
-{
-pagefault_info_t pfinfo;
-unsigned long addr;
-int rc;
-
-rc = hvm_translate_virtual_addr(
-seg, offset, bytes, access_type, sh_ctxt, );
-if ( rc || !bytes )
-return rc;
-
-if ( access_type == hvm_access_insn_fetch )
-rc = hvm_fetch_from_guest_linear(p_data, addr, bytes, 0, );
-else
-rc = hvm_copy_from_guest_linear(p_data, addr, bytes, 0, );
-
-switch ( rc )
-{
-case HVMTRANS_okay:
-return X86EMUL_OKAY;
-case HVMTRANS_bad_linear_to_gfn:
-x86_emul_pagefault(pfinfo.ec, pfinfo.linear, _ctxt->ctxt);
-return X86EMUL_EXCEPTION;
-case HVMTRANS_bad_gfn_to_mfn:
-case HVMTRANS_unhandleable:
-return X86EMUL_UNHANDLEABLE;
-case HVMTRANS_gfn_paged_out:
-case HVMTRANS_gfn_shared:
-return X86EMUL_RETRY;
-}
-
-BUG();
-return X86EMUL_UNHANDLEABLE;
-}
-

[Xen-devel] [PATCH 19/34] x86: check HVM before trying to get ioreq server

[Wei Liu]

This helps with dead code elimination. No functional change.

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

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 8ac4412..f3fa6ce 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4382,6 +4382,10 @@ int arch_acquire_resource(struct domain *d, unsigned int 
type,
 unsigned int i;
 
 rc = -EINVAL;
+if ( !is_hvm_domain(d) )
+break;
+
+rc = -EINVAL;
 if ( id != (unsigned int)ioservid )
 break;
 
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 29/34] x86/mm: put paging_update_nestedmode under CONFIG_HVM

[Wei Liu]

Nested HVM is not enabled when !CONFIG_HVM.

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

diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index dcee496..2aec1d4 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -921,6 +921,7 @@ const struct paging_mode *paging_get_mode(struct vcpu *v)
 
 void paging_update_nestedmode(struct vcpu *v)
 {
+#if CONFIG_HVM
 ASSERT(nestedhvm_enabled(v->domain));
 if (nestedhvm_paging_mode_hap(v))
 /* nested-on-nested */
@@ -929,6 +930,7 @@ void paging_update_nestedmode(struct vcpu *v)
 /* TODO: shadow-on-shadow */
 v->arch.paging.nestedmode = NULL;
 hvm_asid_flush_vcpu(v);
+#endif
 }
 
 void paging_write_p2m_entry(struct p2m_domain *p2m, unsigned long gfn,
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 30/34] x86: PIT emulation is common to PV and HVM

[Wei Liu]

Move the common parts to emul-i8254.c. This requires moving some of
the macros to vpt.h. Some of the code in common code is put under
is_hvm_* checks so that DCE can kick in. Factor out HVM only
pit_load_count_channel0 to reduce amount of code in x86 common code.

Leave HVM specific code where it was before.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/Makefile |   1 +-
 xen/arch/x86/emul-i8254.c | 506 +++-
 xen/arch/x86/hvm/i8254.c  | 462 +
 xen/include/asm-x86/hvm/vpt.h |   9 +-
 4 files changed, 521 insertions(+), 457 deletions(-)
 create mode 100644 xen/arch/x86/emul-i8254.c

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 9b9b63a..5a42ff7 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -27,6 +27,7 @@ obj-y += domain.o
 obj-bin-y += dom0_build.init.o
 obj-y += domain_page.o
 obj-y += e820.o
+obj-y += emul-i8254.o
 obj-y += extable.o
 obj-y += flushtlb.o
 obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o
diff --git a/xen/arch/x86/emul-i8254.c b/xen/arch/x86/emul-i8254.c
new file mode 100644
index 000..605098c
--- /dev/null
+++ b/xen/arch/x86/emul-i8254.c
@@ -0,0 +1,506 @@
+/*
+ * QEMU 8253/8254 interval timer emulation
+ *
+ * Copyright (c) 2003-2004 Fabrice Bellard
+ * Copyright (c) 2006 Intel Corperation
+ * Copyright (c) 2007 Keir Fraser, XenSource Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RW_STATE_LSB 1
+#define RW_STATE_MSB 2
+#define RW_STATE_WORD0 3
+#define RW_STATE_WORD1 4
+
+#define vcpu_vpit(x)   (domain_vpit((x)->domain))
+
+static int pit_get_count(PITState *pit, int channel)
+{
+uint64_t d;
+int  counter;
+struct hvm_hw_pit_channel *c = >hw.channels[channel];
+struct vcpu *v = vpit_vcpu(pit);
+
+ASSERT(spin_is_locked(>lock));
+
+d = muldiv64(get_guest_time(v) - pit->count_load_time[channel],
+ PIT_FREQ, SYSTEM_TIME_HZ);
+
+switch ( c->mode )
+{
+case 0:
+case 1:
+case 4:
+case 5:
+counter = (c->count - d) & 0x;
+break;
+case 3:
+/* XXX: may be incorrect for odd counts */
+counter = c->count - ((2 * d) % c->count);
+break;
+default:
+counter = c->count - (d % c->count);
+break;
+}
+return counter;
+}
+
+static int pit_get_out(PITState *pit, int channel)
+{
+struct hvm_hw_pit_channel *s = >hw.channels[channel];
+uint64_t d;
+int out;
+struct vcpu *v = vpit_vcpu(pit);
+
+ASSERT(spin_is_locked(>lock));
+
+d = muldiv64(get_guest_time(v) - pit->count_load_time[channel],
+ PIT_FREQ, SYSTEM_TIME_HZ);
+
+switch ( s->mode )
+{
+default:
+case 0:
+out = (d >= s->count);
+break;
+case 1:
+out = (d < s->count);
+break;
+case 2:
+out = (((d % s->count) == 0) && (d != 0));
+break;
+case 3:
+out = ((d % s->count) < ((s->count + 1) >> 1));
+break;
+case 4:
+case 5:
+out = (d == s->count);
+break;
+}
+
+return out;
+}
+
+static void pit_set_gate(PITState *pit, int channel, int val)
+{
+struct hvm_hw_pit_channel *s = >hw.channels[channel];
+struct vcpu *v = vpit_vcpu(pit);
+
+ASSERT(spin_is_locked(>lock));
+
+switch ( s->mode )
+{
+default:
+case 0:
+case 4:
+/* XXX: just disable/enable counting */
+break;
+case 1:
+case 5:
+case 2:
+case 3:
+/* Restart counting on rising edge. */
+if ( s->gate < val )
+pit->count_load_time[channel] = get_guest_time(v);
+break;
+}
+
+s->gate = val;
+}
+
+static int pit_get_gate(PITState *pit, int channel)
+{
+ASSERT(spin_is_locked(>lock));
+return 

[Xen-devel] [PATCH 12/34] x86/pt: only call some functions for HVM guests

[Wei Liu]

This patch effectively lifts the check out from these functions to its
caller. Asserts are added for safety.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/hvm/vmsi.c | 4 +++-
 xen/arch/x86/hvm/vmx/vmx.c  | 8 ++--
 xen/drivers/passthrough/pci.c   | 2 +-
 xen/drivers/passthrough/vtd/iommu.c | 6 +++---
 4 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index 3001d5c..39c29d3 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -561,7 +561,9 @@ void msixtbl_init(struct domain *d)
 {
 struct hvm_io_handler *handler;
 
-if ( !is_hvm_domain(d) || !has_vlapic(d) || msixtbl_initialised(d) )
+ASSERT(is_hvm_domain(d));
+
+if ( !has_vlapic(d) || msixtbl_initialised(d) )
 return;
 
 INIT_LIST_HEAD(>arch.hvm_domain.msixtbl_list);
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 73f0d52..7a3fd62 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -315,7 +315,9 @@ void vmx_pi_hooks_assign(struct domain *d)
 {
 struct vcpu *v;
 
-if ( !iommu_intpost || !is_hvm_domain(d) )
+ASSERT(is_hvm_domain(d));
+
+if ( !iommu_intpost )
 return;
 
 ASSERT(!d->arch.hvm_domain.pi_ops.vcpu_block);
@@ -354,7 +356,9 @@ void vmx_pi_hooks_deassign(struct domain *d)
 {
 struct vcpu *v;
 
-if ( !iommu_intpost || !is_hvm_domain(d) )
+ASSERT(is_hvm_domain(d));
+
+if ( !iommu_intpost )
 return;
 
 ASSERT(d->arch.hvm_domain.pi_ops.vcpu_block);
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index c4890a4..9f99fa2 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1439,7 +1439,7 @@ static int assign_device(struct domain *d, u16 seg, u8 
bus, u8 devfn, u32 flag)
 goto done;
 }
 
-if ( pdev->msix )
+if ( pdev->msix && is_hvm_domain(d) )
 msixtbl_init(d);
 
 pdev->fault.count = 0;
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 1710256..6dcbcf2 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2382,13 +2382,13 @@ static int reassign_device_ownership(
 if ( ret )
 return ret;
 
-if ( !has_arch_pdevs(target) )
+if ( !has_arch_pdevs(target) && is_hvm_domain(target) )
 vmx_pi_hooks_assign(target);
 
 ret = domain_context_mapping(target, devfn, pdev);
 if ( ret )
 {
-if ( !has_arch_pdevs(target) )
+if ( !has_arch_pdevs(target) && is_hvm_domain(target) )
 vmx_pi_hooks_deassign(target);
 
 return ret;
@@ -2400,7 +2400,7 @@ static int reassign_device_ownership(
 pdev->domain = target;
 }
 
-if ( !has_arch_pdevs(source) )
+if ( !has_arch_pdevs(source) && is_hvm_domain(source) )
 vmx_pi_hooks_deassign(source);
 
 return ret;
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 34/34] RFC x86: introduce directio virt cap

[Wei Liu]

hvm_directio is set when iommu is enabled, but in fact iommu is not
tied to HVM. In order to not break existing tools, expose a new flag
directio for (iommu_enabled && !hvm_enabled).

RFC This doesn't build at the moment. Do we care about that flag being
inaccurate?

Signed-off-by: Wei Liu 
---
 xen/arch/x86/sysctl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index e704ed7..a8d64c5 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -92,8 +92,10 @@ void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
min(sizeof(pi->hw_cap), sizeof(boot_cpu_data.x86_capability)));
 if ( hvm_enabled )
 pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm;
-if ( iommu_enabled )
+if ( hvm_enabled && iommu_enabled )
 pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm_directio;
+else if ( iommu_enabled )
+pi->capabilities |= XEN_SYSCTL_PHYSCAP_directio;
 }
 
 long arch_do_sysctl(
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 25/34] x86/mm/shadow: make it build with !CONFIG_HVM

[Wei Liu]

Enclose HVM only emulation code under CONFIG_HVM. Add some BUG()s to
to catch any issue.

Note that although some code checks is_hvm_*, which hints it can be
called for PV as well, I can't find such paths.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/mm/shadow/common.c | 18 --
 xen/arch/x86/mm/shadow/multi.c  | 27 +--
 2 files changed, 37 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 0856650..4381538 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -113,6 +113,7 @@ __initcall(shadow_audit_key_init);
 #endif /* SHADOW_AUDIT */
 
 
+#if CONFIG_HVM
 /**/
 /* x86 emulator support for the shadow code
  */
@@ -380,11 +381,13 @@ static const struct x86_emulate_ops 
hvm_shadow_emulator_ops = {
 .cmpxchg= hvm_emulate_cmpxchg,
 .cpuid  = hvmemul_cpuid,
 };
+#endif
 
 const struct x86_emulate_ops *shadow_init_emulation(
 struct sh_emulate_ctxt *sh_ctxt, struct cpu_user_regs *regs,
 unsigned int pte_size)
 {
+#if CONFIG_HVM
 struct segment_register *creg, *sreg;
 struct vcpu *v = current;
 unsigned long addr;
@@ -423,6 +426,10 @@ const struct x86_emulate_ops *shadow_init_emulation(
 ? sizeof(sh_ctxt->insn_buf) : 0;
 
 return _shadow_emulator_ops;
+#else
+BUG();
+return NULL;
+#endif
 }
 
 /* Update an initialized emulation context to prepare for the next
@@ -430,6 +437,7 @@ const struct x86_emulate_ops *shadow_init_emulation(
 void shadow_continue_emulation(struct sh_emulate_ctxt *sh_ctxt,
struct cpu_user_regs *regs)
 {
+#if CONFIG_HVM
 unsigned long addr, diff;
 
 ASSERT(is_hvm_vcpu(current));
@@ -451,6 +459,9 @@ void shadow_continue_emulation(struct sh_emulate_ctxt 
*sh_ctxt,
 ? sizeof(sh_ctxt->insn_buf) : 0;
 sh_ctxt->insn_buf_eip = regs->rip;
 }
+#else
+BUG();
+#endif
 }
 
 
@@ -1685,6 +1696,7 @@ static unsigned int shadow_get_allocation(struct domain 
*d)
 + ((pg & ((1 << (20 - PAGE_SHIFT)) - 1)) ? 1 : 0));
 }
 
+#if CONFIG_HVM
 /**/
 /* Handling guest writes to pagetables. */
 
@@ -1957,6 +1969,7 @@ static void sh_emulate_unmap_dest(struct vcpu *v, void 
*addr,
 
 atomic_inc(>domain->arch.paging.shadow.gtable_dirty_version);
 }
+#endif
 
 /**/
 /* Hash table for storing the guest->shadow mappings.
@@ -2723,12 +2736,13 @@ static int sh_remove_all_mappings(struct domain *d, 
mfn_t gmfn, gfn_t gfn)
&& (page->count_info & PGC_count_mask) <= 3
&& ((page->u.inuse.type_info & PGT_count_mask)
== (is_xen_heap_page(page) ||
-   is_ioreq_server_page(d, page )
+   (is_hvm_domain(d) && is_ioreq_server_page(d, page) )
 {
 SHADOW_ERROR("can't find all mappings of mfn %lx (gfn %lx): "
   "c=%lx t=%lx x=%d i=%d\n", mfn_x(gmfn), gfn_x(gfn),
   page->count_info, page->u.inuse.type_info,
-  !!is_xen_heap_page(page), is_ioreq_server_page(d, 
page));
+  !!is_xen_heap_page(page),
+ is_hvm_domain(d) && is_ioreq_server_page(d, page));
 }
 }
 
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 021ae25..ff7a20c 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2926,18 +2926,25 @@ static int sh_page_fault(struct vcpu *v,
 }
 else
 {
+#if CONFIG_HVM
 /* Magic MMIO marker: extract gfn for MMIO address */
 ASSERT(sh_l1e_is_mmio(sl1e));
+ASSERT(is_hvm_vcpu(v));
 gpa = (((paddr_t)(gfn_x(sh_l1e_mmio_get_gfn(sl1e
<< PAGE_SHIFT)
 | (va & ~PAGE_MASK);
+perfc_incr(shadow_fault_fast_mmio);
+SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
+sh_reset_early_unshadow(v);
+trace_shadow_gen(TRC_SHADOW_FAST_MMIO, va);
+return handle_mmio_with_translation(va, gpa >> PAGE_SHIFT,
+access)
+? EXCRET_fault_fixed : 0;
+#else
+/* When HVM is not enabled, there shouldn't be MMIO marker */
+BUG();
+#endif
 }
-perfc_incr(shadow_fault_fast_mmio);
-SHADOW_PRINTK("fast path mmio %#"PRIpaddr"\n", gpa);
-sh_reset_early_unshadow(v);
-trace_shadow_gen(TRC_SHADOW_FAST_MMIO, va);
-return (handle_mmio_with_translation(va, gpa >> PAGE_SHIFT, access)
-? 

[Xen-devel] [PATCH 28/34] x86/vm_event: put vm_event_fill_regs under CONFIG_HVM

[Wei Liu]

Ideally the HVM specific part of VM event should be moved into hvm/ at
some point, but this will do for now.

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

diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index f91aade..b4f6afb 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -124,6 +124,7 @@ void vm_event_monitor_next_interrupt(struct vcpu *v)
 
 void vm_event_fill_regs(vm_event_request_t *req)
 {
+#if CONFIG_HVM
 const struct cpu_user_regs *regs = guest_cpu_user_regs();
 struct segment_register seg;
 struct hvm_hw_cpu ctxt;
@@ -177,6 +178,7 @@ void vm_event_fill_regs(vm_event_request_t *req)
 
 hvm_get_segment_register(curr, x86_seg_cs, );
 req->data.regs.x86.cs_arbytes = seg.attr;
+#endif
 }
 
 void vm_event_emulate_check(struct vcpu *v, vm_event_response_t *rsp)
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 23/34] x86/oprofile: put SVM only code under CONFIG_HVM

[Wei Liu]

The code snippet in question is to detect NMI held by SVM until STGI
is called. When Xen doesn't even support HVM guests there is no need
to check svm_stgi_label.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/oprofile/op_model_athlon.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/oprofile/op_model_athlon.c 
b/xen/arch/x86/oprofile/op_model_athlon.c
index 2d3763c..3d6e26f 100644
--- a/xen/arch/x86/oprofile/op_model_athlon.c
+++ b/xen/arch/x86/oprofile/op_model_athlon.c
@@ -319,9 +319,11 @@ static int athlon_check_ctrs(unsigned int const cpu,
unsigned long eip = regs->rip;
int mode = 0;
struct vcpu *v = current;
-   struct cpu_user_regs *guest_regs = guest_cpu_user_regs();
unsigned int const nr_ctrs = model->num_counters;
 
+#if CONFIG_HVM
+   struct cpu_user_regs *guest_regs = guest_cpu_user_regs();
+
if (!guest_mode(regs) &&
(eip == (unsigned long)svm_stgi_label)) {
/* SVM guest was running when NMI occurred */
@@ -329,6 +331,7 @@ static int athlon_check_ctrs(unsigned int const cpu,
eip = guest_regs->rip;
mode = xenoprofile_get_mode(v, guest_regs);
} else
+#endif
mode = xenoprofile_get_mode(v, regs);
 
for (i = 0 ; i < nr_ctrs; ++i) {
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 11/34] xen/pt: io.c contains HVM only code

[Wei Liu]

We still need to test CONFIG_X86 because Arm also defines CONFIG_HVM.

Signed-off-by: Wei Liu 
---
 xen/drivers/passthrough/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/Makefile b/xen/drivers/passthrough/Makefile
index 6087333..6b2d2e0 100644
--- a/xen/drivers/passthrough/Makefile
+++ b/xen/drivers/passthrough/Makefile
@@ -4,6 +4,8 @@ subdir-$(CONFIG_X86) += x86
 subdir-$(CONFIG_ARM) += arm
 
 obj-y += iommu.o
-obj-$(CONFIG_X86) += io.o
+ifeq ($(CONFIG_X86),y)
+obj-$(CONFIG_HVM) += io.o
+endif
 obj-$(CONFIG_HAS_PCI) += pci.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += device_tree.o
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 16/34] x86/hvm: enclose hvm_enabled and hvm_funcs in CONFIG_HVM

[Wei Liu]

This helps to take advantage of dead code elimination. Turn
hvm_enabled into proper bool while at it.

Providing an empty hvm_funcs resolves a lot of undefined references to
it in the header. It is safe to do so because those functions / macros
are not expected to be used.

Signed-off-by: Wei Liu 
---
 xen/include/asm-x86/hvm/hvm.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 146720c..b3bc8d2 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -234,8 +234,14 @@ struct hvm_function_table {
 } tsc_scaling;
 };
 
+#if CONFIG_HVM
+extern bool hvm_enabled;
 extern struct hvm_function_table hvm_funcs;
-extern bool_t hvm_enabled;
+#else
+#define hvm_enabled false
+static struct hvm_function_table hvm_funcs = {};
+#endif
+
 extern s8 hvm_port80_allowed;
 
 extern const struct hvm_function_table *start_svm(void);
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 22/34] x86/mm: put HVM only code under CONFIG_HVM

[Wei Liu]

Going through the code, nested EPT, EPT, and ALTP2M depend on HVM code. Put
these components under CONFIG_HVM. This further requires putting one
of the vm event under CONFIG_HVM.

Also make hap_enabled evaluate to false when !CONFIG_HVM. This in turn
requires marking a variable in p2m_set_entry as __maybe_unused.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/mm/Makefile |  5 +++--
 xen/arch/x86/mm/hap/Makefile |  2 +-
 xen/arch/x86/mm/p2m.c| 17 ++---
 xen/common/vm_event.c|  2 ++
 xen/include/asm-x86/hvm/domain.h |  4 
 5 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
index 3017119..156a321 100644
--- a/xen/arch/x86/mm/Makefile
+++ b/xen/arch/x86/mm/Makefile
@@ -2,8 +2,9 @@ subdir-y += shadow
 subdir-y += hap
 
 obj-y += paging.o
-obj-y += p2m.o p2m-pt.o p2m-ept.o p2m-pod.o
-obj-y += altp2m.o
+obj-y += p2m.o p2m-pt.o p2m-pod.o
+obj-$(CONFIG_HVM) += p2m-ept.o
+obj-$(CONFIG_HVM) += altp2m.o
 obj-y += guest_walk_2.o
 obj-y += guest_walk_3.o
 obj-y += guest_walk_4.o
diff --git a/xen/arch/x86/mm/hap/Makefile b/xen/arch/x86/mm/hap/Makefile
index b14a9af..a8e44de 100644
--- a/xen/arch/x86/mm/hap/Makefile
+++ b/xen/arch/x86/mm/hap/Makefile
@@ -3,7 +3,7 @@ obj-y += guest_walk_2level.o
 obj-y += guest_walk_3level.o
 obj-y += guest_walk_4level.o
 obj-y += nested_hap.o
-obj-y += nested_ept.o
+obj-$(CONFIG_HVM) += nested_ept.o
 
 guest_walk_%level.o: guest_walk.c Makefile
$(CC) $(CFLAGS) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 1a04b34..2111cb6 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -531,7 +531,7 @@ struct page_info *p2m_get_page_from_gfn(
 int p2m_set_entry(struct p2m_domain *p2m, gfn_t gfn, mfn_t mfn,
   unsigned int page_order, p2m_type_t p2mt, p2m_access_t p2ma)
 {
-struct domain *d = p2m->domain;
+struct domain * __maybe_unused d = p2m->domain;
 unsigned long todo = 1ul << page_order;
 unsigned int order;
 int set_rc, rc = 0;
@@ -1708,12 +1708,6 @@ void p2m_mem_paging_resume(struct domain *d, 
vm_event_response_t *rsp)
 }
 }
 
-void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
-{
-if ( altp2m_active(v->domain) )
-p2m_switch_vcpu_altp2m_by_id(v, idx);
-}
-
 static struct p2m_domain *
 p2m_getlru_nestedp2m(struct domain *d, struct p2m_domain *p2m)
 {
@@ -2165,6 +2159,14 @@ int unmap_mmio_regions(struct domain *d,
 return i == nr ? 0 : i ?: ret;
 }
 
+#if CONFIG_HVM
+
+void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
+{
+if ( altp2m_active(v->domain) )
+p2m_switch_vcpu_altp2m_by_id(v, idx);
+}
+
 bool_t p2m_switch_vcpu_altp2m_by_id(struct vcpu *v, unsigned int idx)
 {
 struct domain *d = v->domain;
@@ -2542,6 +2544,7 @@ int p2m_altp2m_propagate_change(struct domain *d, gfn_t 
gfn,
 
 return ret;
 }
+#endif /* CONFIG_HVM */
 
 /*** Audit ***/
 
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 144ab81..2824673 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -429,9 +429,11 @@ void vm_event_resume(struct domain *d, struct 
vm_event_domain *ved)
  */
 vm_event_toggle_singlestep(d, v, );
 
+#if CONFIG_HVM
 /* Check for altp2m switch */
 if ( rsp.flags & VM_EVENT_FLAG_ALTERNATE_P2M )
 p2m_altp2m_check(v, rsp.altp2m_idx);
+#endif
 
 if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
 vm_event_set_registers(v, );
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index 5885950..8d28b54 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -202,7 +202,11 @@ struct hvm_domain {
 };
 };
 
+#if CONFIG_HVM
 #define hap_enabled(d)  ((d)->arch.hvm_domain.hap_enabled)
+#else
+#define hap_enabled(d)  false
+#endif
 
 #endif /* __ASM_X86_HVM_DOMAIN_H__ */
 
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 18/34] x86/amd: skip OSVW function calls if !CONFIG_HVM

[Wei Liu]

The two functions are not needed when HVM is not supported in
hypervisor.

Note that using hvm_enabled won't work because early_microcode_init
gets to cpu_request_microcode before hvm_enabled is set in presmp init
call stage.

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

diff --git a/xen/arch/x86/microcode_amd.c b/xen/arch/x86/microcode_amd.c
index 53f9f54..fba44cc 100644
--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -550,7 +550,9 @@ static int cpu_request_microcode(unsigned int cpu, const 
void *buf,
 xfree(mc_old);
 
   out:
+#if CONFIG_HVM
 svm_host_osvw_init();
+#endif
 
 /*
  * In some cases we may return an error even if processor's microcode has
@@ -609,6 +611,7 @@ err1:
 
 static int start_update(void)
 {
+#if CONFIG_HVM
 /*
  * We assume here that svm_host_osvw_init() will be called on each cpu 
(from
  * cpu_request_microcode()).
@@ -619,6 +622,7 @@ static int start_update(void)
  * supporting OSVW so we will not deal with this possibility.
  */
 svm_host_osvw_reset();
+#endif
 
 return 0;
 }
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 31/34] xen: refuse to create HVM guests when !CONFIG_HVM

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/common/domain.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 171d25e..a22df12 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -318,8 +318,14 @@ struct domain *domain_create(domid_t domid,
 if ( !is_idle_domain(d) )
 {
 if ( config->flags & XEN_DOMCTL_CDF_hvm_guest )
+{
+#if CONFIG_HVM
 d->guest_type = guest_type_hvm;
-else
+#else
+err = -EINVAL;
+goto fail;
+#endif
+} else
 d->guest_type = guest_type_pv;
 
 watchdog_domain_init(d);
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 24/34] x86/mem_access: put HVM only function under CONFIG_HVM

[Wei Liu]

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

diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index 03a8641..e1525fd 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -138,6 +138,7 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
 return violation;
 }
 
+#if CONFIG_HVM
 bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
   struct npfec npfec,
   vm_event_request_t **req_ptr)
@@ -244,6 +245,7 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
 /* Return whether vCPU pause is required (aka. sync event) */
 return (p2ma != p2m_access_n2rwx);
 }
+#endif
 
 int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
   struct p2m_domain *ap2m, p2m_access_t a,
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 13/34] x86/pt: split out HVM functions from vtd.c

[Wei Liu]

Functions are moved to hvm.c. Reorder makefile items while at it.

Signed-off-by: Wei Liu 
---
 xen/drivers/passthrough/vtd/x86/Makefile |  3 +-
 xen/drivers/passthrough/vtd/x86/hvm.c| 77 +-
 xen/drivers/passthrough/vtd/x86/vtd.c| 45 +---
 3 files changed, 79 insertions(+), 46 deletions(-)
 create mode 100644 xen/drivers/passthrough/vtd/x86/hvm.c

diff --git a/xen/drivers/passthrough/vtd/x86/Makefile 
b/xen/drivers/passthrough/vtd/x86/Makefile
index df4509d..4ef00a4 100644
--- a/xen/drivers/passthrough/vtd/x86/Makefile
+++ b/xen/drivers/passthrough/vtd/x86/Makefile
@@ -1,2 +1,3 @@
-obj-y += vtd.o
 obj-y += ats.o
+obj-$(CONFIG_HVM) += hvm.o
+obj-y += vtd.o
diff --git a/xen/drivers/passthrough/vtd/x86/hvm.c 
b/xen/drivers/passthrough/vtd/x86/hvm.c
new file mode 100644
index 000..b71b3a7
--- /dev/null
+++ b/xen/drivers/passthrough/vtd/x86/hvm.c
@@ -0,0 +1,77 @@
+/*
+ * Copyright (c) 2008, Intel Corporation.
+ *
+ * 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 .
+ *
+ * Copyright (C) Allen Kay 
+ * Copyright (C) Weidong Han 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../iommu.h"
+#include "../dmar.h"
+#include "../vtd.h"
+#include "../extern.h"
+
+static int _hvm_dpci_isairq_eoi(struct domain *d,
+struct hvm_pirq_dpci *pirq_dpci, void *arg)
+{
+struct hvm_irq *hvm_irq = hvm_domain_irq(d);
+unsigned int isairq = (long)arg;
+const struct dev_intx_gsi_link *digl;
+
+list_for_each_entry ( digl, _dpci->digl_list, list )
+{
+unsigned int link = hvm_pci_intx_link(digl->device, digl->intx);
+
+if ( hvm_irq->pci_link.route[link] == isairq )
+{
+hvm_pci_intx_deassert(d, digl->device, digl->intx);
+if ( --pirq_dpci->pending == 0 )
+{
+stop_timer(_dpci->timer);
+pirq_guest_eoi(dpci_pirq(pirq_dpci));
+}
+}
+}
+
+return 0;
+}
+
+void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq)
+{
+struct hvm_irq_dpci *dpci = NULL;
+
+ASSERT(isairq < NR_ISAIRQS);
+if ( !iommu_enabled)
+return;
+
+spin_lock(>event_lock);
+
+dpci = domain_get_irq_dpci(d);
+
+if ( dpci && test_bit(isairq, dpci->isairq_map) )
+{
+/* Multiple mirq may be mapped to one isa irq */
+pt_pirq_iterate(d, _hvm_dpci_isairq_eoi, (void *)(long)isairq);
+}
+spin_unlock(>event_lock);
+}
diff --git a/xen/drivers/passthrough/vtd/x86/vtd.c 
b/xen/drivers/passthrough/vtd/x86/vtd.c
index 00a9891..ac653ee 100644
--- a/xen/drivers/passthrough/vtd/x86/vtd.c
+++ b/xen/drivers/passthrough/vtd/x86/vtd.c
@@ -63,51 +63,6 @@ void flush_all_cache()
 wbinvd();
 }
 
-static int _hvm_dpci_isairq_eoi(struct domain *d,
-struct hvm_pirq_dpci *pirq_dpci, void *arg)
-{
-struct hvm_irq *hvm_irq = hvm_domain_irq(d);
-unsigned int isairq = (long)arg;
-const struct dev_intx_gsi_link *digl;
-
-list_for_each_entry ( digl, _dpci->digl_list, list )
-{
-unsigned int link = hvm_pci_intx_link(digl->device, digl->intx);
-
-if ( hvm_irq->pci_link.route[link] == isairq )
-{
-hvm_pci_intx_deassert(d, digl->device, digl->intx);
-if ( --pirq_dpci->pending == 0 )
-{
-stop_timer(_dpci->timer);
-pirq_guest_eoi(dpci_pirq(pirq_dpci));
-}
-}
-}
-
-return 0;
-}
-
-void hvm_dpci_isairq_eoi(struct domain *d, unsigned int isairq)
-{
-struct hvm_irq_dpci *dpci = NULL;
-
-ASSERT(isairq < NR_ISAIRQS);
-if ( !iommu_enabled)
-return;
-
-spin_lock(>event_lock);
-
-dpci = domain_get_irq_dpci(d);
-
-if ( dpci && test_bit(isairq, dpci->isairq_map) )
-{
-/* Multiple mirq may be mapped to one isa irq */
-pt_pirq_iterate(d, _hvm_dpci_isairq_eoi, (void *)(long)isairq);
-}
-spin_unlock(>event_lock);
-}
-
 void __hwdom_init vtd_set_hwdom_mapping(struct domain *d)
 {
 unsigned long i, top, max_pfn;
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 20/34] x86/mtrr: move is_var_mtrr_overlapped

[Wei Liu]

Move it to x86 generic code. While at it, use proper boolean type.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/cpu/mtrr/generic.c | 31 +++
 xen/arch/x86/hvm/mtrr.c | 31 ---
 xen/include/asm-x86/mtrr.h  |  2 +-
 3 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/xen/arch/x86/cpu/mtrr/generic.c b/xen/arch/x86/cpu/mtrr/generic.c
index 0976365..499d5f4 100644
--- a/xen/arch/x86/cpu/mtrr/generic.c
+++ b/xen/arch/x86/cpu/mtrr/generic.c
@@ -51,6 +51,37 @@ get_fixed_ranges(mtrr_type * frs)
}
 }
 
+bool is_var_mtrr_overlapped(const struct mtrr_state *m)
+{
+unsigned int seg, i;
+unsigned int num_var_ranges = MASK_EXTR(m->mtrr_cap, MTRRcap_VCNT);
+
+for ( i = 0; i < num_var_ranges; i++ )
+{
+uint64_t base1 = m->var_ranges[i].base >> PAGE_SHIFT;
+uint64_t mask1 = m->var_ranges[i].mask >> PAGE_SHIFT;
+
+if ( !(m->var_ranges[i].mask & MTRR_PHYSMASK_VALID) )
+continue;
+
+for ( seg = i + 1; seg < num_var_ranges; seg ++ )
+{
+uint64_t base2 = m->var_ranges[seg].base >> PAGE_SHIFT;
+uint64_t mask2 = m->var_ranges[seg].mask >> PAGE_SHIFT;
+
+if ( !(m->var_ranges[seg].mask & MTRR_PHYSMASK_VALID) )
+continue;
+
+if ( (base1 & mask1 & mask2) == (base2 & mask2 & mask1) )
+{
+/* MTRR is overlapped. */
+return true;
+}
+}
+}
+return false;
+}
+
 void mtrr_save_fixed_ranges(void *info)
 {
get_fixed_ranges(mtrr_state.fixed_ranges);
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index c502dda..edfe5cd 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -75,37 +75,6 @@ static uint8_t __read_mostly 
mtrr_epat_tbl[MTRR_NUM_TYPES][MEMORY_NUM_TYPES] =
 static uint8_t __read_mostly pat_entry_tbl[PAT_TYPE_NUMS] =
 { [0 ... PAT_TYPE_NUMS-1] = INVALID_MEM_TYPE };
 
-bool_t is_var_mtrr_overlapped(const struct mtrr_state *m)
-{
-unsigned int seg, i;
-unsigned int num_var_ranges = MASK_EXTR(m->mtrr_cap, MTRRcap_VCNT);
-
-for ( i = 0; i < num_var_ranges; i++ )
-{
-uint64_t base1 = m->var_ranges[i].base >> PAGE_SHIFT;
-uint64_t mask1 = m->var_ranges[i].mask >> PAGE_SHIFT;
-
-if ( !(m->var_ranges[i].mask & MTRR_PHYSMASK_VALID) )
-continue;
-
-for ( seg = i + 1; seg < num_var_ranges; seg ++ )
-{
-uint64_t base2 = m->var_ranges[seg].base >> PAGE_SHIFT;
-uint64_t mask2 = m->var_ranges[seg].mask >> PAGE_SHIFT;
-
-if ( !(m->var_ranges[seg].mask & MTRR_PHYSMASK_VALID) )
-continue;
-
-if ( (base1 & mask1 & mask2) == (base2 & mask2 & mask1) )
-{
-/* MTRR is overlapped. */
-return 1;
-}
-}
-}
-return 0;
-}
-
 static int __init hvm_mtrr_pat_init(void)
 {
 unsigned int i, j;
diff --git a/xen/include/asm-x86/mtrr.h b/xen/include/asm-x86/mtrr.h
index 72d0690..7edcb94 100644
--- a/xen/include/asm-x86/mtrr.h
+++ b/xen/include/asm-x86/mtrr.h
@@ -95,7 +95,7 @@ extern bool_t mtrr_def_type_msr_set(struct domain *, struct 
mtrr_state *,
 extern void memory_type_changed(struct domain *);
 extern bool_t pat_msr_set(uint64_t *pat, uint64_t msr);
 
-bool_t is_var_mtrr_overlapped(const struct mtrr_state *m);
+bool is_var_mtrr_overlapped(const struct mtrr_state *m);
 bool mtrr_pat_not_equal(const struct vcpu *vd, const struct vcpu *vs);
 
 #endif /* __ASM_X86_MTRR_H__ */
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 21/34] x86/mm: p2m_flush and nvcpu_flush are HVM only

[Wei Liu]

p2m_flush is only called by HAP code, nvcpu_flush is only useful for
nestedhvm, both of which depend on HVM support.

Enclose their code in CONFIG_HVM. Add assertions.

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

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 1089b86..1a04b34 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1785,10 +1785,13 @@ p2m_flush_table(struct p2m_domain *p2m)
 void
 p2m_flush(struct vcpu *v, struct p2m_domain *p2m)
 {
+#if CONFIG_HVM
+ASSERT(is_hvm_vcpu(v));
 ASSERT(v->domain == p2m->domain);
 vcpu_nestedhvm(v).nv_p2m = NULL;
 p2m_flush_table(p2m);
 hvm_asid_flush_vcpu(v);
+#endif
 }
 
 void
@@ -1839,8 +1842,11 @@ static void assign_np2m(struct vcpu *v, struct 
p2m_domain *p2m)
 
 static void nvcpu_flush(struct vcpu *v)
 {
+#if CONFIG_HVM
+ASSERT(is_hvm_vcpu(v));
 hvm_asid_flush_vcpu(v);
 vcpu_nestedhvm(v).stale_np2m = true;
+#endif
 }
 
 struct p2m_domain *
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 10/34] x86: stub out has_* testing for emulation flags

[Wei Liu]

Most are all HVM only. Provide stubs for !CONFIG_HVM.

One exception is PIT emulation, which is available to both PV and HVM.

Signed-off-by: Wei Liu 
---
 xen/include/asm-x86/domain.h | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 09f6b3d..4c18054 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -440,6 +440,8 @@ struct arch_domain
 uint32_t emulation_flags;
 } __cacheline_aligned;
 
+#ifdef CONFIG_HVM
+
 #define has_vlapic(d)  (!!((d)->arch.emulation_flags & XEN_X86_EMU_LAPIC))
 #define has_vhpet(d)   (!!((d)->arch.emulation_flags & XEN_X86_EMU_HPET))
 #define has_vpm(d) (!!((d)->arch.emulation_flags & XEN_X86_EMU_PM))
@@ -448,11 +450,31 @@ struct arch_domain
 #define has_vpic(d)(!!((d)->arch.emulation_flags & XEN_X86_EMU_PIC))
 #define has_vvga(d)(!!((d)->arch.emulation_flags & XEN_X86_EMU_VGA))
 #define has_viommu(d)  (!!((d)->arch.emulation_flags & XEN_X86_EMU_IOMMU))
-#define has_vpit(d)(!!((d)->arch.emulation_flags & XEN_X86_EMU_PIT))
 #define has_pirq(d)(!!((d)->arch.emulation_flags & \
 XEN_X86_EMU_USE_PIRQ))
 #define has_vpci(d)(!!((d)->arch.emulation_flags & XEN_X86_EMU_VPCI))
 
+#else
+
+#define has_vlapic(d) (0)
+#define has_vhpet(d)  (0)
+#define has_vpm(d)(0)
+#define has_vrtc(d)   (0)
+#define has_vioapic(d)(0)
+#define has_vpic(d)   (0)
+#define has_vvga(d)   (0)
+#define has_viommu(d) (0)
+#define has_pirq(d)   (0)
+#define has_vpci(d)   (0)
+
+#endif
+
+#if CONFIG_HVM || CONFIG_PV
+#define has_vpit(d)(!!((d)->arch.emulation_flags & XEN_X86_EMU_PIT))
+#else
+#define has_vpit(d)   (0)
+#endif
+
 #define has_arch_pdevs(d)(!list_empty(&(d)->arch.pdev_list))
 
 #define gdt_ldt_pt_idx(v) \
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 17/34] x86/vmce: enclose HVM load / save code in CONFIG_HVM

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/arch/x86/cpu/mcheck/vmce.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index e07cd2f..467125b 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -349,6 +349,7 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
 return ret;
 }
 
+#if CONFIG_HVM
 static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 {
 struct vcpu *v;
@@ -392,6 +393,7 @@ static int vmce_load_vcpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 
 HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
   vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
+#endif
 
 /*
  * for Intel MCE, broadcast vMCE to all vcpus
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 33/34] x86/pvshim: disable HVM for PV shim

[Wei Liu]

Signed-off-by: Wei Liu 
---
 tools/firmware/xen-dir/shim.config | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/firmware/xen-dir/shim.config 
b/tools/firmware/xen-dir/shim.config
index 21d7075..de53dfe 100644
--- a/tools/firmware/xen-dir/shim.config
+++ b/tools/firmware/xen-dir/shim.config
@@ -12,7 +12,7 @@ CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
 CONFIG_NR_CPUS=32
 CONFIG_PV=y
 CONFIG_PV_LINEAR_PT=y
-CONFIG_HVM=y
+# CONFIG_HVM is not set
 # CONFIG_SHADOW_PAGING is not set
 # CONFIG_BIGMEM is not set
 # CONFIG_HVM_FEP is not set
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 15/34] x86/nestedhvm: make it build with !CONFIG_HVM

[Wei Liu]

Make two functions static inline so that they can be referenced in p2m
code. Check nestedhvm is enabled before calling
nestedhvm_vmcx_flushtlb (which also has a side effect of not issuing
unnecessary IPIs for non-nested case).

While moving, reformat code and use proper boolean.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/hvm/nestedhvm.c| 21 -
 xen/arch/x86/mm/p2m.c   |  3 ++-
 xen/include/asm-x86/hvm/nestedhvm.h | 19 +--
 3 files changed, 19 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c
index ab50b2a..bd11019 100644
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -26,13 +26,6 @@
 
 static unsigned long *shadow_io_bitmap[3];
 
-/* Nested HVM on/off per domain */
-bool nestedhvm_enabled(const struct domain *d)
-{
-return is_hvm_domain(d) && d->arch.hvm_domain.params &&
-d->arch.hvm_domain.params[HVM_PARAM_NESTEDHVM];
-}
-
 /* Nested VCPU */
 bool_t
 nestedhvm_vcpu_in_guestmode(struct vcpu *v)
@@ -120,20 +113,6 @@ nestedhvm_vmcx_flushtlb(struct p2m_domain *p2m)
 cpumask_clear(p2m->dirty_cpumask);
 }
 
-bool_t
-nestedhvm_is_n2(struct vcpu *v)
-{
-if (!nestedhvm_enabled(v->domain)
-  || nestedhvm_vmswitch_in_progress(v)
-  || !nestedhvm_paging_mode_hap(v))
-return 0;
-
-if (nestedhvm_vcpu_in_guestmode(v))
-return 1;
-
-return 0;
-}
-
 /* Common shadow IO Permission bitmap */
 
 /* There four global patterns of io bitmap each guest can
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 8e9fbb5..1089b86 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1756,7 +1756,8 @@ p2m_flush_table_locked(struct p2m_domain *p2m)
 p2m->np2m_generation++;
 
 /* Make sure nobody else is using this p2m table */
-nestedhvm_vmcx_flushtlb(p2m);
+if ( nestedhvm_enabled(d) )
+nestedhvm_vmcx_flushtlb(p2m);
 
 /* Zap the top level of the trie */
 mfn = pagetable_get_mfn(p2m_get_pagetable(p2m));
diff --git a/xen/include/asm-x86/hvm/nestedhvm.h 
b/xen/include/asm-x86/hvm/nestedhvm.h
index 47165fc..c7003dd 100644
--- a/xen/include/asm-x86/hvm/nestedhvm.h
+++ b/xen/include/asm-x86/hvm/nestedhvm.h
@@ -33,7 +33,11 @@ enum nestedhvm_vmexits {
 };
 
 /* Nested HVM on/off per domain */
-bool nestedhvm_enabled(const struct domain *d);
+static inline bool nestedhvm_enabled(const struct domain *d)
+{
+return is_hvm_domain(d) && d->arch.hvm_domain.params &&
+d->arch.hvm_domain.params[HVM_PARAM_NESTEDHVM];
+}
 
 /* Nested VCPU */
 int nestedhvm_vcpu_initialise(struct vcpu *v);
@@ -70,7 +74,18 @@ unsigned long *nestedhvm_vcpu_iomap_get(bool_t ioport_80, 
bool_t ioport_ed);
 
 void nestedhvm_vmcx_flushtlb(struct p2m_domain *p2m);
 
-bool_t nestedhvm_is_n2(struct vcpu *v);
+static inline bool nestedhvm_is_n2(struct vcpu *v)
+{
+if ( !nestedhvm_enabled(v->domain) ||
+nestedhvm_vmswitch_in_progress(v) ||
+!nestedhvm_paging_mode_hap(v) )
+return false;
+
+if ( nestedhvm_vcpu_in_guestmode(v) )
+return true;
+
+return false;
+}
 
 static inline void nestedhvm_set_cr(struct vcpu *v, unsigned int cr,
 unsigned long value)
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 06/34] x86: fix two unused variable errors when !CONFIG_HVM

[Wei Liu]

The one in context_switch is fixed by annotating with __maybe_unused
because I want to keep prevd around.

The other is fixed by eliminating v.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/domain.c   | 3 ++-
 xen/arch/x86/mm/shadow/common.c | 3 +--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 5bb900e..574bdf0 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1671,7 +1671,8 @@ static void __context_switch(void)
 void context_switch(struct vcpu *prev, struct vcpu *next)
 {
 unsigned int cpu = smp_processor_id();
-const struct domain *prevd = prev->domain, *nextd = next->domain;
+const struct domain * __maybe_unused prevd = prev->domain,
+*nextd = next->domain;
 unsigned int dirty_cpu = next->dirty_cpu;
 
 ASSERT(local_irq_is_enabled());
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index fd42d73..0856650 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -430,10 +430,9 @@ const struct x86_emulate_ops *shadow_init_emulation(
 void shadow_continue_emulation(struct sh_emulate_ctxt *sh_ctxt,
struct cpu_user_regs *regs)
 {
-struct vcpu *v = current;
 unsigned long addr, diff;
 
-ASSERT(is_hvm_vcpu(v));
+ASSERT(is_hvm_vcpu(current));
 
 /*
  * We don't refetch the segment bases, because we don't emulate
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 00/34] Make CONFIG_HVM work

[Wei Liu]

This series goes through x86 code to make CONFIG_HVM work.

With this series, it is possible to build Xen with PV support only.

Running `xl info` on a host with PV only Xen:

root@lcy2-dt108:~# xl info
host   : lcy2-dt108
release: 4.17.0-0.bpo.1-amd64
version: #1 SMP Debian 4.17.8-1~bpo9+1 (2018-07-23)
machine: x86_64
nr_cpus: 8
max_cpu_id : 7
nr_nodes   : 1
cores_per_socket   : 4
threads_per_core   : 2
cpu_mhz: 3504.057
hw_caps:
bfebfbff:77faf3ff:2c100800:0121:000f:009c6fbf::0100
virt_caps  : hvm_directio
total_memory   : 32589
free_memory: 4158
sharing_freed_memory   : 0
sharing_used_memory: 0
outstanding_claims : 0
free_cpus  : 0
xen_major  : 4
xen_minor  : 12
xen_extra  : -unstable
xen_version: 4.12-unstable
xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p
xen_scheduler  : credit
xen_pagesize   : 4096
platform_params: virt_start=0x8000
xen_changeset  : Fri Aug 17 12:53:34 2018 +0100 git:382ad34e4e
xen_commandline: placeholder loglvl=all guest_loglvl=all
com2=115200,8n1 ucode=scan console=com2,vga console_to_ring
sync_console hvm_fep
cc_compiler: gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
cc_compile_by  : wei
cc_compile_domain  : uk.xensource.com
cc_compile_date: Fri Aug 17 14:41:56 BST 2018
build_id   : 3989ecb7693aa02f6ecc748a951ed444cc70ba94
xend_config_format : 4

The hvm_directio flag is not accurate. See the last patch for
discussion.

The major goal at the moment is to get something that works first,
then refine code structure later.  Currently CONFIG_HVM is littered in
individual files. In the future some of the code could / should be
moved to files under hvm/ for cleaner split.

I ran some basic PV / PVSHIM VM life cycle tests and XTF PV tests, all
worked.

$ ls -l xen # PV only, non-debug
-rwxrwxr-x 1 wei wei 1957436 Aug 17 15:32 xen
$ ls -l xen # default build, non-debug
-rwxrwxr-x 1 wei wei 2379388 Aug 17 15:39 xen

The PV only Xen is ~17.8% smaller in size.

Wei.

Wei Liu (34):
  x86: fix building !CONFIG_LOCK_PROFILE
  x86/vvmx: make get_shadow_eptp static function
  x86: HVM_FEP should depend on HVM
  x86/mm: don't reference hvm_funcs directly
  xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM
  x86: fix two unused variable errors when !CONFIG_HVM
  x86: only call memory_type_changed for HVM guests
  x86: enclose hvm_op and dm_op in CONFIG_HVM in PV hypercall table
  x86: guard HAS_VPCI with CONFIG_HVM
  x86: stub out has_* testing for emulation flags
  xen/pt: io.c contains HVM only code
  x86/pt: only call some functions for HVM guests
  x86/pt: split out HVM functions from vtd.c
  x86/pt: add HVM check to XEN_DOMCTL_unbind_pt_irq
  x86/nestedhvm: make it build with !CONFIG_HVM
  x86/hvm: enclose hvm_enabled and hvm_funcs in CONFIG_HVM
  x86/vmce: enclose HVM load / save code in CONFIG_HVM
  x86/amd: skip OSVW function calls if !CONFIG_HVM
  x86: check HVM before trying to get ioreq server
  x86/mtrr: move is_var_mtrr_overlapped
  x86/mm: p2m_flush and nvcpu_flush are HVM only
  x86/mm: put HVM only code under CONFIG_HVM
  x86/oprofile: put SVM only code under CONFIG_HVM
  x86/mem_access: put HVM only function under CONFIG_HVM
  x86/mm/shadow: make it build with !CONFIG_HVM
  x86/mm/shadow: split out HVM only code
  x86: make hvm_inject_* functions build when !CONFIG_HVM
  x86/vm_event: put vm_event_fill_regs under CONFIG_HVM
  x86/mm: put paging_update_nestedmode under CONFIG_HVM
  x86: PIT emulation is common to PV and HVM
  xen: refuse to create HVM guests when !CONFIG_HVM
  x86: expose CONFIG_HVM
  x86/pvshim: disable HVM for PV shim
  RFC x86: introduce directio virt cap

 tools/firmware/xen-dir/shim.config   |   2 +-
 xen/arch/arm/Kconfig |   3 +-
 xen/arch/x86/Kconfig |   9 +-
 xen/arch/x86/Makefile|   1 +-
 xen/arch/x86/cpu/mcheck/vmce.c   |   2 +-
 xen/arch/x86/cpu/mtrr/generic.c  |  31 +-
 xen/arch/x86/domain.c|   3 +-
 xen/arch/x86/domctl.c|   8 +-
 xen/arch/x86/emul-i8254.c| 506 +-
 xen/arch/x86/hvm/i8254.c | 462 +---
 xen/arch/x86/hvm/mtrr.c  |  31 +-
 xen/arch/x86/hvm/nestedhvm.c |  21 +-
 xen/arch/x86/hvm/vmsi.c  |   4 +-
 xen/arch/x86/hvm/vmx/vmx.c   |   8 +-
 xen/arch/x86/hvm/vmx/vvmx.c  |   2 +-
 xen/arch/x86/microcode_amd.c |   4 +-
 xen/arch/x86/mm.c|   6 +-
 xen/arch/x86/mm/Makefile |   5 +-
 xen/arch/x86/mm/hap/Makefile |   2 +-
 xen/arch/x86/mm/mem_access.c |   2 

[Xen-devel] [PATCH 01/34] x86: fix building !CONFIG_LOCK_PROFILE

[Wei Liu]

The init function shouldn't be built or called at all when
!CONFIG_LOCK_PROFILE.

Signed-off-by: Wei Liu 
---
 xen/common/spinlock.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 8f2ba08..36e31c9 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -471,6 +471,7 @@ void _lock_profile_deregister_struct(
 spin_unlock(_profile_lock);
 }
 
+#ifdef CONFIG_LOCK_PROFILE
 static int __init lock_prof_init(void)
 {
 struct lock_profile **q;
@@ -489,5 +490,6 @@ static int __init lock_prof_init(void)
 return 0;
 }
 __initcall(lock_prof_init);
+#endif
 
 #endif /* LOCK_PROFILE */
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 02/34] x86/vvmx: make get_shadow_eptp static function

[Wei Liu]

Its callers live within the same file.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/hvm/vmx/vvmx.c| 2 +-
 xen/include/asm-x86/hvm/vmx/vvmx.h | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 918d47d..b7d9a1a 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1107,7 +1107,7 @@ static void load_shadow_guest_state(struct vcpu *v)
 /* TODO: CR3 target control */
 }
 
-uint64_t get_shadow_eptp(struct vcpu *v)
+static uint64_t get_shadow_eptp(struct vcpu *v)
 {
 struct p2m_domain *p2m = p2m_get_nestedp2m(v);
 struct ept_data *ept = >ept;
diff --git a/xen/include/asm-x86/hvm/vmx/vvmx.h 
b/xen/include/asm-x86/hvm/vmx/vvmx.h
index 9ea35eb..a20bd9e 100644
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h
@@ -188,8 +188,6 @@ enum vmx_insn_errno set_vvmcs_real_safe(const struct vcpu 
*, u32 encoding,
set_vvmcs_real_safe(vcpu, encoding, val) : \
set_vvmcs_virtual_safe(vcpu_nestedhvm(vcpu).nv_vvmcx, encoding, val))
 
-uint64_t get_shadow_eptp(struct vcpu *v);
-
 void nvmx_destroy_vmcs(struct vcpu *v);
 int nvmx_handle_vmptrld(struct cpu_user_regs *regs);
 int nvmx_handle_vmptrst(struct cpu_user_regs *regs);
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 09/34] x86: guard HAS_VPCI with CONFIG_HVM

[Wei Liu]

VPCI is only useful for PVH / HVM guests. Ideally CONFIG_HVM should
imply !PV_SHIM_EXCLUSIVE, but we still want to build PV_SHIM_EXCLUSIVE
with CONFIG_HVM at this stage because a lot of things are still
entangled.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index ba5cb62..73ab8f8 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -23,7 +23,7 @@ config X86
select HAS_PCI
select HAS_PDX
select HAS_UBSAN
-   select HAS_VPCI if !PV_SHIM_EXCLUSIVE
+   select HAS_VPCI if !PV_SHIM_EXCLUSIVE && HVM
select NEEDS_LIBELF
select NUMA
 
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 07/34] x86: only call memory_type_changed for HVM guests

[Wei Liu]

Jan indicated that for PV guests the memory type is not changed, for
HVM guests memory_type_changed is needed for EPT's effective memory
type calculation. Call memory_type_changed for HVM guests only.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/domctl.c   | 4 ++--
 xen/common/domctl.c | 5 +++--
 xen/drivers/passthrough/iommu.c | 3 ++-
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 1002659..a8325f5 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -416,7 +416,7 @@ long arch_do_domctl(
 ret = ioports_permit_access(d, fp, fp + np - 1);
 else
 ret = ioports_deny_access(d, fp, fp + np - 1);
-if ( !ret )
+if ( !ret && is_hvm_domain(d) )
 memory_type_changed(d);
 break;
 }
@@ -824,7 +824,7 @@ long arch_do_domctl(
"ioport_map: error %ld denying dom%d access to 
[%x,%x]\n",
ret, d->domain_id, fmp, fmp + np - 1);
 }
-if ( !ret )
+if ( !ret && is_hvm_domain(d) )
 memory_type_changed(d);
 break;
 }
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 0ef554a..ae99fed 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -977,7 +977,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 ret = iomem_permit_access(d, mfn, mfn + nr_mfns - 1);
 else
 ret = iomem_deny_access(d, mfn, mfn + nr_mfns - 1);
-if ( !ret )
+if ( !ret && is_hvm_domain(d) )
 memory_type_changed(d);
 break;
 }
@@ -1037,7 +1037,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
ret, d->domain_id, mfn, mfn_end);
 }
 /* Do this unconditionally to cover errors on above failure paths. */
-memory_type_changed(d);
+   if ( is_hvm_domain(d) )
+memory_type_changed(d);
 break;
 }
 
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 70d218f..cf5aa20 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -240,7 +240,8 @@ int iommu_construct(struct domain *d)
  * memory_type_changed lose effect if memory type changes.
  * Call memory_type_changed here to amend this.
  */
-memory_type_changed(d);
+if ( is_hvm_domain(d) )
+memory_type_changed(d);
 
 return 0;
 }
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 03/34] x86: HVM_FEP should depend on HVM

[Wei Liu]

Signed-off-by: Wei Liu 
---
 xen/arch/x86/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 63b286a..ba5cb62 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -94,6 +94,7 @@ config BIGMEM
 config HVM_FEP
bool "HVM Forced Emulation Prefix support" if EXPERT = "y"
default DEBUG
+   depends on HVM
---help---
 
  Compiles in a feature that allows HVM guest to arbitrarily
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 05/34] xen: is_hvm_domain should evaluate to 0 when !CONFIG_HVM

[Wei Liu]

Since it is defined in common header file, introduce CONFIG_HVM to
Arm to avoid breakage.

Signed-off-by: Wei Liu 
---
 xen/arch/arm/Kconfig| 3 +++
 xen/include/xen/sched.h | 6 ++
 2 files changed, 9 insertions(+)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 586bc62..c0e969e 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -52,6 +52,9 @@ config HAS_ITS
 prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
 depends on GICV3 && !NEW_VGIC
 
+config HVM
+def_bool y
+
 config NEW_VGIC
bool
prompt "Use new VGIC implementation"
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 51ceebe..8fc3423 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -879,8 +879,14 @@ void watchdog_domain_destroy(struct domain *d);
 
 #define is_pv_domain(d) ((d)->guest_type == guest_type_pv)
 #define is_pv_vcpu(v)   (is_pv_domain((v)->domain))
+
+#if CONFIG_HVM
 #define is_hvm_domain(d) ((d)->guest_type == guest_type_hvm)
+#else
+#define is_hvm_domain(d) (0)
+#endif
 #define is_hvm_vcpu(v)   (is_hvm_domain(v->domain))
+
 #define is_pinned_vcpu(v) ((v)->domain->is_pinned || \
cpumask_weight((v)->cpu_hard_affinity) == 1)
 #ifdef CONFIG_HAS_PASSTHROUGH
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 04/34] x86/mm: don't reference hvm_funcs directly

[Wei Liu]

It is generally not a good idea to reference the internal data
structure of the another subsystem directly. Introduce a wrapper
function for the invlpg hook.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/mm.c | 2 +-
 xen/include/asm-x86/hvm/hvm.h | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 85ccf48..8ac4412 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5800,7 +5800,7 @@ void paging_invlpg(struct vcpu *v, unsigned long va)
 if ( is_pv_vcpu(v) )
 flush_tlb_one_local(va);
 else
-hvm_funcs.invlpg(v, va);
+hvm_invlpg(v, va);
 }
 
 /* Build a 32bit PSE page table using 4MB pages. */
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 4f720ad..146720c 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -454,6 +454,11 @@ static inline int hvm_event_pending(struct vcpu *v)
 return hvm_funcs.event_pending(v);
 }
 
+static inline void hvm_invlpg(struct vcpu *v, unsigned long va)
+{
+hvm_funcs.invlpg(v, va);
+}
+
 /* These bits in CR4 are owned by the host. */
 #define HVM_CR4_HOST_MASK (mmu_cr4_features & \
 (X86_CR4_VMXE | X86_CR4_PAE | X86_CR4_MCE))
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH 08/34] x86: enclose hvm_op and dm_op in CONFIG_HVM in PV hypercall table

[Wei Liu]

PV guest (Dom0) needs to able to use these two hypercalls in order to
serve HVM guests. But if xen doesn't support HVM at all there is no
point in exposing them to PV guests.

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

diff --git a/xen/arch/x86/pv/hypercall.c b/xen/arch/x86/pv/hypercall.c
index bbc3011..75e6cdb 100644
--- a/xen/arch/x86/pv/hypercall.c
+++ b/xen/arch/x86/pv/hypercall.c
@@ -68,7 +68,9 @@ const hypercall_table_t pv_hypercall_table[] = {
 #endif
 HYPERCALL(event_channel_op),
 COMPAT_CALL(physdev_op),
+#ifdef CONFIG_HVM
 HYPERCALL(hvm_op),
+#endif
 HYPERCALL(sysctl),
 HYPERCALL(domctl),
 #ifdef CONFIG_KEXEC
@@ -78,7 +80,9 @@ const hypercall_table_t pv_hypercall_table[] = {
 HYPERCALL(tmem_op),
 #endif
 HYPERCALL(xenpmu_op),
+#ifdef CONFIG_HVM
 COMPAT_CALL(dm_op),
+#endif
 HYPERCALL(mca),
 HYPERCALL(arch_1),
 };
-- 
git-series 0.9.1

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

[Xen-devel] [PATCH v2] xen: xen.lds should depend on Kconfig's auto.conf

[Wei Liu]

xen.lds.S uses on some of the config options set by Kconfig.

Signed-off-by: Wei Liu 
---
v2: correct the path used in the patch.
---
 xen/arch/arm/Makefile | 2 +-
 xen/arch/x86/Makefile | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index b9b141dc84..55c1bf032f 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -124,7 +124,7 @@ $(TARGET)-syms: prelink.o xen.lds 
$(BASEDIR)/common/symbols-dummy.o
 asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
$(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
 
-xen.lds: xen.lds.S
+xen.lds: xen.lds.S ../../include/config/auto.conf
$(CC) -P -E -Ui386 $(AFLAGS) -o $@ $<
sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
mv -f .xen.lds.d.new .xen.lds.d
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 9b9b63ac63..bb7e1d966c 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -218,12 +218,12 @@ efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o: 
;
 asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
$(CC) $(filter-out -Wa$(comma)% -flto,$(CFLAGS)) -S -o $@ $<
 
-xen.lds: xen.lds.S
+xen.lds: xen.lds.S ../../include/config/auto.conf
$(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(AFLAGS)) -o $@ $<
sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
mv -f .xen.lds.d.new .xen.lds.d
 
-efi.lds: xen.lds.S
+efi.lds: xen.lds.S ../../include/config/auto.conf
$(CC) -P -E -Ui386 -DEFI $(filter-out -Wa$(comma)%,$(AFLAGS)) -o $@ $<
sed -e 's/efi\.lds\.o:/efi\.lds:/g' <.$(@F).d >.$(@F).d.new
mv -f .$(@F).d.new .$(@F).d
-- 
2.11.0


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

Re: [Xen-devel] [PATCH] xen: xen.lds should depend on Kconfig's auto.conf

[Wei Liu]

On Fri, Aug 17, 2018 at 03:56:29PM +0100, Wei Liu wrote:
> xen.lds.S uses on some of the config options set by Kconfig.
> 
> Signed-off-by: Wei Liu 

Ignore this patch, the path is wrong.

Wei.

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

[Xen-devel] [PATCH] xen: xen.lds should depend on Kconfig's auto.conf

[Wei Liu]

xen.lds.S uses on some of the config options set by Kconfig.

Signed-off-by: Wei Liu 
---
 xen/arch/arm/Makefile | 2 +-
 xen/arch/x86/Makefile | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index b9b141dc84..4d732df1eb 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -124,7 +124,7 @@ $(TARGET)-syms: prelink.o xen.lds 
$(BASEDIR)/common/symbols-dummy.o
 asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
$(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
 
-xen.lds: xen.lds.S
+xen.lds: xen.lds.S include/config/auto.conf
$(CC) -P -E -Ui386 $(AFLAGS) -o $@ $<
sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
mv -f .xen.lds.d.new .xen.lds.d
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 9b9b63ac63..18d195bf5f 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -218,12 +218,12 @@ efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o: 
;
 asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
$(CC) $(filter-out -Wa$(comma)% -flto,$(CFLAGS)) -S -o $@ $<
 
-xen.lds: xen.lds.S
+xen.lds: xen.lds.S include/config/auto.conf
$(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(AFLAGS)) -o $@ $<
sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new
mv -f .xen.lds.d.new .xen.lds.d
 
-efi.lds: xen.lds.S
+efi.lds: xen.lds.S include/config/auto.conf
$(CC) -P -E -Ui386 -DEFI $(filter-out -Wa$(comma)%,$(AFLAGS)) -o $@ $<
sed -e 's/efi\.lds\.o:/efi\.lds:/g' <.$(@F).d >.$(@F).d.new
mv -f .$(@F).d.new .$(@F).d
-- 
2.11.0


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

Re: [Xen-devel] [PATCH] x86: use VMLOAD for PV context switch

[Brian Woods]

On Fri, Aug 17, 2018 at 01:33:43AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 00:04,  wrote:
> > On Tue, Jul 10, 2018 at 04:14:11AM -0600, Jan Beulich wrote:
> >> Having noticed that VMLOAD alone is about as fast as a single of the
> >> involved WRMSRs, I thought it might be a reasonable idea to also use it
> >> for PV. Measurements, however, have shown that an actual improvement can
> >> be achieved only with an early prefetch of the VMCB (thanks to Andrew
> >> for suggesting to try this), which I have to admit I can't really
> >> explain. This way on my Fam15 box context switch takes over 100 clocks
> >> less on average (the measured values are heavily varying in all cases,
> >> though).
> >> 
> >> This is intentionally not using a new hvm_funcs hook: For one, this is
> >> all about PV, and something similar can hardly be done for VMX.
> >> Furthermore the indirect to direct call patching that is meant to be
> >> applied to most hvm_funcs hooks would be ugly to make work with
> >> functions having more than 6 parameters.
> >> 
> >> Signed-off-by: Jan Beulich 
> > 
> > I have confirmed it with a senior hardware engineer and using vmload in
> > this fashion is safe and recommended for performance.  As far as using
> > vmload with PV.
> > 
> > Acked-by: Brian Woods 
> 
> Thanks. There's another aspect in this same area that I'd like to
> improve, and hence seek clarification on up front: Currently SVM
> code uses two pages per CPU, one for host_vmcb and the other
> for hsa. Afaict the two uses are entirely dis-joint: The host save
> area looks to be simply yet another VMCB, and the parts accessed
> during VMRUN / VM exit are fully separate from the ones used by
> VMLOAD / VMSAVE. Therefore I think both could be folded,
> reducing code size as well as memory (and perhaps cache) footprint.
> 
> I think this separation was done because the PM mentions both
> data structures separately, but iirc there's nothing said anywhere
> that the two structures indeed need to be distinct.
> 
> Jan

From APM Vol 2

15.30.4 VM_HSAVE_PA MSR (C001_0117h)
The 64-bit read/write VM_HSAVE_PA MSR holds the physical address of a
4KB block of memory where VMRUN saves host state, and from which
#VMEXIT reloads host state. The VMM software is expected to set up this
register before issuing the first VMRUN instruction. Software must not
attempt to read or write the host save-state area directly.

Writing this MSR causes a #GP if:
•  any of the low 12 bits of the address written are nonzero, or
•  the address written is greater than or equal to the maximum
   supported physical address for this implementation.



It seems that the HSA is needed for the state of the guest/host.  I
don't see how they can be folded in together.  Am I missing something?

-- 
Brian Woods

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

[Xen-devel] [PATCH] x86/xen: enable early use of set_fixmap in 32-bit Xen PV guest

[Juergen Gross]

Commit 7b25b9cb0dad83 ("x86/xen/time: Initialize pv xen time in
init_hypervisor_platform()") moved the mapping of the shared info area
before pagetable_init(). This breaks booting as 32-bit PV guest as the
use of set_fixmap isn't possible at this time on 32-bit.

This can be worked around by populating the needed PMD on 32-bit
kernel earlier.

In order not to reimplement populate_extra_pte() using extend_brk()
for allocating new page tables extend alloc_low_pages() to do that in
case the early page table pool is not yet available.

Fixes: 7b25b9cb0dad83
Signed-off-by: Juergen Gross 
---
 arch/x86/mm/init.c  | 17 -
 arch/x86/xen/enlighten_pv.c |  2 ++
 arch/x86/xen/mmu_pv.c   |  2 ++
 3 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index acfab322fbe0..5c32a7665492 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -99,15 +99,22 @@ __ref void *alloc_low_pages(unsigned int num)
}
 
if ((pgt_buf_end + num) > pgt_buf_top || !can_use_brk_pgt) {
-   unsigned long ret;
-   if (min_pfn_mapped >= max_pfn_mapped)
-   panic("alloc_low_pages: ran out of memory");
-   ret = memblock_find_in_range(min_pfn_mapped << PAGE_SHIFT,
+   unsigned long ret = 0;
+
+   if (min_pfn_mapped < max_pfn_mapped) {
+   ret = memblock_find_in_range(
+   min_pfn_mapped << PAGE_SHIFT,
max_pfn_mapped << PAGE_SHIFT,
PAGE_SIZE * num , PAGE_SIZE);
+   }
+   if (ret)
+   memblock_reserve(ret, PAGE_SIZE * num);
+   else if (can_use_brk_pgt)
+   ret = __pa(extend_brk(PAGE_SIZE * num, PAGE_SIZE));
+
if (!ret)
panic("alloc_low_pages: can not alloc memory");
-   memblock_reserve(ret, PAGE_SIZE * num);
+
pfn = ret >> PAGE_SHIFT;
} else {
pfn = pgt_buf_end;
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index ee3b00c7acda..d7b2022ee301 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -122,6 +122,8 @@ static void __init xen_banner(void)
 
 static void __init xen_pv_init_platform(void)
 {
+   populate_extra_pte(fix_to_virt(FIX_PARAVIRT_BOOTMAP));
+
set_fixmap(FIX_PARAVIRT_BOOTMAP, xen_start_info->shared_info);
HYPERVISOR_shared_info = (void *)fix_to_virt(FIX_PARAVIRT_BOOTMAP);
 
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 52206ad81e4b..9e7012858420 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -2171,6 +2171,8 @@ void __init xen_relocate_p2m(void)
 #else  /* !CONFIG_X86_64 */
 static RESERVE_BRK_ARRAY(pmd_t, initial_kernel_pmd, PTRS_PER_PMD);
 static RESERVE_BRK_ARRAY(pmd_t, swapper_kernel_pmd, PTRS_PER_PMD);
+RESERVE_BRK(fixup_kernel_pmd, PAGE_SIZE);
+RESERVE_BRK(fixup_kernel_pte, PAGE_SIZE);
 
 static void __init xen_write_cr3_init(unsigned long cr3)
 {
-- 
2.13.7


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  12 guest-start  fail REGR. vs. 125923

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

version targeted for testing:
 xen  3e4ec07e14bce81f6ae22c31ff1302d1f297a226
baseline version:
 xen  3dd454c6c694409aaedd4ed075d6aeace2dd8391

Last test of basis   125923  2018-08-15 16:00:41 Z1 days
Failing since125928  2018-08-15 19:00:49 Z1 days   17 attempts
Testing same since   126009  2018-08-16 20:00:24 Z0 days6 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christian Lindig 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Paul Durrant 
  Wei Liu 
  Zhenzhong Duan 

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



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

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

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

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


Not pushing.


commit 3e4ec07e14bce81f6ae22c31ff1302d1f297a226
Author: Andrew Cooper 
Date:   Thu Aug 16 16:26:22 2018 +0100

x86/setup: Avoid OoB E820 lookup when calculating the L1TF safe address

A number of corner cases (most obviously, no-real-mode and no Multiboot 
memory
map) can end up with e820_raw.nr_map being 0, at which point the L1TF
calculation will underflow.

Spotted by Coverity.

Signed-off-by: Andrew Cooper 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 
Reviewed-by: Wei Liu 

commit afc3f910d3434b540e4e4f51d9fd2723aea22fa2
Author: Jan Beulich 
Date:   Thu Aug 16 00:49:29 2018 -0600

libxl: fix ARM build after 54ed251dc7

Commit "tools: Rework xc_domain_create() to take a full
xen_domctl_createdomain"  failed to replace one further instance of
xc_config in libxl__arch_domain_save_config().

Signed-off-by: Jan Beulich 
Acked-by: Andrew Cooper 
Acked-by: Ian Jackson 

commit 70d8543950ad045fddcb78ae11302e713ef09c76
Author: Zhenzhong Duan 
Date:   Thu Aug 16 09:31:57 2018 +0200

x86/mmcfg: remove redundant code in pci_mmcfg_reject_broken()

No functional change.

Signed-off-by: Zhenzhong Duan 
Acked-by: Jan Beulich 

commit a9e9837f54973ac45488c24e93ed34cbf20e4c66
Author: Jan Beulich 
Date:   Thu Aug 16 09:30:59 2018 +0200

gnttab/ARM: properly implement gnttab_create_status_page()

Prevent the "BUG_ON(page_get_owner(pg) != d)" in
gnttab_unpopulate_status_frames() from triggering.

Reported-by: 王磊 
Signed-off-by: Jan Beulich 
Reviewed-by: Stefano Stabellini 

commit 7626edeaca972e3e823535dcc44338f6b2f0b21f
Author: Paul Durrant 
Date:   Thu Aug 16 09:27:30 2018 +0200

x86/hvm/emulate: make sure rep I/O emulation does not cross GFN boundaries

When emulating a rep I/O operation it is possible that the ioreq will
describe a single operation that spans multiple GFNs. This is fine as long
as all those GFNs fall within an MMIO region covered by a single device
model, but unfortunately the higher levels of the emulation code do not
guarantee that. This is something that should almost certainly be fixed,
but in the meantime this patch makes sure that MMIO is truncated at GFN
boundaries and hence the appropriate device model is re-evaluated for each
target GFN.

NOTE: This patch does not deal with the case of a single MMIO operation
  spanning a GFN boundary. That is more complex to deal with and is
  deferred to a subsequent patch.

Signed-off-by: Paul Durrant 

Convert calculations to be 32-bit only.

Signed-off-by: Jan Beulich 

commit 4cdb6bfde2300c75725b3e267469bd6c955e
Author: Andrew Cooper 
Date:   Fri Mar 16 18:27:24 2018 +

xen/evtchn: Pass max_evtchn_port into 

Re: [Xen-devel] [PATCH v2 2/2] x86/mmcfg/drhd: Move acpi_mmcfg_init() call before calling acpi_parse_dmar()

[zhenzhong.duan]

Ok, that make sense for me. Thanks for your detailed explanation, I will 
rewrite the patch next week.

Sent from mobile

2018年8月17日 20:28于 Jan Beulich 写道：
>
> >>> On 17.08.18 at 09:01,  wrote: 
> > pci_conf_read8() needs pci mmcfg mapping to work on multiple pci segments 
> > system such as HPE Superdome-Flex. 
> > 
> > Move acpi_mmcfg_init() call in acpi_boot_init() before calling 
> > acpi_parse_dmar() so that when pci_conf_read8() is called in 
> > acpi_parse_dev_scope(), we already have the mapping set up. 
> > 
> > acpi_mmcfg_init() only setup mmcfg mapping and has some global variables 
> > initialized so there is no hazard to move it ahead. 
>
> I'm afraid this is a gross understatement. "Setup mappings" 
> alone is already putting such movement under question. Have 
> you checked explicitly that the initialization needed for this 
> setting up of mappings, if any, has actually occurred before 
> the new point the function gets called? 
>
> In particular, mmio_ro_ranges looks to get set up only after 
> the call to acpi_boot_init(). I guess you didn't see a crash 
> solely because you also move the invocation across the call 
> to zap_low_mappings(). 
>
> Similary pci_mmcfg_check_hostbridge() doesn't look all that 
> trivial. 
>
> Please may I ask that you be quite a bit more careful here, 
> even more so when you've been warned already? 
>
> > Meanwhile from its 
> > name, acpi_boot_init() is a proper place to call it. 
> > 
> > The alternative is moving the acpi_parse_dev_scope() call to a later point 
> > after acpi_mmcfg_init(). But acpi_parse_one_drhd(), acpi_parse_one_rmrr() 
> > and acpi_parse_one_atsr() all called acpi_parse_dev_scope() as their main 
> > job. Splitting those functions to two pieces looks less optimal and 
> > meaningless. 
>
> Certainly not meaningless; I'm also not sure why you consider 
> the device scope parsing their main job. It's perhaps their 
> most involved part, but the fact alone that for the purposes 
> here we could probably get away without that part already 
> suggests to me that this is a secondary (yet necessary) aspect. 
>
> Furthermore MMCFG will continue to not work this early (or 
> more precisely not at all until Dom0 boot has progressed far 
> enough) if the range(s) isn't/aren't marked reserved in E820. 
> It would be worthwhile saying half a sentence to this effect 
> in the description. 
>
> Jan 
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/6] x86/shadow: Switch shadow_domain.has_fast_mmio_entries to bool

[Jan Beulich]

>>> On 15.08.18 at 20:34,  wrote:
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -563,8 +563,7 @@ _sh_propagate(struct vcpu *v,
>  {
>  /* Guest l1e maps emulated MMIO space */
>  *sp = sh_l1e_mmio(target_gfn, gflags);
> -if ( !d->arch.paging.shadow.has_fast_mmio_entries )
> -d->arch.paging.shadow.has_fast_mmio_entries = 1;
> +d->arch.paging.shadow.has_fast_mmio_entries = true;

Are you sure the if() isn't intentionally there to avoid dirtying a
cacheline when the value is already as intended?

Jan



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

Re: [Xen-devel] [PATCH 1/6] x86/mm: Use mfn_eq()/mfn_add() rather than opencoded variations

[Jan Beulich]

>>> On 15.08.18 at 20:34,  wrote:
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -729,7 +729,8 @@ hap_write_p2m_entry(struct domain *d, unsigned long gfn, 
> l1_pgentry_t *p,
>   * unless the only change is an increase in access rights. */
>  mfn_t omfn = l1e_get_mfn(*p);
>  mfn_t nmfn = l1e_get_mfn(new);
> -flush_nestedp2m = !( mfn_x(omfn) == mfn_x(nmfn)
> +
> +flush_nestedp2m = !(mfn_eq(omfn, nmfn)
>  && perms_strictly_increased(old_flags, l1e_get_flags(new)) );

Seeing that you strip the stray leading space, could you strip the stray
trailing one as well, and move the && to its proper place?

With the one previously pointed out issue fixed
Reviewed-by: Jan Beulich 

Jan



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

Re: [Xen-devel] [PATCH] x86/build: Use new .nops directive when available

[Jan Beulich]

>>> On 15.08.18 at 19:57,  wrote:
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -29,6 +29,10 @@ $(call as-option-add,CFLAGS,CC,"invpcid 
> (%rax)$$(comma)%rax",-DHAVE_AS_INVPCID)
>  $(call as-option-add,CFLAGS,CC,\
>  ".if ((1 > 0) < 0); .error \"\";.endif",,-DHAVE_AS_NEGATIVE_TRUE)
>  
> +# Check to see whether the assmbler supports the .nop directive.
> +$(call as-option-add,CFLAGS,CC,\
> +".L1: .L2: .nops (.L2 - .L1)$$(comma)9",-DHAVE_AS_NOP_DIRECTIVE)

Can this please be HAVE_AS_NOPS_DIRECTIVE?

> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -84,6 +84,19 @@ static const unsigned char * const p6_nops[ASM_NOP_MAX+1] 
> init_or_livepatch_cons
>  
>  static const unsigned char * const *ideal_nops init_or_livepatch_data = 
> p6_nops;
>  
> +#ifdef HAVE_AS_NOP_DIRECTIVE
> +
> +/* Nops in .init.rodata to compare against the runtime ideal nops. */
> +asm ( ".pushsection .init.rodata, \"a\", @progbits\n\t"
> +  "toolchain_nops: .nops " __stringify(ASM_NOP_MAX) "\n\t"
> +  ".popsection\n\t");

Any particular reason not to put them in .init.text?

> @@ -27,6 +26,14 @@ extern void add_nops(void *insns, unsigned int len);
>  extern void apply_alternatives(struct alt_instr *start, struct alt_instr 
> *end);
>  extern void alternative_instructions(void);
>  
> +asm ( ".macro mknops nr_bytes\n\t"
> +#ifdef HAVE_AS_NOP_DIRECTIVE
> +  ".nops \\nr_bytes, " __stringify(ASM_NOP_MAX) "\n\t"
> +#else
> +  ".skip \\nr_bytes, 0x90\n\t"
> +#endif
> +  ".endm\n\t" );

Did you take a look at "x86/alternatives: allow using assembler macros
in favor of C ones" yet? Perhaps this redundant macro definition could
be avoided that way? I'm not going to exclude though that some more
work might be needed to get there.

Anyway, I'm in principle fine with the change, irrespective of the other
discussion we've had, so with the name change and possibly the other
two remarks taken care of
Acked-by: Jan Beulich 

Jan



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

Re: [Xen-devel] [PATCH v2 2/2] x86/mmcfg/drhd: Move acpi_mmcfg_init() call before calling acpi_parse_dmar()

[Jan Beulich]

>>> On 17.08.18 at 09:01,  wrote:
> pci_conf_read8() needs pci mmcfg mapping to work on multiple pci segments
> system such as HPE Superdome-Flex.
> 
> Move acpi_mmcfg_init() call in acpi_boot_init() before calling
> acpi_parse_dmar() so that when pci_conf_read8() is called in
> acpi_parse_dev_scope(), we already have the mapping set up.
> 
> acpi_mmcfg_init() only setup mmcfg mapping and has some global variables
> initialized so there is no hazard to move it ahead.

I'm afraid this is a gross understatement. "Setup mappings"
alone is already putting such movement under question. Have
you checked explicitly that the initialization needed for this
setting up of mappings, if any, has actually occurred before
the new point the function gets called?

In particular, mmio_ro_ranges looks to get set up only after
the call to acpi_boot_init(). I guess you didn't see a crash
solely because you also move the invocation across the call
to zap_low_mappings().

Similary pci_mmcfg_check_hostbridge() doesn't look all that
trivial.

Please may I ask that you be quite a bit more careful here,
even more so when you've been warned already?

> Meanwhile from its
> name, acpi_boot_init() is a proper place to call it.
> 
> The alternative is moving the acpi_parse_dev_scope() call to a later point
> after acpi_mmcfg_init(). But acpi_parse_one_drhd(), acpi_parse_one_rmrr()
> and acpi_parse_one_atsr() all called acpi_parse_dev_scope() as their main
> job. Splitting those functions to two pieces looks less optimal and 
> meaningless.

Certainly not meaningless; I'm also not sure why you consider
the device scope parsing their main job. It's perhaps their
most involved part, but the fact alone that for the purposes
here we could probably get away without that part already
suggests to me that this is a secondary (yet necessary) aspect.

Furthermore MMCFG will continue to not work this early (or
more precisely not at all until Dom0 boot has progressed far
enough) if the range(s) isn't/aren't marked reserved in E820.
It would be worthwhile saying half a sentence to this effect
in the description.

Jan



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

Re: [Xen-devel] [PATCH v2 1/2] x86/mmcfg: Rename pt_pci_init() and call it in acpi_mmcfg_init()

[Jan Beulich]

>>> On 17.08.18 at 09:01,  wrote:
> Given what pt_pci_init() actually does, rename it properly and move its
> declaration to pci.h, move the only call in acpi_mmcfg_init().
> 
> No functional change.
> 
> Signed-off-by: Zhenzhong Duan 
> Tested-by: Gopalasetty, Manoj 

Acked-by: Jan Beulich 



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

[Xen-devel] [linux-next test] 125915: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 125872
 test-amd64-amd64-rumprun-amd64 12 guest-startfail REGR. vs. 125872
 test-amd64-amd64-xl-shadow   12 guest-start  fail REGR. vs. 125872
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail 
REGR. vs. 125872
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 125872
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 
125872
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
125872
 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install  fail REGR. vs. 125872
 test-amd64-amd64-xl-multivcpu 12 guest-start fail REGR. vs. 125872
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start   fail REGR. vs. 125872
 test-amd64-amd64-xl-xsm  12 guest-start  fail REGR. vs. 125872
 test-amd64-amd64-xl  12 guest-start  fail REGR. vs. 125872
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 125872
 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
125872
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 125872
 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 125872
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 125872
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 125872
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 125872
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 125872
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 125872
 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 125872
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 125872
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 125872
 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 125872
 test-amd64-amd64-examine  8 reboot   fail REGR. vs. 125872
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail REGR. vs. 125872
 test-amd64-amd64-libvirt-xsm 12 guest-start  fail REGR. vs. 125872
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 125872
 test-amd64-amd64-xl-credit2  12 guest-start  fail REGR. vs. 125872
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 125872
 test-amd64-amd64-i386-pvgrub 10 debian-di-installfail REGR. vs. 125872
 test-amd64-amd64-amd64-pvgrub 10 debian-di-install   fail REGR. vs. 125872
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install  fail REGR. vs. 125872
 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 125872

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 12 guest-start  fail REGR. vs. 125872

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-bootfail blocked in 125872
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-bootfail blocked in 125872
 test-amd64-i386-freebsd10-i386  7 xen-boot  fail blocked in 125872
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot fail blocked in 125872
 test-amd64-i386-libvirt   7 xen-bootfail blocked in 125872
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail blocked 
in 125872
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot fail blocked in 125872
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail blocked 
in 125872
 test-amd64-i386-xl-raw7 xen-bootfail blocked in 125872
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot fail blocked in 125872
 test-amd64-i386-xl7 xen-bootfail blocked in 125872
 test-amd64-i386-freebsd10-amd64  7 xen-boot fail blocked in 125872
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail blocked in 
125872
 test-amd64-i386-xl-xsm7 xen-bootfail blocked in 125872
 test-amd64-i386-rumprun-i386  7 xen-bootfail blocked in 125872
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot fail blocked in 125872
 test-amd64-i386-xl-shadow 7 xen-bootfail blocked in 125872
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot  fail blocked in 125872
 test-amd64-i386-examine   8 reboot  fail blocked in 125872
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-bootfail blocked in 125872
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail blocked in 125872
 

Re: [Xen-devel] [PATCH RFC 1/2] drivers/base: export lock_device_hotplug/unlock_device_hotplug

[David Hildenbrand]

On 17.08.2018 13:28, Heiko Carstens wrote:
> On Fri, Aug 17, 2018 at 01:04:58PM +0200, David Hildenbrand wrote:
 If there are no objections, I'll go into that direction. But I'll wait
 for more comments regarding the general concept first.
>>>
>>> It is the middle of the merge window, and maintainers are really busy
>>> right now.  I doubt you will get many review comments just yet...
>>>
>>
>> This has been broken since 2015, so I guess it can wait a bit :)
> 
> I hope you figured out what needs to be locked why. Your patch description
> seems to be "only" about locking order ;)

Well I hope so, too ... but there is a reason for the RFC mark ;) There
is definitely a lot of magic in the current code. And that's why it is
also not that obvious that locking is wrong.

To avoid/fix the locking order problem was the motivation for the
original patch that dropped mem_hotplug_lock on one path. So I focused
on that in my description.

> 
> I tried to figure out and document that partially with 55adc1d05dca ("mm:
> add private lock to serialize memory hotplug operations"), and that wasn't
> easy to figure out. I was especially concerned about sprinkling

Haven't seen that so far as that was reworked by 3f906ba23689
("mm/memory-hotplug: switch locking to a percpu rwsem"). Thanks for the
pointer. There is a long history to all this.

> lock/unlock_device_hotplug() calls, which has the potential to make it the
> next BKL thing.

Well, the thing with memory hotplug and device_hotplug_lock is that

a) ACPI already holds it while adding/removing memory via add_memory()
b) we hold it during online/offline of memory (via sysfs calls to
   device_online()/device_offline())

So it is already pretty much involved in all memory hotplug/unplug
activities on x86 (except paravirt). And as far as I understand, there
are good reasons to hold the lock in core.c and ACPI. (as mentioned by
Rafael)

The exceptions are add_memory() called on s390x, hyper-v, xen and ppc
(including manual probing). And device_online()/device_offline() called
from the kernel.

Holding device_hotplug_lock when adding/removing memory from the system
doesn't sound too wrong (especially as devices are created/removed). At
least that way (documenting and following the rules in the patch
description) we might at least get locking right.


I am very open to other suggestions (but as noted by Greg, many
maintainers might be busy by know).

E.g. When adding the memory block devices, we know that there won't be a
driver to attach to (as there are no drivers for the "memory" subsystem)
- the bus_probe_device() function that takes the device_lock() could
pretty much be avoided for that case. But burying such special cases
down in core driver code definitely won't make locking related to memory
hotplug easier.

Thanks for having a look!

-- 

Thanks,

David / dhildenb

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

Re: [Xen-devel] [PATCH v5 8/8] x86/iommu: add map-reserved dom0-iommu option to map reserved memory ranges

[Jan Beulich]

>>> On 17.08.18 at 13:17,  wrote:
> On Fri, Aug 17, 2018 at 05:08:08AM -0600, Jan Beulich wrote:
>> >>> On 14.08.18 at 15:43,  wrote:
>> > @@ -185,7 +219,13 @@ void __hwdom_init arch_iommu_hwdom_init(struct domain 
>> > *d)
>> >  if ( !hwdom_iommu_map(d, pfn, max_pfn) )
>> >  continue;
>> >  
>> > -rc = iommu_map_page(d, pfn, pfn, IOMMUF_readable|IOMMUF_writable);
>> > +if ( iommu_use_hap_pt(d) )
>> > +{
>> > +ASSERT(is_hvm_domain(d));
>> > +rc = set_identity_p2m_entry(d, pfn, p2m_access_rw, 0);
>> > +}
>> > +else
>> > +rc = iommu_map_page(d, pfn, pfn, 
>> > IOMMUF_readable|IOMMUF_writable);
>> 
>> Why iommu_use_hap_pt()? Shouldn't HAP with or without shared
>> page tables as well as shadow all get the same in-sync p2m and
>> IOMMU mappings?
> 
> iommu_map_page is a noop if iommu_use_hap_pt is true (see
> intel_iommu_map_page for example). Hence in the case the IOMMU page
> tables are shared with HAP the pages must be added to the p2m.

This wasn't what I'm after, while ...

> I could switch this to use set_identity_p2m_entry if the guest is
> auto-translated and only use iommu_map_page for non-autotranslated
> guests.

 indeed this is what I would prefer (unless there a reasons
for not doing so).

Jan



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

Re: [Xen-devel] [PATCH RFC 1/2] drivers/base: export lock_device_hotplug/unlock_device_hotplug

[Heiko Carstens]

On Fri, Aug 17, 2018 at 01:04:58PM +0200, David Hildenbrand wrote:
> >> If there are no objections, I'll go into that direction. But I'll wait
> >> for more comments regarding the general concept first.
> > 
> > It is the middle of the merge window, and maintainers are really busy
> > right now.  I doubt you will get many review comments just yet...
> > 
> 
> This has been broken since 2015, so I guess it can wait a bit :)

I hope you figured out what needs to be locked why. Your patch description
seems to be "only" about locking order ;)

I tried to figure out and document that partially with 55adc1d05dca ("mm:
add private lock to serialize memory hotplug operations"), and that wasn't
easy to figure out. I was especially concerned about sprinkling
lock/unlock_device_hotplug() calls, which has the potential to make it the
next BKL thing.


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

[Xen-devel] Virtualization fundamental.

[Jason Long]

Hello.
Can anyone show me a book about learning Virtualization fundamental?

Thank you.

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

Re: [Xen-devel] [PATCH v5 8/8] x86/iommu: add map-reserved dom0-iommu option to map reserved memory ranges

[Roger Pau Monné]

On Fri, Aug 17, 2018 at 05:08:08AM -0600, Jan Beulich wrote:
> >>> On 14.08.18 at 15:43,  wrote:
> > @@ -185,7 +219,13 @@ void __hwdom_init arch_iommu_hwdom_init(struct domain 
> > *d)
> >  if ( !hwdom_iommu_map(d, pfn, max_pfn) )
> >  continue;
> >  
> > -rc = iommu_map_page(d, pfn, pfn, IOMMUF_readable|IOMMUF_writable);
> > +if ( iommu_use_hap_pt(d) )
> > +{
> > +ASSERT(is_hvm_domain(d));
> > +rc = set_identity_p2m_entry(d, pfn, p2m_access_rw, 0);
> > +}
> > +else
> > +rc = iommu_map_page(d, pfn, pfn, 
> > IOMMUF_readable|IOMMUF_writable);
> 
> Why iommu_use_hap_pt()? Shouldn't HAP with or without shared
> page tables as well as shadow all get the same in-sync p2m and
> IOMMU mappings?

iommu_map_page is a noop if iommu_use_hap_pt is true (see
intel_iommu_map_page for example). Hence in the case the IOMMU page
tables are shared with HAP the pages must be added to the p2m.

I could switch this to use set_identity_p2m_entry if the guest is
auto-translated and only use iommu_map_page for non-autotranslated
guests.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v5 8/8] x86/iommu: add map-reserved dom0-iommu option to map reserved memory ranges

[Jan Beulich]

>>> On 14.08.18 at 15:43,  wrote:
> @@ -138,13 +139,20 @@ static bool __hwdom_init hwdom_iommu_map(const struct 
> domain *d,
>   unsigned long pfn,
>   unsigned long max_pfn)
>  {
> +unsigned int i;
> +
>  /*
>   * Set up 1:1 mapping for dom0. Default to include only conventional RAM
>   * areas and let RMRRs include needed reserved regions. When set, the
>   * inclusive mapping additionally maps in every pfn up to 4GB except 
> those
> - * that fall in unusable ranges.
> + * that fall in unusable ranges for PV Dom0.
>   */
> -if ( (pfn > max_pfn && !mfn_valid(_mfn(pfn))) || xen_in_range(pfn) )
> +if ( (pfn > max_pfn && !mfn_valid(_mfn(pfn))) || xen_in_range(pfn) ||
> + /*
> +  * Ignore any address below 1MB, that's already identity mapped by 
> the
> +  * domain builder for HVM.
> +  */
> + (!d->domain_id && is_hvm_domain(d) && pfn < PFN_DOWN(MB(1))) )

Would you mind clarifying the comment by saying "Dom0 builder"?
The respective source files have been renamed to dom0_build.c
for the same reason, quite some time ago.

> +/* Check that it doesn't overlap with the LAPIC */
> +if ( has_vlapic(d) )
> +{
> +const struct vcpu *v;
> +
> +for_each_vcpu(d, v)
> +if ( pfn == PFN_DOWN(vlapic_base_address(vcpu_vlapic(v))) )
> +return false;
> +}
> +/* ... or the IO-APIC */
> +for ( i = 0; has_vioapic(d) && i < d->arch.hvm_domain.nr_vioapics; i++ )
> +if ( pfn == PFN_DOWN(domain_vioapic(d, i)->base_address) )
> +return false;
> +/*
> + * ... or the PCIe MCFG regions.
> + * TODO: runtime added MMCFG regions are not checked to make sure they
> + * don't overlap with already mapped regions, thus preventing trapping.
> + */
> +if ( has_vpci(d) && vpci_is_mmcfg_address(d, pfn_to_paddr(pfn)) )
> +return false;

Didn't we agree to have such a TODO also in the LAPIC loop?

> @@ -185,7 +219,13 @@ void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
>  if ( !hwdom_iommu_map(d, pfn, max_pfn) )
>  continue;
>  
> -rc = iommu_map_page(d, pfn, pfn, IOMMUF_readable|IOMMUF_writable);
> +if ( iommu_use_hap_pt(d) )
> +{
> +ASSERT(is_hvm_domain(d));
> +rc = set_identity_p2m_entry(d, pfn, p2m_access_rw, 0);
> +}
> +else
> +rc = iommu_map_page(d, pfn, pfn, 
> IOMMUF_readable|IOMMUF_writable);

Why iommu_use_hap_pt()? Shouldn't HAP with or without shared
page tables as well as shadow all get the same in-sync p2m and
IOMMU mappings?

Jan



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

Re: [Xen-devel] [PATCH RFC 1/2] drivers/base: export lock_device_hotplug/unlock_device_hotplug

[David Hildenbrand]

On 17.08.2018 12:06, Greg Kroah-Hartman wrote:
> On Fri, Aug 17, 2018 at 11:41:24AM +0200, David Hildenbrand wrote:
>> On 17.08.2018 11:03, Rafael J. Wysocki wrote:
>>> On Fri, Aug 17, 2018 at 10:56 AM David Hildenbrand  wrote:

 On 17.08.2018 10:41, Greg Kroah-Hartman wrote:
> On Fri, Aug 17, 2018 at 09:59:00AM +0200, David Hildenbrand wrote:
>> From: Vitaly Kuznetsov 
>>
>> Well require to call add_memory()/add_memory_resource() with
>> device_hotplug_lock held, to avoid a lock inversion. Allow external 
>> modules
>> (e.g. hv_balloon) that make use of add_memory()/add_memory_resource() to
>> lock device hotplug.
>>
>> Signed-off-by: Vitaly Kuznetsov 
>> [modify patch description]
>> Signed-off-by: David Hildenbrand 
>> ---
>>  drivers/base/core.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/base/core.c b/drivers/base/core.c
>> index 04bbcd779e11..9010b9e942b5 100644
>> --- a/drivers/base/core.c
>> +++ b/drivers/base/core.c
>> @@ -700,11 +700,13 @@ void lock_device_hotplug(void)
>>  {
>>  mutex_lock(_hotplug_lock);
>>  }
>> +EXPORT_SYMBOL_GPL(lock_device_hotplug);
>>
>>  void unlock_device_hotplug(void)
>>  {
>>  mutex_unlock(_hotplug_lock);
>>  }
>> +EXPORT_SYMBOL_GPL(unlock_device_hotplug);
>
> If these are going to be "global" symbols, let's properly name them.
> device_hotplug_lock/unlock would be better.  But I am _really_ nervous
> about letting stuff outside of the driver core mess with this, as people
> better know what they are doing.

 The only "problem" is that we have kernel modules (for paravirtualized
 devices) that call add_memory(). This is Hyper-V right now, but we might
 have other ones in the future. Without them we would not have to export
 it. We might also get kernel modules that want to call remove_memory() -
 which will require the device_hotplug_lock as of now.

 What we could do is

 a) add_memory() -> _add_memory() and don't export it
 b) add_memory() takes the device_hotplug_lock and calls _add_memory() .
 We export that one.
 c) Use add_memory() in external modules only

 Similar wrapper would be needed e.g. for remove_memory() later on.
>>>
>>> That would be safer IMO, as it would prevent developers from using
>>> add_memory() without the lock, say.
>>>
>>> If the lock is always going to be required for add_memory(), make it
>>> hard (or event impossible) to use the latter without it.
>>>
>>
>> If there are no objections, I'll go into that direction. But I'll wait
>> for more comments regarding the general concept first.
> 
> It is the middle of the merge window, and maintainers are really busy
> right now.  I doubt you will get many review comments just yet...
> 

This has been broken since 2015, so I guess it can wait a bit :)

-- 

Thanks,

David / dhildenb

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

Re: [Xen-devel] [PATCH v5 7/8] vpci: introduce a helper to check MMCFG ranges

[Jan Beulich]

>>> On 14.08.18 at 15:43,  wrote:
> The helpers returns whether a given memory address belongs to a domain
> MMCFG range.
> 
> Signed-off-by: Roger Pau Monné 

I'd prefer if this was part of the patch actually using the new function.

Jan


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

Re: [Xen-devel] [PATCH v5 5/8] x86/iommu: switch the hwdom mapping function to use page_get_type

[Jan Beulich]

>>> On 14.08.18 at 15:43,  wrote:
> --- a/xen/drivers/passthrough/x86/iommu.c
> +++ b/xen/drivers/passthrough/x86/iommu.c
> @@ -134,6 +134,37 @@ void arch_iommu_domain_destroy(struct domain *d)
>  {
>  }
>  
> +static bool __hwdom_init hwdom_iommu_map(const struct domain *d,
> + unsigned long pfn,
> + unsigned long max_pfn)
> +{
> +/*
> + * Set up 1:1 mapping for dom0. Default to include only conventional RAM
> + * areas and let RMRRs include needed reserved regions. When set, the
> + * inclusive mapping additionally maps in every pfn up to 4GB except 
> those
> + * that fall in unusable ranges.
> + */
> +if ( (pfn > max_pfn && !mfn_valid(_mfn(pfn))) || xen_in_range(pfn) )
> +return false;
> +
> +switch ( page_get_type(pfn) )
> +{
> +case RAM_TYPE_UNUSABLE:
> +return false;
> +
> +case RAM_TYPE_CONVENTIONAL:
> +if ( iommu_hwdom_strict )
> +return false;
> +break;
> +
> +default:
> +if ( !iommu_hwdom_inclusive || pfn > max_pfn )
> +return false;
> +}

Ah, in patch 8 it becomes clear why you want execution to fall out
of the switch() in the "true" case. Please disregard the respective
earlier comments then.

Jan



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

Re: [Xen-devel] [PATCH v5 6/8] dom0/pvh: change the order of the MMCFG initialization

[Jan Beulich]

>>> On 14.08.18 at 15:43,  wrote:
> So it's done before the iommu is initialized. This is required in
> order to be able to fetch the MMCFG regions from the domain struct.
> 
> No functional change.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v5 3/8] iommu: make iommu_inclusive_mapping a suboption of dom0-iommu

[Jan Beulich]

>>> On 17.08.18 at 12:32,  wrote:
> On Fri, Aug 17, 2018 at 04:04:34AM -0600, Jan Beulich wrote:
>> >>> On 14.08.18 at 15:43,  wrote:
>> > --- a/xen/drivers/passthrough/vtd/iommu.c
>> > +++ b/xen/drivers/passthrough/vtd/iommu.c
>> > @@ -1304,11 +1304,9 @@ static void __hwdom_init 
>> > intel_iommu_hwdom_init(struct domain *d)
>> >  {
>> >  struct acpi_drhd_unit *drhd;
>> >  
>> > -if ( !iommu_hwdom_passthrough && is_pv_domain(d) )
>> > -{
>> > -/* Set up 1:1 page table for hardware domain. */
>> > -vtd_set_hwdom_mapping(d);
>> > -}
>> > +/* Inclusive mappings are enabled by default on Intel hardware for 
>> > PV. */
>> > +if ( iommu_hwdom_inclusive == -1 )
>> > +iommu_hwdom_inclusive = is_pv_domain(d);
>> 
>> Hmm, I didn't notice this before, but there's an issue here for the
>> late-hwdom case: What if Dom0 and the actual hardware domain
>> differ in their PV-ness? I think you need to keep it at -1 here and
>> take the still -1 value into account in arch_iommu_hwdom_init().
>> iommu_hwdom_init() then also should not override it.
> 
> But isn't the late-hwdom the one that would be passed when calling
> intel_iommu_hwdom_init?
> 
> Or else how is intel_iommu_hwdom_init going to differentiate between
> Dom0 and a late-hwdom if the function is called for both?

Oh, you're right - I was under the wrong impression that the function
would be called for both Dom0 and hwdom in this case (and would act
identically, on the assumption that Dom0 is going to go away soon
anyway). As a result
Reviewed-by: Jan Beulich 

Jan



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

Re: [Xen-devel] [PATCH v5 5/8] x86/iommu: switch the hwdom mapping function to use page_get_type

[Jan Beulich]

>>> On 14.08.18 at 15:43,  wrote:
> +static bool __hwdom_init hwdom_iommu_map(const struct domain *d,

Unused function parameter?

> + unsigned long pfn,
> + unsigned long max_pfn)
> +{
> +/*
> + * Set up 1:1 mapping for dom0. Default to include only conventional RAM
> + * areas and let RMRRs include needed reserved regions. When set, the
> + * inclusive mapping additionally maps in every pfn up to 4GB except 
> those
> + * that fall in unusable ranges.
> + */
> +if ( (pfn > max_pfn && !mfn_valid(_mfn(pfn))) || xen_in_range(pfn) )
> +return false;
> +
> +switch ( page_get_type(pfn) )
> +{
> +case RAM_TYPE_UNUSABLE:
> +return false;
> +
> +case RAM_TYPE_CONVENTIONAL:
> +if ( iommu_hwdom_strict )
> +return false;
> +break;

Simply "return !iommu_hwdom_strict", to make it yet easier to follow
what happens in which case? But depending on your thoughts on
my remarks on the previous patch, this may change all over again
anyway.

> +default:
> +if ( !iommu_hwdom_inclusive || pfn > max_pfn )
> +return false;

And then a plain return statement here too?

Jan



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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  12 guest-start  fail REGR. vs. 125923

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

version targeted for testing:
 xen  3e4ec07e14bce81f6ae22c31ff1302d1f297a226
baseline version:
 xen  3dd454c6c694409aaedd4ed075d6aeace2dd8391

Last test of basis   125923  2018-08-15 16:00:41 Z1 days
Failing since125928  2018-08-15 19:00:49 Z1 days   16 attempts
Testing same since   126009  2018-08-16 20:00:24 Z0 days5 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christian Lindig 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Paul Durrant 
  Wei Liu 
  Zhenzhong Duan 

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



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

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

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

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


Not pushing.


commit 3e4ec07e14bce81f6ae22c31ff1302d1f297a226
Author: Andrew Cooper 
Date:   Thu Aug 16 16:26:22 2018 +0100

x86/setup: Avoid OoB E820 lookup when calculating the L1TF safe address

A number of corner cases (most obviously, no-real-mode and no Multiboot 
memory
map) can end up with e820_raw.nr_map being 0, at which point the L1TF
calculation will underflow.

Spotted by Coverity.

Signed-off-by: Andrew Cooper 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Jan Beulich 
Reviewed-by: Wei Liu 

commit afc3f910d3434b540e4e4f51d9fd2723aea22fa2
Author: Jan Beulich 
Date:   Thu Aug 16 00:49:29 2018 -0600

libxl: fix ARM build after 54ed251dc7

Commit "tools: Rework xc_domain_create() to take a full
xen_domctl_createdomain"  failed to replace one further instance of
xc_config in libxl__arch_domain_save_config().

Signed-off-by: Jan Beulich 
Acked-by: Andrew Cooper 
Acked-by: Ian Jackson 

commit 70d8543950ad045fddcb78ae11302e713ef09c76
Author: Zhenzhong Duan 
Date:   Thu Aug 16 09:31:57 2018 +0200

x86/mmcfg: remove redundant code in pci_mmcfg_reject_broken()

No functional change.

Signed-off-by: Zhenzhong Duan 
Acked-by: Jan Beulich 

commit a9e9837f54973ac45488c24e93ed34cbf20e4c66
Author: Jan Beulich 
Date:   Thu Aug 16 09:30:59 2018 +0200

gnttab/ARM: properly implement gnttab_create_status_page()

Prevent the "BUG_ON(page_get_owner(pg) != d)" in
gnttab_unpopulate_status_frames() from triggering.

Reported-by: 王磊 
Signed-off-by: Jan Beulich 
Reviewed-by: Stefano Stabellini 

commit 7626edeaca972e3e823535dcc44338f6b2f0b21f
Author: Paul Durrant 
Date:   Thu Aug 16 09:27:30 2018 +0200

x86/hvm/emulate: make sure rep I/O emulation does not cross GFN boundaries

When emulating a rep I/O operation it is possible that the ioreq will
describe a single operation that spans multiple GFNs. This is fine as long
as all those GFNs fall within an MMIO region covered by a single device
model, but unfortunately the higher levels of the emulation code do not
guarantee that. This is something that should almost certainly be fixed,
but in the meantime this patch makes sure that MMIO is truncated at GFN
boundaries and hence the appropriate device model is re-evaluated for each
target GFN.

NOTE: This patch does not deal with the case of a single MMIO operation
  spanning a GFN boundary. That is more complex to deal with and is
  deferred to a subsequent patch.

Signed-off-by: Paul Durrant 

Convert calculations to be 32-bit only.

Signed-off-by: Jan Beulich 

commit 4cdb6bfde2300c75725b3e267469bd6c955e
Author: Andrew Cooper 
Date:   Fri Mar 16 18:27:24 2018 +

xen/evtchn: Pass max_evtchn_port into 

Re: [Xen-devel] [PATCH v5 3/8] iommu: make iommu_inclusive_mapping a suboption of dom0-iommu

[Roger Pau Monné]

On Fri, Aug 17, 2018 at 04:04:34AM -0600, Jan Beulich wrote:
> >>> On 14.08.18 at 15:43,  wrote:
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -1304,11 +1304,9 @@ static void __hwdom_init 
> > intel_iommu_hwdom_init(struct domain *d)
> >  {
> >  struct acpi_drhd_unit *drhd;
> >  
> > -if ( !iommu_hwdom_passthrough && is_pv_domain(d) )
> > -{
> > -/* Set up 1:1 page table for hardware domain. */
> > -vtd_set_hwdom_mapping(d);
> > -}
> > +/* Inclusive mappings are enabled by default on Intel hardware for PV. 
> > */
> > +if ( iommu_hwdom_inclusive == -1 )
> > +iommu_hwdom_inclusive = is_pv_domain(d);
> 
> Hmm, I didn't notice this before, but there's an issue here for the
> late-hwdom case: What if Dom0 and the actual hardware domain
> differ in their PV-ness? I think you need to keep it at -1 here and
> take the still -1 value into account in arch_iommu_hwdom_init().
> iommu_hwdom_init() then also should not override it.

But isn't the late-hwdom the one that would be passed when calling
intel_iommu_hwdom_init?

Or else how is intel_iommu_hwdom_init going to differentiate between
Dom0 and a late-hwdom if the function is called for both?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v5 4/8] mm: introduce a helper to get the memory type of a page

[Jan Beulich]

>>> On 17.08.18 at 12:17,  wrote:
 On 14.08.18 at 15:43,  wrote:
>> +switch ( e820.map[i].type )
>> +{
>> +case E820_RAM:
>> +return RAM_TYPE_CONVENTIONAL;
>> +
>> +case E820_RESERVED:
>> +return RAM_TYPE_RESERVED;
>> +
>> +case E820_UNUSABLE:
>> +return RAM_TYPE_UNUSABLE;
>> +
>> +case E820_ACPI:
>> +case E820_NVS:
>> +return RAM_TYPE_ACPI;
>> +
>> +default:
>> +ASSERT_UNREACHABLE();
>> +return -1;
>> +}
>> +}
>> +
>> +return -1;
>> +}
> 
> One more case to consider: What about a page part of which is
> a given type, and the other part of which is simply missing from
> the E820 table? I'm uncertain whether in that case it might be a
> good idea in general to report it as having the given type; for the
> specific purpose you want the function for, that would imo be
> quite helpful.

Considering RAM_TYPE_* are bit masks - perhaps the function
should OR together all types found for the requested page, and
let the caller go from there? And to account for my earlier remark,
add a separate RAM_TYPE_UNKNOWN (and never have the function
return -1 or some such; its return type then would better be
unsigned int)?

Jan



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

[Xen-devel] [qemu-upstream-unstable test] 125919: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122862
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122862
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122862
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122862
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 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-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-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-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-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:
 qemuu4f080070a9809bde857851e68a3aeff0c4b9b6a6
baseline version:
 qemuu43139135a8938de44f66333831d3a8655d07663a

Last test of basis   122862  2018-05-16 03:19:52 Z   93 days
Testing same since   125919  2018-08-15 11:37:57 Z1 days1 attempts


365 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-amd64-i386-xl-xsm   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvhv2-amd

Re: [Xen-devel] [PATCH] libxc: copy back the result of XEN_DOMCTL_createdomain

[Wei Liu]

On Fri, Aug 17, 2018 at 11:50:53AM +0200, Roger Pau Monne wrote:
> Fixes the ARM build breakage introduced by 54ed251dc7.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v5 4/8] mm: introduce a helper to get the memory type of a page

[Jan Beulich]

>>> On 14.08.18 at 15:43,  wrote:
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1181,6 +1181,12 @@ int page_is_ram_type(unsigned long mfn, unsigned long 
> mem_type)
>  return 0;
>  }
>  
> +int page_get_type(unsigned long mfn)
> +{
> +ASSERT_UNREACHABLE();
> +return -1;
> +}

With the assertion, why is the function needed in the first place?

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -430,6 +430,40 @@ int page_is_ram_type(unsigned long mfn, unsigned long 
> mem_type)
>  return 0;
>  }
>  
> +int page_get_type(unsigned long mfn)

Considering we already have get_page_type(), this function name
needs to change. At the very least page_get_ram_type(), looking
at the set of values it may return.

> +{
> +uint64_t maddr = pfn_to_paddr(mfn);
> +unsigned int i;
> +
> +for ( i = 0; i < e820.nr_map; i++ )
> +{
> +/* Test the range. */
> +if ( (e820.map[i].addr <= maddr) &&
> + ((e820.map[i].addr + e820.map[i].size) >= (maddr + PAGE_SIZE)) )

Would you mind inverting the condition and using continue, both
to reduce indentation of the switch and to make it very clear that
no braces are needed / wanted?

> +switch ( e820.map[i].type )
> +{
> +case E820_RAM:
> +return RAM_TYPE_CONVENTIONAL;
> +
> +case E820_RESERVED:
> +return RAM_TYPE_RESERVED;
> +
> +case E820_UNUSABLE:
> +return RAM_TYPE_UNUSABLE;
> +
> +case E820_ACPI:
> +case E820_NVS:
> +return RAM_TYPE_ACPI;
> +
> +default:
> +ASSERT_UNREACHABLE();
> +return -1;
> +}
> +}
> +
> +return -1;
> +}

One more case to consider: What about a page part of which is
a given type, and the other part of which is simply missing from
the E820 table? I'm uncertain whether in that case it might be a
good idea in general to report it as having the given type; for the
specific purpose you want the function for, that would imo be
quite helpful.

Jan



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