[Xen-devel] [ovmf baseline-only test] 38337: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38337 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38337/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f
baseline version:
 ovmf 8084b26e926ba3bf12b8110e7d49d3c928bb17d6

Last test of basis38327  2015-11-24 01:20:56 Z0 days
Testing same since38337  2015-11-24 20:49:54 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Eric Dong 
  Heyi Guo 
  Leif Lindholm 

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.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


commit 63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f
Author: Leif Lindholm 
Date:   Mon Nov 23 19:34:40 2015 +

ShellBinPkg: Arm/AArch64 Shell binary update.

The binaries of ShellBinPkg are generated with ShellPkg from r18915.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
Reviewed-by: Jaben Carsey 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18925 
6f19259b-4bc3-4df7-8a09-765794883524

commit ce7690e267dc3205357e0d0e3a57e2b6fd1de895
Author: Dandan Bi 
Date:   Mon Nov 23 09:37:24 2015 +

MdeModulePkg:Refine the UiApp

Use new created libraries(Boot Manager,Device Manager,Boot Maintenance
Manager) in UiApp.So remove and refine relative code in UiApp.And update
the Nt32Pkg.dsc and MdeModulePkg.dsc.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 
Reviewed-by: Liming Gao 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18924 
6f19259b-4bc3-4df7-8a09-765794883524

commit 4af04335ac9aeb1802b995b102117b6f9de46809
Author: Dandan Bi 
Date:   Mon Nov 23 09:34:55 2015 +

MdeModulePkg:Create Boot Maintenance Manager Library

Split the boot maintenance manager library from UiApp in 
MdeModulePkg/Application
and put the library in MdeModulePkg/Library.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 
Reviewed-by: Liming Gao 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18923 
6f19259b-4bc3-4df7-8a09-765794883524

commit 32465d9ae7eed891154780f0b13fabf0b15ae7c3
Author: Dandan Bi 
Date:   Mon Nov 23 09:33:42 2015 +

MdeModulePkg:Create Device Manager Library

Split the device manager library from UiApp in MdeModulePkg/Application
and put the library in MdeModulePkg/Library.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 
Reviewed-by: Liming Gao 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18922 
6f19259b-4bc3-4df7-8a09-765794883524

commit 3a2dc0f5a9e311a840ffd69571a4a264c9e1c3c0
Author: Dandan Bi 
Date:   Mon Nov 23 09:32:08 2015 +

MdeModulePkg:Create Boot Manager Library

Split the boot manager library from UiApp in MdeModulePkg/Application
and put the library in MdeModulePkg/Library.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 
Reviewed-by: Liming Gao 

git-svn-id: 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  16 guest-start/debian.repeat fail REGR. vs. 65076

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

version targeted for testing:
 xen  0c3f24645b07b875bc1294fb4627f01e030690fe
baseline version:
 xen  9b436680f081ae397e8c25ce2c23d3cd1359ce86

Last test of basis65076  2015-11-24 17:02:33 Z0 days
Testing same since65083  2015-11-24 20:02:22 Z0 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Jan Beulich 

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 0c3f24645b07b875bc1294fb4627f01e030690fe
Author: Boris Ostrovsky 
Date:   Tue Nov 24 18:33:08 2015 +0100

x86/VPMU: Initialize VPMU's lvtpc vector

If a guest sets up performance counters so that they can generate
a PMC interrupt but does not initilaize APIC LVTPC register the
resulting interrupt will cause an APIC error.

Note that a guest deciding to clear LVTPC in order to unduce the error
will not be successful in achieving its goal: emulation code only
looks at the mask bit and always sets the vector to PMU_APIC_VECTOR.
Only the initial value of LVTPC (which is zero) that gets loaded into
APIC as result of PMC initialization is the problem.

Signed-off-by: Boris Ostrovsky 

commit c03480cf5c4e96fb4afb2237ad0a3cac7162564a
Author: Jan Beulich 
Date:   Tue Nov 24 18:32:20 2015 +0100

x86/vPMU: document as unsupported

This is XSA-163.

Signed-off-by: Jan Beulich 
(qemu changes not included)

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

[Xen-devel] [PATCH v2 1/2] x86/VPMU: return correct fixed PMC count

[Brendan Gregg]

Fixes a register typo.

Signed-off-by: Brendan Gregg 
---
 xen/arch/x86/cpu/vpmu_intel.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index 12f80ae..8d83a1a 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -166,10 +166,10 @@ static int core2_get_arch_pmc_count(void)
  */
 static int core2_get_fixed_pmc_count(void)
 {
-u32 eax;
+u32 edx;
 
-eax = cpuid_eax(0xa);
-return MASK_EXTR(eax, PMU_FIXED_NR_MASK);
+edx = cpuid_edx(0xa);
+return MASK_EXTR(edx, PMU_FIXED_NR_MASK);
 }
 
 /* edx bits 5-12: Bit width of fixed-function performance counters  */
-- 
1.9.1


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

[Xen-devel] [PATCH v2 2/2] x86/VPMU: implement ipc and arch filter flags

[Brendan Gregg]

This introduces a way to have a restricted VPMU, by specifying one of two
predefined groups of PMCs to make available. For secure environments, this
allows the VPMU to be used without needing to enable all PMCs.

Signed-off-by: Brendan Gregg 
---
 docs/misc/xen-command-line.markdown | 14 +-
 xen/arch/x86/cpu/vpmu.c | 51 +
 xen/arch/x86/cpu/vpmu_intel.c   | 48 ++
 xen/include/asm-x86/msr-index.h |  1 +
 xen/include/public/pmu.h| 14 --
 5 files changed, 115 insertions(+), 13 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 70daa84..6055a68 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1452,7 +1452,7 @@ Use Virtual Processor ID support if available.  This 
prevents the need for TLB
 flushes on VM entry and exit, increasing performance.
 
 ### vpmu
-> `= ( bts )`
+> `= (  | { bts | ipc | arch [, ...] } )`
 
 > Default: `off`
 
@@ -1468,6 +1468,18 @@ wrong behaviour (see handle\_pmc\_quirk()).
 If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
 feature is switched on on Intel processors supporting this feature.
 
+vpmu=ipc enables performance monitoring, but restricts the counters to the
+most minimum set possible: instructions, cycles, and reference cycles. These
+can be used to calculate instructions per cycle (IPC).
+
+vpmu=arch enables performance monitoring, but restricts the counters to the
+pre-defined architectural events only. These are exposed by cpuid, and listed
+in Table 18-1 from the Intel 64 and IA-32 Architectures Software Developer's
+Manual, Volume 3B, System Programming Guide, Part 2.
+
+If a boolean is not used, combinations of flags are allowed, comma separated.
+For example, vpmu=arch,bts.
+
 Note that if **watchdog** option is also specified vpmu will be turned off.
 
 *Warning:*
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 2f5156a..bb0ca37 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -43,33 +43,64 @@ CHECK_pmu_data;
 CHECK_pmu_params;
 
 /*
- * "vpmu" : vpmu generally enabled
- * "vpmu=off" : vpmu generally disabled
- * "vpmu=bts" : vpmu enabled and Intel BTS feature switched on.
+ * "vpmu" : vpmu generally enabled (all counters)
+ * "vpmu=off"  : vpmu generally disabled
+ * "vpmu=bts"  : vpmu enabled and Intel BTS feature switched on.
+ * "vpmu=ipc"  : vpmu enabled for IPC counters only (most restrictive)
+ * "vpmu=arch" : vpmu enabled for predef arch counters only (restrictive)
+ * flag combinations are allowed, eg, "vpmu=ipc,bts".
  */
 static unsigned int __read_mostly opt_vpmu_enabled;
 unsigned int __read_mostly vpmu_mode = XENPMU_MODE_OFF;
 unsigned int __read_mostly vpmu_features = 0;
-static void parse_vpmu_param(char *s);
-custom_param("vpmu", parse_vpmu_param);
+static void parse_vpmu_params(char *s);
+custom_param("vpmu", parse_vpmu_params);
 
 static DEFINE_SPINLOCK(vpmu_lock);
 static unsigned vpmu_count;
 
 static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
 
-static void __init parse_vpmu_param(char *s)
+static int parse_vpmu_param(char *s, int len)
 {
+if ( ! *s || ! len )
+return 0;
+if ( !strncmp(s, "bts", len) )
+vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
+else if ( !strncmp(s, "ipc", len) )
+vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
+else if ( !strncmp(s, "arch", len) )
+vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
+else if ( *s )
+{
+return 1;
+}
+return 0;
+}
+
+static void __init parse_vpmu_params(char *s)
+{
+bool_t badflag = 0;
+char *sep, *p = s;
+
 switch ( parse_bool(s) )
 {
 case 0:
 break;
 default:
-if ( !strcmp(s, "bts") )
-vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
-else if ( *s )
+sep = strchr(p, ',');
+while (sep != NULL)
+{
+if ( parse_vpmu_param(p, sep - p) )
+badflag = 1;
+p = sep + 1;
+sep = strchr(p, ',');
+}
+sep = strchr(p, 0);
+parse_vpmu_param(p, sep - p);
+if ( badflag )
 {
-printk("VPMU: unknown flag: %s - vpmu disabled!\n", s);
+printk("VPMU: unknown flags: %s - vpmu disabled!\n", s);
 break;
 }
 /* fall through */
diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index 8d83a1a..b26a20b 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -602,12 +602,19 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
  "MSR_PERF_GLOBAL_STATUS(0x38E)!\n");
 return -EINVAL;
 case MSR_IA32_PEBS_ENABLE:
+if ( vpmu_features & XENPMU_FEATURE_IPC_ONLY ||
+ vpmu_features & XENPMU_FEATURE_ARCH_ONLY )
+return 

[Xen-devel] [PATCH v2 0/2] Restricted VPMU filter flags

[Brendan Gregg]

This patch series fixes a minor bug with cpuid register usage for fixed PMC
counts, and implements two VPMU filter flags.

The VPMU feature of Xen is incredibly useful for performance analysis, however,
it is currently all counters or nothing. In secure environments, there can be
hesitation to enable access to all PMCs. This series introduces two new flags
(in addition to the existing "bts"):

vpmu=ipc: As the most restricted minimum set. This enables cycles, reference
cycles, and instructions only. This is enough to calculate instructions per
cycle (IPC).

vpm=arch: This enables the 7 pre-defined architectural events as listed in
cpuid, and in Table 18-1 of the Intel software developer's manual, vol 3B.

There can be additional flags added later on, to allow access to other groups
of PMCs.

As an example of these flags, here is Linux perf running in a PVHVM guest with
the new vpmu=ipc mode:

root@vm0hvm:~# perf stat -d ./noploop

 Performance counter stats for './noploop':

   1511.326375 task-clock (msec) #0.999 CPUs utilized  
24 context-switches  #0.016 K/sec  
 0 cpu-migrations#0.000 K/sec  
   113 page-faults   #0.075 K/sec  
 5,028,638,883 cycles#3.327 GHz
 0 stalled-cycles-frontend   #0.00% frontend cycles idle   
 0 stalled-cycles-backend#0.00% backend  cycles idle   
20,043,427,933 instructions  #3.99  insns per cycle
 0 branches  #0.000 K/sec  
 0 branch-misses #0.00% of all branches
 0 L1-dcache-loads   #0.000 K/sec  
 0 L1-dcache-load-misses #0.00% of all L1-dcache hits  
 0 LLC-loads #0.000 K/sec  
LLC-load-misses:HG

Note that IPC is shown ("insns per cycle"), but other counters are not.

Changes in v2:
* feature flags can now be combined (eg, "vpmu=ipc,bts")
* addressing review comments from Boris:
* restrict DS_AREA and PEBS_ENABLE access when filters are in use
* better variable types
* include MSR_IA32_CMT_EVTSEL_UE_MASK flag

Brendan Gregg (2):
  x86/VPMU: return correct fixed PMC count
  x86/VPMU: implement ipc and arch filter flags

 docs/misc/xen-command-line.markdown | 14 +-
 xen/arch/x86/cpu/vpmu.c | 51 ---
 xen/arch/x86/cpu/vpmu_intel.c   | 54 ++---
 xen/include/asm-x86/msr-index.h |  1 +
 xen/include/public/pmu.h| 14 --
 5 files changed, 118 insertions(+), 16 deletions(-)

-- 
1.9.1


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 63449
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 64988 REGR. vs. 63449

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 64988 pass in 65028
 test-armhf-armhf-xl-multivcpu  6 xen-boot  fail in 64988 pass in 65062
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail in 64988 pass in 65062
 test-armhf-armhf-libvirt-xsm 11 guest-startfail in 65028 pass in 65062
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail in 65028 pass in 65062
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail pass in 64988
 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 65028

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested  3 host-install(3)  broken baseline untested
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 
fail blocked in 63449

Tests which did not succeed, but are not blocking:
 build-i386-rumpuserxen1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   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-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 65028 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 65028 never pass
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 65028 never pass
 test-amd64-i386-libvirt  12 migrate-support-check fail in 65028 never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 65028 never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-check fail in 65028 never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 65028 never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 65028 never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 

Re: [Xen-devel] xen 4.5.0 rtds scheduler perform poorly with 2vms

[Dario Faggioli]

On Mon, 2015-11-23 at 07:42 -0800, Yu-An(Victor) Chen wrote:
> Hi all,
> 
Hello,

> So I was doing some experiments to evaluate RTDS scheduler
> schedubility of real time tasks using 1vm with period of 1 and
> budget of 1. The experiment results turn out as expected(perform
> better than xen-credit).
> 
> But when I tried to perform similar experiments with 2 vms (both with
> now period of 1 and budget of 5000). The schedubility of real
> time tasks turn out really bad. Even if I have one vm idling and the
> other vm running the real time tasks, the schedubility of that vm is
> still really poor(worse than xen-credit). Am I missing some
> configuration I should have set for 2vm cases? Thank you
> 
What is it that you are trying to prove with this setup? This is
despite all Meng is already saying about the non-work conserving nature
of RTDS, and about the LITMUS IPI bug.

In fact, in general, real-time schedulers are really good at isolating
workloads, with precise time guarantees. If you have stuff that needs
to be done in 2 VMs, and you use RTDS for scheduling the 2 VMs, you'll
get good and precisely characterized isolation between them.

But if you put all the stuff in only 1 VM, and then limit its own
utilization, all you are doing is making it hard for the things inside
the VM itself to achieve their target performance, with respect to both
an instance of RTDS where that VM has 100% utilization, as well as with
(almost) any general purpose scheduler.

Then, again, as Meng is saying, if you not only have "stuff" to do
inside the VM, but you are interested in in-guest real-time, then the
scheduling parameters of the VM(s) and the ones of the tasks in the
guest(s), should be set according to a proper real-time hierarchical
scheduling scheme that allows for guarantees to be met.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



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

Re: [Xen-devel] [PATCH v3 12/62] ACPICA: ACPI 6.0: Add changes for FADT table

[Shannon Zhao]

On 2015/11/24 19:29, Jan Beulich wrote:
 On 17.11.15 at 10:40,  wrote:
>> From: Bob Moore 
>>
>> ACPICA commit 72b0b6741990f619f6aaa915302836b7cbb41ac4
>>
>> One new 64-bit field at the end of the table.
>> FADT version is now 6.
>>
>> Link: https://github.com/acpica/acpica/commit/72b0b674 
>> Signed-off-by: Bob Moore 
>> Signed-off-by: Lv Zheng 
>> Signed-off-by: Rafael J. Wysocki 
>> [Linux commit aeb823bbacc2a3aaee29eda5875b58a049fa1f78]
>> Signed-off-by: Shannon Zhao 
>> ---
>>  xen/include/acpi/actbl.h | 17 ++---
>>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> So while I applied this one after fixing it up, I'm not going to do any
> further fixups to later patches I also meant to apply. I realize the
> fixups may have been necessary because of me applying them in
> other than the submitted sequence, but then again such general
> imports from ACPICA/Linux should have been independent of
> earlier changes. I.e. either earlier patches in the series wrongly
> touch these headers, or there's a general problem with the series.
> 
I will split this patch set in several parts and the first part would be
the changes and updates of ACPI SPEC 5.0~6.0. So maybe you could apply
them at next version.

Thanks,
-- 
Shannon


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 63340

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 libvirt  eebe58adeb08730d66fc407cf6024cd8ea319447
baseline version:
 libvirt  3c7590e0a435d833895fc7b5be489e53e223ad95

Last test of basis63340  2015-10-28 04:19:47 Z   27 days
Failing since 63352  2015-10-29 04:20:29 Z   26 days   22 attempts
Testing same since65068  2015-11-24 04:20:15 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Chen Hanxiao 
  Cole Robinson 
  Daniel P. Berrange 
  Daniel Veillard 
  Guido Günther 
  Jim Fehlig 
  Jiri Denemark 
  Joao Martins 
  John Ferlan 
  Ján Tomko 
  Laine Stump 
  Luyao Huang 
  Maxim Perevedentsev 
  Michal Privoznik 
  Michel Normand 
  Mikhail Feoktistov 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 
  Richard Weinberger 
  Roman Bogorodskiy 
  Stefan Berger 
  Stefan Berger 

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



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

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

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

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


Not pushing.

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

[Xen-devel] [linux-mingo-tip-master test] 65069: regressions - FAIL

[osstest service owner]

flight 65069 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65069/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops 5 kernel-build  fail REGR. vs. 60684
 build-i386-pvops  5 kernel-build  fail REGR. vs. 60684

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  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-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a

version targeted for testing:
 linux3c54871e0f73f72bdc4e5ea1f9ab0ad42e3cd5dd
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  

Re: [Xen-devel] Xen 4.7 Development Update

[Han, Huaitong]

On Mon, 2015-11-09 at 16:15 +, Wei Liu wrote:
> = Timeline =
> 
> We now adopt a fixed cut-off date scheme. We will release twice a
> year. The upcoming 4.7 timeline are as followed:
> 
> * Last posting date: March 18, 2016
> * Hard code freeze: April 1, 2016
> * RC1: TBD
> * Release: July 1, 2016
> 
> Note that we don't have freeze exception scheme anymore. All patches
> that wish to go into 4.7 must be posted no later than the last
> posting
> date. All patches posted after that date will be automatically queued
> into next release.
> 
> RCs will be arranged immediately after freeze.
> 
> = Projects =

== Hypervisor ==
=== x86 ===
*Memory protection keys for user pages
 -Huaitong Han

I want to see it in 4.7, I have sent the 1st version patchset for
review, and continue working on it.

Thanks
Huaitong
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 64035

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 64035
 test-amd64-amd64-qemuu-nested 16 debian-hvm-install/l1/l2 fail baseline 
untested
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 64035
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 64035
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 64035
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail like 64035

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  827db7b26384ce083df7154d77f13379b2cf4121
baseline version:
 xen  22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c

Last test of basis64035  2015-11-10 08:01:11 Z   14 days
Failing since 64149  2015-11-11 19:15:29 Z   13 days9 attempts
Testing same since65066  2015-11-24 02:32:19 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Aravind Gopalakrishnan 
  Bob Liu 
  Boris Ostrovsky 
  David Scott 
  Feng Wu 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jim Fehlig 
  Jonathan Davies 
  Juergen Gross 
  Oleksandr Tyshchenko 
  Razvan Cojocaru 
  Riku Voipio 
  Roger Pau Monné 
  Shannon Zhao 
  Simon Rowe 
  Stefano Stabellini 
  Wei Liu 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  0c3f24645b07b875bc1294fb4627f01e030690fe
baseline version:
 xen  9b436680f081ae397e8c25ce2c23d3cd1359ce86

Last test of basis65076  2015-11-24 17:02:33 Z0 days
Testing same since65083  2015-11-24 20:02:22 Z0 days2 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Jan Beulich 

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 :

+ branch=xen-unstable-smoke
+ revision=0c3f24645b07b875bc1294fb4627f01e030690fe
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
0c3f24645b07b875bc1294fb4627f01e030690fe
+ branch=xen-unstable-smoke
+ revision=0c3f24645b07b875bc1294fb4627f01e030690fe
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-unstable
+ '[' x0c3f24645b07b875bc1294fb4627f01e030690fe = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' 

Re: [Xen-devel] [PATCH] libxl: Introduce a template for devices with a controller

[Chun Yan Liu]

>>> On 11/24/2015 at 10:40 PM, in message
<1448376011-20217-1-git-send-email-george.dun...@eu.citrix.com>, George Dunlap
 wrote: 
> We have several outstanding patch series which add devices that have 
> two levels: a controller and individual devices attached to that 
> controller. 
>  
> In the interest of consistency, this patch introduces a section that 
> sketches out a template for interfaces for such devices.

Some typos. Otherwise, agreed.

- Chunyan
 
>  
> Signed-off-by: George Dunlap  
> --- 
> CC: Ian Campbell  
> CC: Ian Jackson  
> CC: Wei Liu  
> CC: Juergen Gross  
> CC: Chun Yan Liu  
> CC: Olaf Hering  
>  
> Changes in v1 (since the RFC): 
>  
> - Use  rather than , and  rather than specifying 
>   controller and device.  The idea being to allow SCSI to use 
>   terminology more natural to it (i.e., scsihost, scsitarget, scsilun) 
>   rather than naming things after USB (controller & device). 
>  
> - Do not require each  to have a deviceid, but just a unique 
>   naming schema. 
>  
> - Allow multiple levels. 
>  
> - Include the paragraph about domain configuration lists. 
> --- 
>  tools/libxl/libxl.h | 65  
> + 
>  1 file changed, 65 insertions(+) 
>  
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h 
> index 6b73848..46bcfe8 100644 
> --- a/tools/libxl/libxl.h 
> +++ b/tools/libxl/libxl.h 
> @@ -1396,6 +1396,71 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int  
> nr_vtpms); 
>   * 
>   *   This function does not interact with the guest and therefore 
>   *   cannot block on the guest. 
> + * 
> + * Controllers 
> + * --- 
> + * 
> + * Most devices are treated individually.  Some classes of device, 
> + * however, like USB or SCSI, inherently have the need to have a 
> + * heiarchy of different levels, with lower-level devices "attached" 
> + * to higher-level ones.  USB for instance has "controllers" at the 
> + * top, which have busses, on which are devices, which consist of 
> + * multiple interfaces.  SCSI has "hosts" at the top, then busses, 
> + * targets, and LUNs. 
> + * 
> + * In that case, for each , there will be a set of funcitons

^^^ functions
> + * and types for each .  For example, for =usb, there 
> + * may be  ctrl (controller) and dev (device), with ctrl being 
> + * level 0. 
> + * 
> + * libxl_device__ will act more or 
> + * less like top-level non-bus devices: they will either create or 
> + * accept a libxl_devid which will be unique within the 
> + *  libxl_devid namespace. 
  ?
> + * 
> + * Lower-level devices must have a unique way to be identified.  One 
> + * way to do this would be to name it via the name of the next level 
> + * up plus an index; for instance, .  Another 
> + * way would be to have another devid namespace for that level.  This 
> + * identifier will be used for queries and removals. 
> + * 
> + * Lower-level devices will will include in their 
  ^ s/will will/will/
> + * libxl_device_ struct a field referring to the unique 
> + * index of the level above.  For instance, libxl_device_usbdev might 
> + * contain the controller devid. 
> + * 
> + * In the case where there are multiple different ways to implement a 
> + * given device -- for instance, one which is fully PV and one which 
> + * uses an emulator -- the controller will contain a field which 
> + * specifies what type of implementation is used.  The implementations 
> + * of individual devices will be known by the controller to which they 
> + * are attached. 
> + * 
> + * If libxl_device__add receives an empty reference to 
> + * the level above, it may return an error.  Or it may (but is not 
> + * required to) automatically choose a suitable device in the level 
> + * above to which to attach the new device at this level.  It may also 
> + * (but is not required to) automatically create a new device at the 
> + * level above if no suitable devices exist.  Each class should 
> + * document its behavior. 
> + * 
> + * libxl_device__list will list all devices of  
> + * at  in the domain.  For example, libxl_class_usbctrl_list 
  
libxl_device_usbctrl_list
> + * will list all usb controllers; libxl_class_usbdev_list will list 
   libxl_device_usbdev_list
> + * all usb devices across all controllers. 
> + * 
> + * For each class, the domain config file will contain a single list 
> + * for each level.  libxl will first iterate through the list of 
> + * top-level devices, then iterate through each level down in turn, 
> + * adding devices to devices in the level above.  For instance, there 
> + * 

Re: [Xen-devel] [PATCH] paravirt: remove paravirt ops pmd_update[_defer] and pte_update_defer

[Rusty Russell]

Juergen Gross  writes:
> Ping?

Acked-by: Rusty Russell 

Cheers,
Rusty.

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

Re: [Xen-devel] Rumprun based upstream QEMU stubdom status update

[Eric Shelton]

Thanks for taking the time to consider my comments and respond.

On Tue, Nov 24, 2015 at 9:44 AM, Wei Liu  wrote:

> Another chunk of work is teaching QEMU to not initialised some
> component or take a different path when initialising some
> components. This is the same as Linux-based stubdom.
>

When I was working on Linux-based stubdom earlier, it was the point where
serious QEMU-related work needed to be done  (in particular, working out
getting the display to work correctly via VNC or otherwise) that I reached
the limit of what I could accomplish on my own in a reasonable amount of
time.  There was simply too much for me to learn about QEMU internals and
how they are supposed to interact with Xen.  On top of that, getting QMP
and save/restore working across domains appears to require some serious
effort, and is for the most part outside of what I need QEMU stubdom for.


> One lesson learned from QEMU-trad stubdom is that the build system
> inevitably turns into a black hole that sucks in effort but yields no
> clear return. That's why we would very much prefer doing things "the
> right way", i.e. relying on well-established ways to deliver this
> feature, and expanding the user base till it is large enough to draw
> enough interest for this feature to be self-sustained.
>

That last bit is where I am interested in bringing this to - having the
basic functionality in place, so that others may be encouraged to drive to
completion the aspects that they have an interest or stake in.  Right now,
there is so much that needs to be done, that many would rather not touch
any of it.


> What is really not clear at the moment is the path to Linux
> distributions and BSDs. Xen project doesn't distribute binaries. Also
> , to build an image requires specialised toolchain and build system
> that distros are not interested in taking in. Building for *BSD is a
> no-go at the moment for Linux-based stubdom and QEMU-trad stubdom.
>

I agree that for the time being, *BSD would be off the table for
Linux-based stubdom - it would take a lot of bootstrapping to get an
environment up and running under *BSD to build the Linux-based stubdom on
*BSD.

It could be sensible to modify the no-binaries position if the notion of a
reproducible build could be implemented.  This could allow distribution of
a binary image for Linux-based stubdom (which would not be all that big)
for use by *BSD and others, yet demonstrate that the binary image does
correspond to the underlying source.  However, that is several step down
the road from just getting it to work on Linux.


> I discussed with Stefano and Anthony to reassess Linux-based stubdom,
> with all the issues mentioned above, if we narrow down the scope of
> the project -- ignore BSD support for now, integrate build with
> Raisin, no distros integration -- it can actually be done within a
> finite time frame.
>
> Here are some issues with the existing patch series:
>
> 1. It's using Dracut build image, which is Redhat-centric.
>

That issue was raised before, but I'm not sure how much it really is.
FWIW, I was using my updated version of Anthony's work on a Gentoo system,
and encountered no issues.  Is there a Linux distribution that we know
dracut does not work on?  It would be helpful to know.  Although I have not
really dug into dracut, it seemed to be effective for our purposes
(collecting the libraries that need to be included in the Linux image for
QEMU), and I'd rather not recreate dracut or part of dracut if we don't
need to.


> 2. Some patches are not yet complete and not suitable to upstream.
>

