Re: [Xen-devel] [PATCHv3 2/2] xenfs: replace xenbus and privcmd with symlinks

[Juergen Gross]

On 28/06/16 20:06, David Vrabel wrote:
> /proc/xen/xenbus does not work correctly.  A read blocked waiting for
> a xenstore message holds the mutex needed for atomic file position
> updates.  This blocks any writes on the same file handle, which can
> deadlock if the write is needed to unblock the read.
> 
> /proc/xen/xenbus is supposed to be identical to the character device
> /dev/xen/xenbus so replace the file with a symlink.
> 
> Similarly, replace /proc/xen/privcmd with a symlink since it should be
> the same as /dev/xen/privcmd.
> 
> Signed-off-by: David Vrabel 
> ---
> v2:
> - remove unneeded includes
> ---

I think you should make xen_xenbus_fops and xen_privcmd_fops static
now that they are no longer referenced by super.c


Juergen

>  drivers/xen/xenfs/super.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
> index 8559a71..0f2e2cd 100644
> --- a/drivers/xen/xenfs/super.c
> +++ b/drivers/xen/xenfs/super.c
> @@ -18,8 +18,6 @@
>  #include 
>  
>  #include "xenfs.h"
> -#include "../privcmd.h"
> -#include "../xenbus/xenbus_comms.h"
>  
>  #include 
>  
> @@ -45,16 +43,16 @@ static const struct file_operations capabilities_file_ops 
> = {
>  static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
>  {
>   static struct tree_descr xenfs_files[] = {
> - [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
> + [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
> },
>   { "capabilities", _file_ops, S_IRUGO },
> - { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
> + { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
>   {""},
>   };
>  
>   static struct tree_descr xenfs_init_files[] = {
> - [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
> + [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
> },
>   { "capabilities", _file_ops, S_IRUGO },
> - { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
> + { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
>   { "xsd_kva", _kva_file_ops, S_IRUSR|S_IWUSR},
>   { "xsd_port", _port_file_ops, S_IRUSR|S_IWUSR},
>  #ifdef CONFIG_XEN_SYMS
> 


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

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

[Tian, Kevin]

> From: Lan, Tianyu
> Sent: Sunday, June 26, 2016 9:43 PM
> 
> On 6/8/2016 4:11 PM, Tian, Kevin wrote:
> > It makes sense... I thought you used this security issue against
> > placing vIOMMU in Qemu, which made me a bit confused earlier. :-)
> >
> > We are still thinking feasibility of some staging plan, e.g. first
> > implementing some vIOMMU features w/o dependency on root-complex in
> > Xen (HVM only) and then later enabling full vIOMMU feature w/
> > root-complex in Xen (covering HVMLite). If we can reuse most code
> > between two stages while shorten time-to-market by half (e.g. from
> > 2yr to 1yr), it's still worthy of pursuing. will report back soon
> > once the idea is consolidated...
> >
> > Thanks Kevin
> 
> 
> After discussion with Kevin, we draft a staging plan of implementing
> vIOMMU in Xen based on Qemu host bridge. Both virtual devices and
> passthough devices use one vIOMMU in Xen. Your comments are very
> appreciated.

The rationale here is to separate BIOS structures from actual vIOMMU
emulation. vIOMMU will be always emulated in Xen hypervisor, regardless of 
where Q35 emulation is done or whether it's HVM or HVMLite. The staging
plan is more for the BIOS structure reporting which is Q35 specific. For now
we first target Qemu Q35 emulation, with a set of vIOMMU ops introduced
as Tianyu listed below to help interact between Qemu and Xen. Later when 
Xen Q35 emulation is ready, the reporting can be done in Xen.

The main limitation of this model is on DMA emulation of Qemu virtual
devices, which needs to query Xen vIOMMU for every virtual DMA. It is 
possibly fine for virtual devices which are normally not for performance 
critical usages. Also there may be some chance to cache some translations
within Qemu like thru ATS (may not worthy of it though...).

> 
> 1. Enable Q35 support in the hvmloader.
> In the real world, VTD support starts from Q35 and OS may have such
> assumption that VTD only exists on the Q35 or newer platform.
> Q35 support seems necessary for vIOMMU support.
> 
> In regardless of Q35 host bridge in the Qemu or Xen hypervisor,
> hvmloader needs to be compatible with Q35 and build Q35 ACPI tables.
> 
> Qemu already has Q35 emulation and so the hvmloader job can start with
> Qemu. When host bridge in Xen is ready, these changes also can be reused.
> 
> 2. Implement vIOMMU in Xen based on Qemu host bridge.
> Add a new device type "Xen iommu" in the Qemu as a wrapper of vIOMMU
> hypercalls to communicate with Xen vIOMMU.
> 
> It's in charge of:
> 1) Query vIOMMU capability(E,G interrupt remapping, DMA translation, SVM
> and so on)
> 2) Create vIOMMU with predefined base address of IOMMU unit regs
> 3) Notify hvmloader to populate related content in the ACPI DMAR
> table.(Add vIOMMU info to struct hvm_info_table)
> 4) Deal with DMA translation request of virtual devices and return
> back translated address.
> 5) Attach/detach hotplug device from vIOMMU
> 
> 
> New hypercalls for vIOMMU that are also necessary when host bridge in Xen.
> 1) Query vIOMMU capability
> 2) Create vIOMMU(IOMMU unit reg base as params)
> 3) Virtual device's DMA translation
> 4) Attach/detach hotplug device from VIOMMU

We don't need 4). Hotplug device is automatically handled by the vIOMMU
with INCLUDE_ALL flag set (which should be the case if we only have one
vIOMMU in Xen). We don't need further notify this event to Xen vIOMMU.

And once we have Xen Q35 emulation in place, possibly only 3) is required
then.

> 
> 
> All IOMMU emulations will be done in Xen
> 1) DMA translation
> 2) Interrupt remapping
> 3) Shared Virtual Memory (SVM)

Please let us know your thoughts. If no one has explicit objection based 
on above rough idea, we'll go to write the high level design doc for more
detail discussion.

Thanks
Kevin

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

[Xen-devel] [ovmf test] 96339: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 94748
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

version targeted for testing:
 ovmf 631c942726640615d53e4a358c078bb915e1bdd4
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z   35 days
Failing since 94750  2016-05-25 03:43:08 Z   34 days   61 attempts
Testing same since96339  2016-06-28 09:46:14 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Chao Zhang 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Darbin Reyes 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Fu Siyuan 
  Fu, Siyuan 
  Gary Li 
  Gary Lin 
  Giri P Mudusuru 
  Hao Wu 
  Hegde Nagaraj P 
  hegdenag 
  Heyi Guo 
  Jan D?bro? 
  Jan Dabros 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Joe Zhou 
  Jordan Justen 
  Katie Dellaquila 
  Laszlo Ersek 
  Liming Gao 
  Lu, ShifeiX A 
  lushifex 
  Marcin Wojtas 
  Marvin H?user 
  Marvin Haeuser 
  Maurice Ma 
  Michael Zimmermann 
  Qiu Shumin 
  Ruiyu Ni 
  Ryan Harkin 
  Sami Mujawar 
  Satya Yarlagadda 
  Sriram Subramanian 
  Star Zeng 
  Sunny Wang 
  Tapan Shah 
  Thomas Palmer 
  Yarlagadda, Satya P 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 

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



sg-report-flight on osstest.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 7351 lines long.)

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

[Xen-devel] [PATCH] x86/cpuid: AVX-512 Feature Detection

[Luwei Kang]

AVX-512 is an extention of AVX2. Its spec can be found at:
https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
This patch detects AVX-512 features by CPUID.

Signed-off-by: Luwei Kang 
---
 xen/arch/x86/hvm/hvm.c  | 14 ++
 xen/arch/x86/traps.c| 22 +-
 xen/include/public/arch-x86/cpufeatureset.h |  9 +
 xen/tools/gen-cpuid.py  |  4 
 4 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c89ab6e..7696b1e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3474,6 +3474,20 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
   xstate_sizes[_XSTATE_BNDCSR]);
 }
 
+if ( _ebx & cpufeat_mask(X86_FEATURE_AVX512F) )
+{
+xfeature_mask |= XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM;
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_OPMASK] +
+  xstate_sizes[_XSTATE_OPMASK]);
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_ZMM] +
+  xstate_sizes[_XSTATE_ZMM]);
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_HI_ZMM] +
+  xstate_sizes[_XSTATE_HI_ZMM]);
+}
+
 if ( _ecx & cpufeat_mask(X86_FEATURE_PKU) )
 {
 xfeature_mask |= XSTATE_PKRU;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 767d0b0..8fb697b 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -975,7 +975,7 @@ void pv_cpuid(struct cpu_user_regs *regs)
 
 switch ( leaf )
 {
-uint32_t tmp, _ecx;
+uint32_t tmp, _ecx, _ebx;
 
 case 0x0001:
 c &= pv_featureset[FEATURESET_1c];
@@ -1157,6 +1157,26 @@ void pv_cpuid(struct cpu_user_regs *regs)
xstate_sizes[_XSTATE_YMM]);
 }
 
+if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
+domain_cpuid(currd, 7, 0, , &_ebx, , );
+else
+cpuid_count(7, 0, , &_ebx, , );
+_ebx &= pv_featureset[FEATURESET_7b0];
+
+if ( _ebx & cpufeat_mask(X86_FEATURE_AVX512F) )
+{
+xfeature_mask |= XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM;
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_OPMASK] +
+  xstate_sizes[_XSTATE_OPMASK]);
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_ZMM] +
+  xstate_sizes[_XSTATE_ZMM]);
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_HI_ZMM] +
+  xstate_sizes[_XSTATE_HI_ZMM]);
+}
+
 a = (uint32_t)xfeature_mask;
 d = (uint32_t)(xfeature_mask >> 32);
 c = xstate_size;
diff --git a/xen/include/public/arch-x86/cpufeatureset.h 
b/xen/include/public/arch-x86/cpufeatureset.h
index 39acf8c..9320c9e 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -206,15 +206,24 @@ XEN_CPUFEATURE(PQM,   5*32+12) /*   Platform QoS 
Monitoring */
 XEN_CPUFEATURE(NO_FPU_SEL,5*32+13) /*!  FPU CS/DS stored as zero */
 XEN_CPUFEATURE(MPX,   5*32+14) /*S  Memory Protection Extensions */
 XEN_CPUFEATURE(PQE,   5*32+15) /*   Platform QoS Enforcement */
+XEN_CPUFEATURE(AVX512F,   5*32+16) /*A  AVX-512 Foundation Instructions */
+XEN_CPUFEATURE(AVX512DQ,  5*32+17) /*A  AVX-512 Doubleword & Quadword 
Instrs */
 XEN_CPUFEATURE(RDSEED,5*32+18) /*A  RDSEED instruction */
 XEN_CPUFEATURE(ADX,   5*32+19) /*A  ADCX, ADOX instructions */
 XEN_CPUFEATURE(SMAP,  5*32+20) /*S  Supervisor Mode Access Prevention 
*/
+XEN_CPUFEATURE(AVX512IFMA,5*32+21) /*A  AVX-512 Integer Fused Multiply Add 
*/
 XEN_CPUFEATURE(CLFLUSHOPT,5*32+23) /*A  CLFLUSHOPT instruction */
 XEN_CPUFEATURE(CLWB,  5*32+24) /*A  CLWB instruction */
+XEN_CPUFEATURE(AVX512PF,  5*32+26) /*A  AVX-512 Prefetch Instructions */
+XEN_CPUFEATURE(AVX512ER,  5*32+27) /*A  AVX-512 Exponent & Reciprocal 
Instrs */
+XEN_CPUFEATURE(AVX512CD,  5*32+28) /*A  AVX-512 Conflict Detection Instrs 
*/
 XEN_CPUFEATURE(SHA,   5*32+29) /*A  SHA1 & SHA256 instructions */
+XEN_CPUFEATURE(AVX512BW,  5*32+30) /*A  AVX-512 Byte and Word Instructions 
*/
+XEN_CPUFEATURE(AVX512VL,  5*32+31) /*A  AVX-512 Vector Length Extensions */
 
 /* Intel-defined CPU features, CPUID level 

Re: [Xen-devel] [PATCH v12 4/6] IOMMU/x86: using a struct pci_dev* instead of SBDF

[Tian, Kevin]

> From: Xu, Quan
> Sent: Sunday, June 26, 2016 6:33 PM
> 
> On June 24, 2016 7:46 PM, Tian, Kevin  wrote:
> > > From: Xu, Quan
> > > Sent: Friday, June 24, 2016 1:52 PM
> > >
> > > From: Quan Xu 
> > >
> > > a struct pci_dev* instead of SBDF is stored inside struct pci_ats_dev
> > > and parameter to enable_ats_device().
> > >
> > > Signed-off-by: Quan Xu 
> >
> > Can we unify the naming convention throughout the patch, e.g.
> > always using ats_pdev for "struct pci_ats_dev" variable,
> 
> Kevin, Is it 'ats_dev'? -Quan
> 

yes.

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

Re: [Xen-devel] [PATCH v7 3/3] x86/vmx: Clean up TRAP_int3 handling

[Tian, Kevin]

> From: Tamas K Lengyel [mailto:ta...@tklengyel.com]
> Sent: Tuesday, June 28, 2016 2:08 AM
> 
> Clean up the handling of TRAP_int3 VMEXITs to conform to the handling
> of TRAP_debug.
> 
> Signed-off-by: Tamas K Lengyel 

Acked-by: Kevin Tian 

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

[Xen-devel] [PATCH] x86/cpuid: AVX-512 Feature Detection

[Luwei Kang]

AVX-512 is an extention of AVX2. Its spec can be found at:
https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
This patch detects AVX-512 features by CPUID.

Signed-off-by: Luwei Kang 
---
 xen/arch/x86/hvm/hvm.c  | 14 ++
 xen/arch/x86/traps.c| 24 +++-
 xen/include/public/arch-x86/cpufeatureset.h |  9 +
 xen/tools/gen-cpuid.py  |  4 
 4 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c89ab6e..7696b1e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3474,6 +3474,20 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
   xstate_sizes[_XSTATE_BNDCSR]);
 }
 
+if ( _ebx & cpufeat_mask(X86_FEATURE_AVX512F) )
+{
+xfeature_mask |= XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM;
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_OPMASK] +
+  xstate_sizes[_XSTATE_OPMASK]);
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_ZMM] +
+  xstate_sizes[_XSTATE_ZMM]);
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_HI_ZMM] +
+  xstate_sizes[_XSTATE_HI_ZMM]);
+}
+
 if ( _ecx & cpufeat_mask(X86_FEATURE_PKU) )
 {
 xfeature_mask |= XSTATE_PKRU;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 767d0b0..a190103 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -975,7 +975,7 @@ void pv_cpuid(struct cpu_user_regs *regs)
 
 switch ( leaf )
 {
-uint32_t tmp, _ecx;
+uint32_t tmp, _ecx, _ebx;
 
 case 0x0001:
 c &= pv_featureset[FEATURESET_1c];
@@ -1139,6 +1139,7 @@ void pv_cpuid(struct cpu_user_regs *regs)
 domain_cpuid(currd, 1, 0, , , &_ecx, );
 else
 _ecx = cpuid_ecx(1);
+
 _ecx &= pv_featureset[FEATURESET_1c];
 
 if ( !(_ecx & cpufeat_mask(X86_FEATURE_XSAVE)) || subleaf >= 63 )
@@ -1157,6 +1158,27 @@ void pv_cpuid(struct cpu_user_regs *regs)
xstate_sizes[_XSTATE_YMM]);
 }
 
+if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
+domain_cpuid(currd, 7, 0, , &_ebx, , );
+else
+cpuid_count(7, 0, , &_ebx, , );
+
+_ebx &= pv_featureset[FEATURESET_7b0];
+
+if ( _ebx & cpufeat_mask(X86_FEATURE_AVX512F) )
+{
+xfeature_mask |= XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM;
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_OPMASK] +
+  xstate_sizes[_XSTATE_OPMASK]);
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_ZMM] +
+  xstate_sizes[_XSTATE_ZMM]);
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_HI_ZMM] +
+  xstate_sizes[_XSTATE_HI_ZMM]);
+}
+
 a = (uint32_t)xfeature_mask;
 d = (uint32_t)(xfeature_mask >> 32);
 c = xstate_size;
diff --git a/xen/include/public/arch-x86/cpufeatureset.h 
b/xen/include/public/arch-x86/cpufeatureset.h
index 39acf8c..9320c9e 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -206,15 +206,24 @@ XEN_CPUFEATURE(PQM,   5*32+12) /*   Platform QoS 
Monitoring */
 XEN_CPUFEATURE(NO_FPU_SEL,5*32+13) /*!  FPU CS/DS stored as zero */
 XEN_CPUFEATURE(MPX,   5*32+14) /*S  Memory Protection Extensions */
 XEN_CPUFEATURE(PQE,   5*32+15) /*   Platform QoS Enforcement */
+XEN_CPUFEATURE(AVX512F,   5*32+16) /*A  AVX-512 Foundation Instructions */
+XEN_CPUFEATURE(AVX512DQ,  5*32+17) /*A  AVX-512 Doubleword & Quadword 
Instrs */
 XEN_CPUFEATURE(RDSEED,5*32+18) /*A  RDSEED instruction */
 XEN_CPUFEATURE(ADX,   5*32+19) /*A  ADCX, ADOX instructions */
 XEN_CPUFEATURE(SMAP,  5*32+20) /*S  Supervisor Mode Access Prevention 
*/
+XEN_CPUFEATURE(AVX512IFMA,5*32+21) /*A  AVX-512 Integer Fused Multiply Add 
*/
 XEN_CPUFEATURE(CLFLUSHOPT,5*32+23) /*A  CLFLUSHOPT instruction */
 XEN_CPUFEATURE(CLWB,  5*32+24) /*A  CLWB instruction */
+XEN_CPUFEATURE(AVX512PF,  5*32+26) /*A  AVX-512 Prefetch Instructions */
+XEN_CPUFEATURE(AVX512ER,  5*32+27) /*A  AVX-512 Exponent & Reciprocal 
Instrs */
+XEN_CPUFEATURE(AVX512CD,  5*32+28) /*A  AVX-512 Conflict Detection Instrs 
*/
 

Re: [Xen-devel] [PATCH v7 2/3] x86/vm_event: Add HVM debug exception vm_events

[Tian, Kevin]

> From: Tamas K Lengyel [mailto:ta...@tklengyel.com]
> Sent: Tuesday, June 28, 2016 2:08 AM
> 
> Since in-guest debug exceptions are now unconditionally trapped to Xen, adding
> a hook for vm_event subscribers to tap into this new always-on guest event. We
> rename along the way hvm_event_breakpoint_type to hvm_event_type to better
> match the various events that can be passed with it. We also introduce the
> necessary monitor_op domctl's to enable subscribing to the events.
> 
> This patch also provides monitor subscribers to int3 events proper access
> to the instruction length necessary for accurate event-reinjection. Without
> this subscribers manually have to evaluate if the int3 instruction has any
> prefix attached which would change the instruction length.
> 
> Signed-off-by: Tamas K Lengyel 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v2] xen: x86: remove duplicated IA32_FEATURE_CONTROL MSR macro

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, June 28, 2016 9:46 PM
> 
> >>> On 28.06.16 at 10:12,  wrote:
> > From: Kai Huang 
> >
> > Below commit introduced a new macro MSR_IA32_FEATURE_CONTROL for
> > IA32_FEATURE_CONTROL MSR but it didn't remove old IA32_FEATURE_CONTROL_MSR
> > macro. The new one has better naming convention, so remove the old as a
> > duplication. Also move the macros of bit definition of IA32_FEATURE_CONTROL
> > MSR
> > down to make them together with the new one. The *_MSR* infix is also
> > removed as
> > it is pointless.
> >
> > commit 5a211704e8813c4890c8ce8dc4189d1dfb35ecd0
> > Author: Len Brown 
> > Date:   Fri Apr 8 22:31:47 2016 +0200
> >
> > mwait-idle: prevent SKL-H boot failure when C8+C9+C10 enabled
> >
> > Some SKL-H configurations require "max_cstate=7" to boot.
> > While that is an effective workaround, it disables C10.
> >
> > ..
> >
> > Above commit also used SGX_ENABLE (bit 18) in IA32_FEATURE_CONTROL MSR
> > without a
> > macro for it. A new macro IA32_FEATURE_CONTROL_SGX_ENABLE is also added for
> > better code and future use.
> >
> > Relevant code that uses those macros are changed accordingly.
> >
> > Signed-off-by: Kai Huang 
> 
> Reviewed-by: Jan Beulich 

Acked-by: Kevin Tian 

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

[Xen-devel] Xen 4.6 script calling conventions

[John Nemeth]

 I'm trying to package Xen 4.6 (specifically Xen 4.6.3) for
use with NetBSD.  I have it mostly done; however, when I try to
create a domU, libxl goes into an infinite loop calling the scripts.
If I try to create a domU with no network or disk, it works fine
(albeit of rather limited use).  Have there been changes between
Xen 4.5 and Xen 4.6 in the calling convention for the scripts?  Is
there documentation on what is expected somewhere?  Please CC me on
any responses.  Here is my domU config file:

-
kernel = "/usr/pkg/etc/xen/kernels/netbsd-XEN3_DOMU.gz"
#kernel = "/usr/pkg/etc/xen/kernels/netbsd-INSTALL_XEN3_DOMU.gz"

memory = 512

name = "netbsd1"

vif = [ 'bridge=bridge0' ]

#disk = [ 'file:/usr/pkg/etc/xen/disks/netbsd1,0x1,w' ]
#disk = [ 'file:/usr/pkg/etc/xen/disks/netbsd1,0x1,w', 'file:/usr/local/isos/Net
BSD-amd64-20140916.iso,0x2,r' ]
#disk = [ 'phy:/dev/vnd0d,0x1,rw' ]

extra = ""
-

Here is the output of "xl -v create netbsd1 -c":