What kinds of things are being done by these patches?  You mentioned
component initialization; however, I did not encounter any problems
relating to that when getting QEMU upstream stubdom up to the point of
running SSH on a standard Linux distribution, etc.  Having to disable such
things makes sense as an issue under rumprun, given the likely difficulties
in getting certain libraries to run under rumprun, but I would expect it to
be less of an issue when QEMU gets run in its native Linux environment.


> And these are the steps that need to be done:
>
> 1. Build with Raisin
>   1.1 Build Linux kernel with a customised config.
>   1.2 Build QEMU from a customised branch.
>   1.3 Extract QEMU libraries dependency with generic tool.
>   1.4 Generate a disk image with generic tool.
> 2. Toolstack plumbing and make work other components.
> 3. Teach OSStest to constantly test it.
>
> Would you be up for working on Raisin integration?  That is, up to the
> point of producing an image. We can discuss certain actions in
> detailed and will help you with the issues you encounter along the
> way. We appreciate help from the community as we're already quite
> stretched with other projects.
>

I believe that is something I can work on, and likely won't be all that bad
given where things already are.  However, I know essentially nothing about
Raisin.  What is a good way to 

Re: [Xen-devel] [PATCH OSSTEST] make-flight: Run separate nested jobs on AMD and Intel

[Hu, Robert]

> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, November 23, 2015 6:49 PM
> To: ian.jack...@eu.citrix.com; xen-devel@lists.xen.org
> Cc: Ian Campbell ; Hu, Robert
> 
> Subject: [PATCH OSSTEST] make-flight: Run separate nested jobs on AMD and
> Intel
> 
> nested HVM relies heavily on the underlying HVM implementation, which
> is different for Intel and AMD and therefore worth testing separately.
> 
> Currently test-amd64-amd64-qemuu-nested is not tied to any specific
> vendor, split it into -amd and -intel jobs and set the host flags
> appropriately.
> 
> Signed-off-by: Ian Campbell 
> Cc: "Hu, Robert" 
> ---
>  make-flight | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/make-flight b/make-flight
> index 6f462ad..6b2b3ea 100755
> --- a/make-flight
> +++ b/make-flight
> @@ -269,7 +269,9 @@ do_hvm_debian_nested_tests () {
>  xen-4.3-testing)  return;;
>esac
> 
> -  job_create_test test-$xenarch$kern-$dom0arch$qemuu_suffix-nested \
> +  for cpuvendor in amd intel; do
> +
> +job_create_test
> test-$xenarch$kern-$dom0arch$qemuu_suffix-nested-$cpuvendor \
>  test-nested xl $xenarch $dom0arch $qemuu_runvar
> \
>  l1_image=$(usual_debianhvm_image amd64)
> \
>  l1_vifmodel='e1000'
> \
> @@ -277,7 +279,9 @@ do_hvm_debian_nested_tests () {
>  l1_enable_nestedhvm='true'
> \
>  l2_image=$(usual_debianhvm_image amd64)
> \
>  bios=$bios
> \
> -all_hostflags=$most_hostflags,hvm
> +all_hostflags=$most_hostflags,hvm-$cpuvendor
> +
> +  done
>  }
> 
>  branch_debianhvm_arch () {
[Hu, Robert] 

Aced-by: Robert Hu 

And thanks!

> --
> 2.6.1


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

[Xen-devel] [PATCHv2] 2/3] update outdated header comment on privcmd.h

[Doug Goldstein]

The BSDs have always accessed privcmd via /dev/xen/privcmd while Linux
has used /proc/xen/privcmd but things are shifting to /dev/xen/privcmd
as well.

CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Ian Campbell 
CC: Wei Liu 
Signed-off-by: Doug Goldstein 
Acked-by: Ian Jackson 
---
 tools/include/xen-sys/FreeBSD/privcmd.h| 2 +-
 tools/include/xen-sys/Linux/privcmd.h  | 2 +-
 tools/include/xen-sys/NetBSD/privcmd.h | 2 +-
 tools/include/xen-sys/NetBSDRump/privcmd.h | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/include/xen-sys/FreeBSD/privcmd.h 
b/tools/include/xen-sys/FreeBSD/privcmd.h
index 0434d4d..cf1241f 100644
--- a/tools/include/xen-sys/FreeBSD/privcmd.h
+++ b/tools/include/xen-sys/FreeBSD/privcmd.h
@@ -1,7 +1,7 @@
 /**
  * privcmd.h
  *
- * Interface to /proc/xen/privcmd.
+ * Interface to /dev/xen/privcmd.
  *
  * Copyright (c) 2003-2005, K A Fraser
  *
diff --git a/tools/include/xen-sys/Linux/privcmd.h 
b/tools/include/xen-sys/Linux/privcmd.h
index 5be860a..e4e666a 100644
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -1,7 +1,7 @@
 /**
  * privcmd.h
  * 
- * Interface to /proc/xen/privcmd.
+ * Interface to /dev/xen/privcmd.
  * 
  * Copyright (c) 2003-2005, K A Fraser
  * 
diff --git a/tools/include/xen-sys/NetBSD/privcmd.h 
b/tools/include/xen-sys/NetBSD/privcmd.h
index 1296b30..555bad9 100644
--- a/tools/include/xen-sys/NetBSD/privcmd.h
+++ b/tools/include/xen-sys/NetBSD/privcmd.h
@@ -30,7 +30,7 @@
 #ifndef __NetBSD_PRIVCMD_H__
 #define __NetBSD_PRIVCMD_H__
 
-/* Interface to /proc/xen/privcmd */
+/* Interface to /dev/xen/privcmd */
 
 typedef struct privcmd_hypercall
 {
diff --git a/tools/include/xen-sys/NetBSDRump/privcmd.h 
b/tools/include/xen-sys/NetBSDRump/privcmd.h
index 1296b30..555bad9 100644
--- a/tools/include/xen-sys/NetBSDRump/privcmd.h
+++ b/tools/include/xen-sys/NetBSDRump/privcmd.h
@@ -30,7 +30,7 @@
 #ifndef __NetBSD_PRIVCMD_H__
 #define __NetBSD_PRIVCMD_H__
 
-/* Interface to /proc/xen/privcmd */
+/* Interface to /dev/xen/privcmd */
 
 typedef struct privcmd_hypercall
 {
-- 
2.4.10


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

[Xen-devel] [PATCHv2] 1/3] libxc: prefer using privcmd character device

[Doug Goldstein]

Prefer using the character device over the proc file if the character
device exists. This follows similar conversions of xenbus to avoid
issues with FMODE_ATOMIC_POS added in Linux 3.14 and newer.

CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Ian Campbell 
CC: Wei Liu 
Signed-off-by: Doug Goldstein 
---
 tools/libxc/xc_linux_osdep.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
index 76c55ff..c078b3d 100644
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -46,7 +46,14 @@
 static xc_osdep_handle linux_privcmd_open(xc_interface *xch)
 {
 int flags, saved_errno;
-int fd = open("/proc/xen/privcmd", O_RDWR);
+int fd = open("/dev/xen/privcmd", O_RDWR); /* prefer this newer interface 
*/
+
+if ( fd == -1 && ( errno == ENOENT || errno == ENXIO ||
+   errno == ENODEV || errno == EACCES ))
+{
+/* Fallback to /proc/xen/privcmd */
+fd = open("/proc/xen/privcmd", O_RDWR);
+}
 
 if ( fd == -1 )
 {
-- 
2.4.10


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

[Xen-devel] [PATCHv2] 3/3] xendomains initscript: test for privcmd char device

[Doug Goldstein]

Allow the init script to continue if either the character device or the
proc file is available.

CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Ian Campbell 
CC: Wei Liu 
Signed-off-by: Doug Goldstein 
Acked-by: Ian Jackson 
---
 tools/hotplug/Linux/xendomains.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/xendomains.in 
b/tools/hotplug/Linux/xendomains.in
index 0603842..686f061 100644
--- a/tools/hotplug/Linux/xendomains.in
+++ b/tools/hotplug/Linux/xendomains.in
@@ -45,7 +45,7 @@ fi
 
 # Correct exit code would probably be 5, but it's enough
 # if xend complains if we're not running as privileged domain
-if ! [ -e /proc/xen/privcmd ]; then
+if ! [ -e /dev/xen/privcmd ] || [ -e /proc/xen/privcmd ]; then
exit 0
 fi
 
-- 
2.4.10


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

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

[Ed Swierk]

RFC. Boot tested on VMware Fusion, and on a 2-socket Xeon server.

diff --git a/xen/include/asm-x86/smp.h b/xen/include/asm-x86/smp.h
index ea07888..a41ce2d 100644
--- a/xen/include/asm-x86/smp.h
+++ b/xen/include/asm-x86/smp.h
@@ -67,7 +67,7 @@ extern unsigned int nr_sockets;
 void set_nr_sockets(void);

 /* Representing HT and core siblings in each socket. */
-extern cpumask_t **socket_cpumask;
+cpumask_t *socket_cpumask(unsigned int socket);

 #endif /* !__ASSEMBLY__ */

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 0946992..6aadaac 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -60,7 +60,7 @@ cpumask_t cpu_online_map __read_mostly;
 EXPORT_SYMBOL(cpu_online_map);

 unsigned int __read_mostly nr_sockets;
-cpumask_t **__read_mostly socket_cpumask;
+static struct radix_tree_root socket_cpumask_tree;
 static cpumask_t *secondary_socket_cpumask;

 struct cpuinfo_x86 cpu_data[NR_CPUS];
@@ -81,6 +81,11 @@ static enum cpu_state {

 void *stack_base[NR_CPUS];

+cpumask_t *socket_cpumask(unsigned int socket)
+{
+return radix_tree_lookup(_cpumask_tree, socket);
+}
+
 static void smp_store_cpu_info(int id)
 {
 struct cpuinfo_x86 *c = cpu_data + id;
@@ -92,9 +97,9 @@ static void smp_store_cpu_info(int id)
 identify_cpu(c);

 socket = cpu_to_socket(id);
-if ( !socket_cpumask[socket] )
+if ( radix_tree_insert(_cpumask_tree, socket,
+   secondary_socket_cpumask) == 0 )
 {
-socket_cpumask[socket] = secondary_socket_cpumask;
 secondary_socket_cpumask = NULL;
 }
 }
@@ -258,7 +263,7 @@ static void set_cpu_sibling_map(int cpu)

 cpumask_set_cpu(cpu, _sibling_setup_map);

-cpumask_set_cpu(cpu, socket_cpumask[cpu_to_socket(cpu)]);
+cpumask_set_cpu(cpu, socket_cpumask(cpu_to_socket(cpu)));

 if ( c[cpu].x86_num_siblings > 1 )
 {
@@ -666,11 +671,12 @@ static void cpu_smpboot_free(unsigned int cpu)
 {
 unsigned int order, socket = cpu_to_socket(cpu);
 struct cpuinfo_x86 *c = cpu_data;
+cpumask_t *m = socket_cpumask(socket);

-if ( cpumask_empty(socket_cpumask[socket]) )
+if ( m && cpumask_empty(m) )
 {
-xfree(socket_cpumask[socket]);
-socket_cpumask[socket] = NULL;
+radix_tree_delete(_cpumask_tree, socket);
+xfree(m);
 }

 c[cpu].phys_proc_id = XEN_INVALID_SOCKET_ID;
@@ -804,6 +810,8 @@ static struct notifier_block cpu_smpboot_nfb = {

 void __init smp_prepare_cpus(unsigned int max_cpus)
 {
+cpumask_t *m;
+
 register_cpu_notifier(_smpboot_nfb);

 mtrr_aps_sync_begin();
@@ -819,9 +827,9 @@ void __init smp_prepare_cpus(unsigned int max_cpus)

 set_nr_sockets();

-socket_cpumask = xzalloc_array(cpumask_t *, nr_sockets);
-if ( socket_cpumask == NULL ||
- (socket_cpumask[cpu_to_socket(0)] = xzalloc(cpumask_t)) == NULL )
+radix_tree_init(_cpumask_tree);
+if ( (m = xzalloc(cpumask_t)) == NULL ||
+ radix_tree_insert(_cpumask_tree, cpu_to_socket(0), m) != 0 )
 panic("No memory for socket CPU siblings map");

 if ( !zalloc_cpumask_var(_cpu(cpu_sibling_mask, 0)) ||
@@ -888,7 +896,7 @@ remove_siblinginfo(int cpu)
 {
 int sibling;

-cpumask_clear_cpu(cpu, socket_cpumask[cpu_to_socket(cpu)]);
+cpumask_clear_cpu(cpu, socket_cpumask(cpu_to_socket(cpu)));

 for_each_cpu ( sibling, per_cpu(cpu_core_mask, cpu) )
 {
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index c0daa2e..7acb3d9 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -52,14 +52,6 @@ static DEFINE_PER_CPU(struct psr_assoc, psr_assoc);

 static struct psr_cat_cbm *temp_cos_to_cbm;

-static unsigned int get_socket_cpu(unsigned int socket)
-{
-if ( likely(socket < nr_sockets) )
-return cpumask_any(socket_cpumask[socket]);
-
-return nr_cpu_ids;
-}
-
 static void __init parse_psr_bool(char *s, char *value, char *feature,
   unsigned int mask)
 {
@@ -331,7 +323,8 @@ static int write_l3_cbm(unsigned int socket,
unsigned int cos, uint64_t cbm)
 do_write_l3_cbm();
 else
 {
-unsigned int cpu = get_socket_cpu(socket);
+cpumask_t *m = socket_cpumask(socket);
+unsigned int cpu = m ? cpumask_any(m) : nr_cpu_ids;

 if ( cpu >= nr_cpu_ids )
 return -ENOTSOCK;
@@ -503,8 +496,9 @@ static void cat_cpu_init(void)
 static void cat_cpu_fini(unsigned int cpu)
 {
 unsigned int socket = cpu_to_socket(cpu);
+cpumask_t *m = socket_cpumask(socket);

-if ( !socket_cpumask[socket] || cpumask_empty(socket_cpumask[socket]) )
+if ( !m || cpumask_empty(m) )
 {
 struct psr_cat_socket_info *info = cat_socket_info + socket;



On Tue, Nov 24, 2015 at 7:20 AM, Jan Beulich  wrote:
 On 24.11.15 at 15:13,  wrote:
>> On Tue, Nov 24, 2015 at 2:34 AM, Jan Beulich  wrote:
>>> Bottom line - for 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-pvh-amd   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-freebsd10-i386  6 xen-bootfail REGR. vs. 59254
 test-amd64-amd64-xl-pvh-intel  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-xsm6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-rumpuserxen-amd64  6 xen-bootfail REGR. vs. 59254
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
59254
 test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-bootfail REGR. vs. 59254
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemut-rhel6hvm-amd  6 xen-bootfail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot   fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-pair10 xen-boot/dst_host fail REGR. vs. 59254
 test-amd64-amd64-pair 9 xen-boot/src_host fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 59254
 test-amd64-i386-pair  9 xen-boot/src_host fail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. 
vs. 59254
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck  6 xen-bootfail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline 
untested
 test-amd64-i386-xl-raw6 xen-bootfail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested

[Xen-devel] qemu-xen.git trouble with tags of stable branches

[Mark Pryor]

Hello,
http://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=summary
looking at the tags for the 2 stable branches which are involved in the recent 
patch to xen.gitunifying the qemu trees.
tags:
qemu-xen-4.6.0qemu-xen-4.5.2

The revisions pointed to in the above tags are not unique and cause wrong 
results in git queries like:git log --pretty=oneline qemu-xen-4.5.2..HEAD | wc 
-l   -> 8419

 git log --pretty=oneline qemu-xen-4.6.0..HEAD | wc -l  -> 4168

the last query should eval to about 85.
In a quick browse of the web view of the repo I see the same patch commit 
multiple times, under different hashes.So this repo is new and still only used 
in staging and if there are errors there is nothing serious, not yet anyway.
Thanks for your attention,PryMar56
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 2/3] arm: export platform_op XENPF_settime64

[Daniel De Graaf]

On 16/11/15 08:08, Ian Campbell wrote:

On Thu, 2015-11-12 at 17:46 +, Stefano Stabellini wrote:

Call update_domain_wallclock_time at domain initialization.
Set time_offset_seconds to the number of seconds between physical boot
and domain initialization: it is going to be used to get/set the
wallclock time.
Add time_offset_seconds to system_time when before calling do_settime,
so that system_time actually accounts for all the time in nsec between
machine boot and when the wallclock was set.

Expose xsm_platform_op to ARM.

Signed-off-by: Stefano Stabellini 


Acked-by: Ian Campbell 

An aside:[...]
@@ -1332,6 +1332,75 @@ static int flask_deassign_dtdevice(struct domain

*d, const char *dtpath)
  }
  #endif /* HAS_PASSTHROUGH && HAS_DEVICE_TREE */

+static int flask_platform_op(uint32_t op)
+{
+switch ( op )
+{
+#ifdef CONFIG_X86
+/* These operations have their own XSM hooks */
+case XENPF_cpu_online:
+case XENPF_cpu_offline:
+case XENPF_cpu_hotadd:
+case XENPF_mem_hotadd:
+return 0;


Should this not then be an error (e.g. fail closed)?


During the invocation of these operations, two XSM hooks are called: this
one (from above the switch) and the individual hook (inside the switch).
This hook needs to allow access so that the more detailed hook is called.


Also, although only implemented today for x86 they don't seem inherently
any more x86 specific than many of the other things below, so maybe the
ifdef could be ditched?


The #ifdef is there mostly as a failsafe reminder to ensure that the
implementation for other architectures actually calls the same XSM hooks
that the x86 version does.


--
Daniel De Graaf
National Security Agency

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f
baseline version:
 ovmf 8084b26e926ba3bf12b8110e7d49d3c928bb17d6

Last test of basis65031  2015-11-23 02:12:10 Z1 days
Testing same since65064  2015-11-24 01:12:13 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Eric Dong 
  Heyi Guo 
  Leif Lindholm 

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 :

+ branch=ovmf
+ revision=63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f
+ branch=ovmf
+ revision=63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'

Re: [Xen-devel] [PATCH 3/4] gdbsx: prefer privcmd character device

[Doug Goldstein]

On 11/24/15 1:19 PM, Doug Goldstein wrote:
> On 11/24/15 12:53 PM, Ian Jackson wrote:
>> Doug Goldstein writes ("[PATCH 3/4] gdbsx: prefer privcmd character device"):
>>> Prefer using the character device over the proc file if the character
>>> device exists.
>>
>> I think this common logic (which also appears in your 1/4 patch)
>> should be factored out.
>>
>> Could gdbsx not use a libxc handle ?
>>
>> Ian.
>>
> 
> I agree. I actually emailed the maintainer about this but his address
> bounced so I left it as the simpler patch instead. I can make that
> chance and resubmit if you'd prefer.
> 

I'll just drop this out of the v2 and look at improving it in another
series.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 3164361121526318f278a7c1b84bdcc475d4ad95
baseline version:
 ovmf 63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f

Last test of basis65064  2015-11-24 01:12:13 Z1 days
Testing same since65085  2015-11-24 21:47:18 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Ruiyu Ni 
  Wei Huang 

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 :

+ branch=ovmf
+ revision=3164361121526318f278a7c1b84bdcc475d4ad95
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
3164361121526318f278a7c1b84bdcc475d4ad95
+ branch=ovmf
+ revision=3164361121526318f278a7c1b84bdcc475d4ad95
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x3164361121526318f278a7c1b84bdcc475d4ad95 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

[Chao Peng]

On Tue, Nov 24, 2015 at 03:34:45AM -0700, Jan Beulich wrote:
> >>> On 23.11.15 at 17:36,  wrote:
> > I instrumented detect_extended_topology() and ran again with 4 CPUs.
> >[...]
> > (XEN) smp_store_cpu_info id=3
> > (XEN) detect_extended_topology cpuid_count op=0xb count=0 eax=0x0 ebx=0x1 
> > ecx=0x100 edx=0x6
> > (XEN) detect_extended_topology initial_apicid=6 core_plus_mask_width=0 
> > core_level_siblings=1
> > (XEN) detect_extended_topology cpuid_count op=0xb count=1 eax=0x0 ebx=0x1 
> > ecx=0x201 edx=0x6
> > (XEN) detect_extended_topology ht_mask_width=0 core_plus_mask_width=0 
> > core_select_mask=0x0 core_level_siblings=1
> >[...]
> > If cpuid 0xb returned 1 rather than 0 in eax[4:0], we would get
> > consecutively-numbered physical processor IDs.
> > 
> > But the only requirement I see in the IA SDM (vol 2A, table 3-17) is that
> > the eax[4:0] value yield unique IDs, not necessarily consecutive. Likewise
> > while the examples in vol 3A sec 8.9 show physical IDs numbered
> > consecutively, the algorithms do not assume this is the case.
> 
> Indeed, and I think I had said so. The algorithm does, however, tell
> us that with the above output CPU 3 (APIC ID 6) is on socket 6 (both
> shifts being zero), which for the whole system results in sockets 1,
> 3, and 5 unused. While not explicitly excluded, I'm not sure how far
> we should go in expecting all kinds of odd configurations (along those
> lines we e.g. have a limit on the largest APIC ID we allow: MAX_APICS /
> MAX_LOCAL_APIC, which for big systems is 4 times the number of
> CPUs we support).
> 
> Taking it to set_nr_sockets(), a pretty basic assumption is broken by
> the above way of presenting topology: We would have to have more
> sockets than there are CPUs. I would have wanted to check what
> e.g. Linux does here, but there doesn't seem to be any support of
> CAT (and hence any need for per-socket data) there.

Actually I checked Linux code when I implementing this but it doesn't
exist. Current Linux CAT patch supports only system-level other than
per-socket level so it doesn't need that as well. There are people
requesting to add per-socket support so Linux need solve this problem
eventually. But at this time, we don't have any reference.

> 
> (I am, btw, now also confused by you saying that e.g. for a 3-CPU
> config things work. If the topology data gets presented in similar
> ways in that case, I can't see why you wouldn't run into the same
> problem. Unless memory corruption occurs silently in one case, but
> "loudly" in the other.)
> 
> Bottom line - for the moment I do not see a reasonable way of
> dealing with that situation. The closest I could see would be what
> we iirc had temporarily during the review cycles of the initial CAT
> series: A command line option to specify the number of sockets. Or
> make all accesses to socket_cpumask[] conditional upon PSR being
> enabled (which would have the bad side effect of making future
> uses for other purposes more cumbersome), or go through and
> range check the socket number on all of those accesses.
> 
> Chao, could you - inside Intel - please check whether there are
> any assumptions on the respective CPUID leaf output that aren't
> explicitly stated in the SDM right now (like resulting in contiguous
> socket numbers), and ask for them getting made explicit (if there
> are any), or it being made explicit that no assumptions at all are
> to be made at all on the presented values

Actually there is already such statement in SDM (ch8.9.1, vol3):

"The value of valid APIC_IDs need not be contiguous across package
boundary or core boundaries".

> (in which case we'd
> have to consume MADT parsing data in set_nr_sockets(), e.g.
> by replacing num_processors there with one more than the
> maximum APIC ID of any non-disabled CPU)?

Even with this, we still have problem for hotplug case, the inserted
CPU may have a APIC_ID bigger than the maximum APIC_ID here.

But let's back to the real world. Most machines that support CAT should
have continuous SOCKET_ID so it's not a problem. Giving that CAT is the
only feature uses this, I guess this suggestion might be better than
other solutions in practice. 

Chao

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

[Xen-devel] [PATCH for-2.5] vnc: fix segfault

[Gerd Hoffmann]

Commit "c7628bf vnc: only alloc server surface with clients connected"
missed one rarely used codepath (cirrus with guest drivers using 2d
accel) where we have to check for the server surface being present,
to avoid qemu crashing with a NULL pointer dereference.  Add the check.

Reported-by: Anthony PERARD 
Signed-off-by: Gerd Hoffmann 
---
 ui/vnc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/ui/vnc.c b/ui/vnc.c
index c9f2fed..7538405 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -931,6 +931,11 @@ static void vnc_dpy_copy(DisplayChangeListener *dcl,
 int i, x, y, pitch, inc, w_lim, s;
 int cmp_bytes;
 
+if (!vd->server) {
+/* no client connected */
+return;
+}
+
 vnc_refresh_server_surface(vd);
 QTAILQ_FOREACH_SAFE(vs, >clients, next, vn) {
 if (vnc_has_feature(vs, VNC_FEATURE_COPYRECT)) {
-- 
1.8.3.1


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

[Xen-devel] How to recognize which guest issues the hypercall?

[Big Strong]

I write a program to intercept all hypercalls happend on a xen hypervisor.
How can I know which domain called the hypercall? Is it possible to obtain
it from the registers?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [V12 1/4] x86/xsaves: using named operand instead numbered operand in xrstor

[Shuai Ruan]

From: Shuai Ruan 

This is pre-req patch for latter xsaves patch. This patch introduce
a macro to handle restor fixup, also use named opreand instead of
numbered operand in restor fixup code.

Signed-off-by: Shuai Ruan 
---
 xen/arch/x86/xstate.c | 43 +++
 1 file changed, 19 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 827e0e1..bb6d5e11 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -158,6 +158,16 @@ void xsave(struct vcpu *v, uint64_t mask)
 ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET] = word_size;
 }
 
+#define XRSTOR_FIXUP   ".section .fixup,\"ax\"   \n"\
+   "2: mov %[size],%%ecx \n"\
+   "   xor %[lmask_out],%[lmask_out] \n"\
+   "   rep stosb \n"\
+   "   lea %[mem],%[ptr] \n"\
+   "   mov %[lmask_in],%[lmask_out]  \n"\
+   "   jmp 1b\n"\
+   ".previous\n"\
+   _ASM_EXTABLE(1b, 2b)
+
 void xrstor(struct vcpu *v, uint64_t mask)
 {
 uint32_t hmask = mask >> 32;
@@ -188,38 +198,23 @@ void xrstor(struct vcpu *v, uint64_t mask)
 {
 default:
 asm volatile ( "1: .byte 0x48,0x0f,0xae,0x2f\n"
-   ".section .fixup,\"ax\"  \n"
-   "2: mov %5,%%ecx \n"
-   "   xor %1,%1\n"
-   "   rep stosb\n"
-   "   lea %2,%0\n"
-   "   mov %3,%1\n"
-   "   jmp 1b   \n"
-   ".previous   \n"
-   _ASM_EXTABLE(1b, 2b)
-   : "+" (ptr), "+" (lmask)
-   : "m" (*ptr), "g" (lmask), "d" (hmask),
- "m" (xsave_cntxt_size)
+   XRSTOR_FIXUP
+   : [ptr] "+" (ptr), [lmask_out] "+" (lmask)
+   : [mem] "m" (*ptr), [lmask_in] "g" (lmask),
+ [hmask] "d" (hmask), [size] "m" (xsave_cntxt_size)
: "ecx" );
 break;
 case 4: case 2:
 asm volatile ( "1: .byte 0x0f,0xae,0x2f\n"
-   ".section .fixup,\"ax\" \n"
-   "2: mov %5,%%ecx\n"
-   "   xor %1,%1   \n"
-   "   rep stosb   \n"
-   "   lea %2,%0   \n"
-   "   mov %3,%1   \n"
-   "   jmp 1b  \n"
-   ".previous  \n"
-   _ASM_EXTABLE(1b, 2b)
-   : "+" (ptr), "+" (lmask)
-   : "m" (*ptr), "g" (lmask), "d" (hmask),
- "m" (xsave_cntxt_size)
+   XRSTOR_FIXUP
+   : [ptr] "+" (ptr), [lmask_out] "+" (lmask)
+   : [mem] "m" (*ptr), [lmask_in] "g" (lmask),
+ [hmask] "d" (hmask), [size] "m" (xsave_cntxt_size)
: "ecx" );
 break;
 }
 }
+#undef XRSTOR_FIXUP
 
 bool_t xsave_enabled(const struct vcpu *v)
 {
-- 
1.9.1


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

[Xen-devel] [V12 0/4] add xsaves/xrstors support

[Shuai Ruan]

From: Shuai Ruan 

Changes in v12:
* Address comments from Jan:
* Add a seperate, pre-req patch to change from using numbered operand to 
  named operand in xrstor.
* Using alterive_io in xrstor side.

Changes in v11:
* Address comments from Jan:
* Using alternative asm on xrstor side. 
  For xsave side(alternative asm), I will send a seperate patch to do this. 

Changes in v10:
* Address comments from Jan:
* Add two new macros to handle alternative asm with fixup code in patch1.
* Fix a coding style error in patch2.

Changes in v9:
* Address comments from Jan:
* Add msr_ia32_xss save/restor support in patch2.
* Change xrstor to alternative asm in patch1.
* Use memcpy() copy the save header to avoid one ugly cast in patch1.
* Fix coding style errors.

Changes in v8:
* Address comments from Jan/Andrew:
* Add optimisation in set_msr_xss in patch1.
* Change from black listing feature to white listing in pv_cpuid in patch2.
* Add MSR_IA32_XSS save/restore support in patch2.
* Fix some code errors and coding style errors.

Changes in v7:
* Address comments from Jan/Andrew:
* Move macro XSTATE_FIXUP into patch3.
* Change lazy write to xss_msr in patch1.
* Drop inner set of brackets and stray cast in patch2.
* Move the condition and memcpy() wouldn't into the new called functions in 
patch2.
* Rebase patch4 base on Andrew's"tools/libxc: Improve efficiency of 
xc_cpuid_apply_policy()".
* For no XSS features are currently supported.For leaf 2...63,ecx remain zero 
at 
  the moment in patch4.

Changes in v6:
* Address comments from Jan.
* Rebase the code based on Andrew'patch "xen/x86: Record xsave features in 
c->x86_capabilities".
* Re-split the patch to avoid building errors. Move some func definitions from 
patch1 to patch2.
* Change func name load/save_xsave_states to compress/expand_xsave_states in 
patch2.  
* Add macro to handle redundancy in xrstor.
* Fix some code errors and coding style errors.
* Add some descriptions in commit message.

Changes in v5:
* Address comments from Andrew/Jan,mainly:
* Add lazy writes of the xss_msr.
* Add xsave_area check when save/restore guest.
* Add xsavec support.
* Use word 2 in xen/include/asm-x86/cpufeature.h.
* Fix some code errors.

Changes in v4:
* Address comments from Andrew, mainly:
* No xsaves suporting for pv guest.
* Using xstate_sizes instead of domain_cpuid in hvm_cupid in patch 3.
* Add support for format translation when perform pv guest migration in patch 
2. 
* Fix some code errors.

Changes in v3:
* Address comments from Jan/Konrad
* Change the bits of eax/ebx/ecx/edx passed to guest in patch 4.
* Add code to verify whether host supports xsaves or not in patch 1.

Changes in v2:
* Address comments from Andrew/chao/Jan, mainly:
* Add details information of xsaves/xrstors feature.
* Test migration between xsaves-support machine and none-xsaves-support machine 
* Remove XGETBV1/XSAVEC/XSAVEOPT out of 'else' in patch 3.
* Change macro name XGETBV to XGETBV1 in patch 4.

Shuai Ruan (4):
  x86/xsaves: using named operand instead numbered operand in xrstor
  x86/xsaves: enable xsaves/xrstors/xsavec in xen
  x86/xsaves: enable xsaves/xrstors for hvm guest
  libxc: expose xsaves/xgetbv1/xsavec to hvm guest

 tools/libxc/xc_cpuid_x86.c |  10 +-
 xen/arch/x86/domain.c  |   8 ++
 xen/arch/x86/domctl.c  |  30 -
 xen/arch/x86/hvm/hvm.c |  45 ++-
 xen/arch/x86/hvm/vmx/vmcs.c|   5 +-
 xen/arch/x86/hvm/vmx/vmx.c |  35 +-
 xen/arch/x86/i387.c|   4 +
 xen/arch/x86/traps.c   |   6 +-
 xen/arch/x86/xstate.c  | 246 -
 xen/include/asm-x86/alternative.h  |   3 +
 xen/include/asm-x86/hvm/vmx/vmcs.h |   4 +
 xen/include/asm-x86/hvm/vmx/vmx.h  |   2 +
 xen/include/asm-x86/xstate.h   |   3 +
 13 files changed, 353 insertions(+), 48 deletions(-)

-- 
1.9.1


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

[Xen-devel] [V12 2/4] x86/xsaves: enable xsaves/xrstors/xsavec in xen

[Shuai Ruan]

This patch uses xsaves/xrstors/xsavec instead of xsaveopt/xrstor
to perform the xsave_area switching so that xen itself
can benefit from them when available.

For xsaves/xrstors/xsavec only use compact format. Add format conversion
support when perform guest os migration. Also, pv guest will not support
xsaves/xrstors.

Signed-off-by: Shuai Ruan 
---
 xen/arch/x86/domain.c |   8 ++
 xen/arch/x86/domctl.c |  30 +-
 xen/arch/x86/hvm/hvm.c|  18 +++-
 xen/arch/x86/i387.c   |   4 +
 xen/arch/x86/traps.c  |   6 +-
 xen/arch/x86/xstate.c | 219 +++---
 xen/include/asm-x86/alternative.h |   3 +
 xen/include/asm-x86/xstate.h  |   2 +
 8 files changed, 262 insertions(+), 28 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 3f9e5d2..9476869 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -910,7 +910,12 @@ int arch_set_info_guest(
 {
 memcpy(v->arch.fpu_ctxt, >fpu_ctxt, sizeof(c.nat->fpu_ctxt));
 if ( v->arch.xsave_area )
+{
  v->arch.xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
+ if ( cpu_has_xsaves || cpu_has_xsavec )
+  v->arch.xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
+   
XSTATE_COMPACTION_ENABLED;
+}
 }
 
 if ( !compat )
@@ -1594,6 +1599,9 @@ static void __context_switch(void)
 
 if ( xcr0 != get_xcr0() && !set_xcr0(xcr0) )
 BUG();
+
+if ( cpu_has_xsaves && has_hvm_container_vcpu(n) )
+set_msr_xss(n->arch.hvm_vcpu.msr_xss);
 }
 vcpu_restore_fpu_eager(n);
 n->arch.ctxt_switch_to(n);
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 0f6fdb9..95b0747 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -897,9 +897,29 @@ long arch_do_domctl(
 ret = -EFAULT;
 
 offset += sizeof(v->arch.xcr0_accum);
-if ( !ret && copy_to_guest_offset(evc->buffer, offset,
-  (void *)v->arch.xsave_area,
-  size - 2 * sizeof(uint64_t)) )
+if ( !ret && (cpu_has_xsaves || cpu_has_xsavec) )
+{
+void *xsave_area;
+
+xsave_area = xmalloc_bytes(size);
+if ( !xsave_area )
+{
+ret = -ENOMEM;
+vcpu_unpause(v);
+goto vcpuextstate_out;
+}
+
+expand_xsave_states(v, xsave_area,
+size - 2 * sizeof(uint64_t));
+
+if ( copy_to_guest_offset(evc->buffer, offset, xsave_area,
+  size - 2 * sizeof(uint64_t)) )
+ ret = -EFAULT;
+xfree(xsave_area);
+   }
+   else if ( !ret && copy_to_guest_offset(evc->buffer, offset,
+  (void *)v->arch.xsave_area,
+  size - 2 * sizeof(uint64_t)) 
)
 ret = -EFAULT;
 
 vcpu_unpause(v);
@@ -955,8 +975,8 @@ long arch_do_domctl(
 v->arch.xcr0_accum = _xcr0_accum;
 if ( _xcr0_accum & XSTATE_NONLAZY )
 v->arch.nonlazy_xstate_used = 1;
-memcpy(v->arch.xsave_area, _xsave_area,
-   evc->size - 2 * sizeof(uint64_t));
+compress_xsave_states(v, _xsave_area,
+  evc->size - 2 * sizeof(uint64_t));
 vcpu_unpause(v);
 }
 else
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 141a130..c981580 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2092,6 +2092,9 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 
 memcpy(v->arch.xsave_area, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
 xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
+if ( cpu_has_xsaves || cpu_has_xsavec )
+xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
+ XSTATE_COMPACTION_ENABLED;
 }
 else
 memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
@@ -2161,8 +2164,8 @@ static int hvm_save_cpu_xsave_states(struct domain *d, 
hvm_domain_context_t *h)
 ctxt->xfeature_mask = xfeature_mask;
 ctxt->xcr0 = v->arch.xcr0;
 ctxt->xcr0_accum = v->arch.xcr0_accum;
-memcpy(>save_area, v->arch.xsave_area,
-   size - offsetof(struct hvm_hw_cpu_xsave, save_area));
+expand_xsave_states(v, >save_area,
+size - offsetof(typeof(*ctxt), save_area));
 }
 
 return 0;
@@ -2261,9 

[Xen-devel] [V12 3/4] x86/xsaves: enable xsaves/xrstors for hvm guest

[Shuai Ruan]

This patch enables xsaves for hvm guest, includes:
1.handle xsaves vmcs init and vmexit.
2.add logic to write/read the XSS msr.

Add IA32_XSS_MSR save/rstore support.

Signed-off-by: Shuai Ruan 
Reviewed-by: Jan Beulich 
---
 xen/arch/x86/hvm/hvm.c | 27 +++
 xen/arch/x86/hvm/vmx/vmcs.c|  5 -
 xen/arch/x86/hvm/vmx/vmx.c | 35 ++-
 xen/arch/x86/xstate.c  |  2 +-
 xen/include/asm-x86/hvm/vmx/vmcs.h |  4 
 xen/include/asm-x86/hvm/vmx/vmx.h  |  2 ++
 xen/include/asm-x86/xstate.h   |  1 +
 7 files changed, 73 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c981580..6c2b512 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4606,6 +4606,20 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 *ebx = _eax + _ebx;
 }
 }
+if ( count == 1 )
+{
+if ( cpu_has_xsaves && cpu_has_vmx_xsaves )
+{
+*ebx = XSTATE_AREA_MIN_SIZE;
+if ( v->arch.xcr0 | v->arch.hvm_vcpu.msr_xss )
+for ( sub_leaf = 2; sub_leaf < 63; sub_leaf++ )
+if ( (v->arch.xcr0 | v->arch.hvm_vcpu.msr_xss) &
+ (1ULL << sub_leaf) )
+*ebx += xstate_sizes[sub_leaf];
+}
+else
+*ebx = *ecx = *edx = 0;
+}
 break;
 
 case 0x8001:
@@ -4705,6 +4719,12 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t 
*msr_content)
 *msr_content = v->arch.hvm_vcpu.guest_efer;
 break;
 
+case MSR_IA32_XSS:
+if ( !cpu_has_xsaves )
+goto gp_fault;
+*msr_content = v->arch.hvm_vcpu.msr_xss;
+break;
+
 case MSR_IA32_TSC:
 *msr_content = _hvm_rdtsc_intercept();
 break;
@@ -4837,6 +4857,13 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
return X86EMUL_EXCEPTION;
 break;
 
+case MSR_IA32_XSS:
+/* No XSS features currently supported for guests. */
+if ( !cpu_has_xsaves || msr_content != 0 )
+goto gp_fault;
+v->arch.hvm_vcpu.msr_xss = msr_content;
+break;
+
 case MSR_IA32_TSC:
 hvm_set_guest_tsc(v, msr_content);
 break;
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 202c0a4..000d06e 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -241,7 +241,8 @@ static int vmx_init_vmcs_config(void)
SECONDARY_EXEC_PAUSE_LOOP_EXITING |
SECONDARY_EXEC_ENABLE_INVPCID |
SECONDARY_EXEC_ENABLE_VM_FUNCTIONS |
-   SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS);
+   SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS |
+   SECONDARY_EXEC_XSAVES);
 rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap);
 if ( _vmx_misc_cap & VMX_MISC_VMWRITE_ALL )
 opt |= SECONDARY_EXEC_ENABLE_VMCS_SHADOWING;
@@ -1273,6 +1274,8 @@ static int construct_vmcs(struct vcpu *v)
 __vmwrite(HOST_PAT, host_pat);
 __vmwrite(GUEST_PAT, guest_pat);
 }
+if ( cpu_has_vmx_xsaves )
+__vmwrite(XSS_EXIT_BITMAP, 0);
 
 vmx_vmcs_exit(v);
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 374eebf..9ad6d82 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -625,7 +625,7 @@ static int vmx_load_vmcs_ctxt(struct vcpu *v, struct 
hvm_hw_cpu *ctxt)
 
 static unsigned int __init vmx_init_msr(void)
 {
-return !!cpu_has_mpx;
+return !!cpu_has_mpx + !!cpu_has_xsaves;
 }
 
 static void vmx_save_msr(struct vcpu *v, struct hvm_msr *ctxt)
@@ -640,6 +640,13 @@ static void vmx_save_msr(struct vcpu *v, struct hvm_msr 
*ctxt)
 }
 
 vmx_vmcs_exit(v);
+
+if ( cpu_has_xsaves )
+{
+ctxt->msr[ctxt->count].val = v->arch.hvm_vcpu.msr_xss;
+if ( ctxt->msr[ctxt->count].val )
+ctxt->msr[ctxt->count++].index = MSR_IA32_XSS;
+}
 }
 
 static int vmx_load_msr(struct vcpu *v, struct hvm_msr *ctxt)
@@ -659,6 +666,12 @@ static int vmx_load_msr(struct vcpu *v, struct hvm_msr 
*ctxt)
 else
 err = -ENXIO;
 break;
+case MSR_IA32_XSS:
+if ( cpu_has_xsaves )
+v->arch.hvm_vcpu.msr_xss = ctxt->msr[i].val;
+else
+err = -ENXIO;
+break;
 default:
 continue;
 }
@@ -2819,6 +2832,18 @@ static void vmx_idtv_reinject(unsigned long idtv_info)
 }
 }
 
+static void vmx_handle_xsaves(void)
+{
+gdprintk(XENLOG_ERR, "xsaves should not cause vmexit\n");
+domain_crash(current->domain);
+}
+
+static void vmx_handle_xrstors(void)
+{
+gdprintk(XENLOG_ERR, "xrstors should not cause 

Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown

[Paul Durrant]

> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 24 November 2015 17:24
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Stefano Stabellini; Ian Campbell; Wei Liu
> Subject: RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for
> ~/control/shutdown
> 
> Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir()
> for ~/control/shutdown"):
> > [Ian Jackson:]
> > > I'm not sure I follow this argument.  What did you think of my idea
> > > of renaming libxl__xs_mkdir to libxl__xs_mknode ?
> >
> > The issue, as I said, is the initial state of the node. If you use
> > XS_MKDIR then it is not guaranteed to be empty.
> 
> It is guaranteed to be empty if nothing ever wrote anything non-empty
> to it.  I think participants in xenstore protocols, and users of
> xenstore to store things, are entitled to assume that no-one writes
> nonempty values to nodes that aren't supposed to have nonempty values.
> 
> And even if the node did somehow end up with a nonempty value, nothing
> would break because no-one would read it.

Maybe. Personally I would have thought a toolstack would want to put things 
into a known state and XS_MKDIR just doesn't do that.

> 
> > If you use XS_WRITE then it is and I think that is the correct
> > semantic here (even though we happen to get away with it at the
> > moment). I'm happy with the function rename, but would you be happy
> > with the change in semantic?
> 
> XS_MKDIR creates missing parents, which XS_WRITE doesn't.
> 

According to the documentation it does: (from xenstore.txt)

READ| 
WRITE   |
Store and read the octet string  at .
WRITE creates any missing parent paths, with empty values.

  Paul

> Ian.

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

Re: [Xen-devel] [PATCH] build: remove .d files from xen/ on a clean

[Jan Beulich]

>>> On 24.11.15 at 18:22,  wrote:

>> On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore 
>  wrote:
>>> On Nov 24, 2015, at 11:07 AM, Jan Beulich  wrote:
>> On 24.11.15 at 17:56,  wrote:
 --- a/xen/Makefile
 +++ b/xen/Makefile
 @@ -88,7 +88,7 @@ _clean: delete-unfresh-files
$(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
 -  rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
 $(TARGET)-syms 
> *~ core
 +  rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
 $(TARGET)-syms 
> *~ core $(DEPS)
>>> 
>>> Is this really a problem only in xen/ ? The referenced commit clearly
>>> introduces "stray" *.d files elsewhere. Also there aren't any source
>>> files in xen/, so I'd expect $(DEPS) to be empty. Please clarify.
>> 
>> So, the files in xen/ were the dependencies files for xen.efi and 
>> xen-syms that were getting left behind. $(DEPS) appears to always
>> have ‘.*.d’ in it, based on me putting an echo into the clean rule to 
>> print it out. However, looking at this, I am also seeing ‘.d’ files left
>> behind in xen/common/compat that I did not notice before.
> 
> Actually, looking closer at it, xen/common/compat does not appear to be
> cleaning at all, so I think that is a separate, unrelated issue.

That would be quite related, as it would be a result of the same
commit.

Jan

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

Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown

[Ian Jackson]

Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() 
for ~/control/shutdown"):
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > And even if the node did somehow end up with a nonempty value, nothing
> > would break because no-one would read it.
> 
> Maybe. Personally I would have thought a toolstack would want to put things 
> into a known state and XS_MKDIR just doesn't do that.

Hrm.

> > > If you use XS_WRITE then it is and I think that is the correct
> > > semantic here (even though we happen to get away with it at the
> > > moment). I'm happy with the function rename, but would you be happy
> > > with the change in semantic?
> > 
> > XS_MKDIR creates missing parents, which XS_WRITE doesn't.
> 
> According to the documentation it does: (from xenstore.txt)
> 
> READ  | 
> WRITE |
>   Store and read the octet string  at .
>   WRITE creates any missing parent paths, with empty values.

Oh!

Well so then perhaps we should jsut change libxl__xs_mkdir to use
WRITE.  This rather confusing situation is probably worth a doc
comment next to the prototype in libxl_internal.h.

Ian.

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

Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown

[Paul Durrant]

> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 24 November 2015 16:35
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Stefano Stabellini; Ian Campbell; Wei Liu
> Subject: RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for
> ~/control/shutdown
> 
> Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir()
> for ~/control/shutdown"):
> > [Ian Jackson]
> > > Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using
> libxl__xs_mkdir()
> > > for ~/control/shutdown"):
> > > > [Ian Jackson:]
> > > > > Maybe it would be easier to rename libxl__xs_mkdir to
> > > > > libxl__xs_mknode ?  (It's probably too late to rename XS_MKDIR.)
> > > >
> > > > There is still the need to set the path to an empty value though, which
> is
> > > not implicitly done by the XS_MKDIR.
> > >
> > > Under what circumstances would this path not contain an empty value
> > > after XS_MKDIR ?
> >
> > In this case I believe you are correct, but my feeling was that
> > people reading the code would be lulled into a false sense of
> > security that XS_MKDIR always did the right thing to initialize a
> > new path.
> 
> I'm not sure I follow this argument.  What did you think of my idea
> of renaming libxl__xs_mkdir to libxl__xs_mknode ?
> 

The issue, as I said, is the initial state of the node. If you use XS_MKDIR 
then it is not guaranteed to be empty. If you use XS_WRITE then it is and I 
think that is the correct semantic here (even though we happen to get away with 
it at the moment). I'm happy with the function rename, but would you be happy 
with the change in semantic?

  Paul

> Ian.

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

Re: [Xen-devel] [PATCH] build: remove .d files from xen/ on a clean

[Jonathan Creekmore]

> On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore 
>  wrote:
> 
>> 
>> On Nov 24, 2015, at 11:07 AM, Jan Beulich  wrote:
>> 
> On 24.11.15 at 17:56,  wrote:
>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -88,7 +88,7 @@ _clean: delete-unfresh-files
>>> $(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
>>> $(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
>>> $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
>>> -   rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
>>> $(TARGET)-syms *~ core
>>> +   rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
>>> $(TARGET)-syms *~ core $(DEPS)
>> 
>> Is this really a problem only in xen/ ? The referenced commit clearly
>> introduces "stray" *.d files elsewhere. Also there aren't any source
>> files in xen/, so I'd expect $(DEPS) to be empty. Please clarify.
> 
> So, the files in xen/ were the dependencies files for xen.efi and 
> xen-syms that were getting left behind. $(DEPS) appears to always
> have ‘.*.d’ in it, based on me putting an echo into the clean rule to 
> print it out. However, looking at this, I am also seeing ‘.d’ files left
> behind in xen/common/compat that I did not notice before.

Actually, looking closer at it, xen/common/compat does not appear to be
cleaning at all, so I think that is a separate, unrelated issue.

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

Re: [Xen-devel] [PATCH v2 2/3] libxl: check for underlying xenstore operation failure...

[Paul Durrant]

> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 24 November 2015 16:49
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Ian Campbell; Wei Liu
> Subject: Re: [Xen-devel] [PATCH v2 2/3] libxl: check for underlying xenstore
> operation failure...
> 
> (Added CC to Ian C and Wei.)
> 
> Paul Durrant writes ("[Xen-devel] [PATCH v2 2/3] libxl: check for underlying
> xenstore operation failure..."):
> > ...in libxl__xs_writev_perms() and libxl__xs_printf()
> 
> Thanks for looking at this.
> 
> 
> > ERROR_FAIL is returned when any underlying operation fails. This is a
> > semantic change in the case of a vasprintf() failure in libxl__xs_printf(),
> > but appears to be better than returning a hardcoded -1.
> 
> This is what libxl__alloc_failed is for.  But, surely it would be
> better to replace the call to vasprintf with one to libxl__vsprintf ?
> 

Ah yes, that would work nicely.

> >  path = libxl__sprintf(gc, "%s/%s", dir, kvs[i]);
> >  if (path && kvs[i + 1]) {
> >  int length = strlen(kvs[i + 1]);
> > -xs_write(ctx->xsh, t, path, kvs[i + 1], length);
> > -if (perms)
> > -xs_set_permissions(ctx->xsh, t, path, perms, num_perms);
> > +if (!xs_write(ctx->xsh, t, path, kvs[i + 1], length))
> > +return ERROR_FAIL;
> 
> This is a good change semantically but I'm not keen on this error
> handling style.  CODING_STYLE says:
> 
>   * Function calls which might fail (ie most function calls) are
> handled by putting the return/status value into a variable, and
> then checking it in a separate statement:
> char *dompath = libxl__xs_get_dompath(gc, bl->domid);
> if (!dompath) { rc = ERROR_FAIL; goto out; }
> 
> In this case the libxenstore return value variable should be called
> `r', I think.  CODING_STYLE says:
> 
> int r; /* the return value from a system call (or libxc call) */
> 
> > +if (perms &&
> > +!xs_set_permissions(ctx->xsh, t, path, perms, num_perms))
> > +return ERROR_FAIL;
> 
> And this is worse, I'm afraid.  Nested ifs are not expensive and there
> is no risk of overloading the compiler.  So I would like to see this:
> 
>   if (perms) {
>   r = xs_set ...
>   if (r) ...
>   }
> 
> 
> I won't insist on you changing the error exits to use `goto out',
> although I tend to think that would be better.
> 

I'm completely happy with that style. I'll fix accordingly.

  Paul

> 
> Thanks,
> Ian.

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

[Xen-devel] Bug: QEMU segfault within vnc

[Anthony PERARD]

Hi,

QEMU segfault while running a Xen guest, the guest is a WinXP.

To reproduce, I start the guest, I don't connect to vnc, and after
about 2min, QEMU segv. I think it's around the time it take for windows to
boot and reach the desktop.

The first commit where this happen is:
vnc: fix local state init
2e0c90af0a33451498d333d72c06e5429c7cd168

The backtrace associated with this commit:
#0  0x7f8be2035680 in pixman_image_get_width () from 
/usr/lib/libpixman-1.so.0
#1  0x5576b9cd1fc7 in vnc_refresh_server_surface (vd=0x7f8be2dd9010) at 
ui/vnc.c:2873
#2  0x5576b9ccd413 in vnc_dpy_copy (dcl=0x7f8be2dd9048, src_x=116, 
src_y=379, dst_x=116, dst_y=367, w=16, h=3) at ui/vnc.c:934
#3  0x5576b9cc1761 in dpy_gfx_copy (con=0x5576bccbbc50, src_x=116, 
src_y=379, dst_x=116, dst_y=367, w=16, h=3) at ui/console.c:1533
#4  0x5576b9cc2b26 in qemu_console_copy (con=0x5576bccbbc50, src_x=116, 
src_y=379, dst_x=116, dst_y=367, w=16, h=3) at ui/console.c:2040
#5  0x5576b9b9baf8 in cirrus_do_copy (s=0x5576bcb5a100, dst=1127772, 
src=1164636, w=16, h=3) at hw/display/cirrus_vga.c:772
#6  0x5576b9b9bbcc in cirrus_bitblt_videotovideo_copy (s=0x5576bcb5a100) at 
hw/display/cirrus_vga.c:791
#7  0x5576b9b9c0a1 in cirrus_bitblt_videotovideo (s=0x5576bcb5a100) at 
hw/display/cirrus_vga.c:913
#8  0x5576b9b9c80f in cirrus_bitblt_start (s=0x5576bcb5a100) at 
hw/display/cirrus_vga.c:1054
#9  0x5576b9b9c898 in cirrus_write_bitblt (s=0x5576bcb5a100, reg_value=2) 
at hw/display/cirrus_vga.c:1075
#10 0x5576b9b9d588 in cirrus_vga_write_gr (s=0x5576bcb5a100, reg_index=49, 
reg_value=2) at hw/display/cirrus_vga.c:1577
#11 0x5576b9b9de03 in cirrus_mmio_blt_write (s=0x5576bcb5a100, address=64, 
value=2 '\002') at hw/display/cirrus_vga.c:1931
#12 0x5576b9b9e32b in cirrus_vga_mem_write (opaque=0x5576bcb5a100, 
addr=98368, mem_value=2, size=1) at hw/display/cirrus_vga.c:2099
#13 0x5576b99e2bc5 in memory_region_write_accessor (mr=0x5576bcb6b0a0, 
addr=98368, value=0x7fff47d22618, size=1, shift=0, mask=255, attrs=...)
at /root/work/qemu/memory.c:450
#14 0x5576b99e2d64 in access_with_adjusted_size (addr=98368, 
value=0x7fff47d22618, size=1, access_size_min=1, access_size_max=1, 
access=0x5576b99e2b54 , mr=0x5576bcb6b0a0, 
attrs=...) at /root/work/qemu/memory.c:506
#15 0x5576b99e55cb in memory_region_dispatch_write (mr=0x5576bcb6b0a0, 
addr=98368, data=2, size=1, attrs=...) at /root/work/qemu/memory.c:1158
#16 0x5576b999eba2 in address_space_rw (as=0x5576ba2a0ec0 
, addr=753728, attrs=..., buf=0x7fff47d22818 "\002", 
len=1, is_write=true)
at /root/work/qemu/exec.c:2497
#17 0x5576b999eed9 in cpu_physical_memory_rw (addr=753728, 
buf=0x7fff47d22818 "\002", len=1, is_write=1) at /root/work/qemu/exec.c:2580
#18 0x5576b9a024b2 in rw_phys_req_item (addr=753728, req=0x7fff47d22810, 
i=0, val=0x7fff47d22818, rw=1) at /root/work/qemu/xen-hvm.c:797
#19 0x5576b9a02520 in write_phys_req_item (addr=753728, req=0x7fff47d22810, 
i=0, val=0x7fff47d22818) at /root/work/qemu/xen-hvm.c:808
#20 0x5576b9a0285c in cpu_ioreq_move (req=0x7fff47d22810) at 
/root/work/qemu/xen-hvm.c:862
#21 0x5576b9a02cec in handle_ioreq (state=0x5576bb888960, 
req=0x7fff47d22810) at /root/work/qemu/xen-hvm.c:944
#22 0x5576b9a02ffa in handle_buffered_iopage (state=0x5576bb888960) at 
/root/work/qemu/xen-hvm.c:1026
#23 0x5576b9a030d1 in cpu_handle_ioreq (opaque=0x5576bb888960) at 
/root/work/qemu/xen-hvm.c:1052
#24 0x5576b9d03123 in aio_dispatch (ctx=0x5576bb856470) at aio-posix.c:160
#25 0x5576b9cf3421 in aio_ctx_dispatch (source=0x5576bb856470, 
callback=0x0, user_data=0x0) at async.c:226
#26 0x7f8bdeb78dc7 in g_main_context_dispatch () from 
/usr/lib/libglib-2.0.so.0
#27 0x5576b9d01805 in glib_pollfds_poll () at main-loop.c:211
#28 0x5576b9d018e0 in os_host_main_loop_wait (timeout=477440) at 
main-loop.c:256
#29 0x5576b9d0198d in main_loop_wait (nonblocking=0) at main-loop.c:504
#30 0x5576b9ade524 in main_loop () at vl.c:1890
#31 0x5576b9ae63f8 in main (argc=44, argv=0x7fff47d22df8, 
envp=0x7fff47d22f60) at vl.c:4644