-
Script started on Sat Jun 25 18:33:46 2016
i386devel: {1} xl -v create netbsd1 -c
Parsing config from netbsd1
libxl: debug: libxl_create.c:1563:do_domain_create: ao 0x7a19e312b0c0: create: 
how=0x0 callback=0x0 poller=0x7a19e310d110
libxl: debug: libxl_create.c:947:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:330:libxl__bootloader_run: no bootloader 
configured, using user supplied kernel
libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch 
w=0x7a19e312e958: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline="", features="(null)"
libxl: debug: libxl_dom.c:625:libxl__build_pv: pv kernel mapped 0 path 
/usr/pkg/etc/xen/kernels/netbsd-XEN3_DOMU.gz
domainbuilder: detail: xc_dom_kernel_file: 
filename="/usr/pkg/etc/xen/kernels/netbsd-XEN3_DOMU.gz"
domainbuilder: detail: xc_dom_malloc_filemap: 2288 kB
domainbuilder: detail: xc_dom_malloc: 7293 kB
domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x23c0c7 -> 0x71f606
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.6, caps xen-3.0-x86_64 
xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... 
domainbuilder: detail: loader probe OK
xc: detail: elf_parse_binary: phdr: paddr=0x8000 memsz=0x547f28
xc: detail: elf_parse_binary: phdr: paddr=0x80647f40 memsz=0x1b80c0
xc: detail: elf_parse_binary: memory: 0x8000 -> 0x8080
xc: detail: elf_xen_parse: __xen_guest: 
"GUEST_OS=NetBSD,GUEST_VER=4.99,XEN_VER=xen-3.0,LOADER=generic,VIRT_BASE=0x8000,ELF_PADDR_OFFSET=0x8000,VIRT_ENTRY=0x8010,HYPERCALL_PAGE=0x0101,BSD_SYMTAB=yes"
xc: detail: elf_xen_parse_guest_info: GUEST_OS="NetBSD"
xc: detail: elf_xen_parse_guest_info: GUEST_VER="4.99"
xc: detail: elf_xen_parse_guest_info: XEN_VER="xen-3.0"
xc: detail: elf_xen_parse_guest_info: LOADER="generic"
xc: detail: elf_xen_parse_guest_info: VIRT_BASE="0x8000"
xc: detail: elf_xen_parse_guest_info: ELF_PADDR_OFFSET="0x8000"
xc: detail: elf_xen_parse_guest_info: VIRT_ENTRY="0x8010"
xc: detail: elf_xen_parse_guest_info: HYPERCALL_PAGE="0x0101"
xc: detail: elf_xen_parse_guest_info: BSD_SYMTAB="yes"
xc: detail: elf_xen_addr_calc_check: addresses:
xc: detail: virt_base= 0x8000
xc: detail: elf_paddr_offset = 0x8000
xc: detail: virt_offset  = 0x0
xc: detail: virt_kstart  = 0x8000
xc: detail: virt_kend= 0x80899e78
xc: detail: virt_entry   = 0x8010
xc: detail: p2m_base = 0x
domainbuilder: detail: xc_dom_malloc: 615 kB
domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64: 
0x8000 -> 0x80933cf0
domainbuilder: detail: xc_dom_mem_init: mem 512 MB, pages 0x2 pages, 4k each
domainbuilder: detail: xc_dom_mem_init: 0x2 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64
domainbuilder: detail: xc_dom_malloc: 1024 kB
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_alloc_segment:   kernel   : 
0x8000 -> 0x80934000  (pfn 0x0 + 0x934 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x0+0x934 
at 0x7a19debcc000
xc: detail: elf_load_binary: phdr 0 at 0x7a19debcc000 -> 0x7a19df113f28
xc: detail: elf_load_binary: phdr 1 at 0x7a19df213f40 -> 0x7a19df23d318
xc: detail: elf_load_bsdsyms: shdr 25 at 0x7a19dfd857e9 -> 0x7a19df3cc748
xc: detail: elf_load_bsdsyms: shdr 26 at 0x7a19dfd86060 -> 0x7a19df3cc8c0
xc: detail: elf_load_bsdsyms: shdr 27 at 0x7a19dfde2850 -> 0x7a19df4290b0
domainbuilder: detail: xc_dom_load_elf_symtab: 
bsd_symtab_start=80899e78, kernel.end=0x80934000 -- 

[Xen-devel] repeating 'd1v0 Over-allocation for domain 1' messages in xen 4.7 Host logs on PVHVM Guest launch

[PGNet Dev]

(relo'd from user list)

I've launched an Ubuntu PVHVM guest, on a Xen 4.7 host

cat guest1.cfg
name = 'guest1'
builder  = 'hvm'
xen_platform_pci = 1
device_model_version = 'qemu-xen'
bios = 'ovmf'
bios_override= '/usr/share/qemu/ovmf-x86_64.bin'
...

On guest launch, `xl dmesg` in host reports

...
(XEN) [2016-06-27 21:54:09] HVM1 restore: CPU 0
(d1) [2016-06-27 21:54:10] HVM Loader
(d1) [2016-06-27 21:54:10] Detected Xen v4.7.0_08-452
(d1) [2016-06-27 21:54:10] Xenbus rings @0xfeffc000, event channel 1
(d1) [2016-06-27 21:54:10] System requested OVMF
(d1) [2016-06-27 21:54:10] CPU speed is 3093 MHz
(d1) [2016-06-27 21:54:10] Relocating guest memory for lowmem MMIO 
space disabled

(d1) [2016-06-27 21:54:10] PCI-ISA link 0 routed to IRQ5
(d1) [2016-06-27 21:54:10] PCI-ISA link 1 routed to IRQ10
(d1) [2016-06-27 21:54:10] PCI-ISA link 2 routed to IRQ11
(d1) [2016-06-27 21:54:10] PCI-ISA link 3 routed to IRQ5
(d1) [2016-06-27 21:54:10] pci dev 01:3 INTA->IRQ10
(d1) [2016-06-27 21:54:10] pci dev 02:0 INTA->IRQ11
(d1) [2016-06-27 21:54:10] pci dev 04:0 INTA->IRQ5
(d1) [2016-06-27 21:54:10] No RAM in high memory; setting high_mem 
resource base to 1
(d1) [2016-06-27 21:54:10] pci dev 02:0 bar 14 size 00100: 
0f008
(d1) [2016-06-27 21:54:10] pci dev 03:0 bar 10 size 00100: 
0f108
(d1) [2016-06-27 21:54:10] pci dev 04:0 bar 30 size 4: 
0f200
(d1) [2016-06-27 21:54:10] pci dev 04:0 bar 10 size 2: 
0f204
(d1) [2016-06-27 21:54:10] pci dev 03:0 bar 30 size 1: 
0f206
(d1) [2016-06-27 21:54:10] pci dev 03:0 bar 18 size 01000: 
0f207
(d1) [2016-06-27 21:54:10] pci dev 02:0 bar 10 size 00100: 
0c001
(d1) [2016-06-27 21:54:10] pci dev 04:0 bar 14 size 00040: 
0c101
(d1) [2016-06-27 21:54:10] pci dev 01:1 bar 20 size 00010: 
0c141

(d1) [2016-06-27 21:54:10] Multiprocessor initialisation:
(d1) [2016-06-27 21:54:10]  - CPU0 ... 39-bit phys ... fixed MTRRs 
... var MTRRs [1/8] ... done.

(d1) [2016-06-27 21:54:10] Writing SMBIOS tables ...
(d1) [2016-06-27 21:54:10] Loading OVMF ...
(XEN) [2016-06-27 21:54:10] d1v0 Over-allocation for domain 1: 
524545 > 524544

(d1) [2016-06-27 21:54:10] Loading ACPI ...
(d1) [2016-06-27 21:54:10] vm86 TSS at fc009f00
(d1) [2016-06-27 21:54:10] BIOS map:
(d1) [2016-06-27 21:54:10]  ffe0-: Main BIOS
(d1) [2016-06-27 21:54:10] E820 table:
(d1) [2016-06-27 21:54:10]  [00]: : - 
:000a: RAM

(d1) [2016-06-27 21:54:10]  HOLE: :000a - :000f
(d1) [2016-06-27 21:54:10]  [01]: :000f - 
:0010: RESERVED
(d1) [2016-06-27 21:54:10]  [02]: :0010 - 
:7eeb6000: RAM

(d1) [2016-06-27 21:54:10]  HOLE: :7eeb6000 - :fc00
(d1) [2016-06-27 21:54:10]  [03]: :fc00 - 
0001:: RESERVED

(d1) [2016-06-27 21:54:10] Invoking OVMF ...

At this point, the guest's up

xl list
NameID   Mem VCPUs 
State  Time(s)
Domain-0 0  4096 1 
r- 31.1
guest1   1  2049 1 
-b 17.4


, accessible and functional.,

uname -a
Linux guest1 4.4.0-24-generic #43-Ubuntu SMP Wed Jun 8 19:27:37 
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux



As long as the guest is up, the Host logs continuously fill up with 
over-allocation errors.



xl dmesg
(XEN) [2016-06-27 21:54:32] d1v0 Over-allocation for domain 1: 
524545 > 524544
(XEN) [2016-06-27 21:54:32] d1v0 Over-allocation for domain 1: 
524545 > 524544
(XEN) [2016-06-27 21:54:34] d1v0 Over-allocation for domain 1: 
524545 > 524544
(XEN) [2016-06-27 21:54:38] d1v0 Over-allocation for domain 1: 
524545 > 524544
(XEN) [2016-06-27 21:54:46] d1v0 Over-allocation for domain 1: 
524545 > 524544
(XEN) [2016-06-27 21:55:02] d1v0 Over-allocation for domain 1: 
524545 > 524544
(XEN) [2016-06-27 21:55:35] d1v0 Over-allocation for domain 1: 
524545 > 524544
(XEN) [2016-06-27 21:56:07] d1v0 Over-allocation for domain 1: 
524545 > 524544
(XEN) [2016-06-27 21:56:39] d1v0 Over-allocation for domain 1: 
524545 > 524544
(XEN) [2016-06-27 21:57:11] d1v0 Over-allocation for domain 1: 
524545 > 524544
(XEN) [2016-06-27 21:57:43] d1v0 Over-allocation for domain 1: 
524545 > 524544
(XEN) [2016-06-27 21:58:15] d1v0 Over-allocation for domain 1: 
524545 > 524544
(XEN) [2016-06-27 21:58:47] d1v0 Over-allocation for domain 1: 
524545 > 524544

...

with multiple guests, it quickly gets ridiculous,

 xl dmesg | grep -i 

[Xen-devel] [xen-4.3-testing test] 96336: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-install  fail pass in 96279
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
96321
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 96321

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail in 96321 like 87893
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 87893
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 87893

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/check fail in 96279 never 
pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  0a8c94fae993dd8f2b27fd4cc694f61c21de84bf
baseline version:
 xen  8fa31952e2d08ef63897c43b5e8b33475ebf5d93

Last test of basis87893  2016-03-29 13:49:52 Z   91 days
Failing since 92180  2016-04-20 17:49:21 Z   69 days   37 attempts
Testing same since96017  2016-06-20 17:22:27 Z8 days   16 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Anthony PERARD 
  Gerd Hoffmann 
  Ian Jackson 
  Jan Beulich 
  Jim Paris 
  Stefan Hajnoczi 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  fail
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  blocked 
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass 

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

[osstest service owner]

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

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  3cdad93704aaa8bf1f274969e401ca21152bc4a2
baseline version:
 xen  9b15b2e367a8565c73d5ba975e05c89c99078e60

Last test of basis96340  2016-06-28 10:01:49 Z0 days
Testing same since96349  2016-06-28 19:02:22 Z0 days1 attempts


People who touched revisions under test:
  Dirk Behme 
  Jan Beulich 
  Julien Grall 
  Stefano Stabellini 

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=3cdad93704aaa8bf1f274969e401ca21152bc4a2
+ . ./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 
3cdad93704aaa8bf1f274969e401ca21152bc4a2
+ branch=xen-unstable-smoke
+ revision=3cdad93704aaa8bf1f274969e401ca21152bc4a2
+ . ./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-4.7-testing
+ '[' x3cdad93704aaa8bf1f274969e401ca21152bc4a2 = 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 

Re: [Xen-devel] [PATCH RESEND] MAINTAINERS/gdbsx: change maintainer

[Konrad Rzeszutek Wilk]

On Tue, Jun 28, 2016 at 04:26:40PM -0700, elena.ufimts...@oracle.com wrote:
> From: Elena Ufimtseva 
> 
> Change gdbsx maintainer to myself.
> 
> 
> Signed-off-by: Elena Ufimtseva 

Acked-by: Konrad Rzeszutek Wilk 


> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a8e0043..e91140f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -206,7 +206,7 @@ F:xen/common/event_fifo.c
>  F:   xen/include/xen/event_fifo.h
>  
>  GDBSX DEBUGGER
> -M:   Mukesh Rathor 
> +M:   Elena Ufimtseva 
>  S:   Supported
>  F:   xen/arch/x86/debug.c
>  F:   tools/debugger/gdbsx/
> -- 
> 2.1.4
> 

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

[Xen-devel] [PATCH RESEND] MAINTAINERS/gdbsx: change maintainer

[elena . ufimtseva]

From: Elena Ufimtseva 

Change gdbsx maintainer to myself.


Signed-off-by: Elena Ufimtseva 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a8e0043..e91140f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -206,7 +206,7 @@ F:  xen/common/event_fifo.c
 F: xen/include/xen/event_fifo.h
 
 GDBSX DEBUGGER
-M: Mukesh Rathor 
+M: Elena Ufimtseva 
 S: Supported
 F: xen/arch/x86/debug.c
 F: tools/debugger/gdbsx/
-- 
2.1.4


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

[Xen-devel] [qemu-upstream-4.3-testing test] 96335: regressions - FAIL

[osstest service owner]

flight 96335 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96335/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 80927
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 80927

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass

version targeted for testing:
 qemuu12e8fccf5b5460be7aecddc71d27eceaba6e1f15
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  143 days
Failing since 93977  2016-05-10 11:09:16 Z   49 days  154 attempts
Testing same since95534  2016-06-11 00:59:46 Z   17 days   34 attempts


People who touched revisions under test:
  Anthony PERARD 
  Gerd Hoffmann 
  Ian Jackson 
  Stefano Stabellini 
  Wei Liu 

jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3   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 12e8fccf5b5460be7aecddc71d27eceaba6e1f15
Author: Ian Jackson 
Date:   Thu May 26 16:21:56 2016 +0100

main loop: Big hammer to fix logfile disk DoS in Xen setups

Re: [Xen-devel] [PATCH] xen-blkfront: save uncompleted reqs in blkfront_resume()

[Konrad Rzeszutek Wilk]

On Mon, Jun 27, 2016 at 04:33:24PM +0800, Bob Liu wrote:
> Uncompleted reqs used to be 'saved and resubmitted' in blkfront_recover() 
> during
> migration, but that's too later after multi-queue introduced.
> 
> After a migrate to another host (which may not have multiqueue support), the
> number of rings (block hardware queues) may be changed and the ring and shadow
> structure will also be reallocated.
> So that blkfront_recover() can't 'save and resubmit' the real uncompleted reqs
> because shadow structure has been reallocated.
> 
> This patch fixes this issue by moving the 'save and resubmit' logic out of
> blkfront_recover() to earlier place:blkfront_resume().
> 
> Signed-off-by: Bob Liu 

Ack-ed and Reviewed-by: Konrad Rzeszutek Wilk 

Let me run it through some tests and if no regressions found I will 
ask Jens to pull it.

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

[Xen-devel] [xen-unstable test] 96330: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  3 host-install(3) broken REGR. vs. 96296
 build-armhf-xsm   5 xen-build fail REGR. vs. 96296

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 96296
 build-amd64-rumpuserxen   6 xen-buildfail   like 96296
 build-i386-rumpuserxen6 xen-buildfail   like 96296
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 96296
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 96296
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 96296
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 96296
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 96296

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  08cffe6696c047123bd552e095163924c8ef4353
baseline version:
 xen  8384dc2d95538c5910d98db3df3ff5448bf0af48

Last test of basis96296  2016-06-27 01:55:48 Z1 days
Testing same since96315  2016-06-27 14:13:25 Z1 days2 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Julien Grall 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  fail
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev

[Xen-devel] Domain creation errors

[Andrew Cooper]

On 28/06/16 18:56, Andrew Cooper wrote:
> 
>
> This is the first in a number of changes trying to clean up error reporting of
> memory conditions.

One area which is constantly causing problems is creation of domains in
low memory conditions.  In the case where the toolstack gets its
calculations wrong, it is very difficult to diagnose what precicely went
wrong, for a number of reasons.

The error handling in xc_domain_populate_physmap_exact() looks like

if ( err >= 0 )
{
DPRINTF("Failed allocation for dom %d: %ld extents of order %d\n",
domid, nr_extents, extent_order);
errno = EBUSY;
err = -1;
}

which hides any error whatsoever behind an -EBUSY.

The reason for this is that the hypercall interface for
XENMEM_populate_physmap identifies which extent failed, but not why it
failed.  (Actually, there are plenty of errors which are accounted
against "the next extent", rather than being directly caused by that
extent).


The error conditions I want to be able to distinguish are "Xen is
completely out of memory", and "You are trying to add memory to a domain
beyond its allotted limit".  The former indicates that a toolstacks
logic to account overall memory is problematic, while the latter
indicates a mismatch between different toolstack areas.  Sadly, both end
up as -EBUSY.

The first problem to solve is that alloc_domheap_pages() can't
distinguish the errors.  Two returns from it are legitimately an
indication of ENOMEM, but the assign_pages() failure is specifically
not.  Returning a struct page_info pointer is unhelpful at
distinguishing the issues.

I have thought of two approaches, but its hard to decide between them.

First is to change alloc_domheap_pages() prototype to

int alloc_domheap_pages(struct domain *d, unsigned int order, unsigned
int memflags, struct page_info *out);

while the second is to use PTR_ERR().

Using PTR_ERR() is less disruptive to the code, but will cause
collateral damage for anyone with out-of-tree patches, as the code will
compile but the error logic will be wrong.  The use of PTR_ERR() is also
quite dangerous in the context of a PV guest, as the resulting pointer
is under 64bit guest ABI control.

I am leaning towards the first option, which at least has the advantage
that any out-of-tree code will break in an obvious way.

Any opinions or alternate suggestions?

~Andrew

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

Re: [Xen-devel] [PATCH v5 00/17] xen/arm: Use the typesafes gfn and mfn

[Andrew Cooper]

On 28/06/16 17:17, Julien Grall wrote:
> Julien Grall (17):
>   xen: Use typesafe gfn/mfn in guest_physmap_* helpers
>   xen: Use typesafe gfn in xenmem_add_to_physmap_one
>   xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the
> typesafe gfn

Committed patches 1-3.

Thanks,

~Andrew

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

Re: [Xen-devel] [PATCH v4] xen: arm: Update arm64 image header

[Andrew Cooper]

On 28/06/16 11:18, Julien Grall wrote:
>
>> This is acceptable as the support of Xen for ARM64 in Linux has been
>> added
>> in Linux 3.11 and the number of boards supported by Linux 3.11 on
>> ARM64 is
>> very limited: ARM models and X-gene. And for the latter it was an early
>> support with only the serial and timer upstreamed.
>>
>> Signed-off-by: Dirk Behme 
>
> Reviewed-by: Julien Grall 
>
> Regards,
>

Committed, thanks.

~Andrew

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

[Xen-devel] [PATCHv3 1/2] libfs: allow simple_fill_super() to add symlinks

[David Vrabel]

simple_fill_super() will add symlinks if an entry has mode & S_IFLNK.
The target is provided in the new "link" field.

Signed-off-by: David Vrabel 
---
v2:
- simplified.
---
 fs/libfs.c | 15 +--
 include/linux/fs.h |  2 +-
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/fs/libfs.c b/fs/libfs.c
index cedeacb..bbf2d82 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -512,9 +512,20 @@ int simple_fill_super(struct super_block *s, unsigned long 
magic,
dput(dentry);
goto out;
}
-   inode->i_mode = S_IFREG | files->mode;
+   if (files->mode & S_IFLNK) {
+   inode->i_mode = files->mode;
+   inode->i_op = _symlink_inode_operations;
+   inode->i_link = kstrdup(files->link, GFP_KERNEL);
+   if (!inode->i_link) {
+   iput(inode);
+   dput(dentry);
+   goto out;
+   }
+   } else {
+   inode->i_mode = S_IFREG | files->mode;
+   inode->i_fop = files->ops;
+   }
inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
-   inode->i_fop = files->ops;
inode->i_ino = i;
d_add(dentry, inode);
}
diff --git a/include/linux/fs.h b/include/linux/fs.h
index dd28814..20c54a2 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2953,7 +2953,7 @@ extern const struct file_operations simple_dir_operations;
 extern const struct inode_operations simple_dir_inode_operations;
 extern void make_empty_dir_inode(struct inode *inode);
 extern bool is_empty_dir_inode(struct inode *inode);
-struct tree_descr { char *name; const struct file_operations *ops; int mode; };
+struct tree_descr { char *name; const struct file_operations *ops; int mode; 
char *link; };
 struct dentry *d_alloc_name(struct dentry *, const char *);
 extern int simple_fill_super(struct super_block *, unsigned long, struct 
tree_descr *);
 extern int simple_pin_fs(struct file_system_type *, struct vfsmount **mount, 
int *count);
-- 
2.1.4


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

[Xen-devel] [PATCHv3 0/2] libfs, xenfs: replace /proc/xen/xenbus with a symlink

[David Vrabel]

Using /proc/xen/xenbus can cause deadlocks on the atomic file position
mutex since this file should behave like a character device and not a
regular file.  This is easiest to achive by making it a symlink to the
existing /dev/xen/xenbus device.

This requires extending simple_fill_super() to add symlinks as well as
regular files.

Changes in v3:
- Rebased on v4.7-rc5.

David


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

[Xen-devel] [PATCHv3 2/2] xenfs: replace xenbus and privcmd with symlinks

[David Vrabel]

/proc/xen/xenbus does not work correctly.  A read blocked waiting for
a xenstore message holds the mutex needed for atomic file position
updates.  This blocks any writes on the same file handle, which can
deadlock if the write is needed to unblock the read.

/proc/xen/xenbus is supposed to be identical to the character device
/dev/xen/xenbus so replace the file with a symlink.

Similarly, replace /proc/xen/privcmd with a symlink since it should be
the same as /dev/xen/privcmd.

Signed-off-by: David Vrabel 
---
v2:
- remove unneeded includes
---
 drivers/xen/xenfs/super.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 8559a71..0f2e2cd 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -18,8 +18,6 @@
 #include 
 
 #include "xenfs.h"
-#include "../privcmd.h"
-#include "../xenbus/xenbus_comms.h"
 
 #include 
 
@@ -45,16 +43,16 @@ static const struct file_operations capabilities_file_ops = 
{
 static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 {
static struct tree_descr xenfs_files[] = {
-   [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+   [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
},
{ "capabilities", _file_ops, S_IRUGO },
-   { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+   { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
{""},
};
 
static struct tree_descr xenfs_init_files[] = {
-   [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+   [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
},
{ "capabilities", _file_ops, S_IRUGO },
-   { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+   { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
{ "xsd_kva", _kva_file_ops, S_IRUSR|S_IWUSR},
{ "xsd_port", _port_file_ops, S_IRUSR|S_IWUSR},
 #ifdef CONFIG_XEN_SYMS
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] xen/page_alloc: Distinguish different errors from assign_pages()

[Andrew Cooper]

On 28/06/16 18:56, Andrew Cooper wrote:
> assign_pages() has a return type of int, but uses for a boolean value.  As
> there are two distinct failure cases, return a more meaningful error.

Sorry - sent an out of date version.  This sentence actually reads

assign_pages() has a return type of int, but only returns 0 or -1.  As there
are two distinct failure cases, return a more meaningful error.

~Andrew

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

[Xen-devel] [PATCH] xen/page_alloc: Distinguish different errors from assign_pages()

[Andrew Cooper]

assign_pages() has a return type of int, but uses for a boolean value.  As
there are two distinct failure cases, return a more meaningful error.

All caller currently use its boolean nature, so there is no resulting
change (yet).

Signed-off-by: Andrew Cooper 
---
CC: George Dunlap 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 

This is the first in a number of changes trying to clean up error reporting of
memory conditions.
---
 xen/common/page_alloc.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 98e30e5..48cf90d 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1740,6 +1740,7 @@ int assign_pages(
 unsigned int order,
 unsigned int memflags)
 {
+int rc = 0;
 unsigned long i;
 
 spin_lock(>page_alloc_lock);
@@ -1748,7 +1749,8 @@ int assign_pages(
 {
 gdprintk(XENLOG_INFO, "Cannot assign page to domain%d -- dying.\n",
 d->domain_id);
-goto fail;
+rc = -EINVAL;
+goto out;
 }
 
 if ( !(memflags & MEMF_no_refcount) )
@@ -1759,7 +1761,8 @@ int assign_pages(
 gprintk(XENLOG_INFO, "Over-allocation for domain %u: "
 "%u > %u\n", d->domain_id,
 d->tot_pages + (1 << order), d->max_pages);
-goto fail;
+rc = -E2BIG;
+goto out;
 }
 
 if ( unlikely(d->tot_pages == 0) )
@@ -1778,12 +1781,9 @@ int assign_pages(
 page_list_add_tail([i], >page_list);
 }
 
+ out:
 spin_unlock(>page_alloc_lock);
-return 0;
-
- fail:
-spin_unlock(>page_alloc_lock);
-return -1;
+return rc;
 }
 
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH linux 0/8] xen: pvhvm: support bootup on secondary vCPUs

[David Vrabel]

On 28/06/16 17:47, Vitaly Kuznetsov wrote:
> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
> particular, when we crash on a secondary vCPU we may want to do kdump
> and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
> on the vCPU which crashed. This doesn't work very well for PVHVM guests as
> we have a number of hypercalls where we pass vCPU id as a parameter. These
> hypercalls either fail or do something unexpected. To solve the issue we
> need to have a mapping between Linux's and Xen's vCPU ids.

Could the soft-reboot hypercall (optionally) return on vcpu 0?

David

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 94856
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 94856
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 94856
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
94856
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
94856
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 94856
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 94856
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 94856

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94856
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94856
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94856

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   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-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail 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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 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-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   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-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu14e60aaece20a1cfc059a69f6491b0899f9257a8
baseline version:
 qemuud6550e9ed2e1a60d889dfb721de00d9a4e3bafbe

Last test of basis94856  2016-05-27 20:14:49 Z   31 days
Failing since 94983  2016-05-31 09:40:12 Z   28 days   39 attempts
Testing same since96328  2016-06-27 23:15:03 Z0 days1 attempts


People who touched revisions under test:
  Aaron Larson 
  Alberto Garcia 
  Aleksandar Markovic 
  Alex Bennée 
  Alex Bligh 
  Alex Williamson 
  Alexander Graf 
  Alexey Kardashevskiy 
  Alistair Francis 
  Amit Shah 
  Andrea Arcangeli 
  Andrew Jeffery 
  Andrew Jones 
  Aneesh Kumar K.V 
  Anthony PERARD 
  Anton Blanchard 
  Ard Biesheuvel 
  

Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping

[Andrew Cooper]

On 28/06/16 17:47, Vitaly Kuznetsov wrote:
> @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block 
> *self, unsigned long action,
>   int cpu = (long)hcpu;
>   switch (action) {
>   case CPU_UP_PREPARE:
> + /* vLAPIC_ID == Xen's vCPU_ID * 2 for HVM guests */
> + per_cpu(xen_vcpu_id, cpu) = cpu_physical_id(cpu) / 2;

Please do not assume or propagate this brokenness.  It is incorrect in
the general case, and I will be fixing in the hypervisor in due course.

Always read the APIC_ID from the LAPIC, per regular hardware.

~Andrew

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

Re: [Xen-devel] [PATCH v5 15/17] xen/arm: p2m: Introduce helpers to insert and remove mapping

[Andrew Cooper]

On 28/06/16 17:17, Julien Grall wrote:
>  void guest_physmap_remove_page(struct domain *d,
> gfn_t gfn,
> mfn_t mfn, unsigned int page_order)
>  {
> -apply_p2m_changes(d, REMOVE,
> -  pfn_to_paddr(gfn_x(gfn)),
> -  pfn_to_paddr(gfn_x(gfn) + (1< -  pfn_to_paddr(mfn_x(mfn)), MATTR_MEM, 0, p2m_invalid,
> -  d->arch.p2m.default_access);
> +p2m_remove_mapping(d, gfn, (1 << page_order), mfn);

As you are changing these, it should be 1ul << page_order to avoid the
potential of overflow.

~Andrew

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

Re: [Xen-devel] [PATCH v5 13/17] xen/arm: Use the typesafes mfn and gfn in map_dev_mmio_region...

[Andrew Cooper]

On 28/06/16 17:17, Julien Grall wrote:
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index f11094e..5ffc3df 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1211,20 +1211,20 @@ int unmap_mmio_regions(struct domain *d,
>  }
>  
>  int map_dev_mmio_region(struct domain *d,
> -unsigned long start_gfn,
> +gfn_t gfn,
>  unsigned long nr,
> -unsigned long mfn)
> +mfn_t mfn)
>  {
>  int res;
>  
> -if ( !(nr && iomem_access_permitted(d, mfn, mfn + nr - 1)) )
> +if ( !(nr && iomem_access_permitted(d, mfn_x(mfn), mfn_x(mfn) + nr - 1)) 
> )
>  return 0;
>  
> -res = map_mmio_regions(d, _gfn(start_gfn), nr, _mfn(mfn));
> +res = map_mmio_regions(d, gfn, nr, mfn);
>  if ( res < 0 )
>  {
>  printk(XENLOG_G_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",

%PRImfn

I would also recommend qualifying what is being mapped, so "to map mfns
[...".

~Andrew

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

Re: [Xen-devel] [PATCH] x86/EFI + Live Patch: avoid symbol address truncation

[Konrad Rzeszutek Wilk]

On Tue, Jun 28, 2016 at 08:03:57AM -0600, Jan Beulich wrote:
> ld associates __init_end, placed outside of any section by the linker
> script, with the following section, resulting in a huge (wrapped, as it
> would be negative) section relative offset. COFF symbol tables store
> section relative addresses, and hence the above leads to assembler

My recollection is it was the linker? Like so:

/home/konrad/xen/xen/.xen.efi.0s.S:21: Warning: value 0x7d2f852e truncated 
to 0x852e
/home/konrad/xen/xen/.xen.efi.0s.S:22: Warning: value 0x7d2f8a05 truncated 
to 0x8a05
/home/konrad/xen/xen/.xen.efi.0s.S:23: Warning: value 0x7d2f8a07 truncated 
to 0x8a07

With this patch I still see those warnings?

(This is on OL7, so ldd (GNU libc) 2.17 gcc (GCC) 4.8.5 20150623 (Red Hat 
4.8.5-4) 

Let me try on different version.

> truncation warnings when all symbols get included in the symbol table
> (for Live Patching code). To overcome this, move __init_end past both
> ALIGN() directives. The consuming code (init_done()) is fine with such
> an adjustment (the distinction really would only be relevant for the
> loop claring the pages, and I think it's acceptable to clear a few
> more on - for now - EFI). This effectively results in the
> (__init_begin,__init_end) and (__2M_init_start,__2M_init_end) pairs to
> become identical, with their different names only serving documentation
> purposes now.
> 
> Note that moving __init_end and __2M_init_end into .init is not a good
> idea, as that would significantly grow xen.efi binary size.
> 
> While inspecting symbol table and ld behavior I also noticed that
> __2M_text_start gets put at address zero in the EFI case, which hasn't
> caused problems solely because we don't actually reference that symbol.
> Correct the setting of the initial address, and comment out said symbol
> for the time being, as with the initial address correction it would in
> turn cause an assembler truncation warning similar to the one mentioned
> above.
> 
> While checking init_done() for correctness with the above changes I
> noticed that code can easily be folded there, at once correcting the
> logged amount of memory which has got freed for the 2M-alignment case
> (i.e. EFI right now).
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -515,6 +515,7 @@ static inline bool_t using_2M_mapping(vo
>  static void noinline init_done(void)
>  {
>  void *va;
> +unsigned long start, end;
>  
>  system_state = SYS_STATE_active;
>  
> @@ -530,18 +531,18 @@ static void noinline init_done(void)
>  /* Destroy Xen's mappings, and reuse the pages. */
>  if ( using_2M_mapping() )
>  {
> -destroy_xen_mappings((unsigned long)&__2M_init_start,
> - (unsigned long)&__2M_init_end);
> -init_xenheap_pages(__pa(__2M_init_start), __pa(__2M_init_end));
> +start = (unsigned long)&__2M_init_start,
> +end   = (unsigned long)&__2M_init_end;
>  }
>  else
>  {
> -destroy_xen_mappings((unsigned long)&__init_begin,
> - (unsigned long)&__init_end);
> -init_xenheap_pages(__pa(__init_begin), __pa(__init_end));
> +start = (unsigned long)&__init_begin;
> +end   = (unsigned long)&__init_end;
>  }
>  
> -printk("Freed %ldkB init memory.\n", 
> (long)(__init_end-__init_begin)>>10);
> +destroy_xen_mappings(start, end);
> +init_xenheap_pages(__pa(start), __pa(end));
> +printk("Freed %ldkB init memory\n", (end - start) >> 10);
>  
>  startup_cpu_idle_loop();
>  }
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -40,9 +40,20 @@ SECTIONS
>  #if !defined(EFI)
>. = __XEN_VIRT_START;
>__image_base__ = .;
> +#else
> +  . = __image_base__;
>  #endif
>  
> +#if 0
> +/*
> + * We don't really use this symbol anywhere, and the way it would get defined
> + * here would result in it having a negative (wrapped to huge positive)
> + * offset relative to the .text section. That, in turn, causes an assembler
> + * truncation warning when including all symbols in the symbol table for Live
> + * Patching code.
> + */
>__2M_text_start = .; /* Start of 2M superpages, mapped RX. */
> +#endif
>  
>. = __XEN_VIRT_START + MB(1);
>_start = .;
> @@ -194,14 +205,13 @@ SECTIONS
> *(.ctors)
> __ctors_end = .;
>} :text
> -  . = ALIGN(PAGE_SIZE);
> -  __init_end = .;
>  
>  #ifdef EFI
>. = ALIGN(MB(2));
>  #else
>. = ALIGN(PAGE_SIZE);
>  #endif
> +  __init_end = .;
>__2M_init_end = .;
>  
>__2M_rwdata_start = .;   /* Start of 2M superpages, mapped RW. */
> @@ -296,7 +306,6 @@ ASSERT(__image_base__ > XEN_VIRT_START |
>  ASSERT(kexec_reloc_size - kexec_reloc <= PAGE_SIZE, "kexec_reloc is too 
> large")
>  #endif
>  
> -ASSERT(IS_ALIGNED(__2M_text_start,   MB(2)), "__2M_text_start misaligned")
>  #ifdef EFI
>  

Re: [Xen-devel] [PATCH v5 07/17] xen: Use a typesafe to define INVALID_GFN

[Andrew Cooper]

On 28/06/16 17:17, Julien Grall wrote:
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index a929e3b..b9ffce2 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5298,7 +5298,7 @@ static int do_altp2m_op(
>   a.u.enable_notify.vcpu_id != curr->vcpu_id )
>  rc = -EINVAL;
>  
> -if ( (gfn_x(vcpu_altp2m(curr).veinfo_gfn) != INVALID_GFN) ||
> +if ( (!gfn_eq(vcpu_altp2m(curr).veinfo_gfn,  INVALID_GFN)) ||

You can drop a set of brackets here, and the double space before
INVALID_GFN.

Otherwise, Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v5 06/17] xen: Use a typesafe to define INVALID_MFN

[Andrew Cooper]

On 28/06/16 17:17, Julien Grall wrote:
> @@ -60,16 +60,17 @@ dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int 
> toaddr,
>  return INVALID_MFN;
>  }
>  
> -mfn = mfn_x(get_gfn(dp, *gfn, )); 
> +mfn = get_gfn(dp, *gfn, );
>  if ( p2m_is_readonly(gfntype) && toaddr )
>  {
>  DBGP2("kdb:p2m_is_readonly: gfntype:%x\n", gfntype);
>  mfn = INVALID_MFN;
>  }
>  else
> -DBGP2("X: vaddr:%lx domid:%d mfn:%lx\n", vaddr, dp->domain_id, mfn);
> +DBGP2("X: vaddr:%lx domid:%d mfn:%lx\n",

This should be PRImfn rather than assuming %lx is the correct format
identifier for mfn_t.

Similarly throughout the patch.

> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 6258a5b..6f90510 100644
> @@ -493,7 +493,7 @@ int p2m_set_entry(struct p2m_domain *p2m, unsigned long 
> gfn, mfn_t mfn,
>  rc = set_rc;
>  
>  gfn += 1ul << order;
> -if ( mfn_x(mfn) != INVALID_MFN )
> +if ( !mfn_eq(mfn, INVALID_MFN) )
>  mfn = _mfn(mfn_x(mfn) + (1ul << order));

This could turn into mfn_add(mfn, 1ul << order), if you fancy fixing it up.

> @@ -1107,7 +1107,7 @@ int clear_mmio_p2m_entry(struct domain *d, unsigned 
> long gfn, mfn_t mfn,
>  }
>  
>  /* Do not use mfn_valid() here as it will usually fail for MMIO pages. */
> -if ( (INVALID_MFN == mfn_x(actual_mfn)) || (t != p2m_mmio_direct) )
> +if ( (mfn_eq(actual_mfn, INVALID_MFN)) || (t != p2m_mmio_direct) )

You can drop the brackets around mfn_eq().

> @@ -838,7 +838,7 @@ mfn_t oos_snapshot_lookup(struct domain *d, mfn_t gmfn)
>  
>  SHADOW_ERROR("gmfn %lx was OOS but not in hash table\n", mfn_x(gmfn));
>  BUG();
> -return _mfn(INVALID_MFN);
> +return INVALID_MFN;

You should be able to get away with deleting this return.  Now that
BUG() is properly annotated with unreachable(), the compiler shouldn't
warn about this exit path from the function.

Otherwise, no major concerns.  Reviewed-by: Andrew Cooper


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

Re: [Xen-devel] [PATCH v5 05/17] xen/passthrough: x86: Use INVALID_GFN rather than INVALID_MFN

[Julien Grall]

On 28/06/16 17:47, Juergen Gross wrote:

On 28/06/16 18:43, Andrew Cooper wrote:

On 28/06/16 17:17, Julien Grall wrote:

A variable containing a guest frame should be compared to INVALID_GFN
and not INVALID_GFN.


I think the text should be changed? I'd expect one 'G' being replaced
bay 'M'. :-)


Correct, the second should be replaced by a 'M'. Thank you for spotting it.

Cheers,



Signed-off-by: Julien Grall 


Reviewed-by: Andrew Cooper 

I suspect these (mis)uses predate my movement of INVALID_GFN from x86
paging code to common code.

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





--
Julien Grall

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

Re: [Xen-devel] GDBSX Maintainer

[Andrew Cooper]

On 28/06/16 17:52, Elena Ufimtseva wrote:
> Hi Julien, Andrew
>
> I was talking to Konrad some time ago about looking into this and the
> possibility of maintaining gdbsx code. I am willing sign up for this
> if there are no objections.

Fine by me.  The traditional way of doing this would be for you to
author a patch changing the mantainers file.

~Andrew

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

Re: [Xen-devel] GDBSX Maintainer

[Elena Ufimtseva]

Hi Julien, Andrew

I was talking to Konrad some time ago about looking into this and the
possibility of maintaining gdbsx code. I am willing sign up for this
if there are no objections.

Elena

On Tue, Jun 28, 2016 at 9:46 AM, Andrew Cooper
 wrote:
> On 28/06/16 17:31, Julien Grall wrote:
>> Hi,
>>
>> I had to modify some code in arch/x86/debug.c and noticed that Mukesh
>> is still the maintainer. IIRC he left Oracle quite a while ago, so my
>> e-mail was bounced by the server.
>>
>> Do we have a new e-mail address for me? If not, does anyone plan to
>> maintain this code? Shall we mark the code as "Orphan"?
>
> If noone explicitly wishes to maintain it, then it should be subsumed
> into general x86.  Its not like its a large or complicated area of code.
>
> ~Andrew
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



-- 
Elena

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

Re: [Xen-devel] [PATCH v2] xen: xen-pciback: Remove create_workqueue

[Bhaktipriya Shridhar]

Ping!
Thanks,
Bhaktipriya


On Wed, Jun 1, 2016 at 9:15 PM, Tejun Heo  wrote:
> On Wed, Jun 01, 2016 at 07:45:08PM +0530, Bhaktipriya Shridhar wrote:
>> System workqueues have been able to handle high level of concurrency
>> for a long time now and there's no reason to use dedicated workqueues
>> just to gain concurrency.  Replace dedicated xen_pcibk_wq with the
>> use of system_wq.
>>
>> Unlike a dedicated per-cpu workqueue created with create_workqueue(),
>> system_wq allows multiple work items to overlap executions even on
>> the same CPU; however, a per-cpu workqueue doesn't have any CPU
>> locality or global ordering guarantees unless the target CPU is
>> explicitly specified and thus the increase of local concurrency shouldn't
>> make any difference.
>>
>> Since the work items could be pending, flush_work() has been used in
>> xen_pcibk_disconnect(). xen_pcibk_xenbus_remove() calls free_pdev()
>> which in turn calls xen_pcibk_disconnect() for every pdev to ensure that
>> there is no pending task while disconnecting the driver.
>>
>> Signed-off-by: Bhaktipriya Shridhar 
>
> Acked-by: Tejun Heo 
>
> Thanks.
>
> --
> tejun

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

Re: [Xen-devel] [PATCH v2] xen: xenbus: Remove create_workqueue

[Bhaktipriya Shridhar]

Ping!
Thanks,
Bhaktipriya


On Tue, May 31, 2016 at 10:59 PM, Tejun Heo  wrote:
> On Tue, May 31, 2016 at 10:26:30PM +0530, Bhaktipriya Shridhar wrote:
>> System workqueues have been able to handle high level of concurrency
>> for a long time now and there's no reason to use dedicated workqueues
>> just to gain concurrency.  Replace dedicated xenbus_frontend_wq with the
>> use of system_wq.
>>
>> Unlike a dedicated per-cpu workqueue created with create_workqueue(),
>> system_wq allows multiple work items to overlap executions even on
>> the same CPU; however, a per-cpu workqueue doesn't have any CPU
>> locality or global ordering guarantees unless the target CPU is
>> explicitly specified and the increase of local concurrency shouldn't
>> make any difference.
>>
>> In this case, there is only a single work item, increase of concurrency
>> level by switching to system_wq should not make any difference.
>>
>> Signed-off-by: Bhaktipriya Shridhar 
>
> Acked-by: Tejun Heo 
>
> Thanks.
>
> --
> tejun

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

[Xen-devel] [PATCH linux 4/8] x86/xen: use xen_vcpu_id mapping when pointing vcpu_info to the shared_info page

[Vitaly Kuznetsov]

shared_info page has space for 32 vcpu info slots for first 32 vCPUs but
these are the first 32 vCPUs from Xen's perspective and we should map them
accordingly with the newly introduced xen_vcpu_id mapping.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/enlighten.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 69f4c0c..1596626 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -189,6 +189,7 @@ static void xen_vcpu_setup(int cpu)
struct vcpu_register_vcpu_info info;
int err;
struct vcpu_info *vcpup;
+   int xen_cpu = per_cpu(xen_vcpu_id, cpu);
 
BUG_ON(HYPERVISOR_shared_info == _dummy_shared_info);
 
@@ -207,8 +208,9 @@ static void xen_vcpu_setup(int cpu)
if (per_cpu(xen_vcpu, cpu) == _cpu(xen_vcpu_info, cpu))
return;
}
-   if (cpu < MAX_VIRT_CPUS)
-   per_cpu(xen_vcpu,cpu) = _shared_info->vcpu_info[cpu];
+   if (xen_cpu < MAX_VIRT_CPUS)
+   per_cpu(xen_vcpu, cpu) =
+   _shared_info->vcpu_info[xen_cpu];
 
if (!have_vcpu_info_placement) {
if (cpu >= MAX_VIRT_CPUS)
@@ -1752,7 +1754,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
 
 void __ref xen_hvm_init_shared_info(void)
 {
-   int cpu;
+   int cpu, xen_cpu;
struct xen_add_to_physmap xatp;
static struct shared_info *shared_info_page = 0;
 
@@ -1777,10 +1779,13 @@ void __ref xen_hvm_init_shared_info(void)
 * online but xen_hvm_init_shared_info is run at resume time too and
 * in that case multiple vcpus might be online. */
for_each_online_cpu(cpu) {
+   xen_cpu = per_cpu(xen_vcpu_id, cpu);
+
/* Leave it to be NULL. */
-   if (cpu >= MAX_VIRT_CPUS)
+   if (xen_cpu >= MAX_VIRT_CPUS)
continue;
-   per_cpu(xen_vcpu, cpu) = 
_shared_info->vcpu_info[cpu];
+   per_cpu(xen_vcpu, cpu) =
+   _shared_info->vcpu_info[xen_cpu];
}
 }
 
-- 
2.5.5


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

[Xen-devel] [PATCH linux 8/8] xen/pvhvm: run xen_vcpu_setup() for the boot CPU

[Vitaly Kuznetsov]

Historically we didn't call VCPUOP_register_vcpu_info for CPU0 for PVHVM
guests (while we had it for PV and ARM guests). This is usually fine as we
can use vcpu info in the sared_info page but when we try booting on a vCPU
with Xen's vCPU id > 31 (e.g. when we try to kdump after crashing on this
CPU) we're not able to boot. Switch to always doing
VCPUOP_register_vcpu_info for the boot CPU.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/xen/enlighten.c | 2 +-
 arch/x86/xen/smp.c   | 7 +++
 arch/x86/xen/xen-ops.h   | 1 +
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 1596626..0be29a0 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -184,7 +184,7 @@ static void clamp_max_cpus(void)
 #endif
 }
 
-static void xen_vcpu_setup(int cpu)
+void xen_vcpu_setup(int cpu)
 {
struct vcpu_register_vcpu_info info;
int err;
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 719cf29..b9b31a7 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -322,6 +322,13 @@ static void __init xen_smp_prepare_boot_cpu(void)
xen_filter_cpu_maps();
xen_setup_vcpu_info_placement();
}
+
+   /*
+* Setup vcpu_info for boot CPU.
+*/
+   if (xen_hvm_domain())
+   xen_vcpu_setup(0);
+
/*
 * The alternative logic (which patches the unlock/lock) runs before
 * the smp bootup up code is activated. Hence we need to set this up
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 4140b07..3cbce3b 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -76,6 +76,7 @@ irqreturn_t xen_debug_interrupt(int irq, void *dev_id);
 
 bool xen_vcpu_stolen(int vcpu);
 
+void xen_vcpu_setup(int cpu);
 void xen_setup_vcpu_info_placement(void);
 
 #ifdef CONFIG_SMP
-- 
2.5.5


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

[Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping

[Vitaly Kuznetsov]

It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we may want to do kdump
and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
on the vCPU which crashed. This doesn't work very well for PVHVM guests as
we have a number of hypercalls where we pass vCPU id as a parameter. These
hypercalls either fail or do something unexpected. To solve the issue
introduce percpu xen_vcpu_id mapping. ARM and PV guests get direct mapping
for now. Boot CPU for PVHVM guest gets its id from CPUID. With secondary
CPUs it is a bit more trickier. Currently, we initialize IPI vectors
before these CPUs boot so we can't use CPUID. However, we know that
physical CPU id (vLAPIC id) is Xen's vCPU id * 2, we can piggyback on
that. Alternatively, we could have disabled all secondary CPUs once we
detect that Xen's and Linux's ideas of vCPU id diverged.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/arm/xen/enlighten.c | 10 ++
 arch/x86/xen/enlighten.c | 18 +-
 include/xen/xen-ops.h|  1 +
 3 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..ea99ca2 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -46,6 +46,10 @@ struct shared_info *HYPERVISOR_shared_info = (void 
*)_dummy_shared_info;
 DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
 static struct vcpu_info __percpu *xen_vcpu_info;
 
+/* Linux <-> Xen vCPU id mapping */
+DEFINE_PER_CPU(int, xen_vcpu_id) = -1;
+EXPORT_SYMBOL_GPL(xen_vcpu_id);
+
 /* These are unused until we support booting "pre-ballooned" */
 unsigned long xen_released_pages;
 struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
@@ -179,6 +183,9 @@ static void xen_percpu_init(void)
pr_info("Xen: initializing cpu%d\n", cpu);
vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
 
+   /* Direct vCPU id mapping for ARM guests. */
+   per_cpu(xen_vcpu_id, cpu) = cpu;
+
info.mfn = virt_to_gfn(vcpup);
info.offset = xen_offset_in_page(vcpup);
 
@@ -328,6 +335,9 @@ static int __init xen_guest_init(void)
if (xen_vcpu_info == NULL)
return -ENOMEM;
 
+   /* Direct vCPU id mapping for ARM guests. */
+   per_cpu(xen_vcpu_id, 0) = 0;
+
if (gnttab_setup_auto_xlat_frames(grant_frames)) {
free_percpu(xen_vcpu_info);
return -ENOMEM;
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 760789a..69f4c0c 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -118,6 +119,10 @@ DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
  */
 DEFINE_PER_CPU(struct vcpu_info, xen_vcpu_info);
 
+/* Linux <-> Xen vCPU id mapping */
+DEFINE_PER_CPU(int, xen_vcpu_id) = -1;
+EXPORT_SYMBOL_GPL(xen_vcpu_id);
+
 enum xen_domain_type xen_domain_type = XEN_NATIVE;
 EXPORT_SYMBOL_GPL(xen_domain_type);
 
@@ -1137,8 +1142,11 @@ void xen_setup_vcpu_info_placement(void)
 {
int cpu;
 
-   for_each_possible_cpu(cpu)
+   for_each_possible_cpu(cpu) {
+   /* Set up direct vCPU id mapping for PV guests. */
+   per_cpu(xen_vcpu_id, cpu) = cpu;
xen_vcpu_setup(cpu);
+   }
 
/* xen_vcpu_setup managed to place the vcpu_info within the
 * percpu area for all cpus, so make use of it. Note that for
@@ -1797,6 +1805,12 @@ static void __init init_hvm_pv_info(void)
 
xen_setup_features();
 
+   cpuid(base + 4, , , , );
+   if (eax & XEN_HVM_CPUID_VCPU_ID_PRESENT)
+   this_cpu_write(xen_vcpu_id, ebx);
+   else
+   this_cpu_write(xen_vcpu_id, smp_processor_id());
+
pv_info.name = "Xen HVM";
 
xen_domain_type = XEN_HVM_DOMAIN;
@@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block 
*self, unsigned long action,
int cpu = (long)hcpu;
switch (action) {
case CPU_UP_PREPARE:
+   /* vLAPIC_ID == Xen's vCPU_ID * 2 for HVM guests */
+   per_cpu(xen_vcpu_id, cpu) = cpu_physical_id(cpu) / 2;
xen_vcpu_setup(cpu);
if (xen_have_vector_callback) {
if (xen_feature(XENFEAT_hvm_safe_pvclock))
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 86abe07..b02a343 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -8,6 +8,7 @@
 #include 
 
 DECLARE_PER_CPU(struct vcpu_info *, xen_vcpu);
+DECLARE_PER_CPU(int, xen_vcpu_id);
 
 void xen_arch_pre_suspend(void);
 void xen_arch_post_suspend(int suspend_cancelled);
-- 
2.5.5


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

[Xen-devel] [PATCH linux 5/8] xen/events: use xen_vcpu_id mapping in events_base

[Vitaly Kuznetsov]

EVTCHNOP_bind_ipi and EVTCHNOP_bind_virq pass vCPU id as a parameter and
Xen's idea of vCPU id should be used. Use the newly introduced xen_vcpu_id
mapping to convert it from Linux's id.

Signed-off-by: Vitaly Kuznetsov 
---
 drivers/xen/events/events_base.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 71d49a9..73b8b65 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -895,7 +895,7 @@ static int bind_ipi_to_irq(unsigned int ipi, unsigned int 
cpu)
irq_set_chip_and_handler_name(irq, _percpu_chip,
  handle_percpu_irq, "ipi");
 
-   bind_ipi.vcpu = cpu;
+   bind_ipi.vcpu = per_cpu(xen_vcpu_id, cpu);
if (HYPERVISOR_event_channel_op(EVTCHNOP_bind_ipi,
_ipi) != 0)
BUG();
@@ -991,7 +991,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu, 
bool percpu)
  handle_edge_irq, "virq");
 
bind_virq.virq = virq;
-   bind_virq.vcpu = cpu;
+   bind_virq.vcpu = per_cpu(xen_vcpu_id, cpu);
ret = HYPERVISOR_event_channel_op(EVTCHNOP_bind_virq,
_virq);
if (ret == 0)
@@ -1318,7 +1318,7 @@ static int rebind_irq_to_cpu(unsigned irq, unsigned tcpu)
 
/* Send future instances of this interrupt to other vcpu. */
bind_vcpu.port = evtchn;
-   bind_vcpu.vcpu = tcpu;
+   bind_vcpu.vcpu = per_cpu(xen_vcpu_id, tcpu);
 
/*
 * Mask the event while changing the VCPU binding to prevent
@@ -1458,7 +1458,7 @@ static void restore_cpu_virqs(unsigned int cpu)
 
/* Get a new binding from Xen. */
bind_virq.virq = virq;
-   bind_virq.vcpu = cpu;
+   bind_virq.vcpu = per_cpu(xen_vcpu_id, cpu);
if (HYPERVISOR_event_channel_op(EVTCHNOP_bind_virq,
_virq) != 0)
BUG();
@@ -1482,7 +1482,7 @@ static void restore_cpu_ipis(unsigned int cpu)
BUG_ON(ipi_from_irq(irq) != ipi);
 
/* Get a new binding from Xen. */
-   bind_ipi.vcpu = cpu;
+   bind_ipi.vcpu = per_cpu(xen_vcpu_id, cpu);
if (HYPERVISOR_event_channel_op(EVTCHNOP_bind_ipi,
_ipi) != 0)
BUG();
-- 
2.5.5


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

[Xen-devel] [PATCH linux 6/8] xen/events: fifo: use xen_vcpu_id mapping

[Vitaly Kuznetsov]

EVTCHNOP_init_control has vCPU id as a parameter and Xen's idea of vCPU id
should be used. Use the newly introduced xen_vcpu_id mapping to convert
it from Linux's id.

Signed-off-by: Vitaly Kuznetsov 
---
 drivers/xen/events/events_fifo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
index 9289a17..e3406cd 100644
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -113,7 +113,7 @@ static int init_control_block(int cpu,
 
init_control.control_gfn = virt_to_gfn(control_block);
init_control.offset  = 0;
-   init_control.vcpu= cpu;
+   init_control.vcpu= per_cpu(xen_vcpu_id, cpu);
 
return HYPERVISOR_event_channel_op(EVTCHNOP_init_control, 
_control);
 }
-- 
2.5.5


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

[Xen-devel] [PATCH linux 7/8] xen/evtchn: use xen_vcpu_id mapping

[Vitaly Kuznetsov]

Use the newly introduced xen_vcpu_id mapping to get Xen's idea of vCPU id
for CPU0.

Signed-off-by: Vitaly Kuznetsov 
---
 drivers/xen/evtchn.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index f4edd6df..0fc6be4 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -448,7 +448,7 @@ static long evtchn_ioctl(struct file *file,
break;
 
bind_virq.virq = bind.virq;
-   bind_virq.vcpu = 0;
+   bind_virq.vcpu = per_cpu(xen_vcpu_id, 0);
rc = HYPERVISOR_event_channel_op(EVTCHNOP_bind_virq,
 _virq);
if (rc != 0)
-- 
2.5.5


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

Re: [Xen-devel] [PATCH v5 05/17] xen/passthrough: x86: Use INVALID_GFN rather than INVALID_MFN

[Juergen Gross]

On 28/06/16 18:43, Andrew Cooper wrote:
> On 28/06/16 17:17, Julien Grall wrote:
>> A variable containing a guest frame should be compared to INVALID_GFN
>> and not INVALID_GFN.

I think the text should be changed? I'd expect one 'G' being replaced
bay 'M'. :-)


Juergen

>>
>> Signed-off-by: Julien Grall 
> 
> Reviewed-by: Andrew Cooper 
> 
> I suspect these (mis)uses predate my movement of INVALID_GFN from x86
> paging code to common code.
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 


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

Re: [Xen-devel] [PATCH] x86/EFI + Live Patch: avoid symbol address truncation

[Andrew Cooper]

On 28/06/16 17:11, Jan Beulich wrote:
>>> --- a/xen/arch/x86/xen.lds.S
>>> +++ b/xen/arch/x86/xen.lds.S
>>> @@ -40,9 +40,20 @@ SECTIONS
>>>  #if !defined(EFI)
>>>. = __XEN_VIRT_START;
>>>__image_base__ = .;
>>> +#else
>>> +  . = __image_base__;
>>>  #endif
>>>  
>>> +#if 0
>>> +/*
>>> + * We don't really use this symbol anywhere, and the way it would get 
>>> defined
>>> + * here would result in it having a negative (wrapped to huge positive)
>>> + * offset relative to the .text section. That, in turn, causes an assembler
>>> + * truncation warning when including all symbols in the symbol table for 
>>> Live
>>> + * Patching code.
>>> + */
>>>__2M_text_start = .; /* Start of 2M superpages, mapped RX. */
>>> +#endif
>>>  
>>>. = __XEN_VIRT_START + MB(1);
>>>_start = .;
>>> @@ -194,14 +205,13 @@ SECTIONS
>>> *(.ctors)
>>> __ctors_end = .;
>>>} :text
>>> -  . = ALIGN(PAGE_SIZE);
>>> -  __init_end = .;
>>>  
>>>  #ifdef EFI
>>>. = ALIGN(MB(2));
>>>  #else
>>>. = ALIGN(PAGE_SIZE);
>>>  #endif
>>> +  __init_end = .;
>>>__2M_init_end = .;
>>>  
>>>__2M_rwdata_start = .;   /* Start of 2M superpages, mapped RW. */
>>> @@ -296,7 +306,6 @@ ASSERT(__image_base__ > XEN_VIRT_START |
>>>  ASSERT(kexec_reloc_size - kexec_reloc <= PAGE_SIZE, "kexec_reloc is too 
>> large")
>>>  #endif
>>>  
>>> -ASSERT(IS_ALIGNED(__2M_text_start,   MB(2)), "__2M_text_start misaligned")
>> If we are #if 0'ing the symbol for documentation purposes, can we #if 0
>> this as well?
> I considered it, but the two #if-s would end up disconnected. And
> with the symbol being first thing in the image (plus the fact that so
> far the assertion was there _without_ triggering despite there
> being a problem - just one it couldn't detect), I think chances are
> slim that it getting fully removed would be a significant problem.
> I.e. I'd prefer the patch to remain as is in this regard, but if the
> only way to get it acked is to do as you suggest, I would
> (hesitantly) do so.

Ok.  I suppose it is sufficiently well documented because of the other
alignment assertions.

With the %lu fix, Reviewed-by: Andrew Cooper 

~Andrew

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

Re: [Xen-devel] making xenstore domain easy configurable

[Doug Goldstein]

On 6/28/16 11:27 AM, Jan Beulich wrote:
 On 28.06.16 at 15:59,  wrote:
>> For xenstored running in the same domain as the toolstack, sockets are
>> less overhead than the shared memory ring, as no hypercalls are
>> involved.  There is also the unfortunate problem that one of the two
>> linux devices for xenstored *still* causes deadlocks when used; a
>> problem which is unresolved from Linux 3.14.
> 
> And these deadlocks aren't possibly related to the introduction
> of FMODE_ATOMIC_POS, and hence would be resolved by
> https://patchwork.kernel.org/patch/8752411/(or something along
> those lines, if nonseekable_open() isn't used on that code path)?
> I ask because we had a similar report, but when I put together the
> (refused upstream) patch I assumed the files under /dev wouldn't
> have the same issue (and I still didn't check whether they would).
> 
> Jan
> 

They are related to FMODE_ATOMIC_POS. The nodes under /dev don't
experience the same issues. Jonathan Creekmore and I submitted patches
to make /dev/xen/xenbus and /dev/xen/privcmd the preferred interfaces
used by the Xen tools over their /proc/xen/ counterparts in an attempt
to prevent people from being bitten by that. One of the patches made it
into 4.6 and the other didn't make it in until 4.7.

-- 
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] [PATCH] xen/arm: io: Protect the handlers with a read-write lock

[Julien Grall]

Currently, accessing the I/O handlers does not require to take a lock
because new handlers are always added at the end of the array. In a
follow-up patch, this array will be sort to optimize the look up.

Given that most of the time the I/O handlers will not be modify,
using a spinlock will add contention when multiple vCPU are accessing
the emulated MMIOs. So use a read-write lock to protected the handlers.

Finally, take the opportunity to re-indent correctly domain_io_init.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/io.c  | 47 +++---
 xen/include/asm-arm/mmio.h |  3 ++-
 2 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 0156755..5a96836 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -70,23 +70,39 @@ static int handle_write(const struct mmio_handler *handler, 
struct vcpu *v,
handler->priv);
 }
 
-int handle_mmio(mmio_info_t *info)
+static const struct mmio_handler *find_mmio_handler(struct domain *d,
+paddr_t gpa)
 {
-struct vcpu *v = current;
-int i;
-const struct mmio_handler *handler = NULL;
-const struct vmmio *vmmio = >domain->arch.vmmio;
+const struct mmio_handler *handler;
+unsigned int i;
+struct vmmio *vmmio = >arch.vmmio;
+
+read_lock(>lock);
 
 for ( i = 0; i < vmmio->num_entries; i++ )
 {
 handler = >handlers[i];
 
-if ( (info->gpa >= handler->addr) &&
- (info->gpa < (handler->addr + handler->size)) )
+if ( (gpa >= handler->addr) &&
+ (gpa < (handler->addr + handler->size)) )
 break;
 }
 
 if ( i == vmmio->num_entries )
+handler = NULL;
+
+read_unlock(>lock);
+
+return handler;
+}
+
+int handle_mmio(mmio_info_t *info)
+{
+struct vcpu *v = current;
+const struct mmio_handler *handler = NULL;
+
+handler = find_mmio_handler(v->domain, info->gpa);
+if ( !handler )
 return 0;
 
 if ( info->dabt.write )
@@ -104,7 +120,7 @@ void register_mmio_handler(struct domain *d,
 
 BUG_ON(vmmio->num_entries >= MAX_IO_HANDLER);
 
-spin_lock(>lock);
+write_lock(>lock);
 
 handler = >handlers[vmmio->num_entries];
 
@@ -113,24 +129,17 @@ void register_mmio_handler(struct domain *d,
 handler->size = size;
 handler->priv = priv;
 
-/*
- * handle_mmio is not using the lock to avoid contention.
- * Make sure the other processors see the new handler before
- * updating the number of entries
- */
-dsb(ish);
-
 vmmio->num_entries++;
 
-spin_unlock(>lock);
+write_unlock(>lock);
 }
 
 int domain_io_init(struct domain *d)
 {
-   spin_lock_init(>arch.vmmio.lock);
-   d->arch.vmmio.num_entries = 0;
+rwlock_init(>arch.vmmio.lock);
+d->arch.vmmio.num_entries = 0;
 
-   return 0;
+return 0;
 }
 
 /*
diff --git a/xen/include/asm-arm/mmio.h b/xen/include/asm-arm/mmio.h
index da1cc2e..32f10f2 100644
--- a/xen/include/asm-arm/mmio.h
+++ b/xen/include/asm-arm/mmio.h
@@ -20,6 +20,7 @@
 #define __ASM_ARM_MMIO_H__
 
 #include 
+#include 
 #include 
 #include 
 
@@ -51,7 +52,7 @@ struct mmio_handler {
 
 struct vmmio {
 int num_entries;
-spinlock_t lock;
+rwlock_t lock;
 struct mmio_handler handlers[MAX_IO_HANDLER];
 };
 
-- 
1.9.1


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

[Xen-devel] GDBSX Maintainer

[Julien Grall]

Hi,

I had to modify some code in arch/x86/debug.c and noticed that Mukesh is 
still the maintainer. IIRC he left Oracle quite a while ago, so my 
e-mail was bounced by the server.


Do we have a new e-mail address for me? If not, does anyone plan to 
maintain this code? Shall we mark the code as "Orphan"?


Cheers,

 Forwarded Message 
Subject: Undelivered Mail Returned to Sender
Date: Tue, 28 Jun 2016 09:18:43 -0700
From: Mail Delivery System 
To: julien.gr...@arm.com

This is the mail system at host usa-sjc-mx-foss1.foss.arm.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

   The mail system

: host userp2040.oracle.com[156.151.31.90] 
said: 550

5.1.1 User Unknown (in reply to RCPT TO command)



Reporting-MTA: dns; usa-sjc-mx-foss1.foss.arm.com
X-Postfix-Queue-ID: DFADD2F
X-Postfix-Sender: rfc822; julien.grall@arm.com
Arrival-Date: Tue, 28 Jun 2016 09:18:26 -0700 (PDT)

Final-Recipient: rfc822; mukesh.rathor@oracle.com
Original-Recipient: rfc822;mukesh.rathor@oracle.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; userp2040.oracle.com
Diagnostic-Code: smtp; 550 5.1.1 User Unknown

--- Begin Message ---
Hello all,

Some of the ARM functions are mixing gfn vs mfn and even physical vs frame.

To avoid more confusion, this patch series makes use of the terminology
described in xen/include/xen/mm.h and the associated typesafe.

This series requires the patch [1] to be applied beforehand. I pushed a
branch with this patch and this series applied on xenbits:
git://xenbits.xen.org/people/julieng/xen-unstable.git branch typesafe-v4

For all the changes see in each patch.

Yours sincerely,

[1] http://lists.xenproject.org/archives/html/xen-devel/2016-06/msg01744.html

Cc: Andrew Cooper 
Cc: Boris Ostrovsky 
Cc: Christoph Egger 
Cc: Feng Wu 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Konrad Rzeszutek Wilk 
Cc: Liu Jinsong 
Cc: Mukesh Rathor 
Cc: Paul Durrant 
Cc: Shannon Zhao 
Cc: Stefano Stabellini 
Cc: Suravee Suthikulpanit 
Cc: Tim Deegan 
Cc: Wei Liu 

Julien Grall (17):
  xen: Use typesafe gfn/mfn in guest_physmap_* helpers
  xen: Use typesafe gfn in xenmem_add_to_physmap_one
  xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the
typesafe gfn
  xen: Use the typesafe mfn and gfn in map_mmio_regions...
  xen/passthrough: x86: Use INVALID_GFN rather than INVALID_MFN
  xen: Use a typesafe to define INVALID_MFN
  xen: Use a typesafe to define INVALID_GFN
  xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and
mfn
  xen/arm: Rework the interface of p2m_cache_flush and use typesafe gfn
  xen/arm: map_regions_rw_cache: Map the region with p2m->default_access
  xen/arm: dom0_build: Remove dead code in allocate_memory
  xen/arm: p2m: Remove unused operation ALLOCATE
  xen/arm: Use the typesafes mfn and gfn in map_dev_mmio_region...
  xen/arm: Use the typesafes mfn and gfn in map_regions_rw_cache ...
  xen/arm: p2m: Introduce helpers to insert and remove mapping
  xen/arm: p2m: Use typesafe gfn for {max,lowest}_mapped_gfn
  xen/arm: p2m: Rework the interface of apply_p2m_changes and use
typesafe

 xen/arch/arm/domain.c   |   4 +-
 xen/arch/arm/domain_build.c |  72 ++---
 xen/arch/arm/domctl.c   |   2 +-
 xen/arch/arm/gic-v2.c   |   4 +-
 xen/arch/arm/mm.c   |  20 +--
 xen/arch/arm/p2m.c  | 269 
 xen/arch/arm/platforms/exynos5.c|   8 +-
 xen/arch/arm/platforms/omap5.c  |  16 +-
 xen/arch/arm/traps.c|  21 +--
 xen/arch/arm/vgic-v2.c  |   4 +-
 xen/arch/x86/cpu/mcheck/mce.c   |   2 +-
 xen/arch/x86/debug.c|  64 
 xen/arch/x86/domain.c   |   7 +-
 xen/arch/x86/domain_build.c |   6 +-
 xen/arch/x86/hvm/emulate.c  |   7 +-
 xen/arch/x86/hvm/hvm.c  |  12 +-
 xen/arch/x86/hvm/ioreq.c|  16 +-
 xen/arch/x86/hvm/svm/nestedsvm.c|   2 +-
 xen/arch/x86/hvm/viridian.c |   6 +-
 xen/arch/x86/hvm/vmx/vmx.c  |   8 +-
 xen/arch/x86/mm.c   |  21 

Re: [Xen-devel] making xenstore domain easy configurable

[Jan Beulich]

>>> On 28.06.16 at 15:59,  wrote:
> For xenstored running in the same domain as the toolstack, sockets are
> less overhead than the shared memory ring, as no hypercalls are
> involved.  There is also the unfortunate problem that one of the two
> linux devices for xenstored *still* causes deadlocks when used; a
> problem which is unresolved from Linux 3.14.

And these deadlocks aren't possibly related to the introduction
of FMODE_ATOMIC_POS, and hence would be resolved by
https://patchwork.kernel.org/patch/8752411/(or something along
those lines, if nonseekable_open() isn't used on that code path)?
I ask because we had a similar report, but when I put together the
(refused upstream) patch I assumed the files under /dev wouldn't
have the same issue (and I still didn't check whether they would).

Jan


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

[Xen-devel] [PATCH v5 13/17] xen/arm: Use the typesafes mfn and gfn in map_dev_mmio_region...

[Julien Grall]

to avoid mixing machine frame with guest frame. Also drop the prefix start_.

Signed-off-by: Julien Grall 

---
Changes in v4:
- Patch added
---
 xen/arch/arm/mm.c |  2 +-
 xen/arch/arm/p2m.c| 10 +-
 xen/include/asm-arm/p2m.h |  4 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0e408f8..b5fc034 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1145,7 +1145,7 @@ int xenmem_add_to_physmap_one(
 if ( extra.res0 )
 return -EOPNOTSUPP;
 
-rc = map_dev_mmio_region(d, gfn_x(gfn), 1, idx);
+rc = map_dev_mmio_region(d, gfn, 1, _mfn(idx));
 return rc;
 
 default:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index f11094e..5ffc3df 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1211,20 +1211,20 @@ int unmap_mmio_regions(struct domain *d,
 }
 
 int map_dev_mmio_region(struct domain *d,
-unsigned long start_gfn,
+gfn_t gfn,
 unsigned long nr,
-unsigned long mfn)
+mfn_t mfn)
 {
 int res;
 
-if ( !(nr && iomem_access_permitted(d, mfn, mfn + nr - 1)) )
+if ( !(nr && iomem_access_permitted(d, mfn_x(mfn), mfn_x(mfn) + nr - 1)) )
 return 0;
 
-res = map_mmio_regions(d, _gfn(start_gfn), nr, _mfn(mfn));
+res = map_mmio_regions(d, gfn, nr, mfn);
 if ( res < 0 )
 {
 printk(XENLOG_G_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",
-   mfn, mfn + nr - 1, d->domain_id);
+   mfn_x(mfn), mfn_x(mfn) + nr - 1, d->domain_id);
 return res;
 }
 
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 4752161..8d29eda 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -152,9 +152,9 @@ int unmap_regions_rw_cache(struct domain *d,
unsigned long mfn);
 
 int map_dev_mmio_region(struct domain *d,
-unsigned long start_gfn,
+gfn_t gfn,
 unsigned long nr,
-unsigned long mfn);
+mfn_t mfn);
 
 int guest_physmap_add_entry(struct domain *d,
 gfn_t gfn,
-- 
1.9.1


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

[Xen-devel] [PATCH v5 16/17] xen/arm: p2m: Use typesafe gfn for {max, lowest}_mapped_gfn

[Julien Grall]

Signed-off-by: Julien Grall 

---
Changes in v4:
- Patch added
---
 xen/arch/arm/mm.c |  2 +-
 xen/arch/arm/p2m.c| 18 +-
 xen/include/asm-arm/p2m.h |  4 ++--
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b5fc034..4e256c2 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1004,7 +1004,7 @@ int page_is_ram_type(unsigned long mfn, unsigned long 
mem_type)
 
 unsigned long domain_get_maximum_gpfn(struct domain *d)
 {
-return d->arch.p2m.max_mapped_gfn;
+return gfn_x(d->arch.p2m.max_mapped_gfn);
 }
 
 void share_xen_page_with_guest(struct page_info *page,
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index a5b584b..9fdc417 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -976,7 +976,7 @@ static int apply_p2m_changes(struct domain *d,
  * This is set in preempt_count_limit.
  *
  */
-p2m->lowest_mapped_gfn = addr >> PAGE_SHIFT;
+p2m->lowest_mapped_gfn = _gfn(addr >> PAGE_SHIFT);
 rc = -ERESTART;
 goto out;
 
@@ -1117,8 +1117,8 @@ static int apply_p2m_changes(struct domain *d,
 
 if ( op == INSERT )
 {
-p2m->max_mapped_gfn = max(p2m->max_mapped_gfn, egfn);
-p2m->lowest_mapped_gfn = min(p2m->lowest_mapped_gfn, sgfn);
+p2m->max_mapped_gfn = gfn_max(p2m->max_mapped_gfn, _gfn(egfn));
+p2m->lowest_mapped_gfn = gfn_min(p2m->lowest_mapped_gfn, _gfn(sgfn));
 }
 
 rc = 0;
@@ -1383,8 +1383,8 @@ int p2m_init(struct domain *d)
 
 p2m->root = NULL;
 
-p2m->max_mapped_gfn = 0;
-p2m->lowest_mapped_gfn = ULONG_MAX;
+p2m->max_mapped_gfn = _gfn(0);
+p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
 
 p2m->default_access = p2m_access_rwx;
 p2m->mem_access_enabled = false;
@@ -1401,8 +1401,8 @@ int relinquish_p2m_mapping(struct domain *d)
 struct p2m_domain *p2m = >arch.p2m;
 
 return apply_p2m_changes(d, RELINQUISH,
-  pfn_to_paddr(p2m->lowest_mapped_gfn),
-  pfn_to_paddr(p2m->max_mapped_gfn),
+  pfn_to_paddr(gfn_x(p2m->lowest_mapped_gfn)),
+  pfn_to_paddr(gfn_x(p2m->max_mapped_gfn)),
   pfn_to_paddr(mfn_x(INVALID_MFN)),
   MATTR_MEM, 0, p2m_invalid,
   d->arch.p2m.default_access);
@@ -1413,8 +1413,8 @@ int p2m_cache_flush(struct domain *d, gfn_t start, 
unsigned long nr)
 struct p2m_domain *p2m = >arch.p2m;
 gfn_t end = gfn_add(start, nr);
 
-start = gfn_max(start, _gfn(p2m->lowest_mapped_gfn));
-end = gfn_min(end, _gfn(p2m->max_mapped_gfn));
+start = gfn_max(start, p2m->lowest_mapped_gfn);
+end = gfn_min(end, p2m->max_mapped_gfn);
 
 return apply_p2m_changes(d, CACHEFLUSH,
  pfn_to_paddr(gfn_x(start)),
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 6e258b9..34096bc 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -34,13 +34,13 @@ struct p2m_domain {
 /* Highest guest frame that's ever been mapped in the p2m
  * Only takes into account ram and foreign mapping
  */
-unsigned long max_mapped_gfn;
+gfn_t max_mapped_gfn;
 
 /* Lowest mapped gfn in the p2m. When releasing mapped gfn's in a
  * preemptible manner this is update to track recall where to
  * resume the search. Apart from during teardown this can only
  * decrease. */
-unsigned long lowest_mapped_gfn;
+gfn_t lowest_mapped_gfn;
 
 /* Gather some statistics for information purposes only */
 struct {
-- 
1.9.1


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

[Xen-devel] [PATCH v5 08/17] xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and mfn

[Julien Grall]

The prototype and the declaration of p2m_lookup disagree on how the
function should be used. One expect a frame number whilst the other
an address.

Thankfully, everyone is using with an address today. However, most of
the callers have to convert a guest frame to an address. Modify
the interface to take a guest physical frame in parameter and return
a machine frame.

Whilst modifying the interface, use typesafe gfn and mfn for clarity
and catching possible misusage.

Signed-off-by: Julien Grall 

---
Changes in v4:
- Use INVALID_MFN_T when possible
---
 xen/arch/arm/p2m.c| 43 +++
 xen/arch/arm/traps.c  | 21 +++--
 xen/include/asm-arm/p2m.h |  7 +++
 3 files changed, 37 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index c938dde..54a363a 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -140,14 +140,15 @@ void flush_tlb_domain(struct domain *d)
 }
 
 /*
- * Lookup the MFN corresponding to a domain's PFN.
+ * Lookup the MFN corresponding to a domain's GFN.
  *
  * There are no processor functions to do a stage 2 only lookup therefore we
  * do a a software walk.
  */
-static paddr_t __p2m_lookup(struct domain *d, paddr_t paddr, p2m_type_t *t)
+static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
 {
 struct p2m_domain *p2m = >arch.p2m;
+const paddr_t paddr = pfn_to_paddr(gfn_x(gfn));
 const unsigned int offsets[4] = {
 zeroeth_table_offset(paddr),
 first_table_offset(paddr),
@@ -158,7 +159,7 @@ static paddr_t __p2m_lookup(struct domain *d, paddr_t 
paddr, p2m_type_t *t)
 ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK
 };
 lpae_t pte, *map;
-paddr_t maddr = INVALID_PADDR;
+mfn_t mfn = INVALID_MFN;
 paddr_t mask = 0;
 p2m_type_t _t;
 unsigned int level, root_table;
@@ -216,21 +217,22 @@ static paddr_t __p2m_lookup(struct domain *d, paddr_t 
paddr, p2m_type_t *t)
 {
 ASSERT(mask);
 ASSERT(pte.p2m.type != p2m_invalid);
-maddr = (pte.bits & PADDR_MASK & mask) | (paddr & ~mask);
+mfn = _mfn(paddr_to_pfn((pte.bits & PADDR_MASK & mask) |
+(paddr & ~mask)));
 *t = pte.p2m.type;
 }
 
 err:
-return maddr;
+return mfn;
 }
 
-paddr_t p2m_lookup(struct domain *d, paddr_t paddr, p2m_type_t *t)
+mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
 {
-paddr_t ret;
+mfn_t ret;
 struct p2m_domain *p2m = >arch.p2m;
 
 spin_lock(>lock);
-ret = __p2m_lookup(d, paddr, t);
+ret = __p2m_lookup(d, gfn, t);
 spin_unlock(>lock);
 
 return ret;
@@ -493,8 +495,9 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
  * No setting was found in the Radix tree. Check if the
  * entry exists in the page-tables.
  */
-paddr_t maddr = __p2m_lookup(d, gfn_x(gfn) << PAGE_SHIFT, NULL);
-if ( INVALID_PADDR == maddr )
+mfn_t mfn = __p2m_lookup(d, gfn, NULL);
+
+if ( mfn_eq(mfn, INVALID_MFN) )
 return -ESRCH;
 
 /* If entry exists then its rwx. */
@@ -1483,8 +1486,7 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t 
start_mfn, xen_pfn_t end_mfn)
 
 mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
 {
-paddr_t p = p2m_lookup(d, pfn_to_paddr(gfn_x(gfn)), NULL);
-return _mfn(p >> PAGE_SHIFT);
+return p2m_lookup(d, gfn, NULL);
 }
 
 /*
@@ -1498,8 +1500,8 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag)
 {
 long rc;
 paddr_t ipa;
-unsigned long maddr;
-unsigned long mfn;
+gfn_t gfn;
+mfn_t mfn;
 xenmem_access_t xma;
 p2m_type_t t;
 struct page_info *page = NULL;
@@ -1508,11 +1510,13 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag)
 if ( rc < 0 )
 goto err;
 
+gfn = _gfn(paddr_to_pfn(ipa));
+
 /*
  * We do this first as this is faster in the default case when no
  * permission is set on the page.
  */
-rc = __p2m_get_mem_access(current->domain, _gfn(paddr_to_pfn(ipa)), );
+rc = __p2m_get_mem_access(current->domain, gfn, );
 if ( rc < 0 )
 goto err;
 
@@ -1561,12 +1565,11 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag)
  * We had a mem_access permission limiting the access, but the page type
  * could also be limiting, so we need to check that as well.
  */
-maddr = __p2m_lookup(current->domain, ipa, );
-if ( maddr == INVALID_PADDR )
+mfn = __p2m_lookup(current->domain, gfn, );
+if ( mfn_eq(mfn, INVALID_MFN) )
 goto err;
 
-mfn = maddr >> PAGE_SHIFT;
-if ( !mfn_valid(mfn) )
+if ( !mfn_valid(mfn_x(mfn)) )
 goto err;
 
 /*
@@ -1575,7 +1578,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag)
 if ( t != p2m_ram_rw )
 goto err;
 
-page = mfn_to_page(mfn);
+

[Xen-devel] [PATCH v5 12/17] xen/arm: p2m: Remove unused operation ALLOCATE

[Julien Grall]

The operation ALLOCATE is unused. If we ever need it, it could be
reimplemented with INSERT.

Signed-off-by: Julien Grall 

---
Changes in v4:
- Patch added
---
 xen/arch/arm/p2m.c| 67 ++-
 xen/include/asm-arm/p2m.h |  3 ---
 2 files changed, 2 insertions(+), 68 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index fcc4513..f11094e 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -547,7 +547,6 @@ static int p2m_mem_access_radix_set(struct p2m_domain *p2m, 
unsigned long pfn,
 
 enum p2m_operation {
 INSERT,
-ALLOCATE,
 REMOVE,
 RELINQUISH,
 CACHEFLUSH,
@@ -667,7 +666,6 @@ static int apply_one_level(struct domain *d,
 {
 const paddr_t level_size = level_sizes[level];
 const paddr_t level_mask = level_masks[level];
-const paddr_t level_shift = level_shifts[level];
 
 struct p2m_domain *p2m = >arch.p2m;
 lpae_t pte;
@@ -678,58 +676,6 @@ static int apply_one_level(struct domain *d,
 
 switch ( op )
 {
-case ALLOCATE:
-ASSERT(level < 3 || !p2m_valid(orig_pte));
-ASSERT(*maddr == 0);
-
-if ( p2m_valid(orig_pte) )
-return P2M_ONE_DESCEND;
-
-if ( is_mapping_aligned(*addr, end_gpaddr, 0, level_size) &&
-   /* We only create superpages when mem_access is not in use. */
- (level == 3 || (level < 3 && !p2m->mem_access_enabled)) )
-{
-struct page_info *page;
-
-page = alloc_domheap_pages(d, level_shift - PAGE_SHIFT, 0);
-if ( page )
-{
-rc = p2m_mem_access_radix_set(p2m, paddr_to_pfn(*addr), a);
-if ( rc < 0 )
-{
-free_domheap_page(page);
-return rc;
-}
-
-pte = mfn_to_p2m_entry(page_to_mfn(page), mattr, t, a);
-if ( level < 3 )
-pte.p2m.table = 0;
-p2m_write_pte(entry, pte, flush_cache);
-p2m->stats.mappings[level]++;
-
-*addr += level_size;
-
-return P2M_ONE_PROGRESS;
-}
-else if ( level == 3 )
-return -ENOMEM;
-}
-
-/* L3 is always suitably aligned for mapping (handled, above) */
-BUG_ON(level == 3);
-
-/*
- * If we get here then we failed to allocate a sufficiently
- * large contiguous region for this level (which can't be
- * L3) or mem_access is in use. Create a page table and
- * continue to descend so we try smaller allocations.
- */
-rc = p2m_create_table(d, entry, 0, flush_cache);
-if ( rc < 0 )
-return rc;
-
-return P2M_ONE_DESCEND;
-
 case INSERT:
 if ( is_mapping_aligned(*addr, end_gpaddr, *maddr, level_size) &&
/*
@@ -1169,7 +1115,7 @@ static int apply_p2m_changes(struct domain *d,
 }
 }
 
-if ( op == ALLOCATE || op == INSERT )
+if ( op == INSERT )
 {
 p2m->max_mapped_gfn = max(p2m->max_mapped_gfn, egfn);
 p2m->lowest_mapped_gfn = min(p2m->lowest_mapped_gfn, sgfn);
@@ -1197,7 +1143,7 @@ out:
 
 spin_unlock(>lock);
 
-if ( rc < 0 && ( op == INSERT || op == ALLOCATE ) &&
+if ( rc < 0 && ( op == INSERT ) &&
  addr != start_gpaddr )
 {
 BUG_ON(addr == end_gpaddr);
@@ -1212,15 +1158,6 @@ out:
 return rc;
 }
 
-int p2m_populate_ram(struct domain *d,
- paddr_t start,
- paddr_t end)
-{
-return apply_p2m_changes(d, ALLOCATE, start, end,
- 0, MATTR_MEM, 0, p2m_ram_rw,
- d->arch.p2m.default_access);
-}
-
 int map_regions_rw_cache(struct domain *d,
  unsigned long start_gfn,
  unsigned long nr,
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 8a96e68..4752161 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -141,9 +141,6 @@ mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t 
*t);
 /* Clean & invalidate caches corresponding to a region of guest address space 
*/
 int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr);
 
-/* Setup p2m RAM mapping for domain d from start-end. */
-int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
-
 int map_regions_rw_cache(struct domain *d,
  unsigned long start_gfn,
  unsigned long nr_mfns,
-- 
1.9.1


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

[Xen-devel] [PATCH v5 06/17] xen: Use a typesafe to define INVALID_MFN

[Julien Grall]

Also take the opportunity to convert arch/x86/debug.c to the typesafe
mfn.

Signed-off-by: Julien Grall 

---
Cc: Christoph Egger 
Cc: Liu Jinsong 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Mukesh Rathor 
Cc: Paul Durrant 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Tim Deegan 

Changes in v5:
- Patch added
---
 xen/arch/arm/p2m.c  |  4 ++--
 xen/arch/x86/cpu/mcheck/mce.c   |  2 +-
 xen/arch/x86/debug.c| 50 ---
 xen/arch/x86/hvm/hvm.c  |  6 ++---
 xen/arch/x86/hvm/viridian.c |  6 ++---
 xen/arch/x86/hvm/vmx/vmx.c  |  2 +-
 xen/arch/x86/mm/guest_walk.c|  4 ++--
 xen/arch/x86/mm/hap/hap.c   |  4 ++--
 xen/arch/x86/mm/p2m-ept.c   |  6 ++---
 xen/arch/x86/mm/p2m-pod.c   | 18 +++---
 xen/arch/x86/mm/p2m-pt.c| 18 +++---
 xen/arch/x86/mm/p2m.c   | 52 -
 xen/arch/x86/mm/paging.c| 12 +-
 xen/arch/x86/mm/shadow/common.c | 44 +-
 xen/arch/x86/mm/shadow/multi.c  | 36 ++--
 xen/common/domain.c |  6 ++---
 xen/common/grant_table.c|  6 ++---
 xen/include/xen/mm.h|  2 +-
 18 files changed, 140 insertions(+), 138 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 34563bb..d690602 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1461,7 +1461,7 @@ int relinquish_p2m_mapping(struct domain *d)
 return apply_p2m_changes(d, RELINQUISH,
   pfn_to_paddr(p2m->lowest_mapped_gfn),
   pfn_to_paddr(p2m->max_mapped_gfn),
-  pfn_to_paddr(INVALID_MFN),
+  pfn_to_paddr(mfn_x(INVALID_MFN)),
   MATTR_MEM, 0, p2m_invalid,
   d->arch.p2m.default_access);
 }
@@ -1476,7 +1476,7 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t 
start_mfn, xen_pfn_t end_mfn)
 return apply_p2m_changes(d, CACHEFLUSH,
  pfn_to_paddr(start_mfn),
  pfn_to_paddr(end_mfn),
- pfn_to_paddr(INVALID_MFN),
+ pfn_to_paddr(mfn_x(INVALID_MFN)),
  MATTR_MEM, 0, p2m_invalid,
  d->arch.p2m.default_access);
 }
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index edcbe48..2695b0c 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1455,7 +1455,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 gfn = PFN_DOWN(gaddr);
 mfn = mfn_x(get_gfn(d, gfn, ));
 
-if ( mfn == INVALID_MFN )
+if ( mfn == mfn_x(INVALID_MFN) )
 {
 put_gfn(d, gfn);
 put_domain(d);
diff --git a/xen/arch/x86/debug.c b/xen/arch/x86/debug.c
index 58cae22..3479f7c 100644
--- a/xen/arch/x86/debug.c
+++ b/xen/arch/x86/debug.c
@@ -43,11 +43,11 @@ typedef unsigned long dbgva_t;
 typedef unsigned char dbgbyte_t;
 
 /* Returns: mfn for the given (hvm guest) vaddr */
-static unsigned long 
+static mfn_t
 dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr,
 unsigned long *gfn)
 {
-unsigned long mfn;
+mfn_t mfn;
 uint32_t pfec = PFEC_page_present;
 p2m_type_t gfntype;
 
@@ -60,16 +60,17 @@ dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr,
 return INVALID_MFN;
 }
 
-mfn = mfn_x(get_gfn(dp, *gfn, )); 
+mfn = get_gfn(dp, *gfn, );
 if ( p2m_is_readonly(gfntype) && toaddr )
 {
 DBGP2("kdb:p2m_is_readonly: gfntype:%x\n", gfntype);
 mfn = INVALID_MFN;
 }
 else
-DBGP2("X: vaddr:%lx domid:%d mfn:%lx\n", vaddr, dp->domain_id, mfn);
+DBGP2("X: vaddr:%lx domid:%d mfn:%lx\n",
+  vaddr, dp->domain_id, mfn_x(mfn));
 
-if ( mfn == INVALID_MFN )
+if ( mfn_eq(mfn, INVALID_MFN) )
 {
 put_gfn(dp, *gfn);
 *gfn = INVALID_GFN;
@@ -91,7 +92,7 @@ dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr,
  *   mode.
  * Returns: mfn for the given (pv guest) vaddr 
  */
-static unsigned long 
+static mfn_t
 dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t pgd3val)
 {
 l4_pgentry_t l4e, *l4t;
@@ -99,31 +100,31 @@ dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t 
pgd3val)
 l2_pgentry_t l2e, *l2t;
 l1_pgentry_t l1e, *l1t;
 unsigned long cr3 = (pgd3val ? pgd3val : dp->vcpu[0]->arch.cr3);
-unsigned long mfn = cr3 >> PAGE_SHIFT;
+mfn_t mfn = _mfn(cr3 >> PAGE_SHIFT);

[Xen-devel] [PATCH v5 11/17] xen/arm: dom0_build: Remove dead code in allocate_memory

[Julien Grall]

The code to allocate memory when dom0 does not use direct mapping is
relying on the presence of memory node in the DT.

However, they are not present when booting using UEFI or when using
ACPI.

Rather than fixing the code, remove it because dom0 is always direct
memory mapped and therefore the code is never tested. Also add a
check to avoid disabling direct memory mapped and not implementing
the associated RAM bank allocation.

Signed-off-by: Julien Grall 

---
Changes in v4:
- Patch added
---
 xen/arch/arm/domain_build.c | 58 ++---
 1 file changed, 7 insertions(+), 51 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 49185f0..923f48a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -235,7 +235,7 @@ fail:
  * (as described above) we allow higher allocations and continue until
  * that runs out (or we have allocated sufficient dom0 memory).
  */
-static void allocate_memory_11(struct domain *d, struct kernel_info *kinfo)
+static void allocate_memory(struct domain *d, struct kernel_info *kinfo)
 {
 const unsigned int min_low_order =
 get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
@@ -247,6 +247,12 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
 bool_t lowmem = is_32bit_domain(d);
 unsigned int bits;
 
+/*
+ * TODO: Implement memory bank allocation when DOM0 is not direct
+ * mapped
+ */
+BUG_ON(!dom0_11_mapping);
+
 printk("Allocating 1:1 mappings totalling %ldMB for dom0:\n",
/* Don't want format this as PRIpaddr (16 digit hex) */
(unsigned long)(kinfo->unassigned_mem >> 20));
@@ -343,56 +349,6 @@ static void allocate_memory_11(struct domain *d, struct 
kernel_info *kinfo)
 }
 }
 
-static void allocate_memory(struct domain *d, struct kernel_info *kinfo)
-{
-
-struct dt_device_node *memory = NULL;
-const void *reg;
-u32 reg_len, reg_size;
-unsigned int bank = 0;
-
-if ( dom0_11_mapping )
-return allocate_memory_11(d, kinfo);
-
-while ( (memory = dt_find_node_by_type(memory, "memory")) )
-{
-int l;
-
-dt_dprintk("memory node\n");
-
-reg_size = dt_cells_to_size(dt_n_addr_cells(memory) + 
dt_n_size_cells(memory));
-
-reg = dt_get_property(memory, "reg", _len);
-if ( reg == NULL )
-panic("Memory node has no reg property");
-
-for ( l = 0;
-  kinfo->unassigned_mem > 0 && l + reg_size <= reg_len
-  && kinfo->mem.nr_banks < NR_MEM_BANKS;
-  l += reg_size )
-{
-paddr_t start, size;
-
-if ( dt_device_get_address(memory, bank, , ) )
-panic("Unable to retrieve the bank %u for %s",
-  bank, dt_node_full_name(memory));
-
-if ( size > kinfo->unassigned_mem )
-size = kinfo->unassigned_mem;
-
-printk("Populate P2M %#"PRIx64"->%#"PRIx64"\n",
-   start, start + size);
-if ( p2m_populate_ram(d, start, start + size) < 0 )
-panic("Failed to populate P2M");
-kinfo->mem.bank[kinfo->mem.nr_banks].start = start;
-kinfo->mem.bank[kinfo->mem.nr_banks].size = size;
-kinfo->mem.nr_banks++;
-
-kinfo->unassigned_mem -= size;
-}
-}
-}
-
 static int write_properties(struct domain *d, struct kernel_info *kinfo,
 const struct dt_device_node *node)
 {
-- 
1.9.1


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

[Xen-devel] [PATCH v5 05/17] xen/passthrough: x86: Use INVALID_GFN rather than INVALID_MFN

[Julien Grall]

A variable containing a guest frame should be compared to INVALID_GFN
and not INVALID_GFN.

Signed-off-by: Julien Grall 

---
Cc: Suravee Suthikulpanit 
Cc: Jan Beulich 

Changes in v5:
- Patch added
---
 xen/drivers/passthrough/amd/iommu_map.c | 2 +-
 xen/drivers/passthrough/x86/iommu.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_map.c 
b/xen/drivers/passthrough/amd/iommu_map.c
index 1b914ba..c758459 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -555,7 +555,7 @@ static int update_paging_mode(struct domain *d, unsigned 
long gfn)
 unsigned long old_root_mfn;
 struct domain_iommu *hd = dom_iommu(d);
 
-if ( gfn == INVALID_MFN )
+if ( gfn == INVALID_GFN )
 return -EADDRNOTAVAIL;
 ASSERT(!(gfn >> DEFAULT_DOMAIN_ADDRESS_WIDTH));
 
diff --git a/xen/drivers/passthrough/x86/iommu.c 
b/xen/drivers/passthrough/x86/iommu.c
index a18a608..cd435d7 100644
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -61,7 +61,7 @@ int arch_iommu_populate_page_table(struct domain *d)
 unsigned long mfn = page_to_mfn(page);
 unsigned long gfn = mfn_to_gmfn(d, mfn);
 
-if ( gfn != INVALID_MFN )
+if ( gfn != INVALID_GFN )
 {
 ASSERT(!(gfn >> DEFAULT_DOMAIN_ADDRESS_WIDTH));
 BUG_ON(SHARED_M2P(gfn));
-- 
1.9.1


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

[Xen-devel] [PATCH v5 01/17] xen: Use typesafe gfn/mfn in guest_physmap_* helpers

[Julien Grall]

Also rename some variables to gfn or mfn when it does not require much
rework.

Finally replace %hu with %d when printing the domain id in
guest_physmap_add_entry (arch/x86/mm/p2m.c).

Signed-off-by: Julien Grall 
Acked-by: Jan Beulich 
Acked-by: Stefano Stabellini 

---
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 

Changes in v4:
- Add Stefano's Acked-by

Changes in v3:
- Use %d to print the domain id rather than %hu
- Add Jan's Acked-by for non-ARM bits

Changes in v2:
- Don't use a wrapper for x86. Instead use mfn_* to make
the change simpler.
---
 xen/arch/arm/domain_build.c|  2 +-
 xen/arch/arm/mm.c  | 10 ++---
 xen/arch/arm/p2m.c | 20 +-
 xen/arch/x86/domain.c  |  5 ++-
 xen/arch/x86/domain_build.c|  6 +--
 xen/arch/x86/hvm/ioreq.c   |  8 ++--
 xen/arch/x86/mm.c  | 12 +++---
 xen/arch/x86/mm/p2m.c  | 78 --
 xen/common/grant_table.c   |  7 ++--
 xen/common/memory.c| 32 
 xen/drivers/passthrough/arm/smmu.c |  4 +-
 xen/include/asm-arm/p2m.h  | 12 +++---
 xen/include/asm-x86/p2m.h  | 11 +++---
 xen/include/xen/mm.h   |  2 +-
 14 files changed, 110 insertions(+), 99 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 410bb4f..9035486 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -117,7 +117,7 @@ static bool_t insert_11_bank(struct domain *d,
 goto fail;
 }
 
-res = guest_physmap_add_page(d, spfn, spfn, order);
+res = guest_physmap_add_page(d, _gfn(spfn), _mfn(spfn), order);
 if ( res )
 panic("Failed map pages to DOM0: %d", res);
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 2ec211b..5ab9b75 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1153,7 +1153,7 @@ int xenmem_add_to_physmap_one(
 }
 
 /* Map at new location. */
-rc = guest_physmap_add_entry(d, gpfn, mfn, 0, t);
+rc = guest_physmap_add_entry(d, _gfn(gpfn), _mfn(mfn), 0, t);
 
 /* If we fail to add the mapping, we need to drop the reference we
  * took earlier on foreign pages */
@@ -1282,8 +1282,8 @@ int create_grant_host_mapping(unsigned long addr, 
unsigned long frame,
 if ( flags & GNTMAP_readonly )
 t = p2m_grant_map_ro;
 
-rc = guest_physmap_add_entry(current->domain, addr >> PAGE_SHIFT,
- frame, 0, t);
+rc = guest_physmap_add_entry(current->domain, _gfn(addr >> PAGE_SHIFT),
+ _mfn(frame), 0, t);
 
 if ( rc )
 return GNTST_general_error;
@@ -1294,13 +1294,13 @@ int create_grant_host_mapping(unsigned long addr, 
unsigned long frame,
 int replace_grant_host_mapping(unsigned long addr, unsigned long mfn,
 unsigned long new_addr, unsigned int flags)
 {
-unsigned long gfn = (unsigned long)(addr >> PAGE_SHIFT);
+gfn_t gfn = _gfn(addr >> PAGE_SHIFT);
 struct domain *d = current->domain;
 
 if ( new_addr != 0 || (flags & GNTMAP_contains_pte) )
 return GNTST_general_error;
 
-guest_physmap_remove_page(d, gfn, mfn, 0);
+guest_physmap_remove_page(d, gfn, _mfn(mfn), 0);
 
 return GNTST_okay;
 }
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5afae1d..0395a40 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1292,26 +1292,26 @@ int map_dev_mmio_region(struct domain *d,
 }
 
 int guest_physmap_add_entry(struct domain *d,
-unsigned long gpfn,
-unsigned long mfn,
+gfn_t gfn,
+mfn_t mfn,
 unsigned long page_order,
 p2m_type_t t)
 {
 return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(gpfn),
- pfn_to_paddr(gpfn + (1 << page_order)),
- pfn_to_paddr(mfn), MATTR_MEM, 0, t,
+ pfn_to_paddr(gfn_x(gfn)),
+ pfn_to_paddr(gfn_x(gfn) + (1 << page_order)),
+ pfn_to_paddr(mfn_x(mfn)), MATTR_MEM, 0, t,
  d->arch.p2m.default_access);
 }
 
 void guest_physmap_remove_page(struct domain *d,
-   unsigned long gpfn,
-   unsigned long mfn, unsigned int page_order)
+   gfn_t gfn,
+

[Xen-devel] [PATCH v5 03/17] xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the typesafe gfn

[Julien Grall]

The correct acronym for a guest physical frame is gfn. Also use
the typesafe gfn to ensure that a guest frame is effectively used.

Signed-off-by: Julien Grall 
Acked-by: Stefano Stabellini 

---
Changes in v4:
- Add Stefano's acked-by

Changes in v2:
- Remove extra pair of brackets.
---
 xen/arch/arm/domain.c | 4 ++--
 xen/arch/arm/mm.c | 2 +-
 xen/include/asm-arm/domain.h  | 2 +-
 xen/include/asm-arm/grant_table.h | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d8a804c..6ce4645 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -464,13 +464,13 @@ struct domain *alloc_domain_struct(void)
 return NULL;
 
 clear_page(d);
-d->arch.grant_table_gpfn = xzalloc_array(xen_pfn_t, max_grant_frames);
+d->arch.grant_table_gfn = xzalloc_array(gfn_t, max_grant_frames);
 return d;
 }
 
 void free_domain_struct(struct domain *d)
 {
-xfree(d->arch.grant_table_gpfn);
+xfree(d->arch.grant_table_gfn);
 free_xenheap_page(d);
 }
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 6882d54..0e408f8 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1082,7 +1082,7 @@ int xenmem_add_to_physmap_one(
 return -EINVAL;
 }
 
-d->arch.grant_table_gpfn[idx] = gfn_x(gfn);
+d->arch.grant_table_gfn[idx] = gfn;
 
 t = p2m_ram_rw;
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 370cdeb..979f7de 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -51,7 +51,7 @@ struct arch_domain
 uint64_t vttbr;
 
 struct hvm_domain hvm_domain;
-xen_pfn_t *grant_table_gpfn;
+gfn_t *grant_table_gfn;
 
 struct vmmio vmmio;
 
diff --git a/xen/include/asm-arm/grant_table.h 
b/xen/include/asm-arm/grant_table.h
index 5e076cc..eb02423 100644
--- a/xen/include/asm-arm/grant_table.h
+++ b/xen/include/asm-arm/grant_table.h
@@ -30,7 +30,7 @@ static inline int replace_grant_supported(void)
 
 #define gnttab_shared_gmfn(d, t, i)  \
 ( ((i >= nr_grant_frames(d->grant_table)) && \
- (i < max_grant_frames)) ? 0 : (d->arch.grant_table_gpfn[i]))
+ (i < max_grant_frames)) ? 0 : gfn_x(d->arch.grant_table_gfn[i]))
 
 #define gnttab_need_iommu_mapping(d)\
 (is_domain_direct_mapped(d) && need_iommu(d))
-- 
1.9.1


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

[Xen-devel] [PATCH v5 02/17] xen: Use typesafe gfn in xenmem_add_to_physmap_one

[Julien Grall]

The x86 version of the function xenmem_add_to_physmap_one contains
variable name gpfn and gfn which make the code very confusing.
I have left unchanged for now.

Also, rename gpfn to gfn in the ARM version as the latter is the correct
acronym for a guest physical frame.

Finally, remove the trailing whitespace around the changes.

Signed-off-by: Julien Grall 
Acked-by: Jan Beulich 
Acked-by: Stefano Stabellini 

---
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 

Changes in v4:
- Add Stefano's Acked-by

Changes in v3:
- Add Jan's Acked-by for non-ARM bits
---
 xen/arch/arm/mm.c| 10 +-
 xen/arch/x86/mm.c| 15 +++
 xen/common/memory.c  |  6 +++---
 xen/include/xen/mm.h |  2 +-
 4 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 5ab9b75..6882d54 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1046,7 +1046,7 @@ int xenmem_add_to_physmap_one(
 unsigned int space,
 union xen_add_to_physmap_batch_extra extra,
 unsigned long idx,
-xen_pfn_t gpfn)
+gfn_t gfn)
 {
 unsigned long mfn = 0;
 int rc;
@@ -1081,8 +1081,8 @@ int xenmem_add_to_physmap_one(
 else
 return -EINVAL;
 }
-
-d->arch.grant_table_gpfn[idx] = gpfn;
+
+d->arch.grant_table_gpfn[idx] = gfn_x(gfn);
 
 t = p2m_ram_rw;
 
@@ -1145,7 +1145,7 @@ int xenmem_add_to_physmap_one(
 if ( extra.res0 )
 return -EOPNOTSUPP;
 
-rc = map_dev_mmio_region(d, gpfn, 1, idx);
+rc = map_dev_mmio_region(d, gfn_x(gfn), 1, idx);
 return rc;
 
 default:
@@ -1153,7 +1153,7 @@ int xenmem_add_to_physmap_one(
 }
 
 /* Map at new location. */
-rc = guest_physmap_add_entry(d, _gfn(gpfn), _mfn(mfn), 0, t);
+rc = guest_physmap_add_entry(d, gfn, _mfn(mfn), 0, t);
 
 /* If we fail to add the mapping, we need to drop the reference we
  * took earlier on foreign pages */
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 7fbc94e..dbcf6cb 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4775,7 +4775,7 @@ int xenmem_add_to_physmap_one(
 unsigned int space,
 union xen_add_to_physmap_batch_extra extra,
 unsigned long idx,
-xen_pfn_t gpfn)
+gfn_t gpfn)
 {
 struct page_info *page = NULL;
 unsigned long gfn = 0; /* gcc ... */
@@ -4834,7 +4834,7 @@ int xenmem_add_to_physmap_one(
 break;
 }
 case XENMAPSPACE_gmfn_foreign:
-return p2m_add_foreign(d, idx, gpfn, extra.foreign_domid);
+return p2m_add_foreign(d, idx, gfn_x(gpfn), extra.foreign_domid);
 default:
 break;
 }
@@ -4849,19 +4849,18 @@ int xenmem_add_to_physmap_one(
 }
 
 /* Remove previously mapped page if it was present. */
-prev_mfn = mfn_x(get_gfn(d, gpfn, ));
+prev_mfn = mfn_x(get_gfn(d, gfn_x(gpfn), ));
 if ( mfn_valid(prev_mfn) )
 {
 if ( is_xen_heap_mfn(prev_mfn) )
 /* Xen heap frames are simply unhooked from this phys slot. */
-guest_physmap_remove_page(d, _gfn(gpfn), _mfn(prev_mfn),
-  PAGE_ORDER_4K);
+guest_physmap_remove_page(d, gpfn, _mfn(prev_mfn), PAGE_ORDER_4K);
 else
 /* Normal domain memory is freed, to avoid leaking memory. */
-guest_remove_page(d, gpfn);
+guest_remove_page(d, gfn_x(gpfn));
 }
 /* In the XENMAPSPACE_gmfn case we still hold a ref on the old page. */
-put_gfn(d, gpfn);
+put_gfn(d, gfn_x(gpfn));
 
 /* Unmap from old location, if any. */
 old_gpfn = get_gpfn_from_mfn(mfn);
@@ -4872,7 +4871,7 @@ int xenmem_add_to_physmap_one(
 guest_physmap_remove_page(d, _gfn(old_gpfn), _mfn(mfn), PAGE_ORDER_4K);
 
 /* Map at new location. */
-rc = guest_physmap_add_page(d, _gfn(gpfn), _mfn(mfn), PAGE_ORDER_4K);
+rc = guest_physmap_add_page(d, gpfn, _mfn(mfn), PAGE_ORDER_4K);
 
 /* In the XENMAPSPACE_gmfn, we took a ref of the gfn at the top */
 if ( space == XENMAPSPACE_gmfn || space == XENMAPSPACE_gmfn_range )
diff --git a/xen/common/memory.c b/xen/common/memory.c
index a8a75e0..812334b 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -649,7 +649,7 @@ static int xenmem_add_to_physmap(struct domain *d,
 
 if ( xatp->space != XENMAPSPACE_gmfn_range )
 return xenmem_add_to_physmap_one(d, xatp->space, extra,
- xatp->idx, xatp->gpfn);
+ xatp->idx, _gfn(xatp->gpfn));
 
 if ( 

[Xen-devel] [PATCH v5 07/17] xen: Use a typesafe to define INVALID_GFN

[Julien Grall]

Also take the opportunity to convert arch/x86/debug.c to the typesafe gfn.

Signed-off-by: Julien Grall 

---
Cc: Mukesh Rathor 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
Cc: Boris Ostrovsky 
Cc: Suravee Suthikulpanit 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Tim Deegan 
Cc: Feng Wu 

Changes in v5:
- Patch added
---
 xen/arch/arm/p2m.c  |  4 ++--
 xen/arch/x86/debug.c| 18 +-
 xen/arch/x86/domain.c   |  2 +-
 xen/arch/x86/hvm/emulate.c  |  7 ---
 xen/arch/x86/hvm/hvm.c  |  6 +++---
 xen/arch/x86/hvm/ioreq.c|  8 
 xen/arch/x86/hvm/svm/nestedsvm.c|  2 +-
 xen/arch/x86/hvm/vmx/vmx.c  |  6 +++---
 xen/arch/x86/mm/altp2m.c|  2 +-
 xen/arch/x86/mm/hap/guest_walk.c| 10 +-
 xen/arch/x86/mm/hap/nested_ept.c|  2 +-
 xen/arch/x86/mm/p2m-pod.c   |  6 +++---
 xen/arch/x86/mm/p2m.c   | 18 +-
 xen/arch/x86/mm/shadow/common.c |  2 +-
 xen/arch/x86/mm/shadow/multi.c  |  2 +-
 xen/arch/x86/mm/shadow/private.h|  2 +-
 xen/drivers/passthrough/amd/iommu_map.c |  2 +-
 xen/drivers/passthrough/vtd/iommu.c |  4 ++--
 xen/drivers/passthrough/x86/iommu.c |  2 +-
 xen/include/asm-x86/guest_pt.h  |  4 ++--
 xen/include/asm-x86/p2m.h   |  2 +-
 xen/include/xen/mm.h|  2 +-
 22 files changed, 57 insertions(+), 56 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index d690602..c938dde 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -479,7 +479,7 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
 }
 
 /* If request to get default access. */
-if ( gfn_x(gfn) == INVALID_GFN )
+if ( gfn_eq(gfn, INVALID_GFN) )
 {
 *access = memaccess[p2m->default_access];
 return 0;
@@ -1879,7 +1879,7 @@ long p2m_set_mem_access(struct domain *d, gfn_t gfn, 
uint32_t nr,
 p2m->mem_access_enabled = true;
 
 /* If request to set default access. */
-if ( gfn_x(gfn) == INVALID_GFN )
+if ( gfn_eq(gfn, INVALID_GFN) )
 {
 p2m->default_access = a;
 return 0;
diff --git a/xen/arch/x86/debug.c b/xen/arch/x86/debug.c
index 3479f7c..1ce0e89 100644
--- a/xen/arch/x86/debug.c
+++ b/xen/arch/x86/debug.c
@@ -44,8 +44,7 @@ typedef unsigned char dbgbyte_t;
 
 /* Returns: mfn for the given (hvm guest) vaddr */
 static mfn_t
-dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr,
-unsigned long *gfn)
+dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr, gfn_t *gfn)
 {
 mfn_t mfn;
 uint32_t pfec = PFEC_page_present;
@@ -53,14 +52,14 @@ dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr,
 
 DBGP2("vaddr:%lx domid:%d\n", vaddr, dp->domain_id);
 
-*gfn = paging_gva_to_gfn(dp->vcpu[0], vaddr, );
-if ( *gfn == INVALID_GFN )
+*gfn = _gfn(paging_gva_to_gfn(dp->vcpu[0], vaddr, ));
+if ( gfn_eq(*gfn, INVALID_GFN) )
 {
 DBGP2("kdb:bad gfn from gva_to_gfn\n");
 return INVALID_MFN;
 }
 
-mfn = get_gfn(dp, *gfn, );
+mfn = get_gfn(dp, gfn_x(*gfn), );
 if ( p2m_is_readonly(gfntype) && toaddr )
 {
 DBGP2("kdb:p2m_is_readonly: gfntype:%x\n", gfntype);
@@ -72,7 +71,7 @@ dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr,
 
 if ( mfn_eq(mfn, INVALID_MFN) )
 {
-put_gfn(dp, *gfn);
+put_gfn(dp, gfn_x(*gfn));
 *gfn = INVALID_GFN;
 }
 
@@ -165,7 +164,8 @@ unsigned int dbg_rw_guest_mem(struct domain *dp, void * 
__user gaddr,
 char *va;
 unsigned long addr = (unsigned long)gaddr;
 mfn_t mfn;
-unsigned long gfn = INVALID_GFN, pagecnt;
+gfn_t gfn = INVALID_GFN;
+unsigned long pagecnt;
 
 pagecnt = min_t(long, PAGE_SIZE - (addr & ~PAGE_MASK), len);
 
@@ -189,8 +189,8 @@ unsigned int dbg_rw_guest_mem(struct domain *dp, void * 
__user gaddr,
 }
 
 unmap_domain_page(va);
-if ( gfn != INVALID_GFN )
-put_gfn(dp, gfn);
+if ( !gfn_eq(gfn, INVALID_GFN) )
+put_gfn(dp, gfn_x(gfn));
 
 addr += pagecnt;
 buf += pagecnt;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index bb59247..c8c7e2d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -783,7 +783,7 @@ int arch_domain_soft_reset(struct domain *d)
  * gfn == INVALID_GFN indicates that the shared_info page was never mapped
  * to the domain's address space and there is nothing to replace.
  */
-if ( gfn == 

[Xen-devel] [PATCH v5 15/17] xen/arm: p2m: Introduce helpers to insert and remove mapping

[Julien Grall]

More the half of the arguments of INSERT and REMOVE are the same for
each callers. Simplify the callers of apply_p2m_changes by adding new
helpers which will fill common arguments with default values.

Signed-off-by: Julien Grall 

---
Changes in v5:
- Add missing Signed-off-by

Changes in v4:
- Patch added
---
 xen/arch/arm/p2m.c | 70 --
 1 file changed, 36 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 0fdd11f..a5b584b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1158,17 +1158,40 @@ out:
 return rc;
 }
 
+static inline int p2m_insert_mapping(struct domain *d,
+ gfn_t start_gfn,
+ unsigned long nr,
+ mfn_t mfn,
+ int mattr, p2m_type_t t)
+{
+return apply_p2m_changes(d, INSERT,
+ pfn_to_paddr(gfn_x(start_gfn)),
+ pfn_to_paddr(gfn_x(start_gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
+ mattr, 0, t, d->arch.p2m.default_access);
+}
+
+static inline int p2m_remove_mapping(struct domain *d,
+ gfn_t start_gfn,
+ unsigned long nr,
+ mfn_t mfn)
+{
+return apply_p2m_changes(d, REMOVE,
+ pfn_to_paddr(gfn_x(start_gfn)),
+ pfn_to_paddr(gfn_x(start_gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
+ /* arguments below not used when removing mapping 
*/
+ MATTR_MEM, 0, p2m_invalid,
+ d->arch.p2m.default_access);
+}
+
 int map_regions_rw_cache(struct domain *d,
  gfn_t gfn,
  unsigned long nr,
  mfn_t mfn)
 {
-return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(gfn_x(gfn)),
- pfn_to_paddr(gfn_x(gfn) + nr),
- pfn_to_paddr(mfn_x(mfn)),
- MATTR_MEM, 0, p2m_mmio_direct,
- d->arch.p2m.default_access);
+return p2m_insert_mapping(d, gfn, nr, mfn,
+  MATTR_MEM, p2m_mmio_direct);
 }
 
 int unmap_regions_rw_cache(struct domain *d,
@@ -1176,12 +1199,7 @@ int unmap_regions_rw_cache(struct domain *d,
unsigned long nr,
mfn_t mfn)
 {
-return apply_p2m_changes(d, REMOVE,
- pfn_to_paddr(gfn_x(gfn)),
- pfn_to_paddr(gfn_x(gfn) + nr),
- pfn_to_paddr(mfn_x(mfn)),
- MATTR_MEM, 0, p2m_invalid,
- d->arch.p2m.default_access);
+return p2m_remove_mapping(d, gfn, nr, mfn);
 }
 
 int map_mmio_regions(struct domain *d,
@@ -1189,12 +1207,8 @@ int map_mmio_regions(struct domain *d,
  unsigned long nr,
  mfn_t mfn)
 {
-return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(gfn_x(start_gfn)),
- pfn_to_paddr(gfn_x(start_gfn) + nr),
- pfn_to_paddr(mfn_x(mfn)),
- MATTR_DEV, 0, p2m_mmio_direct,
- d->arch.p2m.default_access);
+return p2m_insert_mapping(d, start_gfn, nr, mfn,
+  MATTR_MEM, p2m_mmio_direct);
 }
 
 int unmap_mmio_regions(struct domain *d,
@@ -1202,12 +1216,7 @@ int unmap_mmio_regions(struct domain *d,
unsigned long nr,
mfn_t mfn)
 {
-return apply_p2m_changes(d, REMOVE,
- pfn_to_paddr(gfn_x(start_gfn)),
- pfn_to_paddr(gfn_x(start_gfn) + nr),
- pfn_to_paddr(mfn_x(mfn)),
- MATTR_DEV, 0, p2m_invalid,
- d->arch.p2m.default_access);
+return p2m_remove_mapping(d, start_gfn, nr, mfn);
 }
 
 int map_dev_mmio_region(struct domain *d,
@@ -1237,22 +1246,15 @@ int guest_physmap_add_entry(struct domain *d,
 unsigned long page_order,
 p2m_type_t t)
 {
-return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(gfn_x(gfn)),
- pfn_to_paddr(gfn_x(gfn) + (1 << page_order)),
- pfn_to_paddr(mfn_x(mfn)), MATTR_MEM, 0, t,
- d->arch.p2m.default_access);
+return p2m_insert_mapping(d, gfn, (1 << page_order), mfn,
+  MATTR_MEM, t);
 }
 
 void 

[Xen-devel] [PATCH v5 10/17] xen/arm: map_regions_rw_cache: Map the region with p2m->default_access

[Julien Grall]

The parameter 'access' is used by memaccess to restrict temporarily the
permission. This parameter should not be used for other purpose (such
as restricting permanently the permission).

The type p2m_mmio_direct will map the region Read-Write and
non-executable. Note that this is already the current behavior with the
combination of the type and the access. So there is no functional
change.

Signed-off-by: Julien Grall 

---
Cc: Shannon Zhao 

This patch is a candidate for Xen 4.7. Currently this function is
only used to map ACPI regions.

I am wondering if we should introduce a new p2m type for it. And map
this region RO (I am not sure why a guest would want to
modify this region).

Changes in v4:
- Patch added
---
 xen/arch/arm/p2m.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 1cfb62b..fcc4513 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1231,7 +1231,7 @@ int map_regions_rw_cache(struct domain *d,
  pfn_to_paddr(start_gfn + nr),
  pfn_to_paddr(mfn),
  MATTR_MEM, 0, p2m_mmio_direct,
- p2m_access_rw);
+ d->arch.p2m.default_access);
 }
 
 int unmap_regions_rw_cache(struct domain *d,
@@ -1244,7 +1244,7 @@ int unmap_regions_rw_cache(struct domain *d,
  pfn_to_paddr(start_gfn + nr),
  pfn_to_paddr(mfn),
  MATTR_MEM, 0, p2m_invalid,
- p2m_access_rw);
+ d->arch.p2m.default_access);
 }
 
 int map_mmio_regions(struct domain *d,
-- 
1.9.1


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

[Xen-devel] [PATCH v5 04/17] xen: Use the typesafe mfn and gfn in map_mmio_regions...

[Julien Grall]

to avoid mixing machine frame with guest frame.

Signed-off-by: Julien Grall 
Acked-by: Jan Beulich 

---
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 

Changes in v3:
- Use mfn_add when it is possible
- Add Jan's acked-by
---
 xen/arch/arm/domain_build.c  |  4 ++--
 xen/arch/arm/gic-v2.c|  4 ++--
 xen/arch/arm/p2m.c   | 22 +++---
 xen/arch/arm/platforms/exynos5.c |  8 
 xen/arch/arm/platforms/omap5.c   | 16 
 xen/arch/arm/vgic-v2.c   |  4 ++--
 xen/arch/x86/mm/p2m.c| 18 ++
 xen/common/domctl.c  |  4 ++--
 xen/include/xen/p2m-common.h |  8 
 9 files changed, 45 insertions(+), 43 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9035486..49185f0 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1036,9 +1036,9 @@ static int map_range_to_domain(const struct 
dt_device_node *dev,
 if ( need_mapping )
 {
 res = map_mmio_regions(d,
-   paddr_to_pfn(addr),
+   _gfn(paddr_to_pfn(addr)),
DIV_ROUND_UP(len, PAGE_SIZE),
-   paddr_to_pfn(addr));
+   _mfn(paddr_to_pfn(addr)));
 if ( res < 0 )
 {
 printk(XENLOG_ERR "Unable to map 0x%"PRIx64
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 4e2f4c7..3893ece 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -601,9 +601,9 @@ static int gicv2_map_hwdown_extra_mappings(struct domain *d)
d->domain_id, v2m_data->addr, v2m_data->size,
v2m_data->spi_start, v2m_data->nr_spis);
 
-ret = map_mmio_regions(d, paddr_to_pfn(v2m_data->addr),
+ret = map_mmio_regions(d, _gfn(paddr_to_pfn(v2m_data->addr)),
 DIV_ROUND_UP(v2m_data->size, PAGE_SIZE),
-paddr_to_pfn(v2m_data->addr));
+_mfn(paddr_to_pfn(v2m_data->addr)));
 if ( ret )
 {
 printk(XENLOG_ERR "GICv2: Map v2m frame to d%d failed.\n",
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 0395a40..34563bb 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1245,27 +1245,27 @@ int unmap_regions_rw_cache(struct domain *d,
 }
 
 int map_mmio_regions(struct domain *d,
- unsigned long start_gfn,
+ gfn_t start_gfn,
  unsigned long nr,
- unsigned long mfn)
+ mfn_t mfn)
 {
 return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(start_gfn),
- pfn_to_paddr(start_gfn + nr),
- pfn_to_paddr(mfn),
+ pfn_to_paddr(gfn_x(start_gfn)),
+ pfn_to_paddr(gfn_x(start_gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
  MATTR_DEV, 0, p2m_mmio_direct,
  d->arch.p2m.default_access);
 }
 
 int unmap_mmio_regions(struct domain *d,
-   unsigned long start_gfn,
+   gfn_t start_gfn,
unsigned long nr,
-   unsigned long mfn)
+   mfn_t mfn)
 {
 return apply_p2m_changes(d, REMOVE,
- pfn_to_paddr(start_gfn),
- pfn_to_paddr(start_gfn + nr),
- pfn_to_paddr(mfn),
+ pfn_to_paddr(gfn_x(start_gfn)),
+ pfn_to_paddr(gfn_x(start_gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
  MATTR_DEV, 0, p2m_invalid,
  d->arch.p2m.default_access);
 }
@@ -1280,7 +1280,7 @@ int map_dev_mmio_region(struct domain *d,
 if ( !(nr && iomem_access_permitted(d, mfn, mfn + nr - 1)) )
 return 0;
 
-res = map_mmio_regions(d, start_gfn, nr, mfn);
+res = map_mmio_regions(d, _gfn(start_gfn), nr, _mfn(mfn));
 if ( res < 0 )
 {
 printk(XENLOG_G_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",
diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
index bf4964d..c43934f 100644
--- a/xen/arch/arm/platforms/exynos5.c
+++ b/xen/arch/arm/platforms/exynos5.c
@@ -83,12 +83,12 @@ static int exynos5_init_time(void)
 static int exynos5250_specific_mapping(struct domain *d)
 {
 /* Map the chip ID */
-

[Xen-devel] [PATCH v5 17/17] xen/arm: p2m: Rework the interface of apply_p2m_changes and use typesafe

[Julien Grall]

Most of the callers of apply_p2m_changes have a GFN, a MFN and the
number of frame to change in hand.

Rather than asking each caller to convert the frame to an address,
rework the interfaces to pass the GFN, MFN and the number of frame.

Note that it would be possible to do more clean-up in apply_p2m_changes,
but this will be done in a follow-up series.

Signed-off-by: Julien Grall 

---
Changes in v4:
- Patch added
---
 xen/arch/arm/p2m.c | 62 --
 1 file changed, 28 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 9fdc417..bb33a72 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -906,25 +906,26 @@ static void update_reference_mapping(struct page_info 
*page,
 
 static int apply_p2m_changes(struct domain *d,
  enum p2m_operation op,
- paddr_t start_gpaddr,
- paddr_t end_gpaddr,
- paddr_t maddr,
+ gfn_t sgfn,
+ unsigned long nr,
+ mfn_t smfn,
  int mattr,
  uint32_t mask,
  p2m_type_t t,
  p2m_access_t a)
 {
+paddr_t start_gpaddr = pfn_to_paddr(gfn_x(sgfn));
+paddr_t end_gpaddr = pfn_to_paddr(gfn_x(sgfn) + nr);
+paddr_t maddr = pfn_to_paddr(mfn_x(smfn));
 int rc, ret;
 struct p2m_domain *p2m = >arch.p2m;
 lpae_t *mappings[4] = { NULL, NULL, NULL, NULL };
 struct page_info *pages[4] = { NULL, NULL, NULL, NULL };
-paddr_t addr, orig_maddr = maddr;
+paddr_t addr;
 unsigned int level = 0;
 unsigned int cur_root_table = ~0;
 unsigned int cur_offset[4] = { ~0, ~0, ~0, ~0 };
 unsigned int count = 0;
-const unsigned long sgfn = paddr_to_pfn(start_gpaddr),
-egfn = paddr_to_pfn(end_gpaddr);
 const unsigned int preempt_count_limit = (op == MEMACCESS) ? 1 : 0x2000;
 const bool_t preempt = !is_idle_vcpu(current);
 bool_t flush = false;
@@ -986,9 +987,9 @@ static int apply_p2m_changes(struct domain *d,
  * Preempt setting mem_access permissions as required by 
XSA-89,
  * if it's not the last iteration.
  */
-uint32_t progress = paddr_to_pfn(addr) - sgfn + 1;
+uint32_t progress = paddr_to_pfn(addr) - gfn_x(sgfn) + 1;
 
-if ( (egfn - sgfn) > progress && !(progress & mask) )
+if ( nr > progress && !(progress & mask) )
 {
 rc = progress;
 goto out;
@@ -1117,8 +1118,9 @@ static int apply_p2m_changes(struct domain *d,
 
 if ( op == INSERT )
 {
-p2m->max_mapped_gfn = gfn_max(p2m->max_mapped_gfn, _gfn(egfn));
-p2m->lowest_mapped_gfn = gfn_min(p2m->lowest_mapped_gfn, _gfn(sgfn));
+p2m->max_mapped_gfn = gfn_max(p2m->max_mapped_gfn,
+  gfn_add(sgfn, nr));
+p2m->lowest_mapped_gfn = gfn_min(p2m->lowest_mapped_gfn, sgfn);
 }
 
 rc = 0;
@@ -1127,7 +1129,7 @@ out:
 if ( flush )
 {
 flush_tlb_domain(d);
-ret = iommu_iotlb_flush(d, sgfn, egfn - sgfn);
+ret = iommu_iotlb_flush(d, gfn_x(sgfn), nr);
 if ( !rc )
 rc = ret;
 }
@@ -1146,12 +1148,14 @@ out:
 if ( rc < 0 && ( op == INSERT ) &&
  addr != start_gpaddr )
 {
+unsigned long gfn = paddr_to_pfn(addr);
+
 BUG_ON(addr == end_gpaddr);
 /*
  * addr keeps the address of the end of the last successfully-inserted
  * mapping.
  */
-apply_p2m_changes(d, REMOVE, start_gpaddr, addr, orig_maddr,
+apply_p2m_changes(d, REMOVE, sgfn, gfn - gfn_x(sgfn), smfn,
   mattr, 0, p2m_invalid, d->arch.p2m.default_access);
 }
 
@@ -1164,10 +1168,7 @@ static inline int p2m_insert_mapping(struct domain *d,
  mfn_t mfn,
  int mattr, p2m_type_t t)
 {
-return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(gfn_x(start_gfn)),
- pfn_to_paddr(gfn_x(start_gfn) + nr),
- pfn_to_paddr(mfn_x(mfn)),
+return apply_p2m_changes(d, INSERT, start_gfn, nr, mfn,
  mattr, 0, t, d->arch.p2m.default_access);
 }
 
@@ -1176,10 +1177,7 @@ static inline int p2m_remove_mapping(struct domain *d,
  unsigned long nr,
  mfn_t mfn)
 {
-return apply_p2m_changes(d, REMOVE,
- pfn_to_paddr(gfn_x(start_gfn)),
- pfn_to_paddr(gfn_x(start_gfn) + nr),
- pfn_to_paddr(mfn_x(mfn)),
+return apply_p2m_changes(d, REMOVE, start_gfn, nr, mfn,
 

[Xen-devel] [PATCH v5 14/17] xen/arm: Use the typesafes mfn and gfn in map_regions_rw_cache ...

[Julien Grall]

to avoid mixing machine frame with guest frame. Also rename the
parameters of the function and drop pointless PAGE_MASK in the caller.

Signed-off-by: Julien Grall 

---
Changes in v4:
- Patch added
---
 xen/arch/arm/domain_build.c |  8 
 xen/arch/arm/p2m.c  | 20 ++--
 xen/include/asm-arm/p2m.h   | 12 ++--
 3 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 923f48a..60db9e4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1522,9 +1522,9 @@ static void acpi_map_other_tables(struct domain *d)
 addr = acpi_gbl_root_table_list.tables[i].address;
 size = acpi_gbl_root_table_list.tables[i].length;
 res = map_regions_rw_cache(d,
-   paddr_to_pfn(addr & PAGE_MASK),
+   _gfn(paddr_to_pfn(addr)),
DIV_ROUND_UP(size, PAGE_SIZE),
-   paddr_to_pfn(addr & PAGE_MASK));
+   _mfn(paddr_to_pfn(addr)));
 if ( res )
 {
  panic(XENLOG_ERR "Unable to map ACPI region 0x%"PRIx64
@@ -1878,9 +1878,9 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 
 /* Map the EFI and ACPI tables to Dom0 */
 rc = map_regions_rw_cache(d,
-  paddr_to_pfn(d->arch.efi_acpi_gpa),
+  _gfn(paddr_to_pfn(d->arch.efi_acpi_gpa)),
   PFN_UP(d->arch.efi_acpi_len),
-  
paddr_to_pfn(virt_to_maddr(d->arch.efi_acpi_table)));
+  
_mfn(paddr_to_pfn(virt_to_maddr(d->arch.efi_acpi_table;
 if ( rc != 0 )
 {
 printk(XENLOG_ERR "Unable to map EFI/ACPI table 0x%"PRIx64
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5ffc3df..0fdd11f 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1159,27 +1159,27 @@ out:
 }
 
 int map_regions_rw_cache(struct domain *d,
- unsigned long start_gfn,
+ gfn_t gfn,
  unsigned long nr,
- unsigned long mfn)
+ mfn_t mfn)
 {
 return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(start_gfn),
- pfn_to_paddr(start_gfn + nr),
- pfn_to_paddr(mfn),
+ pfn_to_paddr(gfn_x(gfn)),
+ pfn_to_paddr(gfn_x(gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
  MATTR_MEM, 0, p2m_mmio_direct,
  d->arch.p2m.default_access);
 }
 
 int unmap_regions_rw_cache(struct domain *d,
-   unsigned long start_gfn,
+   gfn_t gfn,
unsigned long nr,
-   unsigned long mfn)
+   mfn_t mfn)
 {
 return apply_p2m_changes(d, REMOVE,
- pfn_to_paddr(start_gfn),
- pfn_to_paddr(start_gfn + nr),
- pfn_to_paddr(mfn),
+ pfn_to_paddr(gfn_x(gfn)),
+ pfn_to_paddr(gfn_x(gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
  MATTR_MEM, 0, p2m_invalid,
  d->arch.p2m.default_access);
 }
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 8d29eda..6e258b9 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -142,14 +142,14 @@ mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t 
*t);
 int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr);
 
 int map_regions_rw_cache(struct domain *d,
- unsigned long start_gfn,
- unsigned long nr_mfns,
- unsigned long mfn);
+ gfn_t gfn,
+ unsigned long nr,
+ mfn_t mfn);
 
 int unmap_regions_rw_cache(struct domain *d,
-   unsigned long start_gfn,
-   unsigned long nr_mfns,
-   unsigned long mfn);
+   gfn_t gfn,
+   unsigned long nr,
+   mfn_t mfn);
 
 int map_dev_mmio_region(struct domain *d,
 gfn_t gfn,
-- 
1.9.1


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

[Xen-devel] [PATCH v5 09/17] xen/arm: Rework the interface of p2m_cache_flush and use typesafe gfn

[Julien Grall]

p2m_cache_flush is expecting GFNs in parameter and not MFNs. Rename
the variable to *gfn* and use typesafe to avoid possible misusage.

Also, modify the prototype of the function to describe the range
using the start and the number of GFNs. This will avoid to wonder
whether the end if inclusive or exclusive.

Note that the type of the parameters 'start' is changed from xen_pfn_t
(aka uint64_t) to gfn_t (aka unsigned long). This means that a truncation
will occur for ARM32. It is fine because it will always be encoded on 28
bits maximum (40 bits address).

Signed-off-by: Julien Grall 

---
Changes in v4:
- This patch was originally called "xen/arm: p2m_cache_flush:
Use the correct terminology and typesafe gfn"
- Describe the range using the start and the number of GFNs.

Changes in v3:
- Add a word in the commit message about the truncation.

Changes in v2:
- Drop _gfn suffix
---
 xen/arch/arm/domctl.c |  2 +-
 xen/arch/arm/p2m.c| 11 ++-
 xen/include/asm-arm/p2m.h |  2 +-
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 30453d8..f61f98a 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -30,7 +30,7 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain 
*d,
 if ( e < s )
 return -EINVAL;
 
-return p2m_cache_flush(d, s, e);
+return p2m_cache_flush(d, _gfn(s), domctl->u.cacheflush.nr_pfns);
 }
 case XEN_DOMCTL_bind_pt_irq:
 {
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 54a363a..1cfb62b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1469,16 +1469,17 @@ int relinquish_p2m_mapping(struct domain *d)
   d->arch.p2m.default_access);
 }
 
-int p2m_cache_flush(struct domain *d, xen_pfn_t start_mfn, xen_pfn_t end_mfn)
+int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr)
 {
 struct p2m_domain *p2m = >arch.p2m;
+gfn_t end = gfn_add(start, nr);
 
-start_mfn = MAX(start_mfn, p2m->lowest_mapped_gfn);
-end_mfn = MIN(end_mfn, p2m->max_mapped_gfn);
+start = gfn_max(start, _gfn(p2m->lowest_mapped_gfn));
+end = gfn_min(end, _gfn(p2m->max_mapped_gfn));
 
 return apply_p2m_changes(d, CACHEFLUSH,
- pfn_to_paddr(start_mfn),
- pfn_to_paddr(end_mfn),
+ pfn_to_paddr(gfn_x(start)),
+ pfn_to_paddr(gfn_x(end)),
  pfn_to_paddr(mfn_x(INVALID_MFN)),
  MATTR_MEM, 0, p2m_invalid,
  d->arch.p2m.default_access);
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index f204482..8a96e68 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -139,7 +139,7 @@ void p2m_dump_info(struct domain *d);
 mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t);
 
 /* Clean & invalidate caches corresponding to a region of guest address space 
*/
-int p2m_cache_flush(struct domain *d, xen_pfn_t start_mfn, xen_pfn_t end_mfn);
+int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr);
 
 /* Setup p2m RAM mapping for domain d from start-end. */
 int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
-- 
1.9.1


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

[Xen-devel] [PATCH v5 00/17] xen/arm: Use the typesafes gfn and mfn

[Julien Grall]

Hello all,

Some of the ARM functions are mixing gfn vs mfn and even physical vs frame.

To avoid more confusion, this patch series makes use of the terminology
described in xen/include/xen/mm.h and the associated typesafe.

This series requires the patch [1] to be applied beforehand. I pushed a
branch with this patch and this series applied on xenbits:
git://xenbits.xen.org/people/julieng/xen-unstable.git branch typesafe-v4

For all the changes see in each patch.

Yours sincerely,

[1] http://lists.xenproject.org/archives/html/xen-devel/2016-06/msg01744.html

Cc: Andrew Cooper 
Cc: Boris Ostrovsky 
Cc: Christoph Egger 
Cc: Feng Wu 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Konrad Rzeszutek Wilk 
Cc: Liu Jinsong 
Cc: Mukesh Rathor 
Cc: Paul Durrant 
Cc: Shannon Zhao 
Cc: Stefano Stabellini 
Cc: Suravee Suthikulpanit 
Cc: Tim Deegan 
Cc: Wei Liu 

Julien Grall (17):
  xen: Use typesafe gfn/mfn in guest_physmap_* helpers
  xen: Use typesafe gfn in xenmem_add_to_physmap_one
  xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the
typesafe gfn
  xen: Use the typesafe mfn and gfn in map_mmio_regions...
  xen/passthrough: x86: Use INVALID_GFN rather than INVALID_MFN
  xen: Use a typesafe to define INVALID_MFN
  xen: Use a typesafe to define INVALID_GFN
  xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and
mfn
  xen/arm: Rework the interface of p2m_cache_flush and use typesafe gfn
  xen/arm: map_regions_rw_cache: Map the region with p2m->default_access
  xen/arm: dom0_build: Remove dead code in allocate_memory
  xen/arm: p2m: Remove unused operation ALLOCATE
  xen/arm: Use the typesafes mfn and gfn in map_dev_mmio_region...
  xen/arm: Use the typesafes mfn and gfn in map_regions_rw_cache ...
  xen/arm: p2m: Introduce helpers to insert and remove mapping
  xen/arm: p2m: Use typesafe gfn for {max,lowest}_mapped_gfn
  xen/arm: p2m: Rework the interface of apply_p2m_changes and use
typesafe

 xen/arch/arm/domain.c   |   4 +-
 xen/arch/arm/domain_build.c |  72 ++---
 xen/arch/arm/domctl.c   |   2 +-
 xen/arch/arm/gic-v2.c   |   4 +-
 xen/arch/arm/mm.c   |  20 +--
 xen/arch/arm/p2m.c  | 269 
 xen/arch/arm/platforms/exynos5.c|   8 +-
 xen/arch/arm/platforms/omap5.c  |  16 +-
 xen/arch/arm/traps.c|  21 +--
 xen/arch/arm/vgic-v2.c  |   4 +-
 xen/arch/x86/cpu/mcheck/mce.c   |   2 +-
 xen/arch/x86/debug.c|  64 
 xen/arch/x86/domain.c   |   7 +-
 xen/arch/x86/domain_build.c |   6 +-
 xen/arch/x86/hvm/emulate.c  |   7 +-
 xen/arch/x86/hvm/hvm.c  |  12 +-
 xen/arch/x86/hvm/ioreq.c|  16 +-
 xen/arch/x86/hvm/svm/nestedsvm.c|   2 +-
 xen/arch/x86/hvm/viridian.c |   6 +-
 xen/arch/x86/hvm/vmx/vmx.c  |   8 +-
 xen/arch/x86/mm.c   |  21 +--
 xen/arch/x86/mm/altp2m.c|   2 +-
 xen/arch/x86/mm/guest_walk.c|   4 +-
 xen/arch/x86/mm/hap/guest_walk.c|  10 +-
 xen/arch/x86/mm/hap/hap.c   |   4 +-
 xen/arch/x86/mm/hap/nested_ept.c|   2 +-
 xen/arch/x86/mm/p2m-ept.c   |   6 +-
 xen/arch/x86/mm/p2m-pod.c   |  24 +--
 xen/arch/x86/mm/p2m-pt.c|  18 +--
 xen/arch/x86/mm/p2m.c   | 164 ++-
 xen/arch/x86/mm/paging.c|  12 +-
 xen/arch/x86/mm/shadow/common.c |  46 +++---
 xen/arch/x86/mm/shadow/multi.c  |  38 ++---
 xen/arch/x86/mm/shadow/private.h|   2 +-
 xen/common/domain.c |   6 +-
 xen/common/domctl.c |   4 +-
 xen/common/grant_table.c|  13 +-
 xen/common/memory.c |  38 ++---
 xen/drivers/passthrough/amd/iommu_map.c |   2 +-
 xen/drivers/passthrough/arm/smmu.c  |   4 +-
 xen/drivers/passthrough/vtd/iommu.c |   4 +-
 xen/drivers/passthrough/x86/iommu.c |   2 +-
 xen/include/asm-arm/domain.h|   2 +-
 xen/include/asm-arm/grant_table.h   |   2 +-
 xen/include/asm-arm/p2m.h   |  44 +++---
 xen/include/asm-x86/guest_pt.h  |   4 +-
 xen/include/asm-x86/p2m.h   |  13 +-
 xen/include/xen/mm.h|   8 +-
 xen/include/xen/p2m-common.h|   8 +-
 49 files changed, 481 

Re: [Xen-devel] [PATCH] x86/EFI + Live Patch: avoid symbol address truncation

[Jan Beulich]

>>> On 28.06.16 at 16:26,  wrote:
> On 28/06/16 15:03, Jan Beulich wrote:
>> ld associates __init_end, placed outside of any section by the linker
>> script, with the following section, resulting in a huge (wrapped, as it
>> would be negative) section relative offset.
> 
> So in this case, the cause of the truncation is due to __init_end being
> considered relative to .data.read_mostly?

Yes.

>>  COFF symbol tables store
>> section relative addresses, and hence the above leads to assembler
>> truncation warnings when all symbols get included in the symbol table
>> (for Live Patching code). To overcome this, move __init_end past both
>> ALIGN() directives. The consuming code (init_done()) is fine with such
>> an adjustment (the distinction really would only be relevant for the
>> loop claring the pages, and I think it's acceptable to clear a few
>> more on - for now - EFI). This effectively results in the
>> (__init_begin,__init_end) and (__2M_init_start,__2M_init_end) pairs to
>> become identical, with their different names only serving documentation
>> purposes now.
>>
>> Note that moving __init_end and __2M_init_end into .init is not a good
>> idea, as that would significantly grow xen.efi binary size.
> 
> How about moving just __init_end ?  That shouldn't affect the size of
> any binary, due to the existing page alignment between sections.

There's no page alignment between sections in the disk image
representation - we build with a file alignment of 32.

>> While inspecting symbol table and ld behavior I also noticed that
>> __2M_text_start gets put at address zero in the EFI case, which hasn't
>> caused problems solely because we don't actually reference that symbol.
> 
> The reason that __2M_text_start isn't referenced is because I couldn't
> get the EFI build working.  It was used in my first prototype.

Not surprising with the symbol having ended up at zero.

>> @@ -530,18 +531,18 @@ static void noinline init_done(void)
>>  /* Destroy Xen's mappings, and reuse the pages. */
>>  if ( using_2M_mapping() )
>>  {
>> -destroy_xen_mappings((unsigned long)&__2M_init_start,
>> - (unsigned long)&__2M_init_end);
>> -init_xenheap_pages(__pa(__2M_init_start), __pa(__2M_init_end));
>> +start = (unsigned long)&__2M_init_start,
>> +end   = (unsigned long)&__2M_init_end;
>>  }
>>  else
>>  {
>> -destroy_xen_mappings((unsigned long)&__init_begin,
>> - (unsigned long)&__init_end);
>> -init_xenheap_pages(__pa(__init_begin), __pa(__init_end));
>> +start = (unsigned long)&__init_begin;
>> +end   = (unsigned long)&__init_end;
>>  }
>>  
>> -printk("Freed %ldkB init memory.\n", 
>> (long)(__init_end-__init_begin)>>10);
>> +destroy_xen_mappings(start, end);
>> +init_xenheap_pages(__pa(start), __pa(end));
>> +printk("Freed %ldkB init memory\n", (end - start) >> 10);
> 
> The parameter is now unsigned, so %lu.

Oh, of course - fixed.

>> --- a/xen/arch/x86/xen.lds.S
>> +++ b/xen/arch/x86/xen.lds.S
>> @@ -40,9 +40,20 @@ SECTIONS
>>  #if !defined(EFI)
>>. = __XEN_VIRT_START;
>>__image_base__ = .;
>> +#else
>> +  . = __image_base__;
>>  #endif
>>  
>> +#if 0
>> +/*
>> + * We don't really use this symbol anywhere, and the way it would get 
>> defined
>> + * here would result in it having a negative (wrapped to huge positive)
>> + * offset relative to the .text section. That, in turn, causes an assembler
>> + * truncation warning when including all symbols in the symbol table for 
>> Live
>> + * Patching code.
>> + */
>>__2M_text_start = .; /* Start of 2M superpages, mapped RX. */
>> +#endif
>>  
>>. = __XEN_VIRT_START + MB(1);
>>_start = .;
>> @@ -194,14 +205,13 @@ SECTIONS
>> *(.ctors)
>> __ctors_end = .;
>>} :text
>> -  . = ALIGN(PAGE_SIZE);
>> -  __init_end = .;
>>  
>>  #ifdef EFI
>>. = ALIGN(MB(2));
>>  #else
>>. = ALIGN(PAGE_SIZE);
>>  #endif
>> +  __init_end = .;
>>__2M_init_end = .;
>>  
>>__2M_rwdata_start = .;   /* Start of 2M superpages, mapped RW. */
>> @@ -296,7 +306,6 @@ ASSERT(__image_base__ > XEN_VIRT_START |
>>  ASSERT(kexec_reloc_size - kexec_reloc <= PAGE_SIZE, "kexec_reloc is too 
> large")
>>  #endif
>>  
>> -ASSERT(IS_ALIGNED(__2M_text_start,   MB(2)), "__2M_text_start misaligned")
> 
> If we are #if 0'ing the symbol for documentation purposes, can we #if 0
> this as well?

I considered it, but the two #if-s would end up disconnected. And
with the symbol being first thing in the image (plus the fact that so
far the assertion was there _without_ triggering despite there
being a problem - just one it couldn't detect), I think chances are
slim that it getting fully removed would be a significant problem.
I.e. I'd prefer the patch to remain as is in this regard, but if the
only way to get it acked is to do as you suggest, I would
(hesitantly) do so.

[Xen-devel] [PATCH v2] xen/arm: gic-v3: No need to sort the Redistributor regions

[Julien Grall]

The sorting was required by the vGIC emulation until commit
9b9d51e98edb8c5c731e2d06dfad3633053d88a4 "xen/arm: vgic-v3:
Correctly retrieve the vCPU associated to a re-distributor".

Furthermore, the code is buggy because both local variables 'l' and 'r'
point to the same region.

So drop the code which sort the Redistributors array.

Reported-by: Shanker Donthineni 
Signed-off-by: Julien Grall 

---
Changes in v2:
- Fix compilation with ACPI
---
 xen/arch/arm/gic-v3.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index dfc62e8..b8a4bde 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1134,14 +1134,6 @@ static const hw_irq_controller gicv3_guest_irq_type = {
 .set_affinity = gicv3_irq_set_affinity,
 };
 
-static int __init cmp_rdist(const void *a, const void *b)
-{
-const struct rdist_region *l = a, *r = a;
-
-/* We assume that re-distributor regions can never overlap */
-return ( l->base < r->base) ? -1 : 0;
-}
-
 static paddr_t __initdata dbase = INVALID_PADDR;
 static paddr_t __initdata vbase = INVALID_PADDR, vsize = 0;
 static paddr_t __initdata cbase = INVALID_PADDR, csize = 0;
@@ -1210,9 +1202,6 @@ static void __init gicv3_dt_init(void)
 rdist_regs[i].size = rdist_size;
 }
 
-/* The vGIC code requires the region to be sorted */
-sort(rdist_regs, gicv3.rdist_count, sizeof(*rdist_regs), cmp_rdist, NULL);
-
 if ( !dt_property_read_u32(node, "redistributor-stride", 
_stride) )
 gicv3.rdist_stride = 0;
 
@@ -1455,9 +1444,6 @@ static void __init gicv3_acpi_init(void)
 rdist_regs[i].size = gic_rdist->length;
 }
 
-/* The vGIC code requires the region to be sorted */
-sort(rdist_regs, gicv3.rdist_count, sizeof(*rdist_regs), cmp_rdist, NULL);
-
 gicv3.rdist_regions= rdist_regs;
 
 /* Collect CPU base addresses */
-- 
1.9.1


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 96299

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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

version targeted for testing:
 libvirt  a2adcc1b9376beb7f464be64c326923ba6a5f7e7
baseline version:
 libvirt  0b4645a7e061abc8a4be71fe89865cf248ce6e56

Last test of basis96299  2016-06-27 04:21:09 Z1 days
Testing same since96333  2016-06-28 04:21:58 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Ján Tomko 
  Michal Privoznik 
  Olga Krishtal 

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  pass
 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 fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 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.


commit a2adcc1b9376beb7f464be64c326923ba6a5f7e7
Author: Olga Krishtal 
Date:   Mon Jun 27 21:23:11 2016 +0300

vz: fix build for virNetDev* changes

Patch fixes vz build after changes in IP-related netdev functions(cf0568b0, 
fbc1843d).

Signed-off-by: Olga Krishtal 

commit 05eab47559950403aa67d18b098273269ae6916e
Author: Ján Tomko 
Date:   Mon Jun 27 11:56:17 2016 +0200

Revert "util: new function virNetDevIPInfoAddToDev"

This reverts commit f1e0d0da11c473905470c28a6488bf57d9d0ae6e.

Re: [Xen-devel] making xenstore domain easy configurable

[Juergen Gross]

On 28/06/16 17:23, Andrew Cooper wrote:
> On 28/06/16 16:17, Doug Goldstein wrote:
>> On 6/28/16 8:59 AM, Andrew Cooper wrote:
>>> On 28/06/16 14:36, Juergen Gross wrote:
 On 28/06/16 14:42, Andrew Cooper wrote:
> On 28/06/16 12:56, Juergen Gross wrote:
>> On 28/06/16 13:03, Ian Jackson wrote:
>>> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy 
>>> configurable"):
 So you are telling me the xenstore domain won't work for this case?
>>> Yes.
>> That's rather unfortunate. So in order to be able to make xenstore
>> domain a common setup we need to find a solution for support of
>> xs_restrict() via xenbus, right?
>>
>> TBH, the way xs_restrict() was introduced is rather weird. It is
>> completely bound to the socket interface of oxenstored. So anyone
>> wanting to use xs_restrict() is limited to oxenstored running in
>> dom0. No way to use xenstored or a xenstore domain. I'm really
>> disappointed such a design was accepted and is now the reason for
>> not being able to disaggregate dom0.
>>
>> I've searched through the xen-devel archives and found a very
>> interesting mail:
>>
>> http://lists.xen.org/archives/html/xen-devel/2010-04/msg01318.html
>>
>> The "restrict" feature was added without any further discussion how
>> it is implemented and that the C-variant doesn't support it. The
>> explicit question about non-existing features in the C xenstored was
>> answered just with "the xenstore wire protocol doesn't change".
>>
>> With:
>>
>> http://lists.xen.org/archives/html/xen-devel/2010-07/msg00091.html
>>
>> the XS_RESTRICT value in xs_wire.h (aah, suddenly it was changed?)
>> was added. Again no mentioning of the special implementation in
>> oxenstored.
>>
>> Really, this is not how open source development should be done!
>> Maybe I'm just upset now, but I'm in favor of dropping xs_restrict()
>> support as it has been introduced in a foul way.
> I don't think the lack of xs_restrict() working over the ring should
> preclude these improvements to the configuration of how xenstored starts 
> up.
 It is limiting the solution by not allowing me to drop the sockets
 completely.
>>> I don't think dropping the sockets completely is a sensible course of
>>> action.  I had come the conclusion that you were just not going to use
>>> them, as opposed to removing them entirely.
>>>
>>> For xenstored running in the same domain as the toolstack, sockets are
>>> less overhead than the shared memory ring, as no hypercalls are
>>> involved.  There is also the unfortunate problem that one of the two
>>> linux devices for xenstored *still* causes deadlocks when used; a
>>> problem which is unresolved from Linux 3.14.
>> Since Xen 4.7 the broken devices won't be used by default. I understand
>> that the socket interface is faster and less overhead but I guess my
>> question is how much data is sent over this interface? Does it really
>> matter the small performance difference to justify having two different
>> methods and not trimming the code base down to one method?
> 
> My gut feeling is that the XenServer bootstorm scalability tests will
> notice.  Our metric of "how fast is it to boot 1000 VMs" is very
> important for VDI, as employees tend to get to work and try to log
> during the same short time period.

I think I'll start with just removing the systemd socket stuff. This is
what I need to make the xenstore domain configurable on the installed
system. Removing of the sockets can be done either later or never.


Juergen


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

Re: [Xen-devel] making xenstore domain easy configurable

[Andrew Cooper]

On 28/06/16 16:17, Doug Goldstein wrote:
> On 6/28/16 8:59 AM, Andrew Cooper wrote:
>> On 28/06/16 14:36, Juergen Gross wrote:
>>> On 28/06/16 14:42, Andrew Cooper wrote:
 On 28/06/16 12:56, Juergen Gross wrote:
> On 28/06/16 13:03, Ian Jackson wrote:
>> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy 
>> configurable"):
>>> So you are telling me the xenstore domain won't work for this case?
>> Yes.
> That's rather unfortunate. So in order to be able to make xenstore
> domain a common setup we need to find a solution for support of
> xs_restrict() via xenbus, right?
>
> TBH, the way xs_restrict() was introduced is rather weird. It is
> completely bound to the socket interface of oxenstored. So anyone
> wanting to use xs_restrict() is limited to oxenstored running in
> dom0. No way to use xenstored or a xenstore domain. I'm really
> disappointed such a design was accepted and is now the reason for
> not being able to disaggregate dom0.
>
> I've searched through the xen-devel archives and found a very
> interesting mail:
>
> http://lists.xen.org/archives/html/xen-devel/2010-04/msg01318.html
>
> The "restrict" feature was added without any further discussion how
> it is implemented and that the C-variant doesn't support it. The
> explicit question about non-existing features in the C xenstored was
> answered just with "the xenstore wire protocol doesn't change".
>
> With:
>
> http://lists.xen.org/archives/html/xen-devel/2010-07/msg00091.html
>
> the XS_RESTRICT value in xs_wire.h (aah, suddenly it was changed?)
> was added. Again no mentioning of the special implementation in
> oxenstored.
>
> Really, this is not how open source development should be done!
> Maybe I'm just upset now, but I'm in favor of dropping xs_restrict()
> support as it has been introduced in a foul way.
 I don't think the lack of xs_restrict() working over the ring should
 preclude these improvements to the configuration of how xenstored starts 
 up.
>>> It is limiting the solution by not allowing me to drop the sockets
>>> completely.
>> I don't think dropping the sockets completely is a sensible course of
>> action.  I had come the conclusion that you were just not going to use
>> them, as opposed to removing them entirely.
>>
>> For xenstored running in the same domain as the toolstack, sockets are
>> less overhead than the shared memory ring, as no hypercalls are
>> involved.  There is also the unfortunate problem that one of the two
>> linux devices for xenstored *still* causes deadlocks when used; a
>> problem which is unresolved from Linux 3.14.
> Since Xen 4.7 the broken devices won't be used by default. I understand
> that the socket interface is faster and less overhead but I guess my
> question is how much data is sent over this interface? Does it really
> matter the small performance difference to justify having two different
> methods and not trimming the code base down to one method?

My gut feeling is that the XenServer bootstorm scalability tests will
notice.  Our metric of "how fast is it to boot 1000 VMs" is very
important for VDI, as employees tend to get to work and try to log
during the same short time period.

~Andrew

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

Re: [Xen-devel] making xenstore domain easy configurable

[Doug Goldstein]

On 6/28/16 8:59 AM, Andrew Cooper wrote:
> On 28/06/16 14:36, Juergen Gross wrote:
>> On 28/06/16 14:42, Andrew Cooper wrote:
>>> On 28/06/16 12:56, Juergen Gross wrote:
 On 28/06/16 13:03, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy 
> configurable"):
>> So you are telling me the xenstore domain won't work for this case?
> Yes.
 That's rather unfortunate. So in order to be able to make xenstore
 domain a common setup we need to find a solution for support of
 xs_restrict() via xenbus, right?

 TBH, the way xs_restrict() was introduced is rather weird. It is
 completely bound to the socket interface of oxenstored. So anyone
 wanting to use xs_restrict() is limited to oxenstored running in
 dom0. No way to use xenstored or a xenstore domain. I'm really
 disappointed such a design was accepted and is now the reason for
 not being able to disaggregate dom0.

 I've searched through the xen-devel archives and found a very
 interesting mail:

 http://lists.xen.org/archives/html/xen-devel/2010-04/msg01318.html

 The "restrict" feature was added without any further discussion how
 it is implemented and that the C-variant doesn't support it. The
 explicit question about non-existing features in the C xenstored was
 answered just with "the xenstore wire protocol doesn't change".

 With:

 http://lists.xen.org/archives/html/xen-devel/2010-07/msg00091.html

 the XS_RESTRICT value in xs_wire.h (aah, suddenly it was changed?)
 was added. Again no mentioning of the special implementation in
 oxenstored.

 Really, this is not how open source development should be done!
 Maybe I'm just upset now, but I'm in favor of dropping xs_restrict()
 support as it has been introduced in a foul way.
>>> I don't think the lack of xs_restrict() working over the ring should
>>> preclude these improvements to the configuration of how xenstored starts up.
>> It is limiting the solution by not allowing me to drop the sockets
>> completely.
> 
> I don't think dropping the sockets completely is a sensible course of
> action.  I had come the conclusion that you were just not going to use
> them, as opposed to removing them entirely.
> 
> For xenstored running in the same domain as the toolstack, sockets are
> less overhead than the shared memory ring, as no hypercalls are
> involved.  There is also the unfortunate problem that one of the two
> linux devices for xenstored *still* causes deadlocks when used; a
> problem which is unresolved from Linux 3.14.

Since Xen 4.7 the broken devices won't be used by default. I understand
that the socket interface is faster and less overhead but I guess my
question is how much data is sent over this interface? Does it really
matter the small performance difference to justify having two different
methods and not trimming the code base down to one method?

-- 
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] making xenstore domain easy configurable

[Andrew Cooper]

On 28/06/16 15:58, Juergen Gross wrote:
> On 28/06/16 15:59, Andrew Cooper wrote:
>> On 28/06/16 14:36, Juergen Gross wrote:
>>> On 28/06/16 14:42, Andrew Cooper wrote:
 On 28/06/16 12:56, Juergen Gross wrote:
> On 28/06/16 13:03, Ian Jackson wrote:
>> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy 
>> configurable"):
>>> So you are telling me the xenstore domain won't work for this case?
>> Yes.
> That's rather unfortunate. So in order to be able to make xenstore
> domain a common setup we need to find a solution for support of
> xs_restrict() via xenbus, right?
>
> TBH, the way xs_restrict() was introduced is rather weird. It is
> completely bound to the socket interface of oxenstored. So anyone
> wanting to use xs_restrict() is limited to oxenstored running in
> dom0. No way to use xenstored or a xenstore domain. I'm really
> disappointed such a design was accepted and is now the reason for
> not being able to disaggregate dom0.
>
> I've searched through the xen-devel archives and found a very
> interesting mail:
>
> http://lists.xen.org/archives/html/xen-devel/2010-04/msg01318.html
>
> The "restrict" feature was added without any further discussion how
> it is implemented and that the C-variant doesn't support it. The
> explicit question about non-existing features in the C xenstored was
> answered just with "the xenstore wire protocol doesn't change".
>
> With:
>
> http://lists.xen.org/archives/html/xen-devel/2010-07/msg00091.html
>
> the XS_RESTRICT value in xs_wire.h (aah, suddenly it was changed?)
> was added. Again no mentioning of the special implementation in
> oxenstored.
>
> Really, this is not how open source development should be done!
> Maybe I'm just upset now, but I'm in favor of dropping xs_restrict()
> support as it has been introduced in a foul way.
 I don't think the lack of xs_restrict() working over the ring should
 preclude these improvements to the configuration of how xenstored starts 
 up.
>>> It is limiting the solution by not allowing me to drop the sockets
>>> completely.
>> I don't think dropping the sockets completely is a sensible course of
>> action.  I had come the conclusion that you were just not going to use
>> them, as opposed to removing them entirely.
> If they are not going to be used they can be dropped, no?
>
> Again: the main problem with the sockets is their systemd definition in
> combination of their existence being used for the connection type with
> xenstore (socket vs. kernel).
>
> So either I always connect via the kernel making the sockets useless
> (then I can remove them completely) or I have a way creating the
> sockets only in case of the daemon case which is currently available
> only by removing the systemd definition of the sockets.
>
>> For xenstored running in the same domain as the toolstack, sockets are
>> less overhead than the shared memory ring, as no hypercalls are
>> involved.  There is also the unfortunate problem that one of the two
>> linux devices for xenstored *still* causes deadlocks when used; a
>> problem which is unresolved from Linux 3.14.
> So this would mean we should keep the sockets and just remove their
> systemd definition.

This seems like the best course of action, especially as it appears that
we don't make use of the systemd sockets in the way systemd likes.

As far as I can tell, this will cause xs_restrict() to work as it
currently does when you use oxenstored locally in dom0, in which case I
am happy that there is no net reduction in functionality.

~Andrew

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

Re: [Xen-devel] making xenstore domain easy configurable

[Juergen Gross]

On 28/06/16 15:59, Andrew Cooper wrote:
> On 28/06/16 14:36, Juergen Gross wrote:
>> On 28/06/16 14:42, Andrew Cooper wrote:
>>> On 28/06/16 12:56, Juergen Gross wrote:
 On 28/06/16 13:03, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy 
> configurable"):
>> So you are telling me the xenstore domain won't work for this case?
> Yes.
 That's rather unfortunate. So in order to be able to make xenstore
 domain a common setup we need to find a solution for support of
 xs_restrict() via xenbus, right?

 TBH, the way xs_restrict() was introduced is rather weird. It is
 completely bound to the socket interface of oxenstored. So anyone
 wanting to use xs_restrict() is limited to oxenstored running in
 dom0. No way to use xenstored or a xenstore domain. I'm really
 disappointed such a design was accepted and is now the reason for
 not being able to disaggregate dom0.

 I've searched through the xen-devel archives and found a very
 interesting mail:

 http://lists.xen.org/archives/html/xen-devel/2010-04/msg01318.html

 The "restrict" feature was added without any further discussion how
 it is implemented and that the C-variant doesn't support it. The
 explicit question about non-existing features in the C xenstored was
 answered just with "the xenstore wire protocol doesn't change".

 With:

 http://lists.xen.org/archives/html/xen-devel/2010-07/msg00091.html

 the XS_RESTRICT value in xs_wire.h (aah, suddenly it was changed?)
 was added. Again no mentioning of the special implementation in
 oxenstored.

 Really, this is not how open source development should be done!
 Maybe I'm just upset now, but I'm in favor of dropping xs_restrict()
 support as it has been introduced in a foul way.
>>> I don't think the lack of xs_restrict() working over the ring should
>>> preclude these improvements to the configuration of how xenstored starts up.
>> It is limiting the solution by not allowing me to drop the sockets
>> completely.
> 
> I don't think dropping the sockets completely is a sensible course of
> action.  I had come the conclusion that you were just not going to use
> them, as opposed to removing them entirely.

If they are not going to be used they can be dropped, no?

Again: the main problem with the sockets is their systemd definition in
combination of their existence being used for the connection type with
xenstore (socket vs. kernel).

So either I always connect via the kernel making the sockets useless
(then I can remove them completely) or I have a way creating the
sockets only in case of the daemon case which is currently available
only by removing the systemd definition of the sockets.

> For xenstored running in the same domain as the toolstack, sockets are
> less overhead than the shared memory ring, as no hypercalls are
> involved.  There is also the unfortunate problem that one of the two
> linux devices for xenstored *still* causes deadlocks when used; a
> problem which is unresolved from Linux 3.14.

So this would mean we should keep the sockets and just remove their
systemd definition.

>>> Longterm, a sensible solution would be to make a xenstore protocol
>>> extension to wrap an existing xenstore message in a restrict wrapper,
>>> where the kernel device can apply the appropriate restrict around user
>>> requests.
>> I'd rather let xs_restrict() work in a clean way: setup a new ring and
>> event channel with the appropriate privileges and let the connection
>> to xenstore run via this ring.
> 
> Domains currently don't have any notion of multiple xenstore-rings to
> the same domain.  Somewhere (i.e. in xenstored itself) there would have
> to be some kind of hard upper limit to avoid resource exhaustion, and
> guest kernels would still have to have some privileged way of
> negotiating the setup.  Also, how do you plan to make any of this work
> with xenstored not in a subdomain?

The multiple ring setup should be allowed for dom0 (or similar
privileged domains) only in order to avoid resource exhaustion.
xs_restrict() is limited to dom0, too.

I haven't worked on a design for the implementation yet. I've just
presented a rough interface idea making it rather easy to distinguish
multiple instances by xenstore regardless whether those instances are
located in the same domain or not.


Juergen


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

Re: [Xen-devel] [PATCH V3 04/10] arm/gic-v3: Parse per-cpu redistributor entry in GICC subtable

[Shanker Donthineni]

On 06/28/2016 08:51 AM, Shanker Donthineni wrote:

Hi Julien,


On 06/28/2016 05:40 AM, Julien Grall wrote:

Hello Shanker,

On 27/06/16 21:33, Shanker Donthineni wrote:

@@ -1397,6 +1408,36 @@ gic_acpi_parse_madt_distributor(struct

acpi_subtable_header *header,

  }

  static int __init
+gic_acpi_parse_cpu_redistributor(struct acpi_subtable_header *header,
+ const unsigned long end)
+{
+struct acpi_madt_generic_interrupt *processor;
+u32 size;
+
+processor = (struct acpi_madt_generic_interrupt *)header;
+if ( !(processor->flags & ACPI_MADT_ENABLED) )
+return 0;


You did not answer to my question on previous version of this patch. 
You said that "Disabled GICC entries should be skipped because its 
Redistributor region is not always-on power domain." However from my 
understanding, an usable CPU may have his Redistributor in the not 
always-on power domain. So the issue would the same, correct?




The gicv3_populate_rdist() is not supposed to read GICR registers if 
the  the associated hardware GICR block is in power-off state. The CPU 
accesses to disabled GICR region leads to either a system hang or an 
unexpected behavior.



The description of flag ACPI_MADT_ENABLED in ACPI-6.1 says "If zero, 
this processor in unusable, and the operating system support will not 
attempt to use it".




Regards,





--
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

Re: [Xen-devel] [PATCH] x86/EFI + Live Patch: avoid symbol address truncation

[Andrew Cooper]

On 28/06/16 15:03, Jan Beulich wrote:
> ld associates __init_end, placed outside of any section by the linker
> script, with the following section, resulting in a huge (wrapped, as it
> would be negative) section relative offset.

So in this case, the cause of the truncation is due to __init_end being
considered relative to .data.read_mostly?

>  COFF symbol tables store
> section relative addresses, and hence the above leads to assembler
> truncation warnings when all symbols get included in the symbol table
> (for Live Patching code). To overcome this, move __init_end past both
> ALIGN() directives. The consuming code (init_done()) is fine with such
> an adjustment (the distinction really would only be relevant for the
> loop claring the pages, and I think it's acceptable to clear a few
> more on - for now - EFI). This effectively results in the
> (__init_begin,__init_end) and (__2M_init_start,__2M_init_end) pairs to
> become identical, with their different names only serving documentation
> purposes now.
>
> Note that moving __init_end and __2M_init_end into .init is not a good
> idea, as that would significantly grow xen.efi binary size.

How about moving just __init_end ?  That shouldn't affect the size of
any binary, due to the existing page alignment between sections.

>
> While inspecting symbol table and ld behavior I also noticed that
> __2M_text_start gets put at address zero in the EFI case, which hasn't
> caused problems solely because we don't actually reference that symbol.

The reason that __2M_text_start isn't referenced is because I couldn't
get the EFI build working.  It was used in my first prototype.

> Correct the setting of the initial address, and comment out said symbol
> for the time being, as with the initial address correction it would in
> turn cause an assembler truncation warning similar to the one mentioned
> above.
>
> While checking init_done() for correctness with the above changes I
> noticed that code can easily be folded there, at once correcting the
> logged amount of memory which has got freed for the 2M-alignment case
> (i.e. EFI right now).
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -515,6 +515,7 @@ static inline bool_t using_2M_mapping(vo
>  static void noinline init_done(void)
>  {
>  void *va;
> +unsigned long start, end;
>  
>  system_state = SYS_STATE_active;
>  
> @@ -530,18 +531,18 @@ static void noinline init_done(void)
>  /* Destroy Xen's mappings, and reuse the pages. */
>  if ( using_2M_mapping() )
>  {
> -destroy_xen_mappings((unsigned long)&__2M_init_start,
> - (unsigned long)&__2M_init_end);
> -init_xenheap_pages(__pa(__2M_init_start), __pa(__2M_init_end));
> +start = (unsigned long)&__2M_init_start,
> +end   = (unsigned long)&__2M_init_end;
>  }
>  else
>  {
> -destroy_xen_mappings((unsigned long)&__init_begin,
> - (unsigned long)&__init_end);
> -init_xenheap_pages(__pa(__init_begin), __pa(__init_end));
> +start = (unsigned long)&__init_begin;
> +end   = (unsigned long)&__init_end;
>  }
>  
> -printk("Freed %ldkB init memory.\n", 
> (long)(__init_end-__init_begin)>>10);
> +destroy_xen_mappings(start, end);
> +init_xenheap_pages(__pa(start), __pa(end));
> +printk("Freed %ldkB init memory\n", (end - start) >> 10);

The parameter is now unsigned, so %lu.

>  
>  startup_cpu_idle_loop();
>  }
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -40,9 +40,20 @@ SECTIONS
>  #if !defined(EFI)
>. = __XEN_VIRT_START;
>__image_base__ = .;
> +#else
> +  . = __image_base__;
>  #endif
>  
> +#if 0
> +/*
> + * We don't really use this symbol anywhere, and the way it would get defined
> + * here would result in it having a negative (wrapped to huge positive)
> + * offset relative to the .text section. That, in turn, causes an assembler
> + * truncation warning when including all symbols in the symbol table for Live
> + * Patching code.
> + */
>__2M_text_start = .; /* Start of 2M superpages, mapped RX. */
> +#endif
>  
>. = __XEN_VIRT_START + MB(1);
>_start = .;
> @@ -194,14 +205,13 @@ SECTIONS
> *(.ctors)
> __ctors_end = .;
>} :text
> -  . = ALIGN(PAGE_SIZE);
> -  __init_end = .;
>  
>  #ifdef EFI
>. = ALIGN(MB(2));
>  #else
>. = ALIGN(PAGE_SIZE);
>  #endif
> +  __init_end = .;
>__2M_init_end = .;
>  
>__2M_rwdata_start = .;   /* Start of 2M superpages, mapped RW. */
> @@ -296,7 +306,6 @@ ASSERT(__image_base__ > XEN_VIRT_START |
>  ASSERT(kexec_reloc_size - kexec_reloc <= PAGE_SIZE, "kexec_reloc is too 
> large")
>  #endif
>  
> -ASSERT(IS_ALIGNED(__2M_text_start,   MB(2)), "__2M_text_start misaligned")

If we are #if 0'ing the symbol for documentation purposes, can we #if 0
this as well?

~Andrew

>  #ifdef EFI
>  

[Xen-devel] [PATCH] x86/EFI + Live Patch: avoid symbol address truncation

[Jan Beulich]

ld associates __init_end, placed outside of any section by the linker
script, with the following section, resulting in a huge (wrapped, as it
would be negative) section relative offset. COFF symbol tables store
section relative addresses, and hence the above leads to assembler
truncation warnings when all symbols get included in the symbol table
(for Live Patching code). To overcome this, move __init_end past both
ALIGN() directives. The consuming code (init_done()) is fine with such
an adjustment (the distinction really would only be relevant for the
loop claring the pages, and I think it's acceptable to clear a few
more on - for now - EFI). This effectively results in the
(__init_begin,__init_end) and (__2M_init_start,__2M_init_end) pairs to
become identical, with their different names only serving documentation
purposes now.

Note that moving __init_end and __2M_init_end into .init is not a good
idea, as that would significantly grow xen.efi binary size.

While inspecting symbol table and ld behavior I also noticed that
__2M_text_start gets put at address zero in the EFI case, which hasn't
caused problems solely because we don't actually reference that symbol.
Correct the setting of the initial address, and comment out said symbol
for the time being, as with the initial address correction it would in
turn cause an assembler truncation warning similar to the one mentioned
above.

While checking init_done() for correctness with the above changes I
noticed that code can easily be folded there, at once correcting the
logged amount of memory which has got freed for the 2M-alignment case
(i.e. EFI right now).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -515,6 +515,7 @@ static inline bool_t using_2M_mapping(vo
 static void noinline init_done(void)
 {
 void *va;
+unsigned long start, end;
 
 system_state = SYS_STATE_active;
 
@@ -530,18 +531,18 @@ static void noinline init_done(void)
 /* Destroy Xen's mappings, and reuse the pages. */
 if ( using_2M_mapping() )
 {
-destroy_xen_mappings((unsigned long)&__2M_init_start,
- (unsigned long)&__2M_init_end);
-init_xenheap_pages(__pa(__2M_init_start), __pa(__2M_init_end));
+start = (unsigned long)&__2M_init_start,
+end   = (unsigned long)&__2M_init_end;
 }
 else
 {
-destroy_xen_mappings((unsigned long)&__init_begin,
- (unsigned long)&__init_end);
-init_xenheap_pages(__pa(__init_begin), __pa(__init_end));
+start = (unsigned long)&__init_begin;
+end   = (unsigned long)&__init_end;
 }
 
-printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
+destroy_xen_mappings(start, end);
+init_xenheap_pages(__pa(start), __pa(end));
+printk("Freed %ldkB init memory\n", (end - start) >> 10);
 
 startup_cpu_idle_loop();
 }
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -40,9 +40,20 @@ SECTIONS
 #if !defined(EFI)
   . = __XEN_VIRT_START;
   __image_base__ = .;
+#else
+  . = __image_base__;
 #endif
 
+#if 0
+/*
+ * We don't really use this symbol anywhere, and the way it would get defined
+ * here would result in it having a negative (wrapped to huge positive)
+ * offset relative to the .text section. That, in turn, causes an assembler
+ * truncation warning when including all symbols in the symbol table for Live
+ * Patching code.
+ */
   __2M_text_start = .; /* Start of 2M superpages, mapped RX. */
+#endif
 
   . = __XEN_VIRT_START + MB(1);
   _start = .;
@@ -194,14 +205,13 @@ SECTIONS
*(.ctors)
__ctors_end = .;
   } :text
-  . = ALIGN(PAGE_SIZE);
-  __init_end = .;
 
 #ifdef EFI
   . = ALIGN(MB(2));
 #else
   . = ALIGN(PAGE_SIZE);
 #endif
+  __init_end = .;
   __2M_init_end = .;
 
   __2M_rwdata_start = .;   /* Start of 2M superpages, mapped RW. */
@@ -296,7 +306,6 @@ ASSERT(__image_base__ > XEN_VIRT_START |
 ASSERT(kexec_reloc_size - kexec_reloc <= PAGE_SIZE, "kexec_reloc is too large")
 #endif
 
-ASSERT(IS_ALIGNED(__2M_text_start,   MB(2)), "__2M_text_start misaligned")
 #ifdef EFI
 ASSERT(IS_ALIGNED(__2M_text_end, MB(2)), "__2M_text_end misaligned")
 ASSERT(IS_ALIGNED(__2M_rodata_start, MB(2)), "__2M_rodata_start misaligned")


x86/EFI + Live Patch: avoid symbol address truncation

ld associates __init_end, placed outside of any section by the linker
script, with the following section, resulting in a huge (wrapped, as it
would be negative) section relative offset. COFF symbol tables store
section relative addresses, and hence the above leads to assembler
truncation warnings when all symbols get included in the symbol table
(for Live Patching code). To overcome this, move __init_end past both
ALIGN() directives. The consuming code (init_done()) is fine with such
an adjustment (the distinction really would only be relevant for the
loop claring the pages, and I think it's acceptable 

Re: [Xen-devel] making xenstore domain easy configurable

[Andrew Cooper]

On 28/06/16 14:36, Juergen Gross wrote:
> On 28/06/16 14:42, Andrew Cooper wrote:
>> On 28/06/16 12:56, Juergen Gross wrote:
>>> On 28/06/16 13:03, Ian Jackson wrote:
 Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy 
 configurable"):
> So you are telling me the xenstore domain won't work for this case?
 Yes.
>>> That's rather unfortunate. So in order to be able to make xenstore
>>> domain a common setup we need to find a solution for support of
>>> xs_restrict() via xenbus, right?
>>>
>>> TBH, the way xs_restrict() was introduced is rather weird. It is
>>> completely bound to the socket interface of oxenstored. So anyone
>>> wanting to use xs_restrict() is limited to oxenstored running in
>>> dom0. No way to use xenstored or a xenstore domain. I'm really
>>> disappointed such a design was accepted and is now the reason for
>>> not being able to disaggregate dom0.
>>>
>>> I've searched through the xen-devel archives and found a very
>>> interesting mail:
>>>
>>> http://lists.xen.org/archives/html/xen-devel/2010-04/msg01318.html
>>>
>>> The "restrict" feature was added without any further discussion how
>>> it is implemented and that the C-variant doesn't support it. The
>>> explicit question about non-existing features in the C xenstored was
>>> answered just with "the xenstore wire protocol doesn't change".
>>>
>>> With:
>>>
>>> http://lists.xen.org/archives/html/xen-devel/2010-07/msg00091.html
>>>
>>> the XS_RESTRICT value in xs_wire.h (aah, suddenly it was changed?)
>>> was added. Again no mentioning of the special implementation in
>>> oxenstored.
>>>
>>> Really, this is not how open source development should be done!
>>> Maybe I'm just upset now, but I'm in favor of dropping xs_restrict()
>>> support as it has been introduced in a foul way.
>> I don't think the lack of xs_restrict() working over the ring should
>> preclude these improvements to the configuration of how xenstored starts up.
> It is limiting the solution by not allowing me to drop the sockets
> completely.

I don't think dropping the sockets completely is a sensible course of
action.  I had come the conclusion that you were just not going to use
them, as opposed to removing them entirely.

For xenstored running in the same domain as the toolstack, sockets are
less overhead than the shared memory ring, as no hypercalls are
involved.  There is also the unfortunate problem that one of the two
linux devices for xenstored *still* causes deadlocks when used; a
problem which is unresolved from Linux 3.14.

>
>> Longterm, a sensible solution would be to make a xenstore protocol
>> extension to wrap an existing xenstore message in a restrict wrapper,
>> where the kernel device can apply the appropriate restrict around user
>> requests.
> I'd rather let xs_restrict() work in a clean way: setup a new ring and
> event channel with the appropriate privileges and let the connection
> to xenstore run via this ring.

Domains currently don't have any notion of multiple xenstore-rings to
the same domain.  Somewhere (i.e. in xenstored itself) there would have
to be some kind of hard upper limit to avoid resource exhaustion, and
guest kernels would still have to have some privileged way of
negotiating the setup.  Also, how do you plan to make any of this work
with xenstored not in a subdomain?

It is far easier, and IMO sensible, just to mux something new over the
existing ring.

~Andrew

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

Re: [Xen-devel] making xenstore domain easy configurable

[Andrew Cooper]

On 28/06/16 14:52, Juergen Gross wrote:
> On 28/06/16 14:42, Andrew Cooper wrote:
>> On 28/06/16 12:56, Juergen Gross wrote:
>>> On 28/06/16 13:03, Ian Jackson wrote:
 Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy 
 configurable"):
> So you are telling me the xenstore domain won't work for this case?
 Yes.
>>> That's rather unfortunate. So in order to be able to make xenstore
>>> domain a common setup we need to find a solution for support of
>>> xs_restrict() via xenbus, right?
>>>
>>> TBH, the way xs_restrict() was introduced is rather weird. It is
>>> completely bound to the socket interface of oxenstored. So anyone
>>> wanting to use xs_restrict() is limited to oxenstored running in
>>> dom0. No way to use xenstored or a xenstore domain. I'm really
>>> disappointed such a design was accepted and is now the reason for
>>> not being able to disaggregate dom0.
>>>
>>> I've searched through the xen-devel archives and found a very
>>> interesting mail:
>>>
>>> http://lists.xen.org/archives/html/xen-devel/2010-04/msg01318.html
>>>
>>> The "restrict" feature was added without any further discussion how
>>> it is implemented and that the C-variant doesn't support it. The
>>> explicit question about non-existing features in the C xenstored was
>>> answered just with "the xenstore wire protocol doesn't change".
>>>
>>> With:
>>>
>>> http://lists.xen.org/archives/html/xen-devel/2010-07/msg00091.html
>>>
>>> the XS_RESTRICT value in xs_wire.h (aah, suddenly it was changed?)
>>> was added. Again no mentioning of the special implementation in
>>> oxenstored.
>>>
>>> Really, this is not how open source development should be done!
>>> Maybe I'm just upset now, but I'm in favor of dropping xs_restrict()
>>> support as it has been introduced in a foul way.
>> I don't think the lack of xs_restrict() working over the ring should
>> preclude these improvements to the configuration of how xenstored starts up.
>>
>> Ideally, this issue would be listed in an appropriate place in
>> docs/features/, in the hope that it gets considered and addressed in the
>> future.
> Digging a little bit deeper I think the current xs_restrict()
> implementation renders an oxenstore domain completely useless: as
> soon as dom0 tries to use xs_restrict() it will loose its privileges
> as the complete dom0 connection will be affected. :-(

Can't say I am surprised in the slightest.  It is an extension which has
never been used, which invariably means it doesn't work.

(More replies on the other half of this thread, which I am still writing.)

~Andrew

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

Re: [Xen-devel] [PATCH V3 04/10] arm/gic-v3: Parse per-cpu redistributor entry in GICC subtable

[Shanker Donthineni]

Hi Julien,


On 06/28/2016 05:40 AM, Julien Grall wrote:

Hello Shanker,

On 27/06/16 21:33, Shanker Donthineni wrote:

@@ -1397,6 +1408,36 @@ gic_acpi_parse_madt_distributor(struct

acpi_subtable_header *header,

  }

  static int __init
+gic_acpi_parse_cpu_redistributor(struct acpi_subtable_header *header,
+ const unsigned long end)
+{
+struct acpi_madt_generic_interrupt *processor;
+u32 size;
+
+processor = (struct acpi_madt_generic_interrupt *)header;
+if ( !(processor->flags & ACPI_MADT_ENABLED) )
+return 0;


You did not answer to my question on previous version of this patch. 
You said that "Disabled GICC entries should be skipped because its 
Redistributor region is not always-on power domain." However from my 
understanding, an usable CPU may have his Redistributor in the not 
always-on power domain. So the issue would the same, correct?




The gicv3_populate_rdist() is not supposed to read GICR registers if 
the  the associated hardware GICR block is in power-off state. The CPU 
accesses to disabled GICR region leads to either a system hang or an 
unexpected behavior.




Regards,



--
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

Re: [Xen-devel] making xenstore domain easy configurable

[Juergen Gross]

On 28/06/16 14:42, Andrew Cooper wrote:
> On 28/06/16 12:56, Juergen Gross wrote:
>> On 28/06/16 13:03, Ian Jackson wrote:
>>> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy 
>>> configurable"):
 So you are telling me the xenstore domain won't work for this case?
>>> Yes.
>> That's rather unfortunate. So in order to be able to make xenstore
>> domain a common setup we need to find a solution for support of
>> xs_restrict() via xenbus, right?
>>
>> TBH, the way xs_restrict() was introduced is rather weird. It is
>> completely bound to the socket interface of oxenstored. So anyone
>> wanting to use xs_restrict() is limited to oxenstored running in
>> dom0. No way to use xenstored or a xenstore domain. I'm really
>> disappointed such a design was accepted and is now the reason for
>> not being able to disaggregate dom0.
>>
>> I've searched through the xen-devel archives and found a very
>> interesting mail:
>>
>> http://lists.xen.org/archives/html/xen-devel/2010-04/msg01318.html
>>
>> The "restrict" feature was added without any further discussion how
>> it is implemented and that the C-variant doesn't support it. The
>> explicit question about non-existing features in the C xenstored was
>> answered just with "the xenstore wire protocol doesn't change".
>>
>> With:
>>
>> http://lists.xen.org/archives/html/xen-devel/2010-07/msg00091.html
>>
>> the XS_RESTRICT value in xs_wire.h (aah, suddenly it was changed?)
>> was added. Again no mentioning of the special implementation in
>> oxenstored.
>>
>> Really, this is not how open source development should be done!
>> Maybe I'm just upset now, but I'm in favor of dropping xs_restrict()
>> support as it has been introduced in a foul way.
> 
> I don't think the lack of xs_restrict() working over the ring should
> preclude these improvements to the configuration of how xenstored starts up.
> 
> Ideally, this issue would be listed in an appropriate place in
> docs/features/, in the hope that it gets considered and addressed in the
> future.

Digging a little bit deeper I think the current xs_restrict()
implementation renders an oxenstore domain completely useless: as
soon as dom0 tries to use xs_restrict() it will loose its privileges
as the complete dom0 connection will be affected. :-(


Juergen

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

Re: [Xen-devel] [PATCH v2] xen: x86: remove duplicated IA32_FEATURE_CONTROL MSR macro

[Jan Beulich]

>>> On 28.06.16 at 10:12,  wrote:
> From: Kai Huang 
> 
> Below commit introduced a new macro MSR_IA32_FEATURE_CONTROL for
> IA32_FEATURE_CONTROL MSR but it didn't remove old IA32_FEATURE_CONTROL_MSR
> macro. The new one has better naming convention, so remove the old as a
> duplication. Also move the macros of bit definition of IA32_FEATURE_CONTROL 
> MSR
> down to make them together with the new one. The *_MSR* infix is also 
> removed as
> it is pointless.
> 
> commit 5a211704e8813c4890c8ce8dc4189d1dfb35ecd0
> Author: Len Brown 
> Date:   Fri Apr 8 22:31:47 2016 +0200
> 
> mwait-idle: prevent SKL-H boot failure when C8+C9+C10 enabled
> 
> Some SKL-H configurations require "max_cstate=7" to boot.
> While that is an effective workaround, it disables C10.
> 
> ..
> 
> Above commit also used SGX_ENABLE (bit 18) in IA32_FEATURE_CONTROL MSR 
> without a
> macro for it. A new macro IA32_FEATURE_CONTROL_SGX_ENABLE is also added for
> better code and future use.
> 
> Relevant code that uses those macros are changed accordingly.
> 
> Signed-off-by: Kai Huang 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Boris Ostrovsky]

On 06/28/2016 07:03 AM, Shannon Zhao wrote:
>
> On 2016/6/27 20:05, Boris Ostrovsky wrote:
>>
>> On 06/27/2016 06:29 AM, Julien Grall wrote:
>>> (CC Boris and Doug)
>>>
>>> Hi Shannon,
>>>
>>> On 27/06/16 07:01, Shannon Zhao wrote:
 On 2016/6/24 1:03, Julien Grall wrote:
> On 23/06/16 04:16, Shannon Zhao wrote:
>
> [...]
>
>> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
>> index 264b6ef..5347480 100644
>> --- a/tools/libxl/Makefile
>> +++ b/tools/libxl/Makefile
>> @@ -77,7 +77,29 @@ endif
>>
>>LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
>>LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o
>> libxl_libfdt_compat.o
>> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
>> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
>> +
>> +vpath iasl $(PATH)
>> +libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
>> +$(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
>> +
>> +libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
>> +awk 'NR > 1 {print s} {s=$$0}' $< > $@
>> +./libxl_mk_dsdt_arm >> $@
>> +
>> +libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
>> +iasl -vs -p $* -tc $*.asl
>> +sed -e 's/AmlCode/$*/g' $*.hex >$@
>> +echo "int $*_len=sizeof($*);" >>$@
>> +rm -f $*.aml $*.hex
>> +
> I don't like the idea to add iasl as a dependency for all ARM
> platforms.
> For instance ARMv7 platform will not use ACPI, but we still ask
> users to
> install iasl. So I think we should allow the user to opt-in/opt-out for
> ACPI.
>
> Any opinions?
>
 I agree. But how to exclude for ARMv7. I notice it only has the option
 CONFIG_ARM which doesn't distinguish ARM32 and ARM64.
>>> I am not sure if we plan to introduce Kconfig for tools. If not, you
>>> can add an option to the configure to enable/disable ACPI for guest.
>>>
>>> This would be gated by the presence of "iasl".
>>>
>>> [...]
>>>
>> diff --git a/tools/libxl/libxl_mk_dsdt_arm.c
>> b/tools/libxl/libxl_mk_dsdt_arm.c
>> new file mode 100644
>> index 000..96fadbd
>> --- /dev/null
>> +++ b/tools/libxl/libxl_mk_dsdt_arm.c
> Can we share the code from tools/firmware/acpi/mk_dsdt.c?
>
 Yeah, we can share push_block(), pop_block() stmt() and indent() but the
 main() function is totally different since there are only the processor
 device objects for ARM DSDT but there are many other things in x86.

 I think that since Boris will move the codes under
 tools/firmware/hvmloader/acpi to other place, after that we could see
 how to share codes then.
>>> I would prefer if we discuss about it now in order to avoid code
>>> duplication (I have CCed Boris).
>>>
>>> For instance we can create a new directory under tools for mk_dsdt.c.
>>> The main could be different, although it might be possible to gate ARM
>>> options, and the rest of the code would be shared.
>>
>> So I think we decided earlier to keep ARM and x86 ACPI builders
>> separate, at least for now. 
> I think so as well.
>
>> However, looking at the Makefile and mk_dsdt
>> I wonder whether it would make sense to put the builders in the same
>> directory (I am currently using tools/libacpi) so that those two files
>> can be kept common as much as possible, with the sources being
>> different. E.g. something like
>>
>> tools/libacpi:
>> Makefile
>> mk_dsdt.c
>> acpi_x86.[ch]
>> acpi_arm.[ch]
>> *asl
>> etc.
>>
>> The objects will be built in tools/libxl (there will be no libacpi.so)
>> but the infrastructure and sources will live together.
> I'm fine with this. But I think the patch moving the codes into
> tools/libacpi should be posted firstly, since this series depend on it.
> Boris, could you please send that patch? Then I can add the
> corresponding ARM patch on top of that.


I thought I had it almost ready yesterday but I encountered a problem
that I need to resolve before I post it. If I don't get it fixed in the
next couple of days I will send you a link to my repository so that you
can see what I have.

-boris


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

Re: [Xen-devel] Crash in xen 4.7 adding nic during domu startup

[Jan Beulich]

>>> On 28.06.16 at 13:23,  wrote:
> A clue on doing this would be useful, I can't debug what is now release
> code all day.

Well, debugging (released code or not) is what's needed, I'm afraid.
A first step would be to find out how far the corruption extends:
Considering the non-zero code bytes that got dumped, I would
have expected the 0xE8 to be a function call opcode, but then
the exception couldn't have occurred on the 4th byte after. So I
assume corruption extends beyond the zeroed range, and you
could figure this out by comparing with the actual binary.

If the range of the corrupted area doesn't provide any clues how
or when the corruption occurs, I'd then add debugging code which,
at coarse intervals, would inspect the area in question. Of course
you need to be prepare for the corruption area to move relative to
symbols.

But in the end this is a pretty unusual situation, where I don't think
I can provide pre-cooked debugging instructions.

But of course there are other angles to look at this from: You say
you use GPU pass-through. What about the case when you don't?
And while you appear to try to make logging more verbose by
using a (non-existent) "verbose" command line option, using
"loglvl=all guest_loglvl=all iommu=debug" would yield better
results.

Jan


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

Re: [Xen-devel] [PATCH V3 09/10] xen/arm: io: Use binary search for mmio handler lookup

[Julien Grall]

On 28/06/16 14:19, Shanker Donthineni wrote:

On 06/28/2016 05:49 AM, Julien Grall wrote:

On 27/06/16 21:33, Shanker Donthineni wrote:

As the number of I/O handlers increase, the overhead associated with
linear lookup also increases. The system might have maximum of 144
(assuming CONFIG_NR_CPUS=128) mmio handlers. In worst case scenario,
it would require 144 iterations for finding a matching handler. Now
it is time for us to change from linear (complexity O(n)) to a binary
search (complexity O(log n) for reducing mmio handler lookup overhead.

Signed-off-by: Shanker Donthineni 
---
Changes since v2:
   Converted mmio lookup code to a critical section.
   Copied the function bsreach() from Linux kernel.

  xen/arch/arm/io.c | 97

+++

  1 file changed, 84 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index a5b2c2d..c31fdf3 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -20,9 +20,50 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 

+/*
+ * bsearch - binary search an array of elements
+ * @key: pointer to item being searched for
+ * @base: pointer to first element to search
+ * @num: number of elements
+ * @size: size of each element
+ * @cmp: pointer to comparison function
+ *
+ * This function does a binary search on the given array.  The
+ * contents of the array should already be in ascending sorted order
+ * under the provided comparison function.
+ *
+ * Note that the key need not have the same type as the elements in
+ * the array, e.g. key could be a string and the comparison function
+ * could compare the string with the struct's name field. However, if
+ * the key and elements in the array are of the same type, you can use
+ * the same comparison function for both sort() and bsearch().
+ */
+static void *bsearch(const void *key, const void *base, size_t num,

size_t size,

+ int (*cmp)(const void *key, const void *elt))


This function is not specific to I/O handlers. So this should be moved
to common code. Also please mention in the commit message where the
code came from.



Should I move to xen/arch/arm folder?


To xen/common/

[...]


Anyway, I would try to merge the two compare functions
(match_mmio_handler, cmp_mmio_handler) which have very similar behavior.



Yes, they are not exactly same. One compares only start address and
other one compares the range.


I don't think this will be an issue to compare the range for both and it 
will avoid to duplicate the code.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH V3 09/10] xen/arm: io: Use binary search for mmio handler lookup

[Shanker Donthineni]

Hi Julien,

On 06/28/2016 05:49 AM, Julien Grall wrote:

Hi Shanker,

On 27/06/16 21:33, Shanker Donthineni wrote:

As the number of I/O handlers increase, the overhead associated with
linear lookup also increases. The system might have maximum of 144
(assuming CONFIG_NR_CPUS=128) mmio handlers. In worst case scenario,
it would require 144 iterations for finding a matching handler. Now
it is time for us to change from linear (complexity O(n)) to a binary
search (complexity O(log n) for reducing mmio handler lookup overhead.

Signed-off-by: Shanker Donthineni 
---
Changes since v2:
   Converted mmio lookup code to a critical section.
   Copied the function bsreach() from Linux kernel.

  xen/arch/arm/io.c | 97

+++

  1 file changed, 84 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index a5b2c2d..c31fdf3 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -20,9 +20,50 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 

+/*
+ * bsearch - binary search an array of elements
+ * @key: pointer to item being searched for
+ * @base: pointer to first element to search
+ * @num: number of elements
+ * @size: size of each element
+ * @cmp: pointer to comparison function
+ *
+ * This function does a binary search on the given array.  The
+ * contents of the array should already be in ascending sorted order
+ * under the provided comparison function.
+ *
+ * Note that the key need not have the same type as the elements in
+ * the array, e.g. key could be a string and the comparison function
+ * could compare the string with the struct's name field. However, if
+ * the key and elements in the array are of the same type, you can use
+ * the same comparison function for both sort() and bsearch().
+ */
+static void *bsearch(const void *key, const void *base, size_t num,

size_t size,

+ int (*cmp)(const void *key, const void *elt))


This function is not specific to I/O handlers. So this should be moved 
to common code. Also please mention in the commit message where the 
code came from.




Should I move to xen/arch/arm folder?


+{
+size_t start = 0, end = num;
+int result;
+
+while ( start < end )
+{
+size_t mid = start + (end - start) / 2;
+
+result = cmp(key, base + mid * size);
+if ( result < 0 )
+end = mid;
+else if ( result > 0 )
+start = mid + 1;
+else
+return (void *)base + mid * size;
+}
+
+return NULL;
+}
+
  static int handle_read(const struct mmio_handler *handler, struct vcpu

*v,

 mmio_info_t *info)
  {
@@ -70,23 +111,41 @@ static int handle_write(const struct mmio_handler

*handler, struct vcpu *v,

handler->priv);
  }

-int handle_mmio(mmio_info_t *info)
+static int match_mmio_handler(const void *key, const void *elem)
  {
-struct vcpu *v = current;
-int i;
-const struct mmio_handler *handler = NULL;
-const struct vmmio *vmmio = >domain->arch.vmmio;
+const struct mmio_handler *handler = elem;
+paddr_t addr = (paddr_t)key;

-for ( i = 0; i < vmmio->num_entries; i++ )
-{
-handler = >handlers[i];
+if ( addr < handler->addr )
+return -1;

-if ( (info->gpa >= handler->addr) &&
- (info->gpa < (handler->addr + handler->size)) )
-break;
-}
+if ( addr > (handler->addr + handler->size) )
+return 1;
+
+return 0;
+}

-if ( i == vmmio->num_entries )
+static const struct mmio_handler *
+find_mmio_handler(struct vcpu *v, paddr_t addr)
+{
+struct vmmio *vmmio = >domain->arch.vmmio;
+const struct mmio_handler *handler;
+
+spin_lock(>lock);
+handler = bsearch((const void *)addr, vmmio->handlers,

vmmio->num_entries,

paddr_t is always 64-bit regardless the architecture (ARM64 vs ARM32). 
So the cast will lead to a compilation error on ARM32.




I'll fix.

Please try to at least compile test your patch with ARM64, ARM32 and 
x86 (when you touch common code).




Thanks, I'll follow next time.

Anyway, I would try to merge the two compare functions 
(match_mmio_handler, cmp_mmio_handler) which have very similar behavior.




Yes, they are not exactly same. One compares only start address and 
other one compares the range.



+  sizeof(*handler), match_mmio_handler);
+spin_unlock(>lock);
+
+return handler;
+}
+
+int handle_mmio(mmio_info_t *info)
+{
+const struct mmio_handler *handler;
+struct vcpu *v = current;
+
+handler = find_mmio_handler(v, info->gpa);
+if ( !handler )
  return 0;

  if ( info->dabt.write )
@@ -95,6 +154,14 @@ int handle_mmio(mmio_info_t *info)
  return handle_read(handler, v, info);
  }

+static int cmp_mmio_handler(const void *key, const void *elem)
+{
+const struct mmio_handler *handler0 = key;
+const struct mmio_handler 

Re: [Xen-devel] making xenstore domain easy configurable

[Andrew Cooper]

On 28/06/16 12:56, Juergen Gross wrote:
> On 28/06/16 13:03, Ian Jackson wrote:
>> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy 
>> configurable"):
>>> So you are telling me the xenstore domain won't work for this case?
>> Yes.
> That's rather unfortunate. So in order to be able to make xenstore
> domain a common setup we need to find a solution for support of
> xs_restrict() via xenbus, right?
>
> TBH, the way xs_restrict() was introduced is rather weird. It is
> completely bound to the socket interface of oxenstored. So anyone
> wanting to use xs_restrict() is limited to oxenstored running in
> dom0. No way to use xenstored or a xenstore domain. I'm really
> disappointed such a design was accepted and is now the reason for
> not being able to disaggregate dom0.
>
> I've searched through the xen-devel archives and found a very
> interesting mail:
>
> http://lists.xen.org/archives/html/xen-devel/2010-04/msg01318.html
>
> The "restrict" feature was added without any further discussion how
> it is implemented and that the C-variant doesn't support it. The
> explicit question about non-existing features in the C xenstored was
> answered just with "the xenstore wire protocol doesn't change".
>
> With:
>
> http://lists.xen.org/archives/html/xen-devel/2010-07/msg00091.html
>
> the XS_RESTRICT value in xs_wire.h (aah, suddenly it was changed?)
> was added. Again no mentioning of the special implementation in
> oxenstored.
>
> Really, this is not how open source development should be done!
> Maybe I'm just upset now, but I'm in favor of dropping xs_restrict()
> support as it has been introduced in a foul way.

I don't think the lack of xs_restrict() working over the ring should
preclude these improvements to the configuration of how xenstored starts up.

Ideally, this issue would be listed in an appropriate place in
docs/features/, in the hope that it gets considered and addressed in the
future.

However, the xs_restrict() library function will clearly fail in some
way when cxenstored is in use, and nothing currently uses it, so the
lack of it also working when using a xenstored stubdomain doesn't
constitute a reduction in functionality.


Longterm, a sensible solution would be to make a xenstore protocol
extension to wrap an existing xenstore message in a restrict wrapper,
where the kernel device can apply the appropriate restrict around user
requests.  This isn't the only protocol extension required; there is an
existing problem XenServer has hit that a xenstore-ls response when
enough domains are running will exceed XENSTORE_MAX_PAYLOAD, and fail. 
Someone is going to have to fix that at some point - might as well do
these both at once.

~Andrew

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

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

[osstest service owner]

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

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  9b15b2e367a8565c73d5ba975e05c89c99078e60
baseline version:
 xen  08cffe6696c047123bd552e095163924c8ef4353

Last test of basis96310  2016-06-27 12:02:08 Z1 days
Testing same since96340  2016-06-28 10:01:49 Z0 days1 attempts


People who touched revisions under test:
  Kevin Tian 
  Quan Xu 
  Razvan Cojocaru 
  Tamas K Lengyel 

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=9b15b2e367a8565c73d5ba975e05c89c99078e60
+ . ./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 
9b15b2e367a8565c73d5ba975e05c89c99078e60
+ branch=xen-unstable-smoke
+ revision=9b15b2e367a8565c73d5ba975e05c89c99078e60
+ . ./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-4.7-testing
+ '[' x9b15b2e367a8565c73d5ba975e05c89c99078e60 = 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 

Re: [Xen-devel] [PATCH v4 08/16] xen: Replace _mfn(INVALID_MFN) with MFN_INVALID_T

[Julien Grall]

Hi Jan,

On 28/06/16 08:19, Jan Beulich wrote:

On 27.06.16 at 18:54,  wrote:

This patch is a mechanical replacement. Command used:

42sh> ack -l "_mfn\(INVALID_MFN\)" | xargs  sed -i -e
's/_mfn(INVALID_MFN)/INVALID_MFN_T/g'


Well, wait - if you do this, then I'm no longer sure my remark just
made on patch 2 holds: If you do such a global replacement, then
I think I'd prefer you to switch to the long term final name right
away, rather than having to touch all that code again later.


I will give a look to transform INVALID_{MFN,GFN} into a typesafe.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3] ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM

[Ard Biesheuvel]

On 28 June 2016 at 14:06, Julien Grall  wrote:
> Hi Ard,
>
> On 28/06/16 12:39, Ard Biesheuvel wrote:
>>
>> On 25 June 2016 at 09:16, Shannon Zhao  wrote:
>>>
>>> From: Shannon Zhao 
>>>
>>> Add ACPI support for Virt Xen ARM and only for aarch64. It gets the
>>> ACPI tables through Xen ARM multiboot protocol.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Shannon Zhao 
>>
>>
>> Reviewed-by: Ard Biesheuvel 
>>
>> Committed as 402dde68aff9
>
>
> We have not yet agreed on the bindings between Xen and UEFI (see patch [1]).
> How EDK2 deal with compatibility if we decide to modify the bindings for
> whatever reasons?
>

Thanks for emphasizing that. It would have been good to mention it in
the commit log.

Since this is all under development, I would prefer only the final
version of the binding to be supported (if it deviates from the one
this patch implements). As soon as anything ends up in a Xen release,
we can discuss again whether we need to support different versions of
the binding.

Thanks,
Ard.

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

Re: [Xen-devel] [PATCH v3] ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM

[Julien Grall]

Hi Ard,

On 28/06/16 12:39, Ard Biesheuvel wrote:

On 25 June 2016 at 09:16, Shannon Zhao  wrote:

From: Shannon Zhao 

Add ACPI support for Virt Xen ARM and only for aarch64. It gets the
ACPI tables through Xen ARM multiboot protocol.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Shannon Zhao 


Reviewed-by: Ard Biesheuvel 

Committed as 402dde68aff9


We have not yet agreed on the bindings between Xen and UEFI (see patch 
[1]). How EDK2 deal with compatibility if we decide to modify the 
bindings for whatever reasons?


Regards,

[1] 
http://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02943.html


--
Julien Grall

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

Re: [Xen-devel] making xenstore domain easy configurable

[Juergen Gross]

On 28/06/16 13:03, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy 
> configurable"):
>> So you are telling me the xenstore domain won't work for this case?
> 
> Yes.

That's rather unfortunate. So in order to be able to make xenstore
domain a common setup we need to find a solution for support of
xs_restrict() via xenbus, right?

TBH, the way xs_restrict() was introduced is rather weird. It is
completely bound to the socket interface of oxenstored. So anyone
wanting to use xs_restrict() is limited to oxenstored running in
dom0. No way to use xenstored or a xenstore domain. I'm really
disappointed such a design was accepted and is now the reason for
not being able to disaggregate dom0.

I've searched through the xen-devel archives and found a very
interesting mail:

http://lists.xen.org/archives/html/xen-devel/2010-04/msg01318.html

The "restrict" feature was added without any further discussion how
it is implemented and that the C-variant doesn't support it. The
explicit question about non-existing features in the C xenstored was
answered just with "the xenstore wire protocol doesn't change".

With:

http://lists.xen.org/archives/html/xen-devel/2010-07/msg00091.html

the XS_RESTRICT value in xs_wire.h (aah, suddenly it was changed?)
was added. Again no mentioning of the special implementation in
oxenstored.

Really, this is not how open source development should be done!
Maybe I'm just upset now, but I'm in favor of dropping xs_restrict()
support as it has been introduced in a foul way.


Juergen

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

Re: [Xen-devel] [PATCH v3] ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM

[Ard Biesheuvel]

On 25 June 2016 at 09:16, Shannon Zhao  wrote:
> From: Shannon Zhao 
>
> Add ACPI support for Virt Xen ARM and only for aarch64. It gets the
> ACPI tables through Xen ARM multiboot protocol.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Shannon Zhao 

Reviewed-by: Ard Biesheuvel 

Committed as 402dde68aff9

Thanks,
Ard.

> ---
> Changes since v2:
> * add gFdtClientProtocolGuid to the [Depex]
> * make functions static
> * move XenAcpiRsdpStructurePtr to InstallXenArmTables ()
> * initialize AcpiTable and FdtClient to NULL
>
> Changes since v1:
> * move the codes into ArmVirtPkg
> * use FdtClient
> * don't rely on OvmfPkg/AcpiPlatformDxe/EntryPoint.c while implement own
>   entry point since it's minor
> * use compatible string to find the DT node instead of node path
>
> If you want to test, the corresponding Xen patches can be fetched from:
> https://git.linaro.org/people/shannon.zhao/xen.git  domu_acpi_v2
> ---
>  ArmVirtPkg/ArmVirtXen.dsc  |   8 +
>  ArmVirtPkg/ArmVirtXen.fdf  |   8 +
>  ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c | 244 
> +
>  .../XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf  |  50 +
>  4 files changed, 310 insertions(+)
>  create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
>  create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
>
> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index 594ca64..a869986 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -216,3 +216,11 @@
>
>OvmfPkg/XenBusDxe/XenBusDxe.inf
>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +
> +  #
> +  # ACPI support
> +  #
> +!if $(ARCH) == AARCH64
> +  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
> +!endif
> diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
> index 13412f9..b1e00e5 100644
> --- a/ArmVirtPkg/ArmVirtXen.fdf
> +++ b/ArmVirtPkg/ArmVirtXen.fdf
> @@ -179,6 +179,14 @@ READ_LOCK_STATUS   = TRUE
>INF OvmfPkg/XenBusDxe/XenBusDxe.inf
>INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
>
> +  #
> +  # ACPI support
> +  #
> +!if $(ARCH) == AARCH64
> +  INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  INF ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
> +!endif
> +
>  [FV.FVMAIN_COMPACT]
>  FvAlignment= 16
>  ERASE_POLARITY = 1
> diff --git a/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c 
> b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
> new file mode 100644
> index 000..c6912ba
> --- /dev/null
> +++ b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
> @@ -0,0 +1,244 @@
> +/** @file
> +  Xen ARM ACPI Platform Driver using Xen ARM multiboot protocol
> +
> +  Copyright (C) 2016, Linaro Ltd. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +/**
> +  Get the address of Xen ACPI Root System Description Pointer (RSDP)
> +  structure.
> +
> +  @param  RsdpStructurePtr   Return pointer to RSDP structure
> +
> +  @return EFI_SUCCESSFind Xen RSDP structure successfully.
> +  @return EFI_NOT_FOUND  Don't find Xen RSDP structure.
> +  @return EFI_ABORTEDFind Xen RSDP structure, but it's not 
> integrated.
> +
> +**/
> +STATIC
> +EFI_STATUS
> +EFIAPI
> +GetXenArmAcpiRsdp (
> +  OUT   EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER   **RsdpPtr
> +  )
> +{
> +  EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER   *RsdpStructurePtr;
> +  EFI_STATUS Status;
> +  FDT_CLIENT_PROTOCOL*FdtClient;
> +  CONST UINT64   *Reg;
> +  UINT32 RegElemSize, RegSize;
> +  UINT64 RegBase;
> +  UINT8  Sum;
> +
> +  RsdpStructurePtr = NULL;
> +  FdtClient = NULL;
> +  //
> +  // Get the RSDP structure address from DeviceTree
> +  //
> +  Status = gBS->LocateProtocol (, NULL,
> +  (VOID **));
> +  ASSERT_EFI_ERROR (Status);
> +
> +  Status = FdtClient->FindCompatibleNodeReg (FdtClient, "xen,guest-acpi",
> +(CONST VOID **), , );
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((EFI_D_WARN, "%a: No 'xen,guest-acpi' compatible DT node 

[Xen-devel] [PATCH] xen/arm: gic-v3: No need to sort the Redistributor regions

[Julien Grall]

The sorting was required by the vGIC emulation until commit
9b9d51e98edb8c5c731e2d06dfad3633053d88a4 "xen/arm: vgic-v3:
Correctly retrieve the vCPU associated to a re-distributor".

Furthermore, the code is buggy because both local variables 'l' and 'r'
point to the same region.

So drop the code which sort the Redistributors array.

Reported-by: Shanker Donthineni 
Signed-off-by: Julien Grall 
---
 xen/arch/arm/gic-v3.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index dfc62e8..3b02a8c 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1134,14 +1134,6 @@ static const hw_irq_controller gicv3_guest_irq_type = {
 .set_affinity = gicv3_irq_set_affinity,
 };
 
-static int __init cmp_rdist(const void *a, const void *b)
-{
-const struct rdist_region *l = a, *r = a;
-
-/* We assume that re-distributor regions can never overlap */
-return ( l->base < r->base) ? -1 : 0;
-}
-
 static paddr_t __initdata dbase = INVALID_PADDR;
 static paddr_t __initdata vbase = INVALID_PADDR, vsize = 0;
 static paddr_t __initdata cbase = INVALID_PADDR, csize = 0;
@@ -1210,9 +1202,6 @@ static void __init gicv3_dt_init(void)
 rdist_regs[i].size = rdist_size;
 }
 
-/* The vGIC code requires the region to be sorted */
-sort(rdist_regs, gicv3.rdist_count, sizeof(*rdist_regs), cmp_rdist, NULL);
-
 if ( !dt_property_read_u32(node, "redistributor-stride", 
_stride) )
 gicv3.rdist_stride = 0;
 
-- 
1.9.1


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

Re: [Xen-devel] Crash in xen 4.7 adding nic during domu startup

[Peter Kay]

A clue on doing this would be useful, I can't debug what is now release
code all day.

4.5 is absolutely fine. 4.6.3 (tried last night) does not fail either but
refuses to start my domU that has two nics assigned to it in a vif line.
I'm presuming other people are successfully running multiple NICs on one VM
(ioemu, e1000)

PK

On Tuesday, 28 June 2016, Jan Beulich  wrote:

> >>> On 28.06.16 at 00:28, >
> wrote:
> > (XEN) [2016-06-27 22:11:41.712] [ Xen-4.7.0  x86_64  debug=n  Not
> tainted ]
> > (XEN) [2016-06-27 22:11:41.712] CPU:0
> > (XEN) [2016-06-27 22:11:41.712] RIP:e008:[]
> domain_relinquish_resources+0x10/0x2f0
> > (XEN) [2016-06-27 22:11:41.712] RFLAGS: 00010296   CONTEXT:
> hypervisor (d0v0)
> > (XEN) [2016-06-27 22:11:41.712] rax:    rbx:
> 83020ac4f000   rcx: 82d0802346bc
> > (XEN) [2016-06-27 22:11:41.712] rdx: 8300bf8d7fff   rsi:
>    rdi: 83020afde050
> > (XEN) [2016-06-27 22:11:41.712] rbp: 8300bf8d7e48   rsp:
> 8300bf8d7d78   r8:  0001
> > (XEN) [2016-06-27 22:11:41.712] r9:     r10:
> 0003   r11: 83023d94b1d8
> > (XEN) [2016-06-27 22:11:41.712] r12: 7ffe21eb9530   r13:
>    r14: 83020ac4f000
> > (XEN) [2016-06-27 22:11:41.712] r15: 7ffe21eb9530   cr0:
> 80050033   cr4: 26e0
> > (XEN) [2016-06-27 22:11:41.712] cr3: 000216737000   cr2:
> 
> > (XEN) [2016-06-27 22:11:41.712] ds:    es:    fs:    gs:
>    ss: e010   cs: e008
> > (XEN) [2016-06-27 22:11:41.712] Xen code around 
> (domain_relinquish_resources+0x10/0x2f0):
> > (XEN) [2016-06-27 22:11:41.712]  18 48 8b bf e8 01 00 00 <00> 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00
>
> Something very clearly corrupted your hypervisor code, and that's
> what you'll need to track down.
>
> Jan
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] xc_domain_maximum_gpfn

[Julien Grall]

Hello,

On 27/06/16 14:31, sepanta s wrote:



On Sun, Jun 26, 2016 at 5:19 PM, sepanta s > wrote:

Hi,
what exactly does this module do?

sorry, not module but the function.


The function xc_domain_maximum_gpfn returns the highest frame that has 
ever been mapped in the p2m.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Shannon Zhao]

On 2016/6/27 20:05, Boris Ostrovsky wrote:
> 
> 
> On 06/27/2016 06:29 AM, Julien Grall wrote:
>> (CC Boris and Doug)
>>
>> Hi Shannon,
>>
>> On 27/06/16 07:01, Shannon Zhao wrote:
>>> On 2016/6/24 1:03, Julien Grall wrote:
 On 23/06/16 04:16, Shannon Zhao wrote:

 [...]

> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 264b6ef..5347480 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -77,7 +77,29 @@ endif
>
>LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
>LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o
> libxl_libfdt_compat.o
> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
> +
> +vpath iasl $(PATH)
> +libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
> +$(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
> +
> +libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
> +awk 'NR > 1 {print s} {s=$$0}' $< > $@
> +./libxl_mk_dsdt_arm >> $@
> +
> +libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
> +iasl -vs -p $* -tc $*.asl
> +sed -e 's/AmlCode/$*/g' $*.hex >$@
> +echo "int $*_len=sizeof($*);" >>$@
> +rm -f $*.aml $*.hex
> +

 I don't like the idea to add iasl as a dependency for all ARM
 platforms.
 For instance ARMv7 platform will not use ACPI, but we still ask
 users to
 install iasl. So I think we should allow the user to opt-in/opt-out for
 ACPI.

 Any opinions?

>>> I agree. But how to exclude for ARMv7. I notice it only has the option
>>> CONFIG_ARM which doesn't distinguish ARM32 and ARM64.
>>
>> I am not sure if we plan to introduce Kconfig for tools. If not, you
>> can add an option to the configure to enable/disable ACPI for guest.
>>
>> This would be gated by the presence of "iasl".
>>
>> [...]
>>
> diff --git a/tools/libxl/libxl_mk_dsdt_arm.c
> b/tools/libxl/libxl_mk_dsdt_arm.c
> new file mode 100644
> index 000..96fadbd
> --- /dev/null
> +++ b/tools/libxl/libxl_mk_dsdt_arm.c

 Can we share the code from tools/firmware/acpi/mk_dsdt.c?

>>> Yeah, we can share push_block(), pop_block() stmt() and indent() but the
>>> main() function is totally different since there are only the processor
>>> device objects for ARM DSDT but there are many other things in x86.
>>>
>>> I think that since Boris will move the codes under
>>> tools/firmware/hvmloader/acpi to other place, after that we could see
>>> how to share codes then.
>>
>> I would prefer if we discuss about it now in order to avoid code
>> duplication (I have CCed Boris).
>>
>> For instance we can create a new directory under tools for mk_dsdt.c.
>> The main could be different, although it might be possible to gate ARM
>> options, and the rest of the code would be shared.
> 
> 
> So I think we decided earlier to keep ARM and x86 ACPI builders
> separate, at least for now. 
I think so as well.

> However, looking at the Makefile and mk_dsdt
> I wonder whether it would make sense to put the builders in the same
> directory (I am currently using tools/libacpi) so that those two files
> can be kept common as much as possible, with the sources being
> different. E.g. something like
> 
> tools/libacpi:
> Makefile
> mk_dsdt.c
> acpi_x86.[ch]
> acpi_arm.[ch]
> *asl
> etc.
> 
> The objects will be built in tools/libxl (there will be no libacpi.so)
> but the infrastructure and sources will live together.
I'm fine with this. But I think the patch moving the codes into
tools/libacpi should be posted firstly, since this series depend on it.
Boris, could you please send that patch? Then I can add the
corresponding ARM patch on top of that.

Thanks,
-- 
Shannon


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