QEMU also segfault if I connect briefly to VNC at guest boot time and
disconnect before it finishes booting.

You may find a report from osstest here:
http://lists.xen.org/archives/html/xen-devel/2015-11/msg02688.html

Thanks,

-- 
Anthony PERARD

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

[Xen-devel] [PATCH] console: make printk() line continuation tracking per-CPU

[Jan Beulich]

This avoids cases where split messages (with other than the initial
part not carrying a log level; single line messages only of course)
issued on multiple CPUs interfere with each other, causing messages to
be issued which are supposed to be suppressed due to the log level
setting. E.g.

CPU A   CPU B
XENLOG_G_DEBUG "abc"
XENLOG_G_DEBUG "def\n"
"xyz\n"

would cause the last message to be logged despite this obviously not
being intended (at default log levels).

Suggested-by: Boris Ostrovsky 
Signed-off-by: Jan Beulich 
Tested-by: Boris Ostrovsky 

--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -620,15 +620,18 @@ static void printk_start_of_line(const c
 
 static void vprintk_common(const char *prefix, const char *fmt, va_list args)
 {
+struct vps {
+bool_t continued, do_print;
+}*state;
+static DEFINE_PER_CPU(struct vps, state);
 static char   buf[1024];
-static intstart_of_line = 1, do_print;
-
 char *p, *q;
 unsigned long flags;
 
 /* console_lock can be acquired recursively from __printk_ratelimit(). */
 local_irq_save(flags);
 spin_lock_recursive(_lock);
+state = _cpu(state);
 
 (void)vsnprintf(buf, sizeof(buf), fmt, args);
 
@@ -637,30 +640,30 @@ static void vprintk_common(const char *p
 while ( (q = strchr(p, '\n')) != NULL )
 {
 *q = '\0';
-if ( start_of_line )
-do_print = printk_prefix_check(p, );
-if ( do_print )
+if ( !state->continued )
+state->do_print = printk_prefix_check(p, );
+if ( state->do_print )
 {
-if ( start_of_line )
+if ( !state->continued )
 printk_start_of_line(prefix);
 __putstr(p);
 __putstr("\n");
 }
-start_of_line = 1;
+state->continued = 0;
 p = q + 1;
 }
 
 if ( *p != '\0' )
 {
-if ( start_of_line )
-do_print = printk_prefix_check(p, );
-if ( do_print )
+if ( !state->continued )
+state->do_print = printk_prefix_check(p, );
+if ( state->do_print )
 {
-if ( start_of_line )
+if ( !state->continued )
 printk_start_of_line(prefix);
 __putstr(p);
 }
-start_of_line = 0;
+state->continued = 1;
 }
 
 spin_unlock_recursive(_lock);



console: make printk() line continuation tracking per-CPU

This avoids cases where split messages (with other than the initial
part not carrying a log level; single line messages only of course)
issued on multiple CPUs interfere with each other, causing messages to
be issued which are supposed to be suppressed due to the log level
setting. E.g.

CPU A   CPU B
XENLOG_G_DEBUG "abc"
XENLOG_G_DEBUG "def\n"
"xyz\n"

would cause the last message to be logged despite this obviously not
being intended (at default log levels).

Suggested-by: Boris Ostrovsky 
Signed-off-by: Jan Beulich 
Tested-by: Boris Ostrovsky 

--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -620,15 +620,18 @@ static void printk_start_of_line(const c
 
 static void vprintk_common(const char *prefix, const char *fmt, va_list args)
 {
+struct vps {
+bool_t continued, do_print;
+}*state;
+static DEFINE_PER_CPU(struct vps, state);
 static char   buf[1024];
-static intstart_of_line = 1, do_print;
-
 char *p, *q;
 unsigned long flags;
 
 /* console_lock can be acquired recursively from __printk_ratelimit(). */
 local_irq_save(flags);
 spin_lock_recursive(_lock);
+state = _cpu(state);
 
 (void)vsnprintf(buf, sizeof(buf), fmt, args);
 
@@ -637,30 +640,30 @@ static void vprintk_common(const char *p
 while ( (q = strchr(p, '\n')) != NULL )
 {
 *q = '\0';
-if ( start_of_line )
-do_print = printk_prefix_check(p, );
-if ( do_print )
+if ( !state->continued )
+state->do_print = printk_prefix_check(p, );
+if ( state->do_print )
 {
-if ( start_of_line )
+if ( !state->continued )
 printk_start_of_line(prefix);
 __putstr(p);
 __putstr("\n");
 }
-start_of_line = 1;
+state->continued = 0;
 p = q + 1;
 }
 
 if ( *p != '\0' )
 {
-if ( start_of_line )
-do_print = printk_prefix_check(p, );
-if ( do_print )
+if ( !state->continued )
+state->do_print = printk_prefix_check(p, );
+if ( state->do_print )
 {
-if ( start_of_line )
+if ( !state->continued )
 

Re: [Xen-devel] [PATCH] iommu/quirk: disable shared EPT for Sandybridge and earlier processors.

[Jan Beulich]

>>> On 24.11.15 at 18:17,  wrote:
> --- a/xen/drivers/passthrough/vtd/quirks.c
> +++ b/xen/drivers/passthrough/vtd/quirks.c
> @@ -320,6 +320,20 @@ void __init platform_quirks_init(void)
>  /* Tylersburg interrupt remap quirk */
>  if ( iommu_intremap )
>  tylersburg_intremap_quirk();
> +
> +/*
> + * Disable shared EPT ("sharept") on Sandybridge and older processors
> + * by default.
> + * SandyBridge has no huge page support for IOTLB which leads to fallback
> + * on 4k pages and leads to performance degradation.
> + *
> + * Shared EPT ("sharept") will be disabled only if user has not
> + * provided explicit choice on the command line thus iommu_hap_pt_share 
> is
> + * at its initialized value of -1.
> + */
> +if ( (boot_cpu_data.x86 == 0x06 && (boot_cpu_data.x86_model <= 0x2F ||
> +  boot_cpu_data.x86_model == 0x36)) && (iommu_hap_pt_share == -1) )
> +iommu_hap_pt_share = 0;

If we really want to do this, then I think we should key this on
EPT but not VT-d having 2M support, instead of on CPU models.

Also - with the above only marginally relevant - the line split and/or
indentation is wrong.

Jan


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

Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown

[Paul Durrant]

> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 24 November 2015 17:39
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Stefano Stabellini; Ian Campbell; Wei Liu
> Subject: RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for
> ~/control/shutdown
> 
> Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir()
> for ~/control/shutdown"):
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > > And even if the node did somehow end up with a nonempty value,
> nothing
> > > would break because no-one would read it.
> >
> > Maybe. Personally I would have thought a toolstack would want to put
> things into a known state and XS_MKDIR just doesn't do that.
> 
> Hrm.
> 
> > > > If you use XS_WRITE then it is and I think that is the correct
> > > > semantic here (even though we happen to get away with it at the
> > > > moment). I'm happy with the function rename, but would you be
> happy
> > > > with the change in semantic?
> > >
> > > XS_MKDIR creates missing parents, which XS_WRITE doesn't.
> >
> > According to the documentation it does: (from xenstore.txt)
> >
> > READ| 
> > WRITE   |
> > Store and read the octet string  at .
> > WRITE creates any missing parent paths, with empty values.
> 
> Oh!
> 
> Well so then perhaps we should jsut change libxl__xs_mkdir to use
> WRITE.

I think the rename to libxl__xs_mknode() is warranted, and will avoid anyone's 
belief that the implementer typo-ed the actual XS command :-)

>  This rather confusing situation is probably worth a doc
> comment next to the prototype in libxl_internal.h.

Yep. That sounds like a good idea. I'll do that.

  Paul

> 
> Ian.

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

[Xen-devel] [PATCHv6] 22/28] build: convert HAS_EHCI use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_UART_EHCI defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/arch/x86/Kconfig  | 1 +
 xen/arch/x86/Rules.mk | 1 -
 xen/drivers/char/Kconfig  | 7 +++
 xen/drivers/char/Makefile | 2 +-
 4 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 01cfe69..90d3020 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -11,6 +11,7 @@ config X86
select HAS_CPUFREQ
select HAS_PCI
select UART_NS16550
+   select UART_EHCI
select HAS_GDBSX
select HAS_PDX
select HAS_KEXEC
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 793e1f7..2f12fe8 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -2,7 +2,6 @@
 # x86-specific definitions
 
 HAS_NUMA := y
-HAS_EHCI := y
 HAS_CORE_PARKING := y
 xenoprof := y
 
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index d5cc991..c5a40f2 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -43,3 +43,10 @@ config UART_SCIF
help
  This selects the SuperH SCI(F) UART. If you have a SuperH based board,
  say Y.
+
+config UART_EHCI
+   bool "USB EHCI debug port support"
+   depends on X86
+   help
+ This selects the USB based EHCI debug port to be used as a UART. If
+ you have an x86 based system with USB, say Y.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 68ebc2d..f45d453 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -5,6 +5,6 @@ obj-$(CONFIG_UART_PL011) += pl011.o
 obj-$(CONFIG_UART_EXYNOS4210) += exynos4210-uart.o
 obj-$(CONFIG_UART_OMAP) += omap-uart.o
 obj-$(CONFIG_UART_SCIF) += scif-uart.o
-obj-$(HAS_EHCI) += ehci-dbgp.o
+obj-$(CONFIG_UART_EHCI) += ehci-dbgp.o
 obj-$(CONFIG_ARM) += dt-uart.o
 obj-y += serial.o
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules

[Doug Goldstein]

Wire in the Kconfig build and makefile rules to be able to generate
valid configuration files to be used by the build process but don't
actually use the output for affecting the Xen build.

CC: Ian Campbell 
CC: Stefano Stabellini 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 .gitignore|  8 
 xen/Kconfig   | 26 
 xen/Makefile  | 17 
 xen/arch/arm/Kconfig  | 31 ++
 xen/arch/arm/configs/arm32_defconfig  |  1 +
 xen/arch/arm/configs/arm64_defconfig  |  0
 xen/arch/x86/Kconfig  | 18 
 xen/arch/x86/configs/x86_64_defconfig |  0
 xen/common/Kconfig|  4 ++
 xen/drivers/Kconfig   |  3 ++
 xen/scripts/kconfig/.gitignore|  3 ++
 xen/scripts/kconfig/Makefile  | 77 +++
 12 files changed, 188 insertions(+)
 create mode 100644 xen/Kconfig
 create mode 100644 xen/arch/arm/Kconfig
 create mode 100644 xen/arch/arm/configs/arm32_defconfig
 create mode 100644 xen/arch/arm/configs/arm64_defconfig
 create mode 100644 xen/arch/x86/Kconfig
 create mode 100644 xen/arch/x86/configs/x86_64_defconfig
 create mode 100644 xen/common/Kconfig
 create mode 100644 xen/drivers/Kconfig
 create mode 100644 xen/scripts/kconfig/Makefile

diff --git a/.gitignore b/.gitignore
index 91e1430..780df23 100644
--- a/.gitignore
+++ b/.gitignore
@@ -217,6 +217,11 @@ tools/xentrace/tbctl
 tools/xentrace/xenctx
 tools/xentrace/xentrace
 xen/.banner
+xen/.config
+xen/.config.old
+xen/defconfig
+xen/**/*.cmd
+xen/**/modules.order
 xen/System.map
 xen/arch/arm/asm-offsets.s
 xen/arch/arm/xen.lds
@@ -239,6 +244,9 @@ xen/include/headers++.chk
 xen/include/asm
 xen/include/asm-*/asm-offsets.h
 xen/include/compat/*
+xen/include/config.h
+xen/include/config/
+xen/include/generated/
 xen/include/public/public
 xen/include/xen/*.new
 xen/include/xen/acm_policy.h
diff --git a/xen/Kconfig b/xen/Kconfig
new file mode 100644
index 000..b2d0fe2
--- /dev/null
+++ b/xen/Kconfig
@@ -0,0 +1,26 @@
+#
+# For a description of the syntax of this configuration file,
+# see Documentation/kbuild/kconfig-language.txt from the Linux
+# kernel source tree.
+#
+mainmenu "Xen/$SRCARCH $XEN_FULLVERSION Configuration"
+
+config SRCARCH
+   string
+   option env="SRCARCH"
+
+config ARCH
+   string
+   option env="ARCH"
+
+source "arch/$SRCARCH/Kconfig"
+
+config XEN_FULLVERSION
+   string
+   option env="XEN_FULLVERSION"
+
+config DEFCONFIG_LIST
+   string
+   option defconfig_list
+   default "$ARCH_DEFCONFIG"
+   default "arch/$SRCARCH/defconfig"
diff --git a/xen/Makefile b/xen/Makefile
index c556198..f2f4378 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -17,6 +17,9 @@ export XEN_ROOT := $(BASEDIR)/..
 
 EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
 
+# Don't break if the build process wasn't called from the top level
+XEN_TARGET_ARCH ?= $(shell uname -m)
+
 .PHONY: default
 default: build
 
@@ -88,6 +91,7 @@ _clean: delete-unfresh-files
$(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
+   $(MAKE) -f scripts/kconfig/Makefile clean
rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
$(TARGET)-syms *~ core
rm -f include/asm-*/asm-offsets.h
rm -f .banner
@@ -216,3 +220,16 @@ FORCE:
 
 %/: FORCE
$(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o
+
+kconfig := silentoldconfig oldconfig config menuconfig defconfig \
+   nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig
+.PHONY: $(kconfig)
+$(kconfig):
+   $(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) 
$@
+
+$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd
+   $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
ARCH=$(XEN_TARGET_ARCH) silentoldconfig
+
+# Allow people to just run `make` as before and not force them to configure
+$(BASEDIR)/.config $(BASEDIR)/include/config/auto.conf.cmd: ;
+   $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
ARCH=$(XEN_TARGET_ARCH) defconfig
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
new file mode 100644
index 000..a473137
--- /dev/null
+++ b/xen/arch/arm/Kconfig
@@ -0,0 +1,31 @@
+# Select 32 or 64 bit
+config 64BIT
+   bool "64-bit Xen" if ARCH = "arm64"
+   default ARCH != "arm32"
+   help
+ Say yes to build a 64-bit Xen
+ Say no to build a 32-bit Xen
+
+config ARM_32
+   def_bool y
+   depends on !64BIT
+
+config ARM_64
+   def_bool y
+   

[Xen-devel] [PATCHv6] 08/28] build: convert HAS_IOPORTS use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_IOPORTS defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/Rules.mk   |  1 -
 xen/arch/x86/Kconfig   |  1 +
 xen/arch/x86/Rules.mk  |  1 -
 xen/drivers/char/Kconfig   |  5 +
 xen/drivers/char/ns16550.c | 10 +-
 5 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index fb270f6..870c548 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -61,7 +61,6 @@ CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX
 CFLAGS-$(HAS_MEM_ACCESS)  += -DHAS_MEM_ACCESS
 CFLAGS-$(HAS_MEM_PAGING)  += -DHAS_MEM_PAGING
 CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING
-CFLAGS-$(HAS_IOPORTS)   += -DHAS_IOPORTS
 CFLAGS-$(HAS_PDX)   += -DHAS_PDX
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 8039111..54124c6 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -3,6 +3,7 @@ config X86_64
 
 config X86
def_bool y
+   select HAS_IOPORTS
select HAS_PASSTHROUGH
select HAS_PCI
select UART_NS16550
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 17d2869..151ed25 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,7 +1,6 @@
 
 # x86-specific definitions
 
-HAS_IOPORTS := y
 HAS_ACPI := y
 HAS_NUMA := y
 HAS_VGA  := y
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 6ed451f..8ecea29 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -3,3 +3,8 @@ config UART_NS16550
bool "16550-series UART support"
help
  This selects the 16550-series UART support. For most systems, say Y.
+
+# Select HAS_IOPORTS if 16550 has I/O ports
+config HAS_IOPORTS
+   bool
+   depends on UART_NS16550
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 6f197f3..c56361c 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -348,7 +348,7 @@ static void ns16550_delayed_resume(void *data);
 static u8 ns_read_reg(struct ns16550 *uart, unsigned int reg)
 {
 void __iomem *addr = uart->remapped_io_base + (reg << uart->reg_shift);
-#ifdef HAS_IOPORTS
+#ifdef CONFIG_HAS_IOPORTS
 if ( uart->remapped_io_base == NULL )
 return inb(uart->io_base + reg);
 #endif
@@ -366,7 +366,7 @@ static u8 ns_read_reg(struct ns16550 *uart, unsigned int 
reg)
 static void ns_write_reg(struct ns16550 *uart, unsigned int reg, u8 c)
 {
 void __iomem *addr = uart->remapped_io_base + (reg << uart->reg_shift);
-#ifdef HAS_IOPORTS
+#ifdef CONFIG_HAS_IOPORTS
 if ( uart->remapped_io_base == NULL )
 return outb(c, uart->io_base + reg);
 #endif
@@ -552,7 +552,7 @@ static void __init ns16550_init_preirq(struct serial_port 
*port)
 {
 struct ns16550 *uart = port->uart;
 
-#ifdef HAS_IOPORTS
+#ifdef CONFIG_HAS_IOPORTS
 /* I/O ports are distinguished by their size (16 bits). */
 if ( uart->io_base >= 0x1 )
 #endif
@@ -722,7 +722,7 @@ static void ns16550_resume(struct serial_port *port)
 
 static void __init ns16550_endboot(struct serial_port *port)
 {
-#ifdef HAS_IOPORTS
+#ifdef CONFIG_HAS_IOPORTS
 struct ns16550 *uart = port->uart;
 int rv;
 
@@ -786,7 +786,7 @@ static int __init check_existence(struct ns16550 *uart)
 {
 unsigned char status, scratch, scratch2, scratch3;
 
-#ifdef HAS_IOPORTS
+#ifdef CONFIG_HAS_IOPORTS
 /*
  * We can't poke MMIO UARTs until they get I/O remapped later. Assume that
  * if we're getting MMIO UARTs, the arch code knows what it's doing.
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 00/28] Kconfig conversion

[Doug Goldstein]

The following series is a follow on to the Kconfig conversion patch series.
There are still more components to convert however this is the bare minimal
to get everything working and get the options out of the existing makefiles.

The CONFIG_HAS_ variables are there to match the behavior of the Linux
CONFIG_HAVE_ variables. The purpose is to say that this hardware/profile/env
supports this option while the CONFIG_ variable states that this option was
requested on/off by user intervention.

The UARTs are now uniformly prefixed as CONFIG_UART_ and dropping most of the
CONFIG_HAS_ labeling for them. This means they are now user selectable as
requested by Julien Grall in the prior review. The question I've got is
the old config was just for selecting defaults. Users could enable the OMAP
UART for arm64 for example but I'm not sure if that's valid. Currently this
patchset makes those UARTs not user selectable if they were not previously
defaulted on. But I would like some feedback on this if possible.

Ultimately my goal is to allow for more parts of the hypervisor to be turned
off at compile time and potentially make it easier to include more
experimental features by others which can be turned off by default. Also to
provide the one true location for all possible knobs in the source code.

The patch series can be grabbed at:
https://github.com/cardoe/xen/tree/kconfig_v6

Changes since v5:
- added Andrew Cooper's Acked-by and Tested-by
- rebased to resolve conflict with NUMA changes in staging (minor conflict)

Changes since v4:
- v4 was an oops and was a resend of v3. So the 'Changes since v3' apply here.

Changes since v3:
- fix dependency inversion causing options to appear to flip back on (hi kexec)
- separate out wiring up Kconfig and then using it in the build (added patch 3)
- dropped the old patch 3
- changed UART configs to be prefixed as CONFIG_UART_
- changed ARM UART defaults

Changes since v2:
- drop x86_32 support (patch 2)
- fix make defconfig (patch 2)
- fix 'make -C xen' vs 'cd xen && make' behaving differently (patch 2)
- fix for ARM64 builds (added patch 3)
- At this point all targets are tested on x86_64, arm32, and arm64 with
  fresh clones and rebuilds.

Changes since v1:
- hopefully addressed all review comments
- added CCs to all maintainers from get_maintainer.pl as requested
- drop Kbuild to build Kconfig and instead port the Makefile to the Xen env
- add support for xconfig/gconfig
- include Kconfig docs from Linux


Doug Goldstein (28):
  build: import Kbuild/Kconfig from Linux 4.2
  build: build Kconfig and config rules
  build: use generated Kconfig options for Xen
  build: convert HAS_PASSTHROUGH use to Kconfig
  build: convert HAS_DEVICE_TREE use to Kconfig
  build: convert HAS_PCI use to Kconfig
  build: convert HAS_NS16550 use to Kconfig
  build: convert HAS_IOPORTS use to Kconfig
  build: convert HAS_ACPI use to Kconfig
  build: convert HAS_VIDEO use to Kconfig
  build: convert HAS_VGA use to Kconfig
  build: convert HAS_CPUFREQ use to Kconfig
  build: convert HAS_GDBSX use to Kconfig
  build: convert HAS_PDX use to Kconfig
  build: convert HAS_KEXEC use to Kconfig
  build: convert HAS_ARM_HDLCD use to Kconfig
  build: convert HAS_CADENCE_UART use to Kconfig
  build: convert HAS_PL011 use to Kconfig
  build: convert HAS_EXYNOS4210 use to Kconfig
  build: convert HAS_OMAP use to Kconfig
  build: convert HAS_SCIF use to Kconfig
  build: convert HAS_EHCI use to Kconfig
  build: convert HAS_MEM_ACCESS use to Kconfig
  build: convert HAS_MEM_PAGING use to Kconfig
  build: convert HAS_MEM_SHARING use to Kconfig
  build: convert HAS_GICV3 use to Kconfig
  build: convert CONFIG_COMPAT to Kconfig
  build: convert kexec options to CONFIG_KEXEC

 .gitignore |8 +
 config/arm32.mk|5 -
 config/arm64.mk|4 -
 config/x86_32.mk   |2 -
 config/x86_64.mk   |2 -
 docs/misc/kconfig-language.txt |  395 
 docs/misc/kconfig.txt  |  237 +++
 xen/Kconfig|   26 +
 xen/Makefile   |   25 +
 xen/Rules.mk   |   18 +-
 xen/arch/arm/Kconfig   |   42 +
 xen/arch/arm/Makefile  |2 +-
 xen/arch/arm/Rules.mk  |8 -
 xen/arch/arm/configs/arm32_defconfig   |5 +
 xen/arch/arm/configs/arm64_defconfig   |3 +
 xen/arch/arm/vgic.c|2 +-
 xen/arch/x86/Kconfig   |   39 +
 xen/arch/x86/Rules.mk  |   12 -
 xen/arch/x86/configs/x86_64_defconfig  |0
 xen/common/Kconfig |   44 +
 xen/common/Makefile|8 +-
 xen/common/compat/memory.c |4 +-
 

[Xen-devel] [PATCHv6] 03/28] build: use generated Kconfig options for Xen

[Doug Goldstein]

Switches the build system to rely on the options and flags generated by
Kconfig to control what gets built and how. Follow on patches will
convert items to be prefixed with CONFIG_. Additionally remove a #define
that resulted in a redefined variable when building for arm.

CC: Ian Campbell 
CC: Stefano Stabellini 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/Makefile   | 12 ++--
 xen/Rules.mk   |  2 ++
 xen/drivers/passthrough/arm/smmu.c |  4 
 xen/include/xen/config.h   |  2 ++
 4 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index f2f4378..0f3de72 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -26,6 +26,9 @@ default: build
 .PHONY: dist
 dist: install
 
+.PHONY: build
+build:: $(BASEDIR)/include/config/auto.conf
+
 .PHONY: build install uninstall clean distclean cscope TAGS tags MAP gtags
 build install uninstall debug clean distclean cscope TAGS tags MAP gtags::
 ifneq ($(XEN_TARGET_ARCH),x86_32)
@@ -227,9 +230,14 @@ kconfig := silentoldconfig oldconfig config menuconfig 
defconfig \
 $(kconfig):
$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) 
$@
 
-$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd
+$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd 
$(BASEDIR)/.config
$(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
ARCH=$(XEN_TARGET_ARCH) silentoldconfig
 
 # Allow people to just run `make` as before and not force them to configure
-$(BASEDIR)/.config $(BASEDIR)/include/config/auto.conf.cmd: ;
+$(BASEDIR)/.config:
$(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile 
ARCH=$(XEN_TARGET_ARCH) defconfig
+
+# Break the dependency chain for the first run
+$(BASEDIR)/include/config/auto.conf.cmd: ;
+
+-include $(BASEDIR)/include/config/auto.conf.cmd
diff --git a/xen/Rules.mk b/xen/Rules.mk
index e9d03b9..011768a 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -12,6 +12,8 @@ frame_pointer ?= n
 lto   ?= n
 kexec ?= y
 
+-include $(BASEDIR)/include/config/auto.conf
+
 include $(XEN_ROOT)/Config.mk
 
 # Hardcoded configuration implications and dependencies.
diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index bb08827..62da087 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -196,10 +196,6 @@ static inline int pci_for_each_dma_alias(struct pci_dev 
*pdev,
 #define PHYS_MASK_SHIFTPADDR_BITS
 typedef paddr_t phys_addr_t;
 
-#ifdef CONFIG_ARM_64
-# define CONFIG_64BIT
-#endif
-
 #define VA_BITS0   /* Only used for configuring stage-1 
input size */
 
 /* The macro ACCESS_ONCE start to be replaced in Linux in favor of
diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
index f7258c7..12a4688 100644
--- a/xen/include/xen/config.h
+++ b/xen/include/xen/config.h
@@ -12,6 +12,8 @@
 #endif
 #include 
 
+#include 
+
 #define EXPORT_SYMBOL(var)
 #define EXPORT_SYMBOL_GPL(var)
 
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 06/28] build: convert HAS_PCI use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_PCI defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Daniel De Graaf 
Signed-off-by: Doug Goldstein 
Acked-by: Daniel De Graaf 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/Rules.mk |  1 -
 xen/arch/x86/Kconfig |  1 +
 xen/arch/x86/Rules.mk|  1 -
 xen/common/sysctl.c  |  2 +-
 xen/drivers/Kconfig  |  3 +++
 xen/drivers/Makefile |  2 +-
 xen/drivers/char/ns16550.c   | 24 
 xen/drivers/passthrough/Makefile |  2 +-
 xen/drivers/passthrough/iommu.c  |  2 +-
 xen/drivers/pci/Kconfig  |  4 
 xen/include/xen/iommu.h  | 10 +-
 xen/include/xsm/dummy.h  |  4 ++--
 xen/include/xsm/xsm.h|  6 +++---
 xen/xsm/dummy.c  |  2 +-
 xen/xsm/flask/hooks.c| 14 +++---
 15 files changed, 42 insertions(+), 36 deletions(-)
 create mode 100644 xen/drivers/pci/Kconfig

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 15dcedc..fb270f6 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -61,7 +61,6 @@ CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX
 CFLAGS-$(HAS_MEM_ACCESS)  += -DHAS_MEM_ACCESS
 CFLAGS-$(HAS_MEM_PAGING)  += -DHAS_MEM_PAGING
 CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING
-CFLAGS-$(HAS_PCI)   += -DHAS_PCI
 CFLAGS-$(HAS_IOPORTS)   += -DHAS_IOPORTS
 CFLAGS-$(HAS_PDX)   += -DHAS_PDX
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 4ff1f63..4e1a9da 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -4,6 +4,7 @@ config X86_64
 config X86
def_bool y
select HAS_PASSTHROUGH
+   select HAS_PCI
select HAS_GDBSX
 
 config ARCH_DEFCONFIG
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 09f2844..8743509 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -7,7 +7,6 @@ HAS_NUMA := y
 HAS_VGA  := y
 HAS_VIDEO  := y
 HAS_CPUFREQ := y
-HAS_PCI := y
 HAS_NS16550 := y
 HAS_EHCI := y
 HAS_KEXEC := y
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 85e853f..47d115e 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -401,7 +401,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 break;
 #endif
 
-#ifdef HAS_PCI
+#ifdef CONFIG_HAS_PCI
 case XEN_SYSCTL_pcitopoinfo:
 {
 xen_sysctl_pcitopoinfo_t *ti = >u.pcitopoinfo;
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index 57311cc..5362e41 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -1,4 +1,7 @@
 menu "Device Drivers"
 
 source "drivers/passthrough/Kconfig"
+
+source "drivers/pci/Kconfig"
+
 endmenu
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index e283870..eb32d69 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -1,6 +1,6 @@
 subdir-y += char
 subdir-$(HAS_CPUFREQ) += cpufreq
-subdir-$(HAS_PCI) += pci
+subdir-$(CONFIG_HAS_PCI) += pci
 subdir-$(CONFIG_HAS_PASSTHROUGH) += passthrough
 subdir-$(HAS_ACPI) += acpi
 subdir-$(HAS_VIDEO) += video
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 6eab071..6f197f3 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -16,7 +16,7 @@
 #include 
 #include 
 #include 
-#ifdef HAS_PCI
+#ifdef CONFIG_HAS_PCI
 #include 
 #include 
 #include 
@@ -64,7 +64,7 @@ static struct ns16550 {
 unsigned int timeout_ms;
 bool_t intr_works;
 bool_t dw_usr_bsy;
-#ifdef HAS_PCI
+#ifdef CONFIG_HAS_PCI
 /* PCI card parameters. */
 bool_t pb_bdf_enable;   /* if =1, pb-bdf effective, port behind bridge */
 bool_t ps_bdf_enable;   /* if =1, ps_bdf effective, port on pci card */
@@ -97,7 +97,7 @@ struct ns16550_config_param {
 };
 
 
-#ifdef HAS_PCI
+#ifdef CONFIG_HAS_PCI
 enum {
 param_default = 0,
 param_trumanage,
@@ -475,7 +475,7 @@ static int ns16550_getc(struct serial_port *port, char *pc)
 
 static void pci_serial_early_init(struct ns16550 *uart)
 {
-#ifdef HAS_PCI
+#ifdef CONFIG_HAS_PCI
 if ( !uart->ps_bdf_enable || uart->io_base >= 0x1 )
 return;
 
@@ -621,7 +621,7 @@ static void __init ns16550_init_postirq(struct serial_port 
*port)
 
 ns16550_setup_postirq(uart);
 
-#ifdef HAS_PCI
+#ifdef CONFIG_HAS_PCI
 if ( uart->bar || uart->ps_bdf_enable )
 {
 if ( !uart->enable_ro )
@@ -650,7 +650,7 @@ static void ns16550_suspend(struct serial_port *port)
 
 stop_timer(>timer);
 
-#ifdef HAS_PCI
+#ifdef CONFIG_HAS_PCI
 if ( uart->bar )
uart->cr = pci_conf_read16(0, uart->ps_bdf[0], uart->ps_bdf[1],
   uart->ps_bdf[2], PCI_COMMAND);
@@ -659,7 +659,7 @@ static void ns16550_suspend(struct serial_port *port)
 
 

[Xen-devel] [PATCHv6] 14/28] build: convert HAS_PDX use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_PDX defines in the code base.

CC: Ian Campbell 
CC: Stefano Stabellini 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/Rules.mk  | 1 -
 xen/arch/arm/Kconfig  | 1 +
 xen/arch/arm/Rules.mk | 1 -
 xen/arch/x86/Kconfig  | 1 +
 xen/arch/x86/Rules.mk | 1 -
 xen/common/Kconfig| 4 
 xen/common/Makefile   | 2 +-
 xen/include/xen/pdx.h | 4 ++--
 8 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 0ff1a5d..c2a3e15 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -59,7 +59,6 @@ CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_MEM_ACCESS)  += -DHAS_MEM_ACCESS
 CFLAGS-$(HAS_MEM_PAGING)  += -DHAS_MEM_PAGING
 CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING
-CFLAGS-$(HAS_PDX)   += -DHAS_PDX
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
 ifneq ($(max_phys_cpus),)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 1786769..32f57d4 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -19,6 +19,7 @@ config ARM
select HAS_DEVICE_TREE
select HAS_VIDEO
select HAS_PASSTHROUGH
+   select HAS_PDX
 
 config ARCH_DEFCONFIG
string
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 90b1f24..52b1ad4 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -7,7 +7,6 @@
 #
 
 HAS_ARM_HDLCD := y
-HAS_PDX := y
 
 CFLAGS += -I$(BASEDIR)/include
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 7585c82..a285a1c 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -12,6 +12,7 @@ config X86
select HAS_PCI
select UART_NS16550
select HAS_GDBSX
+   select HAS_PDX
 
 config ARCH_DEFCONFIG
string
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 009f702..193e7ea 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -4,7 +4,6 @@
 HAS_NUMA := y
 HAS_EHCI := y
 HAS_KEXEC := y
-HAS_PDX := y
 HAS_CORE_PARKING := y
 xenoprof := y
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index f63284d..b429a64 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -5,6 +5,10 @@ menu "Common Features"
 config HAS_DEVICE_TREE
bool
 
+# Select HAS_PDX if PDX is supported
+config HAS_PDX
+   bool
+
 # Select HAS_GDBSX if GDBSX is supported
 config HAS_GDBSX
bool
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 5dc2bb2..0acd2b0 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -23,7 +23,7 @@ obj-y += memory.o
 obj-y += multicall.o
 obj-y += notifier.o
 obj-y += page_alloc.o
-obj-$(HAS_PDX) += pdx.o
+obj-$(CONFIG_HAS_PDX) += pdx.o
 obj-y += preempt.o
 obj-y += random.o
 obj-y += rangeset.o
diff --git a/xen/include/xen/pdx.h b/xen/include/xen/pdx.h
index 18fe8e5..6f25f90 100644
--- a/xen/include/xen/pdx.h
+++ b/xen/include/xen/pdx.h
@@ -1,7 +1,7 @@
 #ifndef __XEN_PDX_H__
 #define __XEN_PDX_H__
 
-#ifdef HAS_PDX
+#ifdef CONFIG_HAS_PDX
 
 extern unsigned long max_pdx;
 extern unsigned long pfn_pdx_bottom_mask, ma_va_bottom_mask;
@@ -37,7 +37,7 @@ static inline unsigned long pdx_to_pfn(unsigned long pdx)
 
 extern void pfn_pdx_hole_setup(unsigned long);
 
-#endif /* HAS_PDX */
+#endif /* CONFIG_HAS_PDX */
 #endif /* __XEN_PDX_H__ */
 
 /*
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 15/28] build: convert HAS_KEXEC use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_KEXEC defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/Rules.mk  | 2 +-
 xen/arch/x86/Kconfig  | 1 +
 xen/arch/x86/Rules.mk | 1 -
 xen/common/Kconfig| 4 
 4 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index c2a3e15..4d90aca 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -68,7 +68,7 @@ ifneq ($(max_phys_irqs),)
 CFLAGS-y+= -DMAX_PHYS_IRQS=$(max_phys_irqs)
 endif
 
-CONFIG_KEXEC-$(HAS_KEXEC) := $(kexec)
+CONFIG_KEXEC-$(CONFIG_HAS_KEXEC) := $(kexec)
 CONFIG_KEXEC  := $(CONFIG_KEXEC-y)
 
 CFLAGS-$(CONFIG_KEXEC)  += -DCONFIG_KEXEC
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index a285a1c..01cfe69 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -13,6 +13,7 @@ config X86
select UART_NS16550
select HAS_GDBSX
select HAS_PDX
+   select HAS_KEXEC
 
 config ARCH_DEFCONFIG
string
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 193e7ea..793e1f7 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,7 +3,6 @@
 
 HAS_NUMA := y
 HAS_EHCI := y
-HAS_KEXEC := y
 HAS_CORE_PARKING := y
 xenoprof := y
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index b429a64..6987e84 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -9,6 +9,10 @@ config HAS_DEVICE_TREE
 config HAS_PDX
bool
 
+# Select HAS_KEXEC if kexec is supported
+config HAS_KEXEC
+   bool
+
 # Select HAS_GDBSX if GDBSX is supported
 config HAS_GDBSX
bool
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 13/28] build: convert HAS_GDBSX use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_GDBSX defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/Rules.mk  | 1 -
 xen/arch/x86/Rules.mk | 1 -
 xen/common/Kconfig| 4 
 xen/common/domain.c   | 2 +-
 4 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 351a186..0ff1a5d 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -56,7 +56,6 @@ CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc) += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
-CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX
 CFLAGS-$(HAS_MEM_ACCESS)  += -DHAS_MEM_ACCESS
 CFLAGS-$(HAS_MEM_PAGING)  += -DHAS_MEM_PAGING
 CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 645d44c..009f702 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -4,7 +4,6 @@
 HAS_NUMA := y
 HAS_EHCI := y
 HAS_KEXEC := y
-HAS_GDBSX := y
 HAS_PDX := y
 HAS_CORE_PARKING := y
 xenoprof := y
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 53ca33f..f63284d 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -5,4 +5,8 @@ menu "Common Features"
 config HAS_DEVICE_TREE
bool
 
+# Select HAS_GDBSX if GDBSX is supported
+config HAS_GDBSX
+   bool
+
 endmenu
diff --git a/xen/common/domain.c b/xen/common/domain.c
index f56b7ff..94cb2cc 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -772,7 +772,7 @@ void vcpu_end_shutdown_deferral(struct vcpu *v)
 vcpu_check_shutdown(v);
 }
 
-#ifdef HAS_GDBSX
+#ifdef CONFIG_HAS_GDBSX
 void domain_pause_for_debugger(void)
 {
 struct vcpu *curr = current;
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 11/28] build: convert HAS_VGA use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_VGA defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/arch/x86/Kconfig   | 1 +
 xen/arch/x86/Rules.mk  | 1 -
 xen/drivers/video/Makefile | 4 ++--
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 70188de..0c86a52 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -7,6 +7,7 @@ config X86
select HAS_ACPI
select HAS_PASSTHROUGH
select HAS_VIDEO
+   select HAS_VGA
select HAS_PCI
select UART_NS16550
select HAS_GDBSX
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 8fda89e..47d4dc6 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -2,7 +2,6 @@
 # x86-specific definitions
 
 HAS_NUMA := y
-HAS_VGA  := y
 HAS_CPUFREQ := y
 HAS_EHCI := y
 HAS_KEXEC := y
diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
index 914b6cf..0143c4a 100644
--- a/xen/drivers/video/Makefile
+++ b/xen/drivers/video/Makefile
@@ -1,7 +1,7 @@
-obj-$(HAS_VGA) := vga.o
+obj-$(CONFIG_HAS_VGA) := vga.o
 obj-$(CONFIG_HAS_VIDEO) += font_8x14.o
 obj-$(CONFIG_HAS_VIDEO) += font_8x16.o
 obj-$(CONFIG_HAS_VIDEO) += font_8x8.o
 obj-$(CONFIG_HAS_VIDEO) += lfb.o
-obj-$(HAS_VGA) += vesa.o
+obj-$(CONFIG_HAS_VGA) += vesa.o
 obj-$(HAS_ARM_HDLCD) += arm_hdlcd.o
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 07/28] build: convert HAS_NS16550 use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_NS16550 defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 config/arm32.mk  | 1 -
 config/arm64.mk  | 1 -
 xen/arch/arm/configs/arm32_defconfig | 1 +
 xen/arch/arm/configs/arm64_defconfig | 1 +
 xen/arch/x86/Kconfig | 1 +
 xen/arch/x86/Rules.mk| 1 -
 xen/drivers/Kconfig  | 2 ++
 xen/drivers/char/Kconfig | 5 +
 xen/drivers/char/Makefile| 2 +-
 9 files changed, 11 insertions(+), 4 deletions(-)
 create mode 100644 xen/drivers/char/Kconfig

diff --git a/config/arm32.mk b/config/arm32.mk
index cd97e42..f963338 100644
--- a/config/arm32.mk
+++ b/config/arm32.mk
@@ -13,7 +13,6 @@ HAS_PL011 := y
 HAS_EXYNOS4210 := y
 HAS_OMAP := y
 HAS_SCIF := y
-HAS_NS16550 := y
 HAS_MEM_ACCESS := y
 
 # Use only if calling $(LD) directly.
diff --git a/config/arm64.mk b/config/arm64.mk
index c5deb4e..f35f6bf 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -8,7 +8,6 @@ CFLAGS += #-marm -march= -mcpu= etc
 
 HAS_PL011 := y
 HAS_CADENCE_UART := y
-HAS_NS16550 := y
 HAS_MEM_ACCESS := y
 HAS_GICV3 := y
 
diff --git a/xen/arch/arm/configs/arm32_defconfig 
b/xen/arch/arm/configs/arm32_defconfig
index 5608ff9..e204bbc 100644
--- a/xen/arch/arm/configs/arm32_defconfig
+++ b/xen/arch/arm/configs/arm32_defconfig
@@ -1 +1,2 @@
 CONFIG_64BIT=n
+CONFIG_UART_NS16550=y
diff --git a/xen/arch/arm/configs/arm64_defconfig 
b/xen/arch/arm/configs/arm64_defconfig
index e69de29..debc348 100644
--- a/xen/arch/arm/configs/arm64_defconfig
+++ b/xen/arch/arm/configs/arm64_defconfig
@@ -0,0 +1 @@
+CONFIG_UART_NS16550=y
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 4e1a9da..8039111 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -5,6 +5,7 @@ config X86
def_bool y
select HAS_PASSTHROUGH
select HAS_PCI
+   select UART_NS16550
select HAS_GDBSX
 
 config ARCH_DEFCONFIG
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 8743509..17d2869 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -7,7 +7,6 @@ HAS_NUMA := y
 HAS_VGA  := y
 HAS_VIDEO  := y
 HAS_CPUFREQ := y
-HAS_NS16550 := y
 HAS_EHCI := y
 HAS_KEXEC := y
 HAS_GDBSX := y
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index 5362e41..fe6fcca 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -1,5 +1,7 @@
 menu "Device Drivers"
 
+source "drivers/char/Kconfig"
+
 source "drivers/passthrough/Kconfig"
 
 source "drivers/pci/Kconfig"
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
new file mode 100644
index 000..6ed451f
--- /dev/null
+++ b/xen/drivers/char/Kconfig
@@ -0,0 +1,5 @@
+
+config UART_NS16550
+   bool "16550-series UART support"
+   help
+ This selects the 16550-series UART support. For most systems, say Y.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 47fc3f9..99e8c6f 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,5 +1,5 @@
 obj-y += console.o
-obj-$(HAS_NS16550) += ns16550.o
+obj-$(CONFIG_UART_NS16550) += ns16550.o
 obj-$(HAS_CADENCE_UART) += cadence-uart.o
 obj-$(HAS_PL011) += pl011.o
 obj-$(HAS_EXYNOS4210) += exynos4210-uart.o
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 05/28] build: convert HAS_DEVICE_TREE use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_DEVICE_TREE defines in the code
base.

CC: Ian Campbell 
CC: Stefano Stabellini 
CC: Jan Beulich 
CC: Daniel De Graaf 
Signed-off-by: Doug Goldstein 
Acked-by: Daniel De Graaf 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/Rules.mk |  1 -
 xen/arch/arm/Kconfig |  1 +
 xen/arch/arm/Rules.mk|  1 -
 xen/common/Kconfig   |  4 
 xen/common/Makefile  |  4 ++--
 xen/drivers/char/ns16550.c   |  6 +++---
 xen/drivers/passthrough/Makefile |  2 +-
 xen/drivers/passthrough/iommu.c  |  2 +-
 xen/include/asm-arm/device.h |  2 +-
 xen/include/xen/hvm/iommu.h  |  2 +-
 xen/include/xen/iommu.h  |  4 ++--
 xen/include/xsm/dummy.h  |  4 ++--
 xen/include/xsm/xsm.h| 10 +-
 xen/xsm/dummy.c  |  2 +-
 xen/xsm/flask/hooks.c|  6 +++---
 xen/xsm/xsm_core.c   |  2 +-
 xen/xsm/xsm_policy.c |  4 ++--
 17 files changed, 30 insertions(+), 27 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 07ff563..15dcedc 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -58,7 +58,6 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)  += -DHAS_ACPI
 CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX
-CFLAGS-$(HAS_DEVICE_TREE) += -DHAS_DEVICE_TREE
 CFLAGS-$(HAS_MEM_ACCESS)  += -DHAS_MEM_ACCESS
 CFLAGS-$(HAS_MEM_PAGING)  += -DHAS_MEM_PAGING
 CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index e754adb..c2e3916 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -16,6 +16,7 @@ config ARM_64
 
 config ARM
def_bool y
+   select HAS_DEVICE_TREE
select HAS_PASSTHROUGH
 
 config ARCH_DEFCONFIG
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 86d7b81..4725374 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -6,7 +6,6 @@
 # 'make clean' before rebuilding.
 #
 
-HAS_DEVICE_TREE := y
 HAS_VIDEO := y
 HAS_ARM_HDLCD := y
 HAS_PDX := y
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 0251856..53ca33f 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -1,4 +1,8 @@
 
 menu "Common Features"
 
+# Select HAS_DEVICE_TREE if device tree is supported
+config HAS_DEVICE_TREE
+   bool
+
 endmenu
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 3547c8e..5dc2bb2 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -2,7 +2,7 @@ obj-y += bitmap.o
 obj-$(HAS_CORE_PARKING) += core_parking.o
 obj-y += cpu.o
 obj-y += cpupool.o
-obj-$(HAS_DEVICE_TREE) += device_tree.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += device_tree.o
 obj-y += domctl.o
 obj-y += domain.o
 obj-y += event_2l.o
@@ -70,4 +70,4 @@ subdir-$(x86_64) += hvm
 subdir-$(coverage) += gcov
 
 subdir-y += libelf
-subdir-$(HAS_DEVICE_TREE) += libfdt
+subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 09abca8..6eab071 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 #include 
-#ifdef HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE
 #include 
 #endif
 #ifdef CONFIG_X86
@@ -1131,7 +1131,7 @@ void __init ns16550_init(int index, struct 
ns16550_defaults *defaults)
 ns16550_parse_port_config(uart, (index == 0) ? opt_com1 : opt_com2);
 }
 
-#ifdef HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE
 static int __init ns16550_uart_dt_init(struct dt_device_node *dev,
const void *data)
 {
@@ -1206,7 +1206,7 @@ DT_DEVICE_START(ns16550, "NS16550 UART", DEVICE_SERIAL)
 .init = ns16550_uart_dt_init,
 DT_DEVICE_END
 
-#endif /* HAS_DEVICE_TREE */
+#endif /* CONFIG_HAS_DEVICE_TREE */
 /*
  * Local variables:
  * mode: C
diff --git a/xen/drivers/passthrough/Makefile b/xen/drivers/passthrough/Makefile
index 16e9027..2bb5afb 100644
--- a/xen/drivers/passthrough/Makefile
+++ b/xen/drivers/passthrough/Makefile
@@ -6,4 +6,4 @@ subdir-$(arm) += arm
 obj-y += iommu.o
 obj-$(x86) += io.o
 obj-$(HAS_PCI) += pci.o
-obj-$(HAS_DEVICE_TREE) += device_tree.o
+obj-$(CONFIG_HAS_DEVICE_TREE) += device_tree.o
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 3d02550..8bb7df0 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -357,7 +357,7 @@ int iommu_do_domctl(
 ret = iommu_do_pci_domctl(domctl, d, u_domctl);
 #endif
 
-#ifdef HAS_DEVICE_TREE
+#ifdef CONFIG_HAS_DEVICE_TREE
 if ( ret == -ENODEV )
 ret = iommu_do_dt_domctl(domctl, d, u_domctl);
 #endif
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 5d0a4cd..b455bdf 100644
--- 

[Xen-devel] [PATCHv6] 18/28] build: convert HAS_PL011 use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_UART_PL011 defines in the code base.
The prefix HAS_ does not make sense in this case because these are
intended to be user selected options while HAS_ just states that the
hardware has this support and is controlled by Xen maintainers.

CC: Ian Campbell 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 config/arm32.mk  | 1 -
 config/arm64.mk  | 1 -
 xen/arch/arm/configs/arm32_defconfig | 1 +
 xen/arch/arm/configs/arm64_defconfig | 1 +
 xen/drivers/char/Kconfig | 7 +++
 xen/drivers/char/Makefile| 2 +-
 6 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/config/arm32.mk b/config/arm32.mk
index f963338..3bbdd2d 100644
--- a/config/arm32.mk
+++ b/config/arm32.mk
@@ -9,7 +9,6 @@ CONFIG_XEN_INSTALL_SUFFIX :=
 # Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
 CFLAGS += -marm
 
-HAS_PL011 := y
 HAS_EXYNOS4210 := y
 HAS_OMAP := y
 HAS_SCIF := y
diff --git a/config/arm64.mk b/config/arm64.mk
index 2d119a6..1b9a47f 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -6,7 +6,6 @@ CONFIG_XEN_INSTALL_SUFFIX :=
 
 CFLAGS += #-marm -march= -mcpu= etc
 
-HAS_PL011 := y
 HAS_MEM_ACCESS := y
 HAS_GICV3 := y
 
diff --git a/xen/arch/arm/configs/arm32_defconfig 
b/xen/arch/arm/configs/arm32_defconfig
index e204bbc..61d6b5d 100644
--- a/xen/arch/arm/configs/arm32_defconfig
+++ b/xen/arch/arm/configs/arm32_defconfig
@@ -1,2 +1,3 @@
 CONFIG_64BIT=n
 CONFIG_UART_NS16550=y
+CONFIG_UART_PL011=y
diff --git a/xen/arch/arm/configs/arm64_defconfig 
b/xen/arch/arm/configs/arm64_defconfig
index 1fb8c7b..4bee0a2 100644
--- a/xen/arch/arm/configs/arm64_defconfig
+++ b/xen/arch/arm/configs/arm64_defconfig
@@ -1,2 +1,3 @@
 CONFIG_UART_NS16550=y
 CONFIG_UART_CADENCE=y
+CONFIG_UART_PL011=y
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 5fc44c0..120525b 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -15,3 +15,10 @@ config UART_CADENCE
help
  This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq
  based board, say Y.
+
+config UART_PL011
+   bool "ARM AMBA PL011 UART support"
+   depends on ARM
+   help
+ This selects the ARM(R) AMBA(R) PrimeCell PL011 UART. If you have
+ an Integrator/PP2, Integrator/CP or Versatile platform, say Y.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index d396b2e..0adb3b7 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,7 +1,7 @@
 obj-y += console.o
 obj-$(CONFIG_UART_NS16550) += ns16550.o
 obj-$(CONFIG_UART_CADENCE) += cadence-uart.o
-obj-$(HAS_PL011) += pl011.o
+obj-$(CONFIG_UART_PL011) += pl011.o
 obj-$(HAS_EXYNOS4210) += exynos4210-uart.o
 obj-$(HAS_OMAP) += omap-uart.o
 obj-$(HAS_SCIF) += scif-uart.o
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 28/28] build: convert kexec options to CONFIG_KEXEC

[Doug Goldstein]

Replace kexec := y in Rules.mk with a Kconfig option called CONFIG_KEXEC

CC: Ian Campbell 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/Rules.mk   |  6 --
 xen/common/Kconfig | 12 
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 1999ff5..e31be35 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -10,7 +10,6 @@ lock_profile  ?= n
 crash_debug   ?= n
 frame_pointer ?= n
 lto   ?= n
-kexec ?= y
 
 -include $(BASEDIR)/include/config/auto.conf
 
@@ -65,11 +64,6 @@ ifneq ($(max_phys_irqs),)
 CFLAGS-y+= -DMAX_PHYS_IRQS=$(max_phys_irqs)
 endif
 
-CONFIG_KEXEC-$(CONFIG_HAS_KEXEC) := $(kexec)
-CONFIG_KEXEC  := $(CONFIG_KEXEC-y)
-
-CFLAGS-$(CONFIG_KEXEC)  += -DCONFIG_KEXEC
-
 AFLAGS-y+= -D__ASSEMBLY__ -include 
$(BASEDIR)/include/xen/config.h
 
 # Clang's built-in assembler can't handle .code16/.code32/.code64 yet
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 58858d2..d46f95f 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -29,4 +29,16 @@ config HAS_KEXEC
 config HAS_GDBSX
bool
 
+# Enable/Disable kexec support
+config KEXEC
+   bool "kexec support"
+   default y
+   depends on HAS_KEXEC
+   ---help---
+ Allows a running Xen hypervisor to be replaced with another OS
+ without rebooting. This is primarily used to execute a crash
+ environment to collect information on a Xen hypervisor or dom0 crash.
+
+ If unsure, say Y.
+
 endmenu
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 04/28] build: convert HAS_PASSTHROUGH use to Kconfig

[Doug Goldstein]

Use the Kconfig generated HAS_PASSTHROUGH defines for the code base.

CC: Ian Campbell 
CC: Stefano Stabellini 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Daniel De Graaf 
Signed-off-by: Doug Goldstein 
Acked-by: Daniel De Graaf 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/Rules.mk|  1 -
 xen/arch/arm/Kconfig|  1 +
 xen/arch/arm/Rules.mk   |  1 -
 xen/arch/x86/Kconfig|  1 +
 xen/arch/x86/Rules.mk   |  1 -
 xen/common/compat/memory.c  |  4 ++--
 xen/common/memory.c |  8 
 xen/drivers/Kconfig |  1 +
 xen/drivers/Makefile|  2 +-
 xen/drivers/passthrough/Kconfig |  4 
 xen/include/xen/sched.h |  4 ++--
 xen/include/xsm/dummy.h |  8 
 xen/include/xsm/xsm.h   | 12 ++--
 xen/xsm/dummy.c |  4 ++--
 xen/xsm/flask/hooks.c   | 14 +++---
 15 files changed, 35 insertions(+), 31 deletions(-)
 create mode 100644 xen/drivers/passthrough/Kconfig

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 011768a..07ff563 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -58,7 +58,6 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)  += -DHAS_ACPI
 CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX
-CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(HAS_DEVICE_TREE) += -DHAS_DEVICE_TREE
 CFLAGS-$(HAS_MEM_ACCESS)  += -DHAS_MEM_ACCESS
 CFLAGS-$(HAS_MEM_PAGING)  += -DHAS_MEM_PAGING
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index a473137..e754adb 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -16,6 +16,7 @@ config ARM_64
 
 config ARM
def_bool y
+   select HAS_PASSTHROUGH
 
 config ARCH_DEFCONFIG
string
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index b31770c..86d7b81 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -9,7 +9,6 @@
 HAS_DEVICE_TREE := y
 HAS_VIDEO := y
 HAS_ARM_HDLCD := y
-HAS_PASSTHROUGH := y
 HAS_PDX := y
 
 CFLAGS += -I$(BASEDIR)/include
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 47b715d..4ff1f63 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -3,6 +3,7 @@ config X86_64
 
 config X86
def_bool y
+   select HAS_PASSTHROUGH
select HAS_GDBSX
 
 config ARCH_DEFCONFIG
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 5b8eaed..09f2844 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -8,7 +8,6 @@ HAS_VGA  := y
 HAS_VIDEO  := y
 HAS_CPUFREQ := y
 HAS_PCI := y
-HAS_PASSTHROUGH := y
 HAS_NS16550 := y
 HAS_EHCI := y
 HAS_KEXEC := y
diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index bb10993..19a914d 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -18,7 +18,7 @@ CHECK_TYPE(domid);
 CHECK_mem_access_op;
 CHECK_vmemrange;
 
-#ifdef HAS_PASSTHROUGH
+#ifdef CONFIG_HAS_PASSTHROUGH
 struct get_reserved_device_memory {
 struct compat_reserved_device_memory_map map;
 unsigned int used_entries;
@@ -340,7 +340,7 @@ int compat_memory_op(unsigned int cmd, 
XEN_GUEST_HANDLE_PARAM(void) compat)
 break;
 }
 
-#ifdef HAS_PASSTHROUGH
+#ifdef CONFIG_HAS_PASSTHROUGH
 case XENMEM_reserved_device_memory_map:
 {
 struct get_reserved_device_memory grdm;
diff --git a/xen/common/memory.c b/xen/common/memory.c
index a3bffb7..da4eb36 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -610,7 +610,7 @@ static int xenmem_add_to_physmap(struct domain *d,
 xatp->gpfn += start;
 xatp->size -= start;
 
-#ifdef HAS_PASSTHROUGH
+#ifdef CONFIG_HAS_PASSTHROUGH
 if ( need_iommu(d) )
 this_cpu(iommu_dont_flush_iotlb) = 1;
 #endif
@@ -633,7 +633,7 @@ static int xenmem_add_to_physmap(struct domain *d,
 }
 }
 
-#ifdef HAS_PASSTHROUGH
+#ifdef CONFIG_HAS_PASSTHROUGH
 if ( need_iommu(d) )
 {
 this_cpu(iommu_dont_flush_iotlb) = 0;
@@ -760,7 +760,7 @@ static int construct_memop_from_reservation(
 return 0;
 }
 
-#ifdef HAS_PASSTHROUGH
+#ifdef CONFIG_HAS_PASSTHROUGH
 struct get_reserved_device_memory {
 struct xen_reserved_device_memory_map map;
 unsigned int used_entries;
@@ -1204,7 +1204,7 @@ long do_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 break;
 }
 
-#ifdef HAS_PASSTHROUGH
+#ifdef CONFIG_HAS_PASSTHROUGH
 case XENMEM_reserved_device_memory_map:
 {
 struct get_reserved_device_memory grdm;
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index 7bc7b6e..57311cc 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -1,3 +1,4 @@
 menu "Device Drivers"
 
+source 

[Xen-devel] [PATCHv6] 25/28] build: convert HAS_MEM_SHARING use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_MEM_SHARING defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Razvan Cojocaru 
CC: Tamas K Lengyel 
CC: Daniel De Graaf 
Signed-off-by: Doug Goldstein 
Acked-by: Razvan Cojocaru 
Acked-by: Daniel De Graaf 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 config/x86_32.mk| 1 -
 config/x86_64.mk| 1 -
 xen/Rules.mk| 1 -
 xen/arch/x86/Kconfig| 1 +
 xen/common/Kconfig  | 4 
 xen/common/memory.c | 2 +-
 xen/common/vm_event.c   | 6 +++---
 xen/include/xsm/dummy.h | 2 +-
 xen/include/xsm/xsm.h   | 4 ++--
 xen/xsm/dummy.c | 2 +-
 xen/xsm/flask/hooks.c   | 4 ++--
 11 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/config/x86_32.mk b/config/x86_32.mk
index cf3d27f..29a18ea 100644
--- a/config/x86_32.mk
+++ b/config/x86_32.mk
@@ -6,7 +6,6 @@ CONFIG_MIGRATE := y
 CONFIG_XCUTILS := y
 
 HAS_MEM_ACCESS := y
-HAS_MEM_SHARING := y
 
 CFLAGS += -m32 -march=i686
 
diff --git a/config/x86_64.mk b/config/x86_64.mk
index 4880681..ac13bad 100644
--- a/config/x86_64.mk
+++ b/config/x86_64.mk
@@ -7,7 +7,6 @@ CONFIG_MIGRATE := y
 CONFIG_XCUTILS := y
 
 HAS_MEM_ACCESS := y
-HAS_MEM_SHARING := y
 
 CONFIG_XEN_INSTALL_SUFFIX := .gz
 
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 3b8fd66..1999ff5 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -56,7 +56,6 @@ CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc) += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
-CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
 ifneq ($(max_phys_cpus),)
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 34be03f..3842018 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -17,6 +17,7 @@ config X86
select HAS_KEXEC
select HAS_MEM_ACCESS
select HAS_MEM_PAGING
+   select HAS_MEM_SHARING
 
 config ARCH_DEFCONFIG
string
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index f6cfb9e..58858d2 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -13,6 +13,10 @@ config HAS_MEM_ACCESS
 config HAS_MEM_PAGING
bool
 
+# Select HAS_MEM_SHARING if mem sharing is supported
+config HAS_MEM_SHARING
+   bool
+
 # Select HAS_PDX if PDX is supported
 config HAS_PDX
bool
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 5180fa8..4de6d49 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1291,7 +1291,7 @@ int prepare_ring_for_helper(
 return -ENOENT;
 }
 #endif
-#ifdef HAS_MEM_SHARING
+#ifdef CONFIG_HAS_MEM_SHARING
 if ( p2m_is_shared(p2mt) )
 {
 if ( page )
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 2e59e41..28a7add 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -518,7 +518,7 @@ static void monitor_notification(struct vcpu *v, unsigned 
int port)
 vm_event_resume(v->domain, >domain->vm_event->monitor);
 }
 
-#ifdef HAS_MEM_SHARING
+#ifdef CONFIG_HAS_MEM_SHARING
 /* Registered with Xen-bound event channel for incoming notifications. */
 static void mem_sharing_notification(struct vcpu *v, unsigned int port)
 {
@@ -549,7 +549,7 @@ void vm_event_cleanup(struct domain *d)
 destroy_waitqueue_head(>vm_event->monitor.wq);
 (void)vm_event_disable(d, >vm_event->monitor);
 }
-#ifdef HAS_MEM_SHARING
+#ifdef CONFIG_HAS_MEM_SHARING
 if ( d->vm_event->share.ring_page )
 {
 destroy_waitqueue_head(>vm_event->share.wq);
@@ -682,7 +682,7 @@ int vm_event_domctl(struct domain *d, 
xen_domctl_vm_event_op_t *vec,
 }
 break;
 
-#ifdef HAS_MEM_SHARING
+#ifdef CONFIG_HAS_MEM_SHARING
 case XEN_DOMCTL_VM_EVENT_OP_SHARING:
 {
 struct vm_event_domain *ved = >vm_event->share;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index dd7618f..d6051a4 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -576,7 +576,7 @@ static XSM_INLINE int xsm_mem_paging(XSM_DEFAULT_ARG struct 
domain *d)
 }
 #endif
 
-#ifdef HAS_MEM_SHARING
+#ifdef CONFIG_HAS_MEM_SHARING
 static XSM_INLINE int xsm_mem_sharing(XSM_DEFAULT_ARG struct domain *d)
 {
 XSM_ASSERT_ACTION(XSM_DM_PRIV);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index b23ecda..0a4c34f 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -160,7 +160,7 @@ struct xsm_operations {
 int (*mem_paging) (struct domain *d);
 #endif
 
-#ifdef HAS_MEM_SHARING
+#ifdef CONFIG_HAS_MEM_SHARING
 int (*mem_sharing) (struct domain *d);
 #endif
 
@@ -617,7 +617,7 @@ static inline int xsm_mem_paging (xsm_default_t def, struct 
domain *d)

[Xen-devel] [PATCHv6] 19/28] build: convert HAS_EXYNOS4210 use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_UART_EXYNOS4210 defines in the code base.

CC: Ian Campbell 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 config/arm32.mk  | 1 -
 xen/arch/arm/configs/arm32_defconfig | 1 +
 xen/drivers/char/Kconfig | 7 +++
 xen/drivers/char/Makefile| 2 +-
 4 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/config/arm32.mk b/config/arm32.mk
index 3bbdd2d..56b71d7 100644
--- a/config/arm32.mk
+++ b/config/arm32.mk
@@ -9,7 +9,6 @@ CONFIG_XEN_INSTALL_SUFFIX :=
 # Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
 CFLAGS += -marm
 
-HAS_EXYNOS4210 := y
 HAS_OMAP := y
 HAS_SCIF := y
 HAS_MEM_ACCESS := y
diff --git a/xen/arch/arm/configs/arm32_defconfig 
b/xen/arch/arm/configs/arm32_defconfig
index 61d6b5d..420602a 100644
--- a/xen/arch/arm/configs/arm32_defconfig
+++ b/xen/arch/arm/configs/arm32_defconfig
@@ -1,3 +1,4 @@
 CONFIG_64BIT=n
 CONFIG_UART_NS16550=y
 CONFIG_UART_PL011=y
+CONFIG_UART_EXYNOS4210=y
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 120525b..7262975 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -22,3 +22,10 @@ config UART_PL011
help
  This selects the ARM(R) AMBA(R) PrimeCell PL011 UART. If you have
  an Integrator/PP2, Integrator/CP or Versatile platform, say Y.
+
+config UART_EXYNOS4210
+   bool "Samsung Exynos 4210 UART support"
+   depends on ARM_32
+   help
+ This selects the Samsung Exynos 4210 UART. If you have a Samsung
+ Exynos based board, say Y.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 0adb3b7..ebea593 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -2,7 +2,7 @@ obj-y += console.o
 obj-$(CONFIG_UART_NS16550) += ns16550.o
 obj-$(CONFIG_UART_CADENCE) += cadence-uart.o
 obj-$(CONFIG_UART_PL011) += pl011.o
-obj-$(HAS_EXYNOS4210) += exynos4210-uart.o
+obj-$(CONFIG_UART_EXYNOS4210) += exynos4210-uart.o
 obj-$(HAS_OMAP) += omap-uart.o
 obj-$(HAS_SCIF) += scif-uart.o
 obj-$(HAS_EHCI) += ehci-dbgp.o
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 20/28] build: convert HAS_OMAP use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_UART_OMAP defines in the code base.

CC: Ian Campbell 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 config/arm32.mk  | 1 -
 xen/arch/arm/configs/arm32_defconfig | 1 +
 xen/drivers/char/Kconfig | 7 +++
 xen/drivers/char/Makefile| 2 +-
 4 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/config/arm32.mk b/config/arm32.mk
index 56b71d7..b1de8da 100644
--- a/config/arm32.mk
+++ b/config/arm32.mk
@@ -9,7 +9,6 @@ CONFIG_XEN_INSTALL_SUFFIX :=
 # Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
 CFLAGS += -marm
 
-HAS_OMAP := y
 HAS_SCIF := y
 HAS_MEM_ACCESS := y
 
diff --git a/xen/arch/arm/configs/arm32_defconfig 
b/xen/arch/arm/configs/arm32_defconfig
index 420602a..121c3f6 100644
--- a/xen/arch/arm/configs/arm32_defconfig
+++ b/xen/arch/arm/configs/arm32_defconfig
@@ -2,3 +2,4 @@ CONFIG_64BIT=n
 CONFIG_UART_NS16550=y
 CONFIG_UART_PL011=y
 CONFIG_UART_EXYNOS4210=y
+CONFIG_UART_OMAP=y
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 7262975..70f0eee6 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -29,3 +29,10 @@ config UART_EXYNOS4210
help
  This selects the Samsung Exynos 4210 UART. If you have a Samsung
  Exynos based board, say Y.
+
+config UART_OMAP
+   bool "OMAP UART support"
+   depends on ARM_32
+   help
+ This selects the Texas Instruments OMAP UART. If you have a Texas
+ Instruments based CPU, say Y.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index ebea593..06d02fb 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -3,7 +3,7 @@ obj-$(CONFIG_UART_NS16550) += ns16550.o
 obj-$(CONFIG_UART_CADENCE) += cadence-uart.o
 obj-$(CONFIG_UART_PL011) += pl011.o
 obj-$(CONFIG_UART_EXYNOS4210) += exynos4210-uart.o
-obj-$(HAS_OMAP) += omap-uart.o
+obj-$(CONFIG_UART_OMAP) += omap-uart.o
 obj-$(HAS_SCIF) += scif-uart.o
 obj-$(HAS_EHCI) += ehci-dbgp.o
 obj-$(CONFIG_ARM) += dt-uart.o
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 27/28] build: convert CONFIG_COMPAT to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_COMPAT defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/arch/x86/Kconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 3842018..7d92a23 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -25,6 +25,13 @@ config ARCH_DEFCONFIG
 
 menu "Architecture Features"
 
+config COMPAT
+   def_bool y
+   help
+ 32-bit interface support on 64-bit Xen which is used for both
+ HVM and PV guests. HVMLoader makes 32-bit hypercalls irrespective
+ of the destination runmode of the guest.
+
 endmenu
 
 source "common/Kconfig"
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 17/28] build: convert HAS_CADENCE_UART use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_CADENCE_UART defines in the code base.

CC: Ian Campbell 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 config/arm64.mk  | 1 -
 xen/arch/arm/configs/arm64_defconfig | 1 +
 xen/drivers/char/Kconfig | 7 +++
 xen/drivers/char/Makefile| 2 +-
 4 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/config/arm64.mk b/config/arm64.mk
index f35f6bf..2d119a6 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -7,7 +7,6 @@ CONFIG_XEN_INSTALL_SUFFIX :=
 CFLAGS += #-marm -march= -mcpu= etc
 
 HAS_PL011 := y
-HAS_CADENCE_UART := y
 HAS_MEM_ACCESS := y
 HAS_GICV3 := y
 
diff --git a/xen/arch/arm/configs/arm64_defconfig 
b/xen/arch/arm/configs/arm64_defconfig
index debc348..1fb8c7b 100644
--- a/xen/arch/arm/configs/arm64_defconfig
+++ b/xen/arch/arm/configs/arm64_defconfig
@@ -1 +1,2 @@
 CONFIG_UART_NS16550=y
+CONFIG_UART_CADENCE=y
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 8ecea29..5fc44c0 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -8,3 +8,10 @@ config UART_NS16550
 config HAS_IOPORTS
bool
depends on UART_NS16550
+
+config UART_CADENCE
+   bool "Xilinx Zynq Cadence UART support"
+   depends on ARM_64
+   help
+ This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq
+ based board, say Y.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 99e8c6f..d396b2e 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,6 +1,6 @@
 obj-y += console.o
 obj-$(CONFIG_UART_NS16550) += ns16550.o
-obj-$(HAS_CADENCE_UART) += cadence-uart.o
+obj-$(CONFIG_UART_CADENCE) += cadence-uart.o
 obj-$(HAS_PL011) += pl011.o
 obj-$(HAS_EXYNOS4210) += exynos4210-uart.o
 obj-$(HAS_OMAP) += omap-uart.o
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 10/28] build: convert HAS_VIDEO use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_VIDEO defines in the code base.

CC: Ian Campbell 
CC: Stefano Stabellini 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/arch/arm/Kconfig   |  1 +
 xen/arch/arm/Rules.mk  |  1 -
 xen/arch/x86/Kconfig   |  1 +
 xen/arch/x86/Rules.mk  |  1 -
 xen/drivers/Kconfig|  2 ++
 xen/drivers/Makefile   |  2 +-
 xen/drivers/video/Kconfig  | 13 +
 xen/drivers/video/Makefile |  8 
 8 files changed, 22 insertions(+), 7 deletions(-)
 create mode 100644 xen/drivers/video/Kconfig

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index c2e3916..1786769 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -17,6 +17,7 @@ config ARM_64
 config ARM
def_bool y
select HAS_DEVICE_TREE
+   select HAS_VIDEO
select HAS_PASSTHROUGH
 
 config ARCH_DEFCONFIG
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 4725374..90b1f24 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -6,7 +6,6 @@
 # 'make clean' before rebuilding.
 #
 
-HAS_VIDEO := y
 HAS_ARM_HDLCD := y
 HAS_PDX := y
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 8c24c05..70188de 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -6,6 +6,7 @@ config X86
select HAS_IOPORTS
select HAS_ACPI
select HAS_PASSTHROUGH
+   select HAS_VIDEO
select HAS_PCI
select UART_NS16550
select HAS_GDBSX
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 166deb9..8fda89e 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,7 +3,6 @@
 
 HAS_NUMA := y
 HAS_VGA  := y
-HAS_VIDEO  := y
 HAS_CPUFREQ := y
 HAS_EHCI := y
 HAS_KEXEC := y
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index eb01d47..f0ad01e 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -8,4 +8,6 @@ source "drivers/passthrough/Kconfig"
 
 source "drivers/pci/Kconfig"
 
+source "drivers/video/Kconfig"
+
 endmenu
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index 9f6c18b..01d6b8d 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -3,4 +3,4 @@ subdir-$(HAS_CPUFREQ) += cpufreq
 subdir-$(CONFIG_HAS_PCI) += pci
 subdir-$(CONFIG_HAS_PASSTHROUGH) += passthrough
 subdir-$(CONFIG_HAS_ACPI) += acpi
-subdir-$(HAS_VIDEO) += video
+subdir-$(CONFIG_HAS_VIDEO) += video
diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
new file mode 100644
index 000..a88a7a9
--- /dev/null
+++ b/xen/drivers/video/Kconfig
@@ -0,0 +1,13 @@
+
+# Select HAS_VIDEO if video is supported
+config HAS_VIDEO
+   bool
+
+# Select HAS_VGA if VGA is supported
+config HAS_VGA
+   bool
+   depends on HAS_VIDEO
+
+# Select HAS_ARM_HDLCD if ARM HDLCD is supported
+config HAS_ARM_HDLCD
+   bool
diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
index a756292..914b6cf 100644
--- a/xen/drivers/video/Makefile
+++ b/xen/drivers/video/Makefile
@@ -1,7 +1,7 @@
 obj-$(HAS_VGA) := vga.o
-obj-$(HAS_VIDEO) += font_8x14.o
-obj-$(HAS_VIDEO) += font_8x16.o
-obj-$(HAS_VIDEO) += font_8x8.o
-obj-$(HAS_VIDEO) += lfb.o
+obj-$(CONFIG_HAS_VIDEO) += font_8x14.o
+obj-$(CONFIG_HAS_VIDEO) += font_8x16.o
+obj-$(CONFIG_HAS_VIDEO) += font_8x8.o
+obj-$(CONFIG_HAS_VIDEO) += lfb.o
 obj-$(HAS_VGA) += vesa.o
 obj-$(HAS_ARM_HDLCD) += arm_hdlcd.o
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 12/28] build: convert HAS_CPUFREQ use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_CPUFREQ defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Liu Jinsong 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/arch/x86/Kconfig| 1 +
 xen/arch/x86/Rules.mk   | 1 -
 xen/drivers/Kconfig | 2 ++
 xen/drivers/Makefile| 2 +-
 xen/drivers/cpufreq/Kconfig | 4 
 5 files changed, 8 insertions(+), 2 deletions(-)
 create mode 100644 xen/drivers/cpufreq/Kconfig

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 0c86a52..7585c82 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -8,6 +8,7 @@ config X86
select HAS_PASSTHROUGH
select HAS_VIDEO
select HAS_VGA
+   select HAS_CPUFREQ
select HAS_PCI
select UART_NS16550
select HAS_GDBSX
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 47d4dc6..645d44c 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -2,7 +2,6 @@
 # x86-specific definitions
 
 HAS_NUMA := y
-HAS_CPUFREQ := y
 HAS_EHCI := y
 HAS_KEXEC := y
 HAS_GDBSX := y
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index f0ad01e..bc3a54f 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -4,6 +4,8 @@ source "drivers/acpi/Kconfig"
 
 source "drivers/char/Kconfig"
 
+source "drivers/cpufreq/Kconfig"
+
 source "drivers/passthrough/Kconfig"
 
 source "drivers/pci/Kconfig"
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index 01d6b8d..7bbb654 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -1,5 +1,5 @@
 subdir-y += char
-subdir-$(HAS_CPUFREQ) += cpufreq
+subdir-$(CONFIG_HAS_CPUFREQ) += cpufreq
 subdir-$(CONFIG_HAS_PCI) += pci
 subdir-$(CONFIG_HAS_PASSTHROUGH) += passthrough
 subdir-$(CONFIG_HAS_ACPI) += acpi
diff --git a/xen/drivers/cpufreq/Kconfig b/xen/drivers/cpufreq/Kconfig
new file mode 100644
index 000..00be480
--- /dev/null
+++ b/xen/drivers/cpufreq/Kconfig
@@ -0,0 +1,4 @@
+
+# Select HAS_CPUFREQ if CPU frequency scaling is supported
+config HAS_CPUFREQ
+   bool
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 16/28] build: convert HAS_ARM_HDLCD use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_ARM_HDLCD defines in the code base.

CC: Ian Campbell 
CC: Stefano Stabellini 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/arch/arm/Kconfig   | 1 +
 xen/arch/arm/Rules.mk  | 2 --
 xen/drivers/video/Makefile | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 32f57d4..9e7351e 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -18,6 +18,7 @@ config ARM
def_bool y
select HAS_DEVICE_TREE
select HAS_VIDEO
+   select HAS_ARM_HDLCD
select HAS_PASSTHROUGH
select HAS_PDX
 
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 52b1ad4..2158bd8 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -6,8 +6,6 @@
 # 'make clean' before rebuilding.
 #
 
-HAS_ARM_HDLCD := y
-
 CFLAGS += -I$(BASEDIR)/include
 
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
index 0143c4a..b9b5e23 100644
--- a/xen/drivers/video/Makefile
+++ b/xen/drivers/video/Makefile
@@ -4,4 +4,4 @@ obj-$(CONFIG_HAS_VIDEO) += font_8x16.o
 obj-$(CONFIG_HAS_VIDEO) += font_8x8.o
 obj-$(CONFIG_HAS_VIDEO) += lfb.o
 obj-$(CONFIG_HAS_VGA) += vesa.o
-obj-$(HAS_ARM_HDLCD) += arm_hdlcd.o
+obj-$(CONFIG_HAS_ARM_HDLCD) += arm_hdlcd.o
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 09/28] build: convert HAS_ACPI use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_ACPI defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 xen/Rules.mk | 1 -
 xen/arch/x86/Kconfig | 1 +
 xen/arch/x86/Rules.mk| 1 -
 xen/common/sysctl.c  | 2 +-
 xen/drivers/Kconfig  | 2 ++
 xen/drivers/Makefile | 2 +-
 xen/drivers/acpi/Kconfig | 4 
 7 files changed, 9 insertions(+), 4 deletions(-)
 create mode 100644 xen/drivers/acpi/Kconfig

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 870c548..351a186 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -56,7 +56,6 @@ CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc) += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
-CFLAGS-$(HAS_ACPI)  += -DHAS_ACPI
 CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX
 CFLAGS-$(HAS_MEM_ACCESS)  += -DHAS_MEM_ACCESS
 CFLAGS-$(HAS_MEM_PAGING)  += -DHAS_MEM_PAGING
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 54124c6..8c24c05 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -4,6 +4,7 @@ config X86_64
 config X86
def_bool y
select HAS_IOPORTS
+   select HAS_ACPI
select HAS_PASSTHROUGH
select HAS_PCI
select UART_NS16550
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 151ed25..166deb9 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,7 +1,6 @@
 
 # x86-specific definitions
 
-HAS_ACPI := y
 HAS_NUMA := y
 HAS_VGA  := y
 HAS_VIDEO  := y
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 47d115e..a3007b8 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -171,7 +171,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 op->u.availheap.avail_bytes <<= PAGE_SHIFT;
 break;
 
-#ifdef HAS_ACPI
+#ifdef CONFIG_HAS_ACPI
 case XEN_SYSCTL_get_pmstat:
 ret = do_get_pm_info(>u.get_pmstat);
 break;
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index fe6fcca..eb01d47 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -1,5 +1,7 @@
 menu "Device Drivers"
 
+source "drivers/acpi/Kconfig"
+
 source "drivers/char/Kconfig"
 
 source "drivers/passthrough/Kconfig"
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index eb32d69..9f6c18b 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -2,5 +2,5 @@ subdir-y += char
 subdir-$(HAS_CPUFREQ) += cpufreq
 subdir-$(CONFIG_HAS_PCI) += pci
 subdir-$(CONFIG_HAS_PASSTHROUGH) += passthrough
-subdir-$(HAS_ACPI) += acpi
+subdir-$(CONFIG_HAS_ACPI) += acpi
 subdir-$(HAS_VIDEO) += video
diff --git a/xen/drivers/acpi/Kconfig b/xen/drivers/acpi/Kconfig
new file mode 100644
index 000..11ab5e4
--- /dev/null
+++ b/xen/drivers/acpi/Kconfig
@@ -0,0 +1,4 @@
+
+# Select HAS_ACPI if ACPI is supported
+config HAS_ACPI
+   bool
-- 
2.4.10


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

[Xen-devel] [PATCHv6] 24/28] build: convert HAS_MEM_PAGING use to Kconfig

[Doug Goldstein]

Use the Kconfig generated CONFIG_HAS_MEM_PAGING defines in the code base.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Razvan Cojocaru 
CC: Tamas K Lengyel 
CC: Daniel De Graaf 
Signed-off-by: Doug Goldstein 
Acked-by: Razvan Cojocaru 
Acked-by: Daniel De Graaf 
Acked-by: Andrew Cooper 
Tested-by: Andrew Cooper 
---
 config/x86_32.mk| 1 -
 config/x86_64.mk| 1 -
 xen/Rules.mk| 1 -
 xen/arch/x86/Kconfig| 1 +
 xen/common/Kconfig  | 4 
 xen/common/memory.c | 2 +-
 xen/common/vm_event.c   | 8 
 xen/include/xsm/dummy.h | 2 +-
 xen/include/xsm/xsm.h   | 4 ++--
 xen/xsm/dummy.c | 2 +-
 xen/xsm/flask/hooks.c   | 4 ++--
 11 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/config/x86_32.mk b/config/x86_32.mk
index ed69447..cf3d27f 100644
--- a/config/x86_32.mk
+++ b/config/x86_32.mk
@@ -6,7 +6,6 @@ CONFIG_MIGRATE := y
 CONFIG_XCUTILS := y
 
 HAS_MEM_ACCESS := y
-HAS_MEM_PAGING := y
 HAS_MEM_SHARING := y
 
 CFLAGS += -m32 -march=i686
diff --git a/config/x86_64.mk b/config/x86_64.mk
index f74611f..4880681 100644
--- a/config/x86_64.mk
+++ b/config/x86_64.mk
@@ -7,7 +7,6 @@ CONFIG_MIGRATE := y
 CONFIG_XCUTILS := y
 
 HAS_MEM_ACCESS := y
-HAS_MEM_PAGING := y
 HAS_MEM_SHARING := y
 
 CONFIG_XEN_INSTALL_SUFFIX := .gz
diff --git a/xen/Rules.mk b/xen/Rules.mk
index f5ffe9d..3b8fd66 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -56,7 +56,6 @@ CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc) += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
-CFLAGS-$(HAS_MEM_PAGING)  += -DHAS_MEM_PAGING
 CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 530563f..34be03f 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -16,6 +16,7 @@ config X86
select HAS_PDX
select HAS_KEXEC
select HAS_MEM_ACCESS
+   select HAS_MEM_PAGING
 
 config ARCH_DEFCONFIG
string
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index bdb95f0..f6cfb9e 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -9,6 +9,10 @@ config HAS_DEVICE_TREE
 config HAS_MEM_ACCESS
bool
 
+# Select HAS_MEM_PAGING if mem paging is supported
+config HAS_MEM_PAGING
+   bool
+
 # Select HAS_PDX if PDX is supported
 config HAS_PDX
bool
diff --git a/xen/common/memory.c b/xen/common/memory.c
index da4eb36..5180fa8 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1282,7 +1282,7 @@ int prepare_ring_for_helper(
 
 page = get_page_from_gfn(d, gmfn, , P2M_UNSHARE);
 
-#ifdef HAS_MEM_PAGING
+#ifdef CONFIG_HAS_MEM_PAGING
 if ( p2m_is_paging(p2mt) )
 {
 if ( page )
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 0fe93dc..2e59e41 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -403,7 +403,7 @@ void vm_event_resume(struct domain *d, struct 
vm_event_domain *ved)
 break;
 #endif
 
-#ifdef HAS_MEM_PAGING
+#ifdef CONFIG_HAS_MEM_PAGING
 case VM_EVENT_REASON_MEM_PAGING:
 p2m_mem_paging_resume(d, );
 break;
@@ -502,7 +502,7 @@ int __vm_event_claim_slot(struct domain *d, struct 
vm_event_domain *ved,
 return vm_event_grab_slot(ved, (current->domain != d));
 }
 
-#ifdef HAS_MEM_PAGING
+#ifdef CONFIG_HAS_MEM_PAGING
 /* Registered with Xen-bound event channel for incoming notifications. */
 static void mem_paging_notification(struct vcpu *v, unsigned int port)
 {
@@ -530,7 +530,7 @@ static void mem_sharing_notification(struct vcpu *v, 
unsigned int port)
 /* Clean up on domain destruction */
 void vm_event_cleanup(struct domain *d)
 {
-#ifdef HAS_MEM_PAGING
+#ifdef CONFIG_HAS_MEM_PAGING
 if ( d->vm_event->paging.ring_page )
 {
 /* Destroying the wait queue head means waking up all
@@ -592,7 +592,7 @@ int vm_event_domctl(struct domain *d, 
xen_domctl_vm_event_op_t *vec,
 
 switch ( vec->mode )
 {
-#ifdef HAS_MEM_PAGING
+#ifdef CONFIG_HAS_MEM_PAGING
 case XEN_DOMCTL_VM_EVENT_OP_PAGING:
 {
 struct vm_event_domain *ved = >vm_event->paging;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 7a9006b..dd7618f 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -568,7 +568,7 @@ static XSM_INLINE int xsm_mem_access(XSM_DEFAULT_ARG struct 
domain *d)
 }
 #endif
 
-#ifdef HAS_MEM_PAGING
+#ifdef CONFIG_HAS_MEM_PAGING
 static XSM_INLINE int xsm_mem_paging(XSM_DEFAULT_ARG struct domain *d)
 {
 XSM_ASSERT_ACTION(XSM_DM_PRIV);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index a550ae2..b23ecda 100644

Re: [Xen-devel] [PATCHv2 0/3] Implement per-cpu reader-writer locks

[George Dunlap]

On 20/11/15 16:03, Malcolm Crossley wrote:
> This patch series adds per-cpu reader-writer locks as a generic lock
> implementation and then converts the grant table and p2m rwlocks to
> use the percpu rwlocks, in order to improve multi-socket host performance.
> 
> CPU profiling has revealed the rwlocks themselves suffer from severe cache
> line bouncing due to the cmpxchg operation used even when taking a read lock.
> Multiqueue paravirtualised I/O results in heavy contention of the grant table
> and p2m read locks of a specific domain and so I/O throughput is bottlenecked
> by the overhead of the cache line bouncing itself.
> 
> Per-cpu read locks avoid lock cache line bouncing by using a per-cpu data
> area to record a CPU has taken the read lock. Correctness is enforced for the 
> write lock by using a per lock barrier which forces the per-cpu read lock 
> to revert to using a standard read lock. The write lock then polls all 
> the percpu data area until active readers for the lock have exited.
> 
> Removing the cache line bouncing on a multi-socket Haswell-EP system 
> dramatically improves performance, with 16 vCPU network IO performance going 
> from 15 gb/s to 64 gb/s! The host under test was fully utilising all 40 
> logical CPU's at 64 gb/s, so a bigger logical CPU host may see an even better
> IO improvement.

Impressive -- thanks for doing this work.

One question: Your description here sounds like you've tested with a
single large domain, but what happens with multiple domains?

It looks like the "per-cpu-rwlock" is shared by *all* locks of a
particular type (e.g., all domains share the per-cpu p2m rwlock).
(Correct me if I'm wrong here.)

Which means two things:

 1) *Any* writer will have to wait for the rwlock of that type to be
released on *all* domains before being able to write.  Is there any risk
that on a busy system, this will be an unusually long wait?

2) *All* domains will have to take the slow path for reading when a
*any* domain has or is trying to acquire the write lock.  What is the
probability that on a busy system that turns out to be "most of the time"?

#2 is of course no worse than it is now, but #1 could be a bit of a bear.

 -George


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

Re: [Xen-devel] [PATCH] build: remove .d files from xen/ on a clean

[Jonathan Creekmore]

> On Nov 24, 2015, at 11:30 AM, Jan Beulich  wrote:
> 
 On 24.11.15 at 18:22,  wrote:
> 
>>> On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore 
>>  wrote:
 On Nov 24, 2015, at 11:07 AM, Jan Beulich  wrote:
>>> On 24.11.15 at 17:56,  wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -88,7 +88,7 @@ _clean: delete-unfresh-files
>   $(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
>   $(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
>   $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
> - rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
> $(TARGET)-syms 
>> *~ core
> + rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
> $(TARGET)-syms 
>> *~ core $(DEPS)
 
 Is this really a problem only in xen/ ? The referenced commit clearly
 introduces "stray" *.d files elsewhere. Also there aren't any source
 files in xen/, so I'd expect $(DEPS) to be empty. Please clarify.
>>> 
>>> So, the files in xen/ were the dependencies files for xen.efi and 
>>> xen-syms that were getting left behind. $(DEPS) appears to always
>>> have ‘.*.d’ in it, based on me putting an echo into the clean rule to 
>>> print it out. However, looking at this, I am also seeing ‘.d’ files left
>>> behind in xen/common/compat that I did not notice before.
>> 
>> Actually, looking closer at it, xen/common/compat does not appear to be
>> cleaning at all, so I think that is a separate, unrelated issue.
> 
> That would be quite related, as it would be a result of the same
> commit.

Yeah, I now see where that change got introduced. I don’t see a clear way of 
cleaning
those objects files since the build system no longer goes into the 
common/compat directory at
all. The existing clean rules walk all of the subdirectories, cleaning object 
files and dependency
files as it goes. 


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

Re: [Xen-devel] [PATCHv2 0/3] Implement per-cpu reader-writer locks

[George Dunlap]

On 24/11/15 18:16, George Dunlap wrote:
> On 20/11/15 16:03, Malcolm Crossley wrote:
>> This patch series adds per-cpu reader-writer locks as a generic lock
>> implementation and then converts the grant table and p2m rwlocks to
>> use the percpu rwlocks, in order to improve multi-socket host performance.
>>
>> CPU profiling has revealed the rwlocks themselves suffer from severe cache
>> line bouncing due to the cmpxchg operation used even when taking a read lock.
>> Multiqueue paravirtualised I/O results in heavy contention of the grant table
>> and p2m read locks of a specific domain and so I/O throughput is bottlenecked
>> by the overhead of the cache line bouncing itself.
>>
>> Per-cpu read locks avoid lock cache line bouncing by using a per-cpu data
>> area to record a CPU has taken the read lock. Correctness is enforced for 
>> the 
>> write lock by using a per lock barrier which forces the per-cpu read lock 
>> to revert to using a standard read lock. The write lock then polls all 
>> the percpu data area until active readers for the lock have exited.
>>
>> Removing the cache line bouncing on a multi-socket Haswell-EP system 
>> dramatically improves performance, with 16 vCPU network IO performance going 
>> from 15 gb/s to 64 gb/s! The host under test was fully utilising all 40 
>> logical CPU's at 64 gb/s, so a bigger logical CPU host may see an even better
>> IO improvement.
> 
> Impressive -- thanks for doing this work.
> 
> One question: Your description here sounds like you've tested with a
> single large domain, but what happens with multiple domains?
> 
> It looks like the "per-cpu-rwlock" is shared by *all* locks of a
> particular type (e.g., all domains share the per-cpu p2m rwlock).
> (Correct me if I'm wrong here.)

Sorry, looking in more detail at the code, it seems I am wrong.  The
fast-path stores which "slow" lock has been grabbed in the per-cpu
variable; so the writer only needs to wait for readers that have grabbed
the particular lock it's interested in.  So the scenarios I outline
below shouldn't really be issues.

The description of the algorithm  in the changelog could do with a bit
more detail. :-)

 -George


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

Re: [Xen-devel] [PATCHv2 0/3] Implement per-cpu reader-writer locks

[Andrew Cooper]

On 24/11/15 18:16, George Dunlap wrote:
> On 20/11/15 16:03, Malcolm Crossley wrote:
>> This patch series adds per-cpu reader-writer locks as a generic lock
>> implementation and then converts the grant table and p2m rwlocks to
>> use the percpu rwlocks, in order to improve multi-socket host performance.
>>
>> CPU profiling has revealed the rwlocks themselves suffer from severe cache
>> line bouncing due to the cmpxchg operation used even when taking a read lock.
>> Multiqueue paravirtualised I/O results in heavy contention of the grant table
>> and p2m read locks of a specific domain and so I/O throughput is bottlenecked
>> by the overhead of the cache line bouncing itself.
>>
>> Per-cpu read locks avoid lock cache line bouncing by using a per-cpu data
>> area to record a CPU has taken the read lock. Correctness is enforced for 
>> the 
>> write lock by using a per lock barrier which forces the per-cpu read lock 
>> to revert to using a standard read lock. The write lock then polls all 
>> the percpu data area until active readers for the lock have exited.
>>
>> Removing the cache line bouncing on a multi-socket Haswell-EP system 
>> dramatically improves performance, with 16 vCPU network IO performance going 
>> from 15 gb/s to 64 gb/s! The host under test was fully utilising all 40 
>> logical CPU's at 64 gb/s, so a bigger logical CPU host may see an even better
>> IO improvement.
> Impressive -- thanks for doing this work.
>
> One question: Your description here sounds like you've tested with a
> single large domain, but what happens with multiple domains?

The test was with two domU's, doing network traffic between them.

>
> It looks like the "per-cpu-rwlock" is shared by *all* locks of a
> particular type (e.g., all domains share the per-cpu p2m rwlock).
> (Correct me if I'm wrong here.)

The per-pcpu pointer is shared for all locks of a particular type, but
allows the individual lock to be distinguished by following the pointer
back.

Therefore, the locks are not actually shared.

>
> Which means two things:
>
>  1) *Any* writer will have to wait for the rwlock of that type to be
> released on *all* domains before being able to write.  Is there any risk
> that on a busy system, this will be an unusually long wait?

No.  The write-locker looks through all pcpus and ignores any whose
per-cpu pointer is not pointing at the intended percpu_rwlock.

>From _percpu_write_lock():

/*
 * Remove any percpu readers not contending on this rwlock
 * from our check mask.
 */
if ( per_cpu_ptr(per_cpudata, cpu) != percpu_rwlock )
cpumask_clear_cpu(cpu, _cpu(percpu_rwlock_readers));

As a result, two calls to _percpu_write_lock() against different
percpu_rwlock_t's will not interact.

>
> 2) *All* domains will have to take the slow path for reading when a
> *any* domain has or is trying to acquire the write lock.  What is the
> probability that on a busy system that turns out to be "most of the time"?

_percpu_read_lock() will only take the slow path if:

1) The intended lock is (or is in the process of being) taken for writing
2) The callpath has nested _percpu_read_lock() of the same type of lock

By observation, 2) does not occur currently in the code.

~Andrew

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

[Xen-devel] [PATCH 2/4] update outdated header comment on privcmd.h

[Doug Goldstein]

The BSDs have always accessed privcmd via /dev/xen/privcmd while Linux
has used /proc/xen/privcmd but things are shifting to /dev/xen/privcmd
as well.

CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Ian Campbell 
CC: Wei Liu 
Signed-off-by: Doug Goldstein 
---
 tools/include/xen-sys/FreeBSD/privcmd.h| 2 +-
 tools/include/xen-sys/Linux/privcmd.h  | 2 +-
 tools/include/xen-sys/NetBSD/privcmd.h | 2 +-
 tools/include/xen-sys/NetBSDRump/privcmd.h | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/include/xen-sys/FreeBSD/privcmd.h 
b/tools/include/xen-sys/FreeBSD/privcmd.h
index 0434d4d..cf1241f 100644
--- a/tools/include/xen-sys/FreeBSD/privcmd.h
+++ b/tools/include/xen-sys/FreeBSD/privcmd.h
@@ -1,7 +1,7 @@
 /**
  * privcmd.h
  *
- * Interface to /proc/xen/privcmd.
+ * Interface to /dev/xen/privcmd.
  *
  * Copyright (c) 2003-2005, K A Fraser
  *
diff --git a/tools/include/xen-sys/Linux/privcmd.h 
b/tools/include/xen-sys/Linux/privcmd.h
index 5be860a..e4e666a 100644
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -1,7 +1,7 @@
 /**
  * privcmd.h
  * 
- * Interface to /proc/xen/privcmd.
+ * Interface to /dev/xen/privcmd.
  * 
  * Copyright (c) 2003-2005, K A Fraser
  * 
diff --git a/tools/include/xen-sys/NetBSD/privcmd.h 
b/tools/include/xen-sys/NetBSD/privcmd.h
index 1296b30..555bad9 100644
--- a/tools/include/xen-sys/NetBSD/privcmd.h
+++ b/tools/include/xen-sys/NetBSD/privcmd.h
@@ -30,7 +30,7 @@
 #ifndef __NetBSD_PRIVCMD_H__
 #define __NetBSD_PRIVCMD_H__
 
-/* Interface to /proc/xen/privcmd */
+/* Interface to /dev/xen/privcmd */
 
 typedef struct privcmd_hypercall
 {
diff --git a/tools/include/xen-sys/NetBSDRump/privcmd.h 
b/tools/include/xen-sys/NetBSDRump/privcmd.h
index 1296b30..555bad9 100644
--- a/tools/include/xen-sys/NetBSDRump/privcmd.h
+++ b/tools/include/xen-sys/NetBSDRump/privcmd.h
@@ -30,7 +30,7 @@
 #ifndef __NetBSD_PRIVCMD_H__
 #define __NetBSD_PRIVCMD_H__
 
-/* Interface to /proc/xen/privcmd */
+/* Interface to /dev/xen/privcmd */
 
 typedef struct privcmd_hypercall
 {
-- 
2.4.10


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

[Xen-devel] [PATCH 1/4] libxc: prefer using privcmd character device

[Doug Goldstein]

Prefer using the character device over the proc file if the character
device exists. This follows similar conversions of xenbus to avoid
issues with FMODE_ATOMIC_POS added in Linux 3.14 and newer.

CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Ian Campbell 
CC: Wei Liu 
Signed-off-by: Doug Goldstein 
---
 tools/libxc/xc_linux_osdep.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
index 76c55ff..fb69770 100644
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -46,7 +46,13 @@
 static xc_osdep_handle linux_privcmd_open(xc_interface *xch)
 {
 int flags, saved_errno;
-int fd = open("/proc/xen/privcmd", O_RDWR);
+int fd = open("/dev/xen/privcmd", O_RDWR); /* prefer this newer interface 
*/
+
+if ( fd == -1 )
+{
+/* Fallback to /proc/xen/privcmd */
+fd = open("/proc/xen/privcmd", O_RDWR);
+}
 
 if ( fd == -1 )
 {
-- 
2.4.10


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

[Xen-devel] [PATCH 4/4] xendomains initscript: test for privcmd char device

[Doug Goldstein]

Allow the init script to continue if either the character device or the
proc file is available.

CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Ian Campbell 
CC: Wei Liu 
Signed-off-by: Doug Goldstein 
---
 tools/hotplug/Linux/xendomains.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/xendomains.in 
b/tools/hotplug/Linux/xendomains.in
index 0603842..686f061 100644
--- a/tools/hotplug/Linux/xendomains.in
+++ b/tools/hotplug/Linux/xendomains.in
@@ -45,7 +45,7 @@ fi
 
 # Correct exit code would probably be 5, but it's enough
 # if xend complains if we're not running as privileged domain
-if ! [ -e /proc/xen/privcmd ]; then
+if ! [ -e /dev/xen/privcmd ] || [ -e /proc/xen/privcmd ]; then
exit 0
 fi
 
-- 
2.4.10


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

Re: [Xen-devel] [PATCH 2/4] update outdated header comment on privcmd.h

[Ian Jackson]

Doug Goldstein writes ("[PATCH 2/4] update outdated header comment on 
privcmd.h"):
> The BSDs have always accessed privcmd via /dev/xen/privcmd while Linux
> has used /proc/xen/privcmd but things are shifting to /dev/xen/privcmd
> as well.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH 3/4] gdbsx: prefer privcmd character device

[Ian Jackson]

Doug Goldstein writes ("[PATCH 3/4] gdbsx: prefer privcmd character device"):
> Prefer using the character device over the proc file if the character
> device exists.

I think this common logic (which also appears in your 1/4 patch)
should be factored out.

Could gdbsx not use a libxc handle ?

Ian.

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

Re: [Xen-devel] [PATCH 4/4] xendomains initscript: test for privcmd char device

[Ian Jackson]

Doug Goldstein writes ("[PATCH 4/4] xendomains initscript: test for privcmd 
char device"):
> Allow the init script to continue if either the character device or the
> proc file is available.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown

[Ian Jackson]

Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() 
for ~/control/shutdown"):
> [Ian Jackson]
> > Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using 
> > libxl__xs_mkdir()
> > for ~/control/shutdown"):
> > > [Ian Jackson:]
> > > > Maybe it would be easier to rename libxl__xs_mkdir to
> > > > libxl__xs_mknode ?  (It's probably too late to rename XS_MKDIR.)
> > >
> > > There is still the need to set the path to an empty value though, which is
> > not implicitly done by the XS_MKDIR.
> > 
> > Under what circumstances would this path not contain an empty value
> > after XS_MKDIR ?
> 
> In this case I believe you are correct, but my feeling was that
> people reading the code would be lulled into a false sense of
> security that XS_MKDIR always did the right thing to initialize a
> new path.

I'm not sure I follow this argument.  What did you think of my idea
of renaming libxl__xs_mkdir to libxl__xs_mknode ?

Ian.

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

Re: [Xen-devel] [PATCH] MAINTAINERS: mini-os patches should be copied to minios-devel

[Ian Campbell]

On Fri, 2015-11-20 at 15:35 +0100, Samuel Thibault wrote:
> Ian Campbell, on Fri 20 Nov 2015 14:22:11 +, wrote:
> > Signed-off-by: Ian Campbell 
> > Cc: samuel.thiba...@ens-lyon.org
> > Cc: stefano.stabell...@eu.citrix.com
> > Cc: minios-de...@lists.xenproject.org
> 
> Acked-by: Samuel Thibault 

Applied, thanks.


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

Re: [Xen-devel] [PATCH] get_maintainer: fix perl 5.22/5.24 deprecated/incompatible "\C" use

[Ian Campbell]

On Thu, 2015-11-19 at 08:43 +, Olaf Hering wrote:
> From: Joe Perches 
> 
> Perl 5.22 emits a deprecated message when "\C" is used in a regex.  Perl
> 5.24 will disallow it altogether.
> 
> Fix it by using [A-Z] instead of \C.

They aren't quite equivalent, but [A-Z] suffices for the usage here.

>  [ Upstream commit ce8155f7a3d59ce868ea16d8891edda4d865e873 ]
> 
> Signed-off-by: Olaf Hering 

Acked + applied.

> Cc: Ian Campbell 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Keir Fraser 
> Cc: Tim Deegan 
> ---
>  scripts/get_maintainer.pl | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index cc445cd..9fda278 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -277,7 +277,7 @@ open (my $maint, '<', "${xen_path}MAINTAINERS")
>  while (<$maint>) {
>  my $line = $_;
>  
> -if ($line =~ m/^(\C):\s*(.*)/) {
> +if ($line =~ m/^([A-Z]):\s*(.*)/) {
>   my $type = $1;
>   my $value = $2;
>  
> @@ -512,7 +512,7 @@ sub range_is_maintained {
>  
>  for (my $i = $start; $i < $end; $i++) {
>   my $line = $typevalue[$i];
> - if ($line =~ m/^(\C):\s*(.*)/) {
> + if ($line =~ m/^([A-Z]):\s*(.*)/) {
>   my $type = $1;
>   my $value = $2;
>   if ($type eq 'S') {
> @@ -530,7 +530,7 @@ sub range_has_maintainer {
>  
>  for (my $i = $start; $i < $end; $i++) {
>   my $line = $typevalue[$i];
> - if ($line =~ m/^(\C):\s*(.*)/) {
> + if ($line =~ m/^([A-Z]):\s*(.*)/) {
>   my $type = $1;
>   my $value = $2;
>   if ($type eq 'M') {
> @@ -579,7 +579,7 @@ sub get_maintainers {
>  
>   for ($i = $start; $i < $end; $i++) {
>   my $line = $typevalue[$i];
> - if ($line =~ m/^(\C):\s*(.*)/) {
> + if ($line =~ m/^([A-Z]):\s*(.*)/) {
>   my $type = $1;
>   my $value = $2;
>   if ($type eq 'X') {
> @@ -594,7 +594,7 @@ sub get_maintainers {
>   if (!$exclude) {
>   for ($i = $start; $i < $end; $i++) {
>   my $line = $typevalue[$i];
> - if ($line =~ m/^(\C):\s*(.*)/) {
> + if ($line =~ m/^([A-Z]):\s*(.*)/) {
>   my $type = $1;
>   my $value = $2;
>   if ($type eq 'F') {
> @@ -897,7 +897,7 @@ sub find_first_section {
>  
>  while ($index < @typevalue) {
>   my $tv = $typevalue[$index];
> - if (($tv =~ m/^(\C):\s*(.*)/)) {
> + if (($tv =~ m/^([A-Z]):\s*(.*)/)) {
>   last;
>   }
>   $index++;
> @@ -911,7 +911,7 @@ sub find_starting_index {
>  
>  while ($index > 0) {
>   my $tv = $typevalue[$index];
> - if (!($tv =~ m/^(\C):\s*(.*)/)) {
> + if (!($tv =~ m/^([A-Z]):\s*(.*)/)) {
>   last;
>   }
>   $index--;
> @@ -925,7 +925,7 @@ sub find_ending_index {
>  
>  while ($index < @typevalue) {
>   my $tv = $typevalue[$index];
> - if (!($tv =~ m/^(\C):\s*(.*)/)) {
> + if (!($tv =~ m/^([A-Z]):\s*(.*)/)) {
>   last;
>   }
>   $index++;
> @@ -951,7 +951,7 @@ sub get_maintainer_role {
>  
>  for ($i = $start + 1; $i < $end; $i++) {
>   my $tv = $typevalue[$i];
> - if ($tv =~ m/^(\C):\s*(.*)/) {
> + if ($tv =~ m/^([A-Z]):\s*(.*)/) {
>   my $ptype = $1;
>   my $pvalue = $2;
>   if ($ptype eq "S") {
> @@ -1010,7 +1010,7 @@ sub add_categories {
>  
>  for ($i = $start + 1; $i < $end; $i++) {
>   my $tv = $typevalue[$i];
> - if ($tv =~ m/^(\C):\s*(.*)/) {
> + if ($tv =~ m/^([A-Z]):\s*(.*)/) {
>   my $ptype = $1;
>   my $pvalue = $2;
>   if ($ptype eq "L") {
> @@ -1052,7 +1052,7 @@ sub add_categories {
>   if ($name eq "") {
>   if ($i > 0) {
>   my $tv = $typevalue[$i - 1];
> - if ($tv =~ m/^(\C):\s*(.*)/) {
> + if ($tv =~ m/^([A-Z]):\s*(.*)/) {
>   if ($1 eq "P") {
>   $name = $2;
>   $pvalue = format_email($name, $address,
> $email_usename);

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

Re: [Xen-devel] [PATCH] tools/libxl: Drop dead code following calls to libxl__exec()

[Ian Campbell]

On Thu, 2015-11-19 at 12:43 +, Andrew Cooper wrote:
> libxl__exec() doesn't ever return.  Inform the compiler of this, and
> remove all dead code.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Acked + applied, thanks.

> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> ---
>  tools/libxl/libxl.c| 1 -
>  tools/libxl/libxl_aoutils.c| 2 --
>  tools/libxl/libxl_bootloader.c | 1 -
>  tools/libxl/libxl_internal.h   | 2 +-
>  4 files changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 854e957..6ad9e13 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1983,7 +1983,6 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t
> domid, int autopass)
>  }
>  
>  libxl__exec(gc, autopass_fd, -1, -1, args[0], args, NULL);
> -abort();
>  
>   x_fail:
>  GC_FREE;
> diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
> index d5fbc4d..9e493cd 100644
> --- a/tools/libxl/libxl_aoutils.c
> +++ b/tools/libxl/libxl_aoutils.c
> @@ -603,8 +603,6 @@ int libxl__async_exec_start(libxl__async_exec_state
> *aes)
>  /* child */
>  libxl__exec(gc, aes->stdfds[0], aes->stdfds[1],
>  aes->stdfds[2], args[0], args, aes->env);
> -/* notreached */
> -abort();
>  }
>  
>  return 0;
> diff --git a/tools/libxl/libxl_bootloader.c
> b/tools/libxl/libxl_bootloader.c
> index 95dde98..9caf212 100644
> --- a/tools/libxl/libxl_bootloader.c
> +++ b/tools/libxl/libxl_bootloader.c
> @@ -556,7 +556,6 @@ static void bootloader_gotptys(libxl__egc *egc,
> libxl__openpty_state *op)
>  r = login_tty(libxl__carefd_fd(bl->ptys[0].slave));
>  if (r) { LOGE(ERROR, "login_tty failed"); exit(-1); }
>  libxl__exec(gc, -1, -1, -1, bl->args[0], (char **) bl->args,
> env);
> -exit(-1);
>  }
>  
>  /* parent */
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 590870a..58d07cd 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1578,7 +1578,7 @@ _hidden int
> libxl__xenstore_child_wait_deprecated(libxl__gc *gc,
>   */
>  _hidden  void libxl__exec(libxl__gc *gc, int stdinfd, int stdoutfd,
>    int stderrfd, const char *arg0, char *const
> args[],
> -  char *const env[]);
> +  char *const env[]) __attribute__((noreturn));
>  
>  /* from xl_create */
>  
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] build: remove .d files from xen/ on a clean

[Jonathan Creekmore]

Dependency files were getting left behind in the xen
directory (since 8b6ef9c152edceabecc7f90c811cd538a7b7a110),
so append the $(DEPS) to the clean rule that runs in the
hypervisor directory.

CC: Ian Campbell 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
Signed-off-by: Jonathan Creekmore 
---
 xen/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/Makefile b/xen/Makefile
index c556198..fa9cf0a 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -88,7 +88,7 @@ _clean: delete-unfresh-files
$(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
-   rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
$(TARGET)-syms *~ core
+   rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
$(TARGET)-syms *~ core $(DEPS)
rm -f include/asm-*/asm-offsets.h
rm -f .banner
 
-- 
2.4.9 (Apple Git-60)


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

Re: [Xen-devel] [PATCH] build: remove .d files from xen/ on a clean

[Doug Goldstein]

On 11/24/15 11:07 AM, Jan Beulich wrote:
 On 24.11.15 at 17:56,  wrote:
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -88,7 +88,7 @@ _clean: delete-unfresh-files
>>  $(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
>>  $(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
>>  $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
>> -rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
>> $(TARGET)-syms *~ core
>> +rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
>> $(TARGET)-syms *~ core $(DEPS)
> 
> Is this really a problem only in xen/ ? The referenced commit clearly
> introduces "stray" *.d files elsewhere. Also there aren't any source
> files in xen/, so I'd expect $(DEPS) to be empty. Please clarify.
> 
> Jan
> 

Andrew Cooper, myself and the author see the following after running
make && make clean without this patch:

$ ls -la xen
total 124
drwxrwxr-x 10 doug doug  4096 Nov 24 11:09 .
drwxrwxr-x 12 doug doug  4096 Nov 24 10:53 ..
drwxrwxr-x  4 doug doug  4096 Sep 16 10:48 arch
drwxrwxr-x 10 doug doug 12288 Nov 24 11:09 common
-rw-rw-r--  1 doug doug 19116 Jul 31 09:55 COPYING
drwxrwxr-x  2 doug doug  4096 Nov 24 11:09 crypto
drwxrwxr-x  8 doug doug  4096 Nov 24 11:09 drivers
drwxrwxr-x 13 doug doug  4096 Nov 24 11:09 include
-rw-rw-r--  1 doug doug   502 Nov 24 10:53 Kconfig
-rw-rw-r--  1 doug doug  8639 Nov 24 10:53 Makefile
-rw-rw-r--  1 doug doug  5840 Nov 24 10:55 Rules.mk
drwxrwxr-x  3 doug doug  4096 Nov 24 10:53 scripts
drwxrwxr-x  2 doug doug  4096 Nov 24 11:09 tools
-rw-rw-r--  1 doug doug   279 Nov 24 11:00 ..xen.efi.0r.o.d
-rw-rw-r--  1 doug doug   374 Nov 24 11:00 ..xen.efi.0s.o.d
-rw-rw-r--  1 doug doug   279 Nov 24 11:00 ..xen.efi.1r.o.d
-rw-rw-r--  1 doug doug   374 Nov 24 11:00 ..xen.efi.1s.o.d
-rw-rw-r--  1 doug doug   374 Nov 24 11:00 ..xen-syms.0.o.d
-rw-rw-r--  1 doug doug   374 Nov 24 11:00 ..xen-syms.1.o.d
drwxrwxr-x  3 doug doug  4096 Nov 24 11:09 xsm


-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Xen Security Advisory 163 - virtual PMU is unsupported

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Xen Security Advisory XSA-163

  virtual PMU is unsupported

ISSUE DESCRIPTION
=

The Virtual Performance Measurement Unit feature has been documented
as unsupported, so far only on Intel CPUs.  Further issues have been
found or are suspected which would also (or exclusively) affect AMD
CPUs.  We believe that the functionality is mostly intended for
non-production use anyway.  Therefore this functionality is hereby
documented as generally unsupported security-wise.

IMPACT
==

Use of the feature may have unknown effects, ranging from information
leaks through Denial of Service to privilege escalation.

VULNERABLE SYSTEMS
==

Only systems which enable the VPMU feature are affected.  That is,
only systems with a `vpmu' setting on the hypervisor command line.

Xen versions from 3.3 onwards are affected.

Only x86 systems are affected.  ARM systems do not currently implement
vPMU and are therefore currently unaffected; should this functionality
be added to ARM in the future it would be covered by this exclusion.

In Xen versions prior to 4.6 only HVM guests can take advantage of
this unsupported functionality.  In Xen versions from 4.6 onwards all
guest kinds can use this unsupported functionality.

MITIGATION
==

Not enabling vPMU support (by omitting the "vpmu" hypervisor command
line option) will avoid using and exposing the unsupported
functionality.

RESOLUTION
==

Applying the attached patch documents the situation.  The patch does
not fix any security issues.

xsa163.patch   xen-unstable

$ sha256sum xsa163*
b9185a45a41f31e7c2f85b79a669b8b1dbf00c6b40a79b00c779b344ccab45b7  xsa163.patch
$
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJWVJqRAAoJEIP+FMlX6CvZba8H/23BreIs2Gxkh+9Jty8EEMdp
nk3hSpEgxIb101XsbZ4JNwMO8QqBoTi1Bt0+k4bnjdRsU1G/vImacaN9LlefmLJc
jn3n4Ce9ODGQvCEp1LPwWQusduFhMUIaUK6cwB2LclYxUnxCgUpLBFReOp9QIbgZ
Bv+rrw9gcNb8zUKT53FZ7bOApRoU28rSFX1XE72ELPDdGbpTVXxlvQZtKsQY7N7O
Se1COml0MDhufWRf3SNxO2MmqZsg43fsjvJaJgGoXE+4gslcLBMjiwgoUDX2k9CG
Pi4M5uLNLxXJZkgbo1qi8ueQB9yck6tMg+o6f3wDFz28SFfu8/D2szXGOblpE5w=
=2Wqz
-END PGP SIGNATURE-


xsa163.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/3] libxl: re-name libxl__xs_write() to libxl__xs_printf()...

[Ian Campbell]

On Mon, 2015-11-16 at 17:15 +, Ian Jackson wrote:
> Paul Durrant writes ("[PATCH v2 1/3] libxl: re-name libxl__xs_write() to
> libxl__xs_printf()..."):
> > ...to denote what it actually does.
> > 
> > The name libxl__xs_write() suggests something taking a buffer and
> > length,
> > akin to write(2), whereas the semantics of the function are actually
> > more
> > akin to printf(3).
> > 
> > This patch is a textual substitution of libxl__xs_write with
> > libxl__xs_printf with some associated formatting fixes.
> 
> Acked-by: Ian Jackson 

Did you have opinions on the other two patches and/or shall I just apply
this one in the meantime?

Ian.


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

[Xen-devel] [PATCH] x86/kexec: Hide more kexec infrastructure behind CONFIG_KEXEC

[Andrew Cooper]

Experimenting with the kconfig series showed that various bits of kexec
infrastructure were still being unconditionally included.  Make them
conditional on CONFIG_KEXEC.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: David Vrabel 
CC: Doug Goldstein 

This patch is independent of the kconfig series.
---
 xen/arch/x86/x86_64/Makefile | 4 ++--
 xen/arch/x86/xen.lds.S   | 4 
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/x86_64/Makefile b/xen/arch/x86/x86_64/Makefile
index d5af722..5b54c16 100644
--- a/xen/arch/x86/x86_64/Makefile
+++ b/xen/arch/x86/x86_64/Makefile
@@ -3,7 +3,7 @@ subdir-y += compat
 obj-bin-y += entry.o
 obj-bin-y += gpr_switch.o
 obj-y += traps.o
-obj-y += machine_kexec.o
+obj-$(CONFIG_KEXEC) += machine_kexec.o
 obj-y += pci.o
 obj-y += acpi_mmcfg.o
 obj-y += mmconf-fam10h.o
@@ -12,6 +12,6 @@ obj-y += mmconfig-shared.o
 obj-y += domain.o
 obj-y += cpu_idle.o
 obj-y += cpufreq.o
-obj-bin-y += kexec_reloc.o
+obj-bin-$(CONFIG_KEXEC) += kexec_reloc.o
 
 obj-$(crash_debug)   += gdbstub.o
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 6553cff..e18e08f 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -220,5 +220,9 @@ SECTIONS
 ASSERT(__image_base__ > XEN_VIRT_START ||
_end <= XEN_VIRT_END - NR_CPUS * PAGE_SIZE,
"Xen image overlaps stubs area")
+
+#ifdef CONFIG_KEXEC
 ASSERT(kexec_reloc_size - kexec_reloc <= PAGE_SIZE, "kexec_reloc is too large")
+#endif
+
 ASSERT((cpu0_stack & (STACK_SIZE - 1)) == 0, "cpu0_stack misaligned")
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] cxenstored: correct calculation of data/space in the ring

[Ian Campbell]

On Mon, 2015-11-16 at 18:36 +, Wei Liu wrote:

Ian, were your concerns addressed by this threadlet?

> On Mon, Nov 16, 2015 at 06:09:54PM +, Ian Jackson wrote:
> > Andrew Cooper writes ("Re: [PATCH] cxenstored: correct calculation of
> > data/space in the ring"):
> > > On 16/11/15 18:01, Ian Jackson wrote:
> > > > Wei Liu writes ("[PATCH] cxenstored: correct calculation of
> > > > data/space in the ring"):
> > > > > The cxenstored implementation can't handle cross ring boundary
> > > > > read and
> > > > > write. It gets aways with buggy behaviour because upper layer
> > > > > won't
> > > > > sleep when short-write or short-read occurs.
> > > > I don't understand why you think this is a bug.
> > > 
> > > It is exactly the same bug as I fixed in c/s 8a2c11f8
> > > 
> > > The short reads/writes themselves aren't inherently a problem.  They
> > > are
> > > genuine signals that the server should wait for the client to
> > > produce/consume more data.
> > > 
> > > However, the low level functions erroneously return a short
> > > read/write
> > > when hitting the ring boundary when there is actually more
> > > space/data. 
> > > This causes a protocol stall as the server incorrectly believes that
> > > the
> > > client has the next action to perform.
> > 
> > If I understand Wei correctly you are contradicting him.  The `upper
> > layer' in question is inside the C xenstored so there is no protocol
> > stall.
> > 
> 
> There is no protocol stall for now. But the code that controls whether
> to sleep or not can change (however unlikely). And it would be hard to
> debug such bug as the effort for debugging stubdom / oxenstored already
> demonstrated.
> 
> IMO short-writing and short-reading when there is still space / data is
> a bug in its own right. We might as well just fix it before we get hit
> again.
> 
> Wei.
> 
> > (I haven't peered at the code...)
> > 
> > Ian.

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

Re: [Xen-devel] [PATCH 2/4] x86/PoD: Identify when a domain has already been killed from PoD exhaustion

[George Dunlap]

On Mon, Nov 2, 2015 at 2:32 PM, Andrew Cooper  wrote:
> On 02/11/15 14:07, George Dunlap wrote:
>> On 30/10/15 18:33, Andrew Cooper wrote:
>>> p2m_pod_demand_populate() can be entered repeatedly during a single path
>>> through the hypervisor, e.g. on a toolstack batch map operation.
>>>
>>> The domain might be crashed, but the interface currently lacks a way of
>>> passing an error back through the generic p2m layer.
>>>
>>> Longterm the p2m layer needs reworking to allow errors to be returned, but 
>>> in
>>> the short term, avoid repeatedly re-sweeping the domain after it has already
>>> been crashed from PoD exhaustion.
>>>
>>> Signed-off-by: Andrew Cooper 
>>> ---
>>> CC: Jan Beulich 
>>> CC: George Dunlap 
>>> ---
>>>  xen/arch/x86/mm/p2m-pod.c | 3 ++-
>>>  xen/include/asm-x86/p2m.h | 2 ++
>>>  2 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
>>> index be15cf3..6fb054f 100644
>>> --- a/xen/arch/x86/mm/p2m-pod.c
>>> +++ b/xen/arch/x86/mm/p2m-pod.c
>>> @@ -1048,7 +1048,7 @@ p2m_pod_demand_populate(struct p2m_domain *p2m, 
>>> unsigned long gfn,
>>>  /* This check is done with the pod lock held.  This will make sure that
>>>   * even if d->is_dying changes under our feet, p2m_pod_empty_cache()
>>>   * won't start until we're done. */
>>> -if ( unlikely(d->is_dying) )
>>> +if ( unlikely(d->is_dying) || p2m->pod.dead )
>> So after getting lost in a maze of twisty passages, it looks like
>> "d->is_dying" might be the wrong thing to check here.  d->is_dying is
>> *only* set, AFAICT, in two places:
>>  - in domain_kill(), which is only called for XEN_DOMCTL_destroydomain
>>  - in domain_create(), if the creation failed for some reason.
>
> d->is_dying indicates that the domains resources are starting to be torn
> down.  It is the correct check here.
>
>>
>> Would it make more sense to check d->is_shutting_down instead?
>
> A domain resume hypercall can clear d->is_shutting_down, making it an
> inappropriate check.

Well if domain_resume() cleared it, then the sweep would be run one
more time and then crashed again, which wouldn't hurt too much.

The real reason d->is_shutting_down is an inappropriate check is that
there are lots of *other* reasons why a domain might shut down -- or
even crash -- which should not prevent p2m sweeps from happening on
the domain.  The only legitimate reason to do no more sweeps, other
than the final tear-down, is a failed PoD sweep.

So I think I've convinced myself that something like this is
(unfortunately) necessary.

I do think it should have a more descriptive name -- "out_of_memory"
or "sweep_failed" would be better than "dead".

In some imaginary future where p2m functions have proper error
handling, one could imagine the toolstack deciding to repopulate the
PoD cache and clear this flag, allowing the domain to continue rather
than crashing it.

Thanks,
 -George

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

Re: [Xen-devel] [PATCH MINI-OS] Add a .gitignore

[Ian Campbell]

On Mon, 2015-11-23 at 17:35 +0100, Samuel Thibault wrote:
> Ian Campbell, on Mon 23 Nov 2015 16:34:31 +, wrote:
> > Signed-off-by: Ian Campbell 
> 
> Acked-by: Samuel Thibault 

Thanks, applied along with a corresponding update to
xen.git's MINIOS_UPSTREAM_REVISION.

Ian.

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

Re: [Xen-devel] [PATCH] xen/arm: use masking operation instead of test_bit for MCSF bits

[Ian Campbell]

On Thu, 2015-11-19 at 12:46 +, Julien Grall wrote:
> This is a follow of commit 90f2e2a307fc6a6258c39cc87b3b2bf9441c0fa7 "use
> masking operation instead of test_bit for MCSF bits" where the ARM
> changes were missing.
> 
> Signed-off-by: Julien Grall 

Acked + applied.

> ---
>  xen/arch/arm/domain.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 880d0a6..1b0f9eb 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -327,7 +327,7 @@ void hypercall_cancel_continuation(void)
>  struct cpu_user_regs *regs = guest_cpu_user_regs();
>  struct mc_state *mcs = >mc_state;
>  
> -if ( test_bit(_MCSF_in_multicall, >flags) )
> +if ( mcs->flags & MCSF_in_multicall )
>  {
>  __clear_bit(_MCSF_call_preempted, >flags);
>  }
> @@ -352,7 +352,7 @@ unsigned long hypercall_create_continuation(
>  
>  va_start(args, format);
>  
> -if ( test_bit(_MCSF_in_multicall, >flags) )
> +if ( mcs->flags & MCSF_in_multicall )
>  {
>  __set_bit(_MCSF_call_preempted, >flags);
>  

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

Re: [Xen-devel] [PATCH] Config.mk: Update SEABIOS_UPSTREAM_TAG to rel-1.9.0

[Ian Campbell]

On Wed, 2015-11-18 at 12:02 +, Wei Liu wrote:
> On Wed, Nov 18, 2015 at 12:01:33PM +, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell 
> 
> Acked-by: Wei Liu 

Thanks, applied.


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

Re: [Xen-devel] [PATCHv5] 00/28] Kconfig conversion

[Doug Goldstein]

On 11/24/15 9:58 AM, Andrew Cooper wrote:
> On 20/11/15 19:09, Doug Goldstein wrote:
>> The following series is a follow on to the Kconfig conversion patch series.
>> There are still more components to convert however this is the bare minimal
>> to get everything working and get the options out of the existing makefiles.
>>
>> The CONFIG_HAS_ variables are there to match the behavior of the Linux
>> CONFIG_HAVE_ variables. The purpose is to say that this hardware/profile/env
>> supports this option while the CONFIG_ variable states that this option was
>> requested on/off by user intervention.
>>
>> The UARTs are now uniformly prefixed as CONFIG_UART_ and dropping most of the
>> CONFIG_HAS_ labeling for them. This means they are now user selectable as
>> requested by Julien Grall in the prior review. The question I've got is
>> the old config was just for selecting defaults. Users could enable the OMAP
>> UART for arm64 for example but I'm not sure if that's valid. Currently this
>> patchset makes those UARTs not user selectable if they were not previously
>> defaulted on. But I would like some feedback on this if possible.
>>
>> Ultimately my goal is to allow for more parts of the hypervisor to be turned
>> off at compile time and potentially make it easier to include more
>> experimental features by others which can be turned off by default. Also to
>> provide the one true location for all possible knobs in the source code.
>>
>> The patch series can be grabbed at:
>> https://github.com/cardoe/xen/tree/kconfig_v5
> 
> Having had a play with this, everything appears to be in order.
> 
> Acked-by: Andrew Cooper 
> Tested-by: Andrew Cooper 
> 
> Thankyou very much for your work here.
> 

There's now a conflict in staging due to the NUMA changes. Its a simple
conflict and does not affect the resultant build. I will post a v6 to
resolve the conflict to make it easier to merge.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] build: remove .d files from xen/ on a clean

[Jan Beulich]

>>> On 24.11.15 at 17:56,  wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -88,7 +88,7 @@ _clean: delete-unfresh-files
>   $(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
>   $(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
>   $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
> - rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
> $(TARGET)-syms *~ core
> + rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi 
> $(TARGET)-syms *~ core $(DEPS)

Is this really a problem only in xen/ ? The referenced commit clearly
introduces "stray" *.d files elsewhere. Also there aren't any source
files in xen/, so I'd expect $(DEPS) to be empty. Please clarify.

Jan


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

Re: [Xen-devel] [PATCH v2] xen: sched: fix (ACPI S3) resume with cpupools with different schedulers.

[Dario Faggioli]

On Tue, 2015-11-24 at 15:32 +, George Dunlap wrote:
> On 13/11/15 17:10, Dario Faggioli wrote:
> > 
> > During suspend, the pCPUs are not removed from their
> > pools with the standard procedure (which would involve
> > schedule_cpu_switch(). During resume, they:
> >  1) are assigned to the default cpupool (CPU_UP_PREPARE
> > phase);
> >  2) are moved to the pool they were in before suspend,
> > via schedule_cpu_switch() (CPU_ONLINE phase)
> > 
> > During resume, scheduling (even if just the idle loop)
> > can happen right after the CPU_STARTING phase(before
> > CPU_ONLINE), i.e., before the pCPU is put back in its
> > pool.
> 
> So why are we restoring scheduling stuff during CPU_STARTING, but
> only
> putting cpus back in their pools at CPU_ONLINE?
> 
Indeed. Much worse: we open the CPU for scheduling before it's back in
its pool (this is all what this bug is about!). this never made much
sense to me.

> At some point I think I knew the answer to this, but it's worth
> revisiting it.
> 
So, I once had a look, and tried shuffling things around, in a way in
which the order made more sense to me, but it does not work 'out of the
box'.

The issues have, AFAICR, to do with the fact that memory allocations
(for the per-pCPU scheduling data, need IRQs enabled (which means
CPU_UP_PREPARE, much rather than CPU_STARTING, is what we want) on the
scheduling side, and other data that need to be ready and initialized
in order to setup cpupools (e.g., per_cpu(cpupool, cpu)).

As said, I don't recall all the details, sorry. I recall thinking that
a solution would involve putting the CPU in the pool earlier, but that
in turn calls for other work (e.g., tweaking the priorities of the
callbacks for avoiding races).

It's on my list of things to do, but not with super high priority. Are
you saying that we should drop this patch, and do the callback
reordering/refactoring first?

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



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

Re: [Xen-devel] [PATCH] x86/kexec: Hide more kexec infrastructure behind CONFIG_KEXEC

[David Vrabel]

On 24/11/15 16:23, Andrew Cooper wrote:
> Experimenting with the kconfig series showed that various bits of kexec
> infrastructure were still being unconditionally included.  Make them
> conditional on CONFIG_KEXEC.

Reviewed-by: David Vrabel 

David

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

Re: [Xen-devel] [PATCH XEN v5 07/23] tools: Refactor /dev/xen/gnt{dev, shr} wrappers into libxengnttab.

[Daniel De Graaf]

On 16/11/15 07:30, Ian Campbell wrote:

On Fri, 2015-11-13 at 15:38 -0500, Daniel De Graaf wrote:

On 13/11/15 10:02, Ian Campbell wrote:

On Wed, 2015-11-11 at 15:03 +, Ian Jackson wrote:

Ian Campbell writes ("[PATCH XEN v5 07/23] tools: Refactor
/dev/xen/gnt{dev,shr} wrappers into libxengnttab."):

libxengnttab will provide a stable API and ABI for accessing the
grant table devices.

[...]

+/**
+ * Memory maps a grant reference from one domain to a local
address
range.
+ * Mappings should be unmapped with xengnttab_munmap. If
notify_offset
or
+ * notify_port are not -1, this version will attempt to set up an
unmap
+ * notification at the given offset and event channel. When the
page
is
+ * unmapped, the byte at the given offset will be zeroed and a
wakeup
will be
+ * sent to the given event channel.  Logs errors.


What happens if the unmap notification cannot be set up ?

Also "when the page is unmapped" makes it sound like you mean
xengnttab_munmap but actually I think this is when the grant is
withdrawn by the grantor ?

If the grant is withdrawn by the grantor, does the page become
unuseable immediately ?  If so, how can anyone ever use this safely ?


Daniel, could you answer these ones please.


This is intended to allow the kernel to send a close-request notification
when the application that allocated the grant page exits without calling
a proper shutdown (i.e. it crashes, calls _exit, calls execve, etc).


That is the kernel of the grantor or grantee process? It sounds like
grantor tells grantee (who would then be expected to unmap?)


The kernel providing gntalloc is the one that sends the notification, since
the other domain (gntdev) must take action to unmap the page.


Who actually does the unmap, the grantee process or their kernel? I suppose
the process, which is expected to be watching for the notification and is
required to do the unmap itself. IOW the "munmap notification" is a request
to please munmap, not a notification that something has been unmapped out
from beneath the calling process.


Correct.  The remote process actually does the unmap; there is no back-channel
available to notify the kernel of the other side directly (and setting one up
would usually be a waste of resources).


What happens if the unmap notification cannot be set up? Does the call fail
(and unmap what it has done) or does it succeed?


The only reason for the setup to fail is if an invalid event channel or offset
is specified.  It looks like this causes a new mapping to fail (it is freed).


I think the answer to the other two questions depend on the clarifications
above, but I think it is the case that nothing is unmapped automatically,
all that this does is give you a result from evtchn_poll etc with the
expectation that the caller will call xengnttab_munmap in a controlled way
by themselves.


Without this signal, the kernel has no way to request that the mapper of
the page release it, and since Xen has no grant revocation mechanism, the
page will likely be tied up until the process on the other side is told to
release the page through some other method.


+/*
+ * Creates and shares pages with another domain.
+ *

...

+void *xengntshr_share_pages(xengntshr_handle *xgs, uint32_t domid,
+int count, uint32_t *refs, int
writable);


Can this fail ?  Can it partially succeed ?


Daniel?


It can fail if you are out of pages to grant (there is a module parameter
that can be adjusted via sysfs for the maximum), or in the unlikely case
that the kernel itself is out of room in its grant mapping table (or if
the syscall itself encounters -ENOMEM).


Does it either completely succeed or undo partial work, or does it return
partial success somehow?


The limit is checked (and the current count updated) prior to making any
changes.




+/*
+ * Creates and shares a page with another domain, with unmap
notification.
+ *
+ * @parm xgs a handle to an open grant sharing instance
+ * @parm domid the domain to share memory with
+ * @parm refs the grant reference of the pages (output)
+ * @parm writable true if the other domain can write to the page
+ * @parm notify_offset The byte offset in the page to use for
unmap
+ * notification; -1 for none.
+ * @parm notify_port The event channel port to use for unmap
notify,
or -1
+ * @return local mapping of the page
+ */
+void *xengntshr_share_page_notify(xengntshr_handle *xgs, uint32_t
domid,


What is this `unmap notification' ?


Daniel?


As mentioned above, it is a way for the kernel to request for the other
side to unmap a page.  It is probably easiest to understand if looking
at the libvchan driver: one byte of the page is a "status" byte, and
when the side using xengntshr exits or dies, this byte is set to zero
and the event channel is notified.  When the peer is woken by the notify
and sees the state byte set to zero, it removes its own mappings so that
the shared pages can be freed.


This is the sending end of the 

[Xen-devel] [iGVT-g] XenGT for PV guest

[Oleksii Kurochko]

Hi all,

I am trying to enable XenGT for Android on board vtc1010 in PV mode.
Used:
- Intel® Atom™ processor E3827
- Xen 4.3.1 on branch "byt_experiment".
- dom0: ubuntu 14-04 with linux vgt 3.11.6-vgt+ kernel version
- domU: Android-IA 5.1 with 3.11.6-vgt+ (added Android configs)  kernel
version

vgt was successfully started in dom0.
vgt does not start in domU. After registration of pci dev in i915_init()
there is no call of i915_pci_driver.probe(). Inte HD Graphics is on pci
bus, but it is not passthrough to domU. When tried to passtrough it to domU
than dom0 crashes in drm_framebuffer_remove(). More than that it is not my
case because of intel hd graphics need to be working in dom0 and domU.

So could U give advice how to probe i915 driver in domU?

With best,
 Oleksii


-- 
Oleksii Kurochko | Embedded Dev
GlobalLogic
www.globallogic.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 2/3] libxl: check for underlying xenstore operation failure...

[Ian Jackson]

(Added CC to Ian C and Wei.)

Paul Durrant writes ("[Xen-devel] [PATCH v2 2/3] libxl: check for underlying 
xenstore operation failure..."):
> ...in libxl__xs_writev_perms() and libxl__xs_printf()

Thanks for looking at this.


> ERROR_FAIL is returned when any underlying operation fails. This is a
> semantic change in the case of a vasprintf() failure in libxl__xs_printf(),
> but appears to be better than returning a hardcoded -1.

This is what libxl__alloc_failed is for.  But, surely it would be
better to replace the call to vasprintf with one to libxl__vsprintf ?

>  path = libxl__sprintf(gc, "%s/%s", dir, kvs[i]);
>  if (path && kvs[i + 1]) {
>  int length = strlen(kvs[i + 1]);
> -xs_write(ctx->xsh, t, path, kvs[i + 1], length);
> -if (perms)
> -xs_set_permissions(ctx->xsh, t, path, perms, num_perms);
> +if (!xs_write(ctx->xsh, t, path, kvs[i + 1], length))
> +return ERROR_FAIL;

This is a good change semantically but I'm not keen on this error
handling style.  CODING_STYLE says:

  * Function calls which might fail (ie most function calls) are
handled by putting the return/status value into a variable, and
then checking it in a separate statement:
char *dompath = libxl__xs_get_dompath(gc, bl->domid);
if (!dompath) { rc = ERROR_FAIL; goto out; }

In this case the libxenstore return value variable should be called
`r', I think.  CODING_STYLE says:

int r; /* the return value from a system call (or libxc call) */

> +if (perms &&
> +!xs_set_permissions(ctx->xsh, t, path, perms, num_perms))
> +return ERROR_FAIL;

And this is worse, I'm afraid.  Nested ifs are not expensive and there
is no risk of overloading the compiler.  So I would like to see this:

  if (perms) {
  r = xs_set ...
  if (r) ...
  }


I won't insist on you changing the error exits to use `goto out',
although I tend to think that would be better.


Thanks,
Ian.

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