Re: [Xen-devel] unable start xen in hikey

2016-08-04 Thread Chenxiao Zhao 
The xen.cfg file seems fine to me. I suggest you try to use the dtb file 
compiled from the kernel source and update UEFI bootloader on hikey 
board to the latest version.


hope this could help.

On 8/4/2016 11:02 PM, Kamenee Arumugam wrote:

I have already pass hi6220-key.dtb in my xen.cfg:

options=console=dtuart dom0_mem=512M dom0_max_vcpus=4 conswitch=x
dtuart=/smb/uart@f7113000
kernel=Image console=hvc0 root=/dev/mmcblk1p4 rootwait rw
dtb=hi6220-hikey.dtb

I download the hi6220-hikey.dtb from this site:
https://android.googlesource.com/device/linaro/hikey-kernel/+/f117fa12746b59aa0a1a4d6335145e58935c422b/hi6220-hikey.dtb


Firstly, I build kernel using the command below:

make -j24 Image hi6220-hikey.dtb

I placed hikey6220-hikey.dtb in linux directory level. I also copied the
dtb into sd before booting up. Please correct me if my steps are wrong.


On Thu, Aug 4, 2016 at 3:27 AM, Chenxiao Zhao > wrote:

you have to pass hi6220-key.dtb to xen.

On Thu, Aug 4, 2016 at 2:15 AM Kamenee Arumugam
> wrote:

Hi all,

I am unable to start xen in hikey successfully but getting to
this prompt message:


>/Xen 4.7.0 (c/s Mon Jun 20 11:38:15 2016 +0100 git:9a6cc4f) EFI
loader/
>/Using configuration file 'xen.cfg'/
>/Image: 0x79fd-0x7acb8c00
/
/> Unable to create new FDT
/
/Shell

/
I am following this wiki (http://wiki.xen.org/wiki/HiKey) to
setup xen in hikey. I am not sure what could cause this issue
here. Appreciate all of you input and advice here.

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




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

[Xen-devel] [PATCH RFC 03/04] tools/libxc: arm: Implement save ops arm_setup

2016-08-04 Thread Chenxiao Zhao 
arm_setup need to return number of pages that vm is allocated. Code is 
copied from x64 save ops.


Signed-off-by: Chenxiao Zhao 

diff --git a/tools/libxc/xc_sr_save_arm.c b/tools/libxc/xc_sr_save_arm.c
index 611f99a..a2ef2db 100644
--- a/tools/libxc/xc_sr_save_arm.c
+++ b/tools/libxc/xc_sr_save_arm.c
@@ -122,7 +122,23 @@ static int arm_normalise_page(struct xc_sr_context 
*ctx,


 static int arm_setup(struct xc_sr_context *ctx)
 {
-/* no-op */
+xc_interface *xch = ctx->xch;
+xen_pfn_t nr_pfns;
+
+if (xc_domain_nr_gpfns(xch, ctx->domid, _pfns) < 0 )
+{
+PERROR("Unable to obtain the guest p2m size");
+return -1;
+}
+if ( nr_pfns > ~XEN_DOMCTL_PFINFO_LTAB_MASK )
+{
+errno = E2BIG;
+PERROR("Cannot save this big a guest");
+return -1;
+}
+
+ctx->save.p2m_size = nr_pfns;
+
 return 0;
 }

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

[Xen-devel] [PATCH RFC 04/04] xen: arm64: save/restore domain type

2016-08-04 Thread Chenxiao Zhao 
On arm64 VM uses d->arch.type to indicate if the domain is 32-bit or 
64-bit. This value is set while parsing kernel image. while restoring 
VCPU state, it will use this value to decide the VCPU type. I can not 
find a proper place to save/restore this value in state file, this is 
surely not a good implementation.


Signed-off-by: Chenxiao Zhao 

diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index 3073b17..4702f60 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -108,6 +108,7 @@ static int cpu_save(struct domain *d, 
hvm_domain_context_t *h)

 continue;

 memset(, 0, sizeof(ctxt));
+   ctxt.is_64bit = is_64bit_domain(d);
 ctxt.sctlr = v->arch.sctlr;
 ctxt.ttbr0 = v->arch.ttbr0;
 ctxt.ttbr1 = v->arch.ttbr1;
@@ -188,6 +189,9 @@ static int cpu_load(struct domain *d, 
hvm_domain_context_t *h)

 if ( hvm_load_entry(VCPU, h, ) != 0 )
 return -EINVAL;

+if(ctxt.is_64bit)
+   v->domain->arch.type = DOMAIN_64BIT;
+
 v->arch.sctlr = ctxt.sctlr;
 v->arch.ttbr0 = ctxt.ttbr0;
 v->arch.ttbr1 = ctxt.ttbr1;
diff --git a/xen/include/public/arch-arm/hvm/save.h 
b/xen/include/public/arch-arm/hvm/save.h

index 80330dc..68b6136 100644
--- a/xen/include/public/arch-arm/hvm/save.h
+++ b/xen/include/public/arch-arm/hvm/save.h
@@ -53,6 +53,10 @@ struct hvm_hw_cpu
 uint64_t vfp[66];
 #endif

+#ifdef CONFIG_ARM_64
+uint32_t is_64bit;
+#endif
+
 /* Guest core registers */
 struct vcpu_guest_core_regs core_regs;

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

[Xen-devel] [PATCH RFC 02/04] tools/libxc: arm: Add missing save ops

2016-08-04 Thread Chenxiao Zhao 
Add arm_check_vm_state function, .check_vm_state can not be NULL in arch 
specific ops.


Signed-off-by: Chenxiao Zhao 

diff --git a/tools/libxc/xc_sr_save_arm.c b/tools/libxc/xc_sr_save_arm.c
index 1442679..611f99a 100644
--- a/tools/libxc/xc_sr_save_arm.c
+++ b/tools/libxc/xc_sr_save_arm.c
@@ -161,6 +161,12 @@ static int arm_cleanup(struct xc_sr_context *ctx)
 return 0;
 }

+static int arm_check_vm_state(struct xc_sr_context *ctx)
+{
+   /* no-op */
+   return 0;
+}
+
 struct xc_sr_save_ops save_ops_arm =
 {
 .pfn_to_gfn  = arm_pfn_to_gfn,
@@ -169,6 +175,7 @@ struct xc_sr_save_ops save_ops_arm =
 .start_of_stream = arm_start_of_stream,
 .start_of_checkpoint = arm_start_of_checkpoint,
 .end_of_checkpoint   = arm_end_of_checkpoint,
+.check_vm_state  = arm_check_vm_state,
 .cleanup = arm_cleanup,
 };

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

[Xen-devel] [PATCH RFC 00/04] xen: arm64: Support VM save/restore on arm64

2016-08-04 Thread Chenxiao Zhao 

Hi all,

This patch added support VM save/restore for arm64. It is based on 
previous work done by Ian Campbell [1] with some bug fixes to make it 
work on stable-4.7. You should apply Ian's patch first.


There still some known issues that have not fixed yet.

* GIC v2 not support
* No live migration
* does not support VM with multiple CPU cores


[1] 
https://lists.xenproject.org/archives/html/xen-devel/2015-12/msg01053.html


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

[Xen-devel] [PATCH RFC 01/04] xen: arm64: save/restore VCPU state for arm64

2016-08-04 Thread Chenxiao Zhao 

added support to save/restore arm64 registers

Signed-off-by: Chenxiao Zhao 

diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index aee3353..3073b17 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -120,7 +120,8 @@ static int cpu_save(struct domain *d, 
hvm_domain_context_t *h)

 ctxt.dfar = v->arch.dfar;
 ctxt.dfsr = v->arch.dfsr;
 #else
-/* XXX 64-bit */
+   ctxt.far = v->arch.far;
+   ctxt.esr = v->arch.esr;
 #endif

 #ifdef CONFIG_ARM_32
@@ -199,7 +200,8 @@ static int cpu_load(struct domain *d, 
hvm_domain_context_t *h)

 v->arch.dfar = ctxt.dfar;
 v->arch.dfsr = ctxt.dfsr;
 #else
-/* XXX 64-bit */
+v->arch.far = ctxt.far;
+v->arch.esr = ctxt.esr;
 #endif

 #ifdef CONFIG_ARM_32
diff --git a/xen/include/public/arch-arm/hvm/save.h 
b/xen/include/public/arch-arm/hvm/save.h

index db916b1..80330dc 100644
--- a/xen/include/public/arch-arm/hvm/save.h
+++ b/xen/include/public/arch-arm/hvm/save.h
@@ -46,16 +46,26 @@ DECLARE_HVM_SAVE_TYPE(HEADER, 1, struct 
hvm_save_header);


 struct hvm_hw_cpu
 {
+#ifdef CONFIG_ARM_32
 uint64_t vfp[34]; /* Vector floating pointer */
 /* VFP v3 state is 34x64 bit, VFP v4 is not yet supported */
+#else
+uint64_t vfp[66];
+#endif

 /* Guest core registers */
 struct vcpu_guest_core_regs core_regs;

-uint32_t sctlr, ttbcr;
+uint32_t sctlr;
+#ifdef CONFIG_ARM_32
+uint32_t ttbcr;
+#else
+uint64_t ttbcr;
+#endif
 uint64_t ttbr0, ttbr1;

 uint32_t ifar, dfar;
+uint64_t far, esr;
 uint32_t ifsr, dfsr;
 uint32_t dacr;
 uint64_t par;

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

Re: [Xen-devel] [PATCH v5 0/4] x86/ioreq server: Introduce HVMMEM_ioreq_server mem type.

2016-08-04 Thread Yu Zhang 


On 7/12/2016 5:02 PM, Yu Zhang wrote:

XenGT leverages ioreq server to track and forward the accesses to GPU
I/O resources, e.g. the PPGTT(per-process graphic translation tables).
Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges
to be emulated. To select an ioreq server, the rangeset is searched to
see if the I/O range is recorded. However, number of ram pages to be
tracked may exceed the upper limit of rangeset.

Previously, one solution was proposed to refactor the rangeset, and
extend its upper limit. However, after 12 rounds discussion, we have
decided to drop this approach due to security concerns. Now this new
patch series introduces a new mem type, HVMMEM_ioreq_server, and added
hvm operations to let one ioreq server to claim its ownership of ram
pages with this type. Accesses to a page of this type will be handled
by the specified ioreq server directly.

Yu Zhang (4):
   x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server.
   x86/ioreq server: Add new functions to get/set memory types.
   x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to
 an ioreq server.
   x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an
 ioreq server unmaps.

  xen/arch/x86/hvm/emulate.c   |  33 +++-
  xen/arch/x86/hvm/hvm.c   | 395 ++-
  xen/arch/x86/hvm/ioreq.c |  41 
  xen/arch/x86/mm/hap/hap.c|   9 +
  xen/arch/x86/mm/hap/nested_hap.c |   2 +-
  xen/arch/x86/mm/p2m-ept.c|  14 +-
  xen/arch/x86/mm/p2m-pt.c |  30 ++-
  xen/arch/x86/mm/p2m.c|  77 
  xen/arch/x86/mm/shadow/multi.c   |   3 +-
  xen/include/asm-x86/hvm/ioreq.h  |   2 +
  xen/include/asm-x86/p2m.h|  36 +++-
  xen/include/public/hvm/hvm_op.h  |  34 +++-
  12 files changed, 528 insertions(+), 148 deletions(-)



Hi Jan & George, any comments on this version? :)
Sorry if this mail disturbs, but it has been more than 3 weeks since the 
post...


Thanks
Yu




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

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

2016-08-04 Thread Platform Team regression test user 
This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf afd6b28915cac422294a28033ef83727b27ce216
baseline version:
 ovmf 365a3aab857a2820d36d2ae9b3b62f06230b295a

Last test of basis66913  2016-08-04 06:49:16 Z0 days
Testing same since66919  2016-08-04 16:51:37 Z0 days1 attempts


People who touched revisions under test:
  Daniil Egranov 

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



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

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

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


Push not applicable.


commit afd6b28915cac422294a28033ef83727b27ce216
Author: Daniil Egranov 
Date:   Wed Aug 3 18:10:48 2016 -0500

ArmPlatformPkg: change PcdBdsLinuxSupport default value

The built-in Linux Loader is obsolete and not included in most builds.
The patch sets the PcdBdsLinuxSupport default value to FALSE and prevents
ArmBds from looking for built-in Linux Loader by default and ASSERTing
when it cannot be found. Platforms which still using built-in loader have
to set this PCD in their platform description file.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daniil Egranov 
Reviewed-by: Leif Lindholm 

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

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

2016-08-04 Thread osstest service owner 
flight 99944 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99944/

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuu09704e6ded83fa0bec14baf32f800f6512156ca0
baseline version:
 qemuu6eac5f7bad6cd8f56b3514ac485dd35d79abff66

Last test of basis99938  2016-08-04 05:27:33 Z0 days
Testing same since99944  2016-08-04 14:42:43 Z0 days1 attempts


People who touched revisions under test:
  Cao jin 
  Daniel P. Berrange 
  Dave Hansen 
  Emilio G. Cota 
  Eric Blake 
  Fam Zheng 
  Gerd Hoffmann 
  Greg Kurz 
  Igor Mammedov 
  Markus Armbruster 
  Paolo Bonzini 
  Peter Maydell 
  Peter Xu 
  Robert Ho 
  Sergey Fedorov 
  Shmulik Ladkani 
  Stefan Hajnoczi 

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-pvops

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

2016-08-04 Thread osstest service owner 
flight 99942 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99942/

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. 99917
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
99917

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 99917
 build-i386-rumpuserxen6 xen-buildfail   like 99917
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 99917
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 99917
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 99917
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 99917

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-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   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-libvirt-xsm 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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-amd64-i386-libvirt-xsm  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-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-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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

version targeted for testing:
 xen  350bc1a9d4ebc03b18a43cdafcb626618caace55
baseline version:
 xen  e9522e4932aaa7f083688b6612b5897839409260

Last test of basis99917  2016-08-03 08:27:27 Z1 days
Failing since 99928  2016-08-03 16:14:26 Z1 days3 attempts
Testing same since99942  2016-08-04 14:14:00 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anshul Makkar 
  Dario Faggioli 
  George Dunlap 
  Jacob Pan 
  Jan Beulich 
  Joao Martins 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Len Brown 
  Paul Durrant 
  Rafael J. Wysocki 
  Stefano Stabellini 
  Tim Deegan 
  Wei Liu 
  Yu Zhang 

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

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

2016-08-04 Thread osstest service owner 
flight 99948 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99948/

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  97323702bf101615cfdcf329913094c4cc82bf99
baseline version:
 xen  0a7ba29364576deb4c13b3bb4cf7d03136bead98

Last test of basis99947  2016-08-04 18:01:52 Z0 days
Testing same since99948  2016-08-04 20:01:24 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 

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=97323702bf101615cfdcf329913094c4cc82bf99
+ . ./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 
97323702bf101615cfdcf329913094c4cc82bf99
+ branch=xen-unstable-smoke
+ revision=97323702bf101615cfdcf329913094c4cc82bf99
+ . ./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
+ '[' x97323702bf101615cfdcf329913094c4cc82bf99 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo

[Xen-devel] [PATCH v2 01/23] hvmloader: Provide hvmloader_acpi_build_tables()

2016-08-04 Thread Boris Ostrovsky 
In preparation for moving out ACPI builder make all
BIOSes call hvmloader_acpi_build_tables() instead of
calling ACPI code directly.

No functional changes.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
 tools/firmware/hvmloader/ovmf.c| 2 +-
 tools/firmware/hvmloader/rombios.c | 2 +-
 tools/firmware/hvmloader/seabios.c | 2 +-
 tools/firmware/hvmloader/util.c| 7 +++
 tools/firmware/hvmloader/util.h| 4 
 5 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index 59d0e45..1c8a71b 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -127,7 +127,7 @@ static void ovmf_acpi_build_tables(void)
 .dsdt_15cpu_len = 0
 };
 
-acpi_build_tables(, ACPI_PHYSICAL_ADDRESS);
+hvmloader_acpi_build_tables(, ACPI_PHYSICAL_ADDRESS);
 }
 
 static void ovmf_create_smbios_tables(void)
diff --git a/tools/firmware/hvmloader/rombios.c 
b/tools/firmware/hvmloader/rombios.c
index 2ded844..38a86ff 100644
--- a/tools/firmware/hvmloader/rombios.c
+++ b/tools/firmware/hvmloader/rombios.c
@@ -181,7 +181,7 @@ static void rombios_acpi_build_tables(void)
 .dsdt_15cpu_len = dsdt_15cpu_len,
 };
 
-acpi_build_tables(, ACPI_PHYSICAL_ADDRESS);
+hvmloader_acpi_build_tables(, ACPI_PHYSICAL_ADDRESS);
 }
 
 static void rombios_create_mp_tables(void)
diff --git a/tools/firmware/hvmloader/seabios.c 
b/tools/firmware/hvmloader/seabios.c
index c5d2b34..3d046fd 100644
--- a/tools/firmware/hvmloader/seabios.c
+++ b/tools/firmware/hvmloader/seabios.c
@@ -97,7 +97,7 @@ static void seabios_acpi_build_tables(void)
 .dsdt_15cpu_len = 0,
 };
 
-acpi_build_tables(, rsdp);
+hvmloader_acpi_build_tables(, rsdp);
 add_table(rsdp);
 }
 
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 9382709..9af29b1 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -21,6 +21,7 @@
 #include "config.h"
 #include "hypercall.h"
 #include "ctype.h"
+#include "acpi/acpi2_0.h"
 #include 
 #include 
 #include 
@@ -856,6 +857,12 @@ int hpet_exists(unsigned long hpet_base)
 return ((hpet_id >> 16) == 0x8086);
 }
 
+void hvmloader_acpi_build_tables(struct acpi_config *config,
+ unsigned int physical)
+{
+acpi_build_tables(config, physical);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 9808016..0fb266e 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -276,6 +276,10 @@ extern struct e820map memory_map;
 bool check_overlap(uint64_t start, uint64_t size,
uint64_t reserved_start, uint64_t reserved_size);
 
+struct acpi_config;
+void hvmloader_acpi_build_tables(struct acpi_config *config,
+ unsigned int physical);
+
 #endif /* __HVMLOADER_UTIL_H__ */
 
 /*
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 00/23] Make ACPI builder available to components other than hvmloader

2016-08-04 Thread Boris Ostrovsky 
The goal here is to build ACPI tables for PVHv2/HVMlite guests while reusing 
existing
hvmloader's ACPI builder code. The builder is provided as a library in 
tools/libacpi.

This version is built on top of Anthony's 
git://xenbits.xen.org/people/aperard/xen-unstable.git:hvmloader-with-separated-bios-v7

It also requires (still not fully ACKed, sigh) ACPI relicensing patch
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg01975.html

Major changes:
* Keep struct_acpi_info private to build.c
* Separate table allocation and loading, similar to ARM's approach

More detailed changes are listed per patch.


Boris Ostrovsky (23):
  hvmloader: Provide hvmloader_acpi_build_tables()
  acpi/hvmloader: Allow acpi_build_tables() callers specify acpi_info
values
  acpi/hvmloader: Initialize vm_gid data outside ACPI code
  acpi/hvmloader: Decide which SSDTs to install in hvmloader
  acpi/hvmloader: Move passthrough initialization from ACPI code
  acpi/hvmloader: Collect processor and NUMA info in hvmloader
  acpi/hvmloader: Set TIS header address in hvmloader
  acpi/hvmloader: Make providing IOAPIC in MADT optional
  acpi/hvmloader: Build WAET optionally
  acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
  acpi/hvmloader: Translate all addresses when assigning addresses in
ACPI tables
  acpi/hvmloader: Link ACPI object files directly
  acpi/hvmloader: Include file/paths adjustments
  acpi: Move ACPI code to tools/libacpi
  x86: Add more checks verifying that PIT/PIC/IOAPIC are emulated
  x86: Allow LAPIC-only emulation_flags for HVM guests
  libacpi: Build DSDT for PVH guests
  libxc/libxl: Allow multiple ACPI modules
  libxl/acpi: Add ACPI e820 entry
  libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests
  ilibxl: Initialize domain build info before calling libxl__domain_make
  libxl/acpi: Build ACPI tables for HVMlite guests
  libxc/xc_dom_core: Copy ACPI tables to guest space

 .gitignore|  20 +-
 tools/firmware/hvmloader/Makefile |  20 +-
 tools/firmware/hvmloader/acpi/Makefile|  70 ---
 tools/firmware/hvmloader/acpi/README  |  24 -
 tools/firmware/hvmloader/acpi/acpi2_0.h   | 470 ---
 tools/firmware/hvmloader/acpi/build.c | 646 --
 tools/firmware/hvmloader/acpi/dsdt.asl| 478 ---
 tools/firmware/hvmloader/acpi/mk_dsdt.c   | 501 
 tools/firmware/hvmloader/acpi/ssdt_pm.asl | 418 -
 tools/firmware/hvmloader/acpi/ssdt_s3.asl |  28 --
 tools/firmware/hvmloader/acpi/ssdt_s4.asl |  28 --
 tools/firmware/hvmloader/acpi/ssdt_tpm.asl|  28 --
 tools/firmware/hvmloader/acpi/static_tables.c | 168 ---
 tools/firmware/hvmloader/config.h |   8 +-
 tools/firmware/hvmloader/hvmloader.c  |   3 +-
 tools/firmware/hvmloader/mp_tables.c  |   1 +
 tools/firmware/hvmloader/ovmf.c   |   4 +-
 tools/firmware/hvmloader/pci.c|   1 +
 tools/firmware/hvmloader/pir.c|   1 +
 tools/firmware/hvmloader/rombios.c|   4 +-
 tools/firmware/hvmloader/seabios.c|   5 +-
 tools/firmware/hvmloader/smp.c|   1 +
 tools/firmware/hvmloader/util.c   |  98 
 tools/firmware/hvmloader/util.h   |   4 +
 tools/libacpi/Makefile|  80 
 tools/libacpi/README  |  32 ++
 tools/libacpi/acpi2_0.h   | 461 ++
 tools/libacpi/build.c | 645 +
 tools/libacpi/dsdt.asl| 458 ++
 tools/libacpi/dsdt_acpi_info.asl  |  23 +
 tools/libacpi/libacpi.h   | 110 +
 tools/libacpi/mk_dsdt.c   | 511 
 tools/libacpi/ssdt_pm.asl | 418 +
 tools/libacpi/ssdt_s3.asl |  28 ++
 tools/libacpi/ssdt_s4.asl |  28 ++
 tools/libacpi/ssdt_tpm.asl|  28 ++
 tools/libacpi/static_tables.c | 168 +++
 tools/libacpi/x86.h   |  30 ++
 tools/libxc/include/xc_dom.h  |   5 +-
 tools/libxc/xc_dom_core.c |  92 
 tools/libxc/xc_dom_hvmloader.c|   3 +-
 tools/libxl/Makefile  |  19 +-
 tools/libxl/libxl_arch.h  |   3 +
 tools/libxl/libxl_create.c|  22 +-
 tools/libxl/libxl_dom.c   |  57 ++-
 tools/libxl/libxl_x86.c   |  44 +-
 tools/libxl/libxl_x86_acpi.c  | 199 
 tools/libxl/libxl_x86_acpi.h  |  35 ++
 xen/arch/x86/domain.c |  26 +-
 xen/arch/x86/hvm/vlapic.c |  14 +-
 xen/arch/x86/hvm/vpt.c|

[Xen-devel] [PATCH v2 21/23] ilibxl: Initialize domain build info before calling libxl__domain_make

2016-08-04 Thread Boris Ostrovsky 
libxl__domain_make() may want to use b_info so we should set defaults
a little earlier.

Signed-off-by: Boris Ostrovsky 
---
v2:
* New patch. The need for this patch was triggered by commit b173750d2bc2

 tools/libxl/libxl_create.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 828f254..08822e3 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -883,17 +883,6 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
-ret = libxl__domain_make(gc, d_config, , >config);
-if (ret) {
-LOG(ERROR, "cannot make domain: %d", ret);
-dcs->guest_domid = domid;
-ret = ERROR_FAIL;
-goto error_out;
-}
-
-dcs->guest_domid = domid;
-dcs->sdss.dm.guest_domid = 0; /* means we haven't spawned */
-
 ret = libxl__domain_build_info_setdefault(gc, _config->b_info);
 if (ret) {
 LOG(ERROR, "Unable to set domain build info defaults");
@@ -907,6 +896,17 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
+ret = libxl__domain_make(gc, d_config, , >config);
+if (ret) {
+LOG(ERROR, "cannot make domain: %d", ret);
+dcs->guest_domid = domid;
+ret = ERROR_FAIL;
+goto error_out;
+}
+
+dcs->guest_domid = domid;
+dcs->sdss.dm.guest_domid = 0; /* means we haven't spawned */
+
 /*
  * Set the dm version quite early so that libxl doesn't have to pass the
  * build info around just to know if the domain has a device model or not.
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 22/23] libxl/acpi: Build ACPI tables for HVMlite guests

2016-08-04 Thread Boris Ostrovsky 
Signed-off-by: Boris Ostrovsky 
---
v2:
* Only initialize ACPI tables here but don't load them just yet
  (store them in acpi_modeuls[])
* Reorder .gitignore changes

 .gitignore   |  12 ++-
 tools/libacpi/build.c|   7 +-
 tools/libacpi/libacpi.h  |  15 +++-
 tools/libxl/Makefile |  17 +++-
 tools/libxl/libxl_arch.h |   3 +
 tools/libxl/libxl_dom.c  |   1 +
 tools/libxl/libxl_x86.c  |  29 +--
 tools/libxl/libxl_x86_acpi.c | 199 +++
 tools/libxl/libxl_x86_acpi.h |  35 
 9 files changed, 298 insertions(+), 20 deletions(-)
 create mode 100644 tools/libxl/libxl_x86_acpi.c
 create mode 100644 tools/libxl/libxl_x86_acpi.h

diff --git a/.gitignore b/.gitignore
index d6ba3dd..cf6ede9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -170,15 +170,19 @@ tools/include/xen/*
 tools/include/xen-xsm/*
 tools/include/xen-foreign/*.(c|h|size)
 tools/include/xen-foreign/checker
-tools/libxl/libxlu_cfg_y.output
+tools/libxl/_libxl.api-for-check
+tools/libxl/*.api-ok
 tools/libxl/*.pc
 tools/libxl/*.pc.in
-tools/libxl/xl
+tools/libxl/dsdt*.c
+tools/libxl/dsdt_*.asl
+tools/libxl/libxlu_cfg_y.output
+tools/libxl/mk_dsdt
+tools/libxl/ssdt_*.h
 tools/libxl/testenum
 tools/libxl/testenum.c
 tools/libxl/tmp.*
-tools/libxl/_libxl.api-for-check
-tools/libxl/*.api-ok
+tools/libxl/xl
 tools/misc/cpuperf/cpuperf-perfcntr
 tools/misc/cpuperf/cpuperf-xen
 tools/misc/xc_shadow
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index 2432eb9..1778b88 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -21,6 +21,7 @@
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
 #include "x86.h"
+#include 
 #include 
 #include 
 
@@ -491,7 +492,7 @@ static int new_vm_gid(struct acpi_ctxt *ctxt,
 return 1;
 }
 
-void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
+int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
 {
 struct acpi_info *acpi_info;
 struct acpi_20_rsdp *rsdp;
@@ -626,11 +627,11 @@ void acpi_build_tables(struct acpi_ctxt *ctxt, struct 
acpi_config *config)
 if ( !new_vm_gid(ctxt, config, acpi_info) )
 goto oom;
 
-return;
+return 0;
 
 oom:
 printf("unable to build ACPI tables: out of memory\n");
-
+return -1;
 }
 
 /*
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index ce2d50b..da20278 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -48,6 +48,15 @@ struct acpi_ctxt {
 void (*free)(struct acpi_ctxt *ctxt, void *v, uint32_t size);
 unsigned long (*v2p)(struct acpi_ctxt *ctxt, void *v);
 } mem_ops;
+
+unsigned int page_size;
+unsigned int page_shift;
+
+/* Memory allocator */
+unsigned long alloc_base_paddr;
+unsigned long alloc_base_vaddr;
+unsigned long alloc_currp;
+unsigned long alloc_end;
 };
 
 struct acpi_config {
@@ -80,13 +89,13 @@ struct acpi_config {
  * This must match the OperationRegion(BIOS, SystemMemory, )
  * definition in the DSDT
  */
-unsigned int infop;
+unsigned long infop;
 
 /* RSDP address */
-unsigned int rsdp;
+unsigned long rsdp;
 };
 
-void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
+int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
 
 #endif /* __LIBACPI_H__ */
 
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 3a2d64a..a148374 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -75,7 +75,20 @@ else
 LIBXL_OBJS-y += libxl_no_colo.o
 endif
 
-LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
+ACPI_PATH  = $(XEN_ROOT)/tools/libacpi
+ACPI_FILES = dsdt_pvh.c
+ACPI_OBJS  = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
+$(ACPI_FILES): acpi
+$(ACPI_OBJS): CFLAGS += -I. -DSTDUTILS=\"$(CURDIR)/libxl_x86_acpi.h\"
+vpath build.c $(ACPI_PATH)/
+vpath static_tables.c $(ACPI_PATH)/
+LIBXL_OBJS-$(CONFIG_X86) += $(ACPI_OBJS)
+
+.PHONY: acpi
+acpi:
+   $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(shell pwd)
+
+LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o 
libxl_x86_acpi.o
 LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
 
 ifeq ($(CONFIG_NetBSD),y)
@@ -166,6 +179,7 @@ $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs 
it.
 
 libxl_dom.o: CFLAGS += -I$(XEN_ROOT)/tools  # include libacpi/x86.h
+libxl_x86_acpi.o: CFLAGS += -I$(XEN_ROOT)/tools
 
 SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
 $(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenevtchn)
@@ -308,6 +322,7 @@ clean:
$(RM) -f testidl.c.new testidl.c *.api-ok
$(RM) -f xenlight.pc
$(RM) -f xlutil.pc
+   $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(shell pwd) clean
 
 distclean: clean
$(RM) -f xenlight.pc.in xlutil.pc.in
diff --git

[Xen-devel] [PATCH v2 05/23] acpi/hvmloader: Move passthrough initialization from ACPI code

2016-08-04 Thread Boris Ostrovsky 
Initialize it in hvmloader, avoiding ACPI code's use of xenstore_read()

Signed-off-by: Boris Ostrovsky 
---
v2:
* Dropped pt_ prefix
* Slight change in construct_passthrough_tables() code (thus dropped Jan's R-b)

 tools/firmware/hvmloader/acpi/build.c   | 28 +---
 tools/firmware/hvmloader/acpi/libacpi.h |  5 +
 tools/firmware/hvmloader/util.c | 11 +++
 3 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index a5750eb..8ca7e69 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -285,37 +285,27 @@ static struct acpi_20_slit *construct_slit(void)
 }
 
 static int construct_passthrough_tables(unsigned long *table_ptrs,
-int nr_tables)
+int nr_tables,
+struct acpi_config *config)
 {
-const char *s;
-uint8_t *acpi_pt_addr;
-uint32_t acpi_pt_length;
+unsigned long pt_addr;
 struct acpi_header *header;
 int nr_added;
 int nr_max = (ACPI_MAX_SECONDARY_TABLES - nr_tables - 1);
 uint32_t total = 0;
 uint8_t *buffer;
 
-s = xenstore_read(HVM_XS_ACPI_PT_ADDRESS, NULL);
-if ( s == NULL )
-return 0;
-
-acpi_pt_addr = (uint8_t*)(uint32_t)strtoll(s, NULL, 0);
-if ( acpi_pt_addr == NULL )
-return 0;
-
-s = xenstore_read(HVM_XS_ACPI_PT_LENGTH, NULL);
-if ( s == NULL )
+if ( config->pt.addr == 0 )
 return 0;
 
-acpi_pt_length = (uint32_t)strtoll(s, NULL, 0);
+pt_addr = config->pt.addr;
 
 for ( nr_added = 0; nr_added < nr_max; nr_added++ )
 {
-if ( (acpi_pt_length - total) < sizeof(struct acpi_header) )
+if ( (config->pt.length - total) < sizeof(struct acpi_header) )
 break;
 
-header = (struct acpi_header*)acpi_pt_addr;
+header = (struct acpi_header*)pt_addr;
 
 buffer = mem_alloc(header->length, 16);
 if ( buffer == NULL )
@@ -324,7 +314,7 @@ static int construct_passthrough_tables(unsigned long 
*table_ptrs,
 
 table_ptrs[nr_tables++] = (unsigned long)buffer;
 total += header->length;
-acpi_pt_addr += header->length;
+pt_addr += header->length;
 }
 
 return nr_added;
@@ -445,7 +435,7 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 }
 
 /* Load any additional tables passed through. */
-nr_tables += construct_passthrough_tables(table_ptrs, nr_tables);
+nr_tables += construct_passthrough_tables(table_ptrs, nr_tables, config);
 
 table_ptrs[nr_tables] = 0;
 return nr_tables;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index f397a93..22fd5f6 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -44,6 +44,11 @@ struct acpi_config {
 uint64_t vm_gid[2];
 unsigned long vm_gid_addr; /* OUT parameter */
 
+struct {
+uint32_t addr;
+uint32_t length;
+} pt;
+
 /*
  * Address where acpi_info should be placed.
  * This must match the OperationRegion(BIOS, SystemMemory, )
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 61fc211..d61aea6 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -900,6 +901,16 @@ void hvmloader_acpi_build_tables(struct acpi_config 
*config,
 config->vm_gid[1] = strtoll(end+1, NULL, 0);
 }
 
+s = xenstore_read(HVM_XS_ACPI_PT_ADDRESS, NULL);
+if ( s )
+{
+config->pt.addr = strtoll(s, NULL, 0);
+
+s = xenstore_read(HVM_XS_ACPI_PT_LENGTH, NULL);
+if ( s )
+config->pt.length = strtoll(s, NULL, 0);
+}
+
 if ( battery_port_exists() )
 config->table_flags |= ACPI_HAS_SSDT_PM;
 if ( !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1)  )
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 10/23] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops

2016-08-04 Thread Boris Ostrovsky 
Components that wish to use ACPI builder will need to provide their own
mem_alloc() and virt_to_phys() routines. Pointers to these routines will
be passed to the builder as memory ops.

Signed-off-by: Boris Ostrovsky 
---
v2:
* Added acpi_ctxt.free() op

 tools/firmware/hvmloader/acpi/build.c   | 91 ++---
 tools/firmware/hvmloader/acpi/libacpi.h | 10 +++-
 tools/firmware/hvmloader/util.c | 16 +-
 3 files changed, 74 insertions(+), 43 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index e362ccd..7302c35 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -70,7 +70,8 @@ static void set_checksum(
 p[checksum_offset] = -sum;
 }
 
-static struct acpi_20_madt *construct_madt(struct acpi_config *config,
+static struct acpi_20_madt *construct_madt(struct acpi_ctxt *ctxt,
+   struct acpi_config *config,
struct acpi_info *info)
 {
 struct acpi_20_madt   *madt;
@@ -84,7 +85,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_config 
*config,
 sz += sizeof(struct acpi_20_madt_ioapic);
 sz += sizeof(struct acpi_20_madt_lapic) * config->hvminfo->nr_vcpus;
 
-madt = mem_alloc(sz, 16);
+madt = ctxt->mem_ops.alloc(ctxt, sz, 16);
 if (!madt) return NULL;
 
 memset(madt, 0, sizeof(*madt));
@@ -164,11 +165,12 @@ static struct acpi_20_madt *construct_madt(struct 
acpi_config *config,
 return madt;
 }
 
-static struct acpi_20_hpet *construct_hpet(void)
+static struct acpi_20_hpet *construct_hpet(struct acpi_ctxt *ctxt,
+   struct acpi_config *config)
 {
 struct acpi_20_hpet *hpet;
 
-hpet = mem_alloc(sizeof(*hpet), 16);
+hpet = ctxt->mem_ops.alloc(ctxt, sizeof(*hpet), 16);
 if (!hpet) return NULL;
 
 memset(hpet, 0, sizeof(*hpet));
@@ -187,11 +189,12 @@ static struct acpi_20_hpet *construct_hpet(void)
 return hpet;
 }
 
-static struct acpi_20_waet *construct_waet(void)
+static struct acpi_20_waet *construct_waet(struct acpi_ctxt *ctxt,
+   struct acpi_config *config)
 {
 struct acpi_20_waet *waet;
 
-waet = mem_alloc(sizeof(*waet), 16);
+waet = ctxt->mem_ops.alloc(ctxt, sizeof(*waet), 16);
 if (!waet) return NULL;
 
 memcpy(waet, , sizeof(*waet));
@@ -202,7 +205,8 @@ static struct acpi_20_waet *construct_waet(void)
 return waet;
 }
 
-static struct acpi_20_srat *construct_srat(struct acpi_config *config)
+static struct acpi_20_srat *construct_srat(struct acpi_ctxt *ctxt,
+   struct acpi_config *config)
 {
 struct acpi_20_srat *srat;
 struct acpi_20_srat_processor *processor;
@@ -214,7 +218,7 @@ static struct acpi_20_srat *construct_srat(struct 
acpi_config *config)
 size = sizeof(*srat) + sizeof(*processor) * config->hvminfo->nr_vcpus +
sizeof(*memory) * config->numa.nr_vmemranges;
 
-p = mem_alloc(size, 16);
+p = ctxt->mem_ops.alloc(ctxt, size, 16);
 if ( !p )
 return NULL;
 
@@ -260,7 +264,8 @@ static struct acpi_20_srat *construct_srat(struct 
acpi_config *config)
 return srat;
 }
 
-static struct acpi_20_slit *construct_slit(struct acpi_config *config)
+static struct acpi_20_slit *construct_slit(struct acpi_ctxt *ctxt,
+   struct acpi_config *config)
 {
 struct acpi_20_slit *slit;
 unsigned int i, num, size;
@@ -268,7 +273,7 @@ static struct acpi_20_slit *construct_slit(struct 
acpi_config *config)
 num = config->numa.nr_vnodes * config->numa.nr_vnodes;
 size = sizeof(*slit) + num * sizeof(uint8_t);
 
-slit = mem_alloc(size, 16);
+slit = ctxt->mem_ops.alloc(ctxt, size, 16);
 if ( !slit )
 return NULL;
 
@@ -292,7 +297,8 @@ static struct acpi_20_slit *construct_slit(struct 
acpi_config *config)
 return slit;
 }
 
-static int construct_passthrough_tables(unsigned long *table_ptrs,
+static int construct_passthrough_tables(struct acpi_ctxt *ctxt,
+unsigned long *table_ptrs,
 int nr_tables,
 struct acpi_config *config)
 {
@@ -315,7 +321,7 @@ static int construct_passthrough_tables(unsigned long 
*table_ptrs,
 
 header = (struct acpi_header*)pt_addr;
 
-buffer = mem_alloc(header->length, 16);
+buffer = ctxt->mem_ops.alloc(ctxt, header->length, 16);
 if ( buffer == NULL )
 break;
 memcpy(buffer, header, header->length);
@@ -328,7 +334,8 @@ static int construct_passthrough_tables(unsigned long 
*table_ptrs,
 return nr_added;
 }
 
-static int construct_secondary_tables(unsigned long *table_ptrs,
+static int construct_secondary_tables(struct acpi_ctxt *ctxt,
+

[Xen-devel] [PATCH v2 17/23] libacpi: Build DSDT for PVH guests

2016-08-04 Thread Boris Ostrovsky 
PVH guests require DSDT with only ACPI INFO (Xen-specific) and Processor
objects. We separate ASL's ACPI INFO definition into dsdt_acpi_info.asl so
that it can be included in ASLs for both HVM and PVH2.

Signed-off-by: Boris Ostrovsky 
---
 tools/libacpi/Makefile   | 21 +
 tools/libacpi/dsdt.asl   | 20 
 tools/libacpi/dsdt_acpi_info.asl | 23 +++
 tools/libacpi/mk_dsdt.c  | 10 ++
 4 files changed, 50 insertions(+), 24 deletions(-)
 create mode 100644 tools/libacpi/dsdt_acpi_info.asl

diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index 816322f..d741ac5 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -18,7 +18,7 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
 MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
 
 # Sources to be generated
-C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c  
dsdt_anycpu_qemu_xen.c)
+C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c  
dsdt_anycpu_qemu_xen.c dsdt_pvh.c)
 H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
ssdt_tpm.h)
 
 vpath iasl $(PATH)
@@ -34,13 +34,15 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
 $(MK_DSDT): mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
-$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl $(MK_DSDT)
+$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl 
$(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
+   cat dsdt_acpi_info.asl >> $@
$(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl $(MK_DSDT)
+$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
+   cat dsdt_acpi_info.asl >> $@
$(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $@
 
 $(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
@@ -49,6 +51,17 @@ $(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
echo "int $*_len=sizeof($*);" >>$@
rm -f $(ACPI_BUILD_DIR)/$*.aml $(ACPI_BUILD_DIR)/$*.hex
 
+$(ACPI_BUILD_DIR)/dsdt_pvh.asl: dsdt_acpi_info.asl $(MK_DSDT)
+   printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 5, \"Xen\", \"HVM\", 
0)\n{" > $@
+   cat dsdt_acpi_info.asl >> $@
+   $(MK_DSDT) --debug=$(debug) --maxcpu any --no-dm >> $@
+
+$(ACPI_BUILD_DIR)/dsdt_pvh.c: iasl $(ACPI_BUILD_DIR)/dsdt_pvh.asl
+   iasl -vs -p $(ACPI_BUILD_DIR)/$* -tc $(ACPI_BUILD_DIR)/dsdt_pvh.asl
+   sed -e 's/AmlCode/dsdt_pvh/g' $(ACPI_BUILD_DIR)/$*.hex >$@
+   echo "int dsdt_pvh_len=sizeof(dsdt_pvh);" >>$@
+   rm -f $(ACPI_BUILD_DIR)/$*.aml $(ACPI_BUILD_DIR)/$*.hex
+
 iasl:
@echo
@echo "ACPI ASL compiler (iasl) is needed"
@@ -58,7 +71,7 @@ iasl:
@exit 1
 
 clean:
-   rm -fr $(C_SRC) $(H_SRC) $(MK_DSDT) $(patsubst %.c,%.asl,$(C_SRC))
+   rm -fr $(C_SRC) $(H_SRC) $(MK_DSDT) $(patsubst %.c,%.asl,$(C_SRC)) 
$(ACPI_BUILD_DIR)/dsdt_pvh.c
 
 distclean: clean
 
diff --git a/tools/libacpi/dsdt.asl b/tools/libacpi/dsdt.asl
index 895a8e5..715bd7a 100644
--- a/tools/libacpi/dsdt.asl
+++ b/tools/libacpi/dsdt.asl
@@ -41,26 +41,6 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
 
 Scope (\_SB)
 {
-   /* ACPI_INFO_PHYSICAL_ADDRESS == 0xFC00 */
-   OperationRegion(BIOS, SystemMemory, 0xFC00, 40)
-   Field(BIOS, ByteAcc, NoLock, Preserve) {
-   UAR1, 1,
-   UAR2, 1,
-   LTP1, 1,
-   HPET, 1,
-   Offset(2),
-   NCPU, 16,
-   PMIN, 32,
-   PLEN, 32,
-   MSUA, 32, /* MADT checksum address */
-   MAPA, 32, /* MADT LAPIC0 address */
-   VGIA, 32, /* VM generation id address */
-   LMIN, 32,
-   HMIN, 32,
-   LLEN, 32,
-   HLEN, 32
-   }
-
 /* Fix HCT test for 0x400 pci memory:
  * - need to report low 640 MB mem as motherboard resource
  */
diff --git a/tools/libacpi/dsdt_acpi_info.asl b/tools/libacpi/dsdt_acpi_info.asl
new file mode 100644
index 000..eeecd49
--- /dev/null
+++ b/tools/libacpi/dsdt_acpi_info.asl
@@ -0,0 +1,23 @@
+
+Scope (\_SB)
+{
+   /* ACPI_INFO_PHYSICAL_ADDRESS == 0xFC00 */
+   OperationRegion(BIOS, SystemMemory, 0xFC00, 40)
+   Field(BIOS, ByteAcc, NoLock, Preserve) {
+   UAR1, 1,
+   UAR2, 1,
+   LTP1, 1,
+   HPET, 1,
+   Offset(2),
+   NCPU, 16,
+   PMIN, 32,
+   PLEN, 32,
+   MSUA, 32, /* MADT checksum address */
+   MAPA, 32, /* MADT LAPIC0 address */
+   VGIA, 32, /* VM generation id address */
+   LMIN, 32,
+   HMIN, 32,
+   LLEN, 32,
+   HLEN, 32
+   }
+}
diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index

[Xen-devel] [PATCH v2 04/23] acpi/hvmloader: Decide which SSDTs to install in hvmloader

2016-08-04 Thread Boris Ostrovsky 
With that, xenstore_read() won't need to be done in ACPI code

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
 tools/firmware/hvmloader/acpi/build.c   | 15 ++-
 tools/firmware/hvmloader/acpi/libacpi.h |  4 
 tools/firmware/hvmloader/util.c | 12 
 3 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index df104a3..a5750eb 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -70,11 +70,6 @@ static void set_checksum(
 p[checksum_offset] = -sum;
 }
 
-static uint8_t battery_port_exists(void)
-{
-return (inb(0x88) == 0x1F);
-}
-
 static struct acpi_20_madt *construct_madt(struct acpi_info *info)
 {
 struct acpi_20_madt   *madt;
@@ -336,6 +331,7 @@ static int construct_passthrough_tables(unsigned long 
*table_ptrs,
 }
 
 static int construct_secondary_tables(unsigned long *table_ptrs,
+  struct acpi_config *config,
   struct acpi_info *info)
 {
 int nr_tables = 0;
@@ -369,7 +365,7 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 if (!waet) return -1;
 table_ptrs[nr_tables++] = (unsigned long)waet;
 
-if ( battery_port_exists() )
+if ( config->table_flags & ACPI_HAS_SSDT_PM )
 {
 ssdt = mem_alloc(sizeof(ssdt_pm), 16);
 if (!ssdt) return -1;
@@ -377,7 +373,7 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 table_ptrs[nr_tables++] = (unsigned long)ssdt;
 }
 
-if ( !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1) )
+if ( config->table_flags & ACPI_HAS_SSDT_S3 )
 {
 ssdt = mem_alloc(sizeof(ssdt_s3), 16);
 if (!ssdt) return -1;
@@ -387,7 +383,7 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 printf("S3 disabled\n");
 }
 
-if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1) )
+if ( config->table_flags & ACPI_HAS_SSDT_S4 )
 {
 ssdt = mem_alloc(sizeof(ssdt_s4), 16);
 if (!ssdt) return -1;
@@ -572,7 +568,8 @@ void acpi_build_tables(struct acpi_config *config)
  offsetof(struct acpi_header, checksum),
  sizeof(struct acpi_20_fadt));
 
-nr_secondaries = construct_secondary_tables(secondary_tables, acpi_info);
+nr_secondaries = construct_secondary_tables(secondary_tables,
+ config, acpi_info);
 if ( nr_secondaries < 0 )
 goto oom;
 
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index 4cbd41e..f397a93 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -24,6 +24,10 @@
 #define ACPI_HAS_COM2(1<<1)
 #define ACPI_HAS_LPT1(1<<2)
 #define ACPI_HAS_HPET(1<<3)
+#define ACPI_HAS_SSDT_PM (1<<4)
+#define ACPI_HAS_SSDT_S3 (1<<5)
+#define ACPI_HAS_SSDT_S4 (1<<6)
+
 
 struct acpi_config {
 const unsigned char *dsdt_anycpu;
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index e8ce12b..61fc211 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -859,6 +859,11 @@ int hpet_exists(unsigned long hpet_base)
 return ((hpet_id >> 16) == 0x8086);
 }
 
+static uint8_t battery_port_exists(void)
+{
+return (inb(0x88) == 0x1F);
+}
+
 void hvmloader_acpi_build_tables(struct acpi_config *config,
  unsigned int physical)
 {
@@ -895,6 +900,13 @@ void hvmloader_acpi_build_tables(struct acpi_config 
*config,
 config->vm_gid[1] = strtoll(end+1, NULL, 0);
 }
 
+if ( battery_port_exists() )
+config->table_flags |= ACPI_HAS_SSDT_PM;
+if ( !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1)  )
+config->table_flags |= ACPI_HAS_SSDT_S3;
+if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
+config->table_flags |= ACPI_HAS_SSDT_S4;
+
 config->rsdp = physical;
 config->infop = ACPI_INFO_PHYSICAL_ADDRESS;
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 07/23] acpi/hvmloader: Set TIS header address in hvmloader

2016-08-04 Thread Boris Ostrovsky 
Users other than hvmloader may provide TIS address as virtual.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
v2:
* constified tis_hdr.

 tools/firmware/hvmloader/acpi/build.c   | 9 -
 tools/firmware/hvmloader/acpi/libacpi.h | 3 +++
 tools/firmware/hvmloader/config.h   | 2 ++
 tools/firmware/hvmloader/util.c | 4 
 4 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 075d8d7..e99b90a 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -333,7 +333,6 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 struct acpi_20_tcpa *tcpa;
 unsigned char *ssdt;
 static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
-uint16_t *tis_hdr;
 void *lasa;
 
 /* MADT. */
@@ -386,10 +385,10 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 }
 
 /* TPM TCPA and SSDT. */
-tis_hdr = (uint16_t *)0xFED40F00;
-if ( (tis_hdr[0] == tis_signature[0]) &&
- (tis_hdr[1] == tis_signature[1]) &&
- (tis_hdr[2] == tis_signature[2]) )
+if ( (config->table_flags & ACPI_HAS_TCPA) &&
+ (config->tis_hdr[0] == tis_signature[0]) &&
+ (config->tis_hdr[1] == tis_signature[1]) &&
+ (config->tis_hdr[2] == tis_signature[2]) )
 {
 ssdt = mem_alloc(sizeof(ssdt_tpm), 16);
 if (!ssdt) return -1;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index 3712c42..2160074 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -29,6 +29,7 @@
 #define ACPI_HAS_SSDT_PM (1<<4)
 #define ACPI_HAS_SSDT_S3 (1<<5)
 #define ACPI_HAS_SSDT_S4 (1<<6)
+#define ACPI_HAS_TCPA(1<<7)
 
 
 struct acpi_numa {
@@ -62,6 +63,8 @@ struct acpi_config {
 struct acpi_numa numa;
 struct hvm_info_table *hvminfo;
 
+const uint16_t *tis_hdr;
+
 /*
  * Address where acpi_info should be placed.
  * This must match the OperationRegion(BIOS, SystemMemory, )
diff --git a/tools/firmware/hvmloader/config.h 
b/tools/firmware/hvmloader/config.h
index 4c6d8ad..c9526e3 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -55,6 +55,8 @@ extern struct bios_config ovmf_config;
 /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
 #define PCI_MEM_END 0xfc00
 
+#define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
+
 extern unsigned long pci_mem_start, pci_mem_end;
 extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
 
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 1f8d539..c5ae526 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -919,6 +919,10 @@ void hvmloader_acpi_build_tables(struct acpi_config 
*config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
+config->table_flags |= ACPI_HAS_TCPA;
+
+config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
+
 config->numa.nr_vmemranges = nr_vmemranges;
 config->numa.nr_vnodes = nr_vnodes;
 config->numa.vcpu_to_vnode = vcpu_to_vnode;
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 08/23] acpi/hvmloader: Make providing IOAPIC in MADT optional

2016-08-04 Thread Boris Ostrovsky 
Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 tools/firmware/hvmloader/acpi/build.c   | 70 ++---
 tools/firmware/hvmloader/acpi/libacpi.h |  1 +
 tools/firmware/hvmloader/util.c |  2 +-
 3 files changed, 40 insertions(+), 33 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index e99b90a..6ec8739 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -98,43 +98,49 @@ static struct acpi_20_madt *construct_madt(struct 
acpi_config *config,
 madt->lapic_addr = LAPIC_BASE_ADDRESS;
 madt->flags  = ACPI_PCAT_COMPAT;
 
-intsrcovr = (struct acpi_20_madt_intsrcovr *)(madt + 1);
-for ( i = 0; i < 16; i++ )
-{
-memset(intsrcovr, 0, sizeof(*intsrcovr));
-intsrcovr->type   = ACPI_INTERRUPT_SOURCE_OVERRIDE;
-intsrcovr->length = sizeof(*intsrcovr);
-intsrcovr->source = i;
-
-if ( i == 0 )
-{
-/* ISA IRQ0 routed to IOAPIC GSI 2. */
-intsrcovr->gsi= 2;
-intsrcovr->flags  = 0x0;
-}
-else if ( PCI_ISA_IRQ_MASK & (1U << i) )
-{
-/* PCI: active-low level-triggered. */
-intsrcovr->gsi= i;
-intsrcovr->flags  = 0xf;
-}
-else
+if ( config->table_flags & ACPI_HAS_IOAPIC )
+{ 
+intsrcovr = (struct acpi_20_madt_intsrcovr *)(madt + 1);
+for ( i = 0; i < 16; i++ )
 {
-/* No need for a INT source override structure. */
-continue;
+memset(intsrcovr, 0, sizeof(*intsrcovr));
+intsrcovr->type   = ACPI_INTERRUPT_SOURCE_OVERRIDE;
+intsrcovr->length = sizeof(*intsrcovr);
+intsrcovr->source = i;
+
+if ( i == 0 )
+{
+/* ISA IRQ0 routed to IOAPIC GSI 2. */
+intsrcovr->gsi= 2;
+intsrcovr->flags  = 0x0;
+}
+else if ( PCI_ISA_IRQ_MASK & (1U << i) )
+{
+/* PCI: active-low level-triggered. */
+intsrcovr->gsi= i;
+intsrcovr->flags  = 0xf;
+}
+else
+{
+/* No need for a INT source override structure. */
+continue;
+}
+
+intsrcovr++;
 }
 
-intsrcovr++;
-}
+io_apic = (struct acpi_20_madt_ioapic *)intsrcovr;
+memset(io_apic, 0, sizeof(*io_apic));
+io_apic->type= ACPI_IO_APIC;
+io_apic->length  = sizeof(*io_apic);
+io_apic->ioapic_id   = IOAPIC_ID;
+io_apic->ioapic_addr = IOAPIC_BASE_ADDRESS;
 
-io_apic = (struct acpi_20_madt_ioapic *)intsrcovr;
-memset(io_apic, 0, sizeof(*io_apic));
-io_apic->type= ACPI_IO_APIC;
-io_apic->length  = sizeof(*io_apic);
-io_apic->ioapic_id   = IOAPIC_ID;
-io_apic->ioapic_addr = IOAPIC_BASE_ADDRESS;
+lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
+}
+else
+lapic = (struct acpi_20_madt_lapic *)(madt + 1);
 
-lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
 info->nr_cpus = config-> hvminfo->nr_vcpus;
 info->madt_lapic0_addr = (uint32_t)lapic;
 for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index 2160074..e15abf7 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -30,6 +30,7 @@
 #define ACPI_HAS_SSDT_S3 (1<<5)
 #define ACPI_HAS_SSDT_S4 (1<<6)
 #define ACPI_HAS_TCPA(1<<7)
+#define ACPI_HAS_IOAPIC  (1<<8)
 
 
 struct acpi_numa {
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index c5ae526..325c0a2 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -919,7 +919,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
-config->table_flags |= ACPI_HAS_TCPA;
+config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 15/23] x86: Add more checks verifying that PIT/PIC/IOAPIC are emulated

2016-08-04 Thread Boris Ostrovsky 
Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
v2:
* Added ASSERT(has_vpic(d))
* This patch can go in independent of the rest of the series.

 xen/arch/x86/hvm/vlapic.c | 14 --
 xen/arch/x86/hvm/vpt.c|  2 +-
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index ba9b293..1d5d287 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1114,7 +1114,14 @@ static int __vlapic_accept_pic_intr(struct vcpu *v)
 struct domain *d = v->domain;
 struct vlapic *vlapic = vcpu_vlapic(v);
 uint32_t lvt0 = vlapic_get_reg(vlapic, APIC_LVT0);
-union vioapic_redir_entry redir0 = domain_vioapic(d)->redirtbl[0];
+union vioapic_redir_entry redir0;
+
+ASSERT(has_vpic(d));
+
+if ( !has_vioapic(d) )
+return 0;
+
+redir0 = domain_vioapic(d)->redirtbl[0];
 
 /* We deliver 8259 interrupts to the appropriate CPU as follows. */
 return ((/* IOAPIC pin0 is unmasked and routing to this LAPIC? */
@@ -1130,7 +1137,7 @@ static int __vlapic_accept_pic_intr(struct vcpu *v)
 
 int vlapic_accept_pic_intr(struct vcpu *v)
 {
-if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
+if ( vlapic_hw_disabled(vcpu_vlapic(v)) || !has_vpic(v->domain) )
 return 0;
 
 TRACE_2D(TRC_HVM_EMUL_LAPIC_PIC_INTR,
@@ -1145,6 +1152,9 @@ void vlapic_adjust_i8259_target(struct domain *d)
 {
 struct vcpu *v;
 
+if ( !has_vpic(d) )
+return;
+
 for_each_vcpu ( d, v )
 if ( __vlapic_accept_pic_intr(v) )
 goto found;
diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c
index 358ec57..c90aa95 100644
--- a/xen/arch/x86/hvm/vpt.c
+++ b/xen/arch/x86/hvm/vpt.c
@@ -496,7 +496,7 @@ void pt_adjust_global_vcpu_target(struct vcpu *v)
 struct pl_time *pl_time;
 int i;
 
-if ( v == NULL )
+if ( v == NULL || !has_vpit(v->domain) )
 return;
 
 vpit = >domain->arch.vpit;
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 19/23] libxl/acpi: Add ACPI e820 entry

2016-08-04 Thread Boris Ostrovsky 
Add entry for ACPI tables created for PVHv2 guests to e820 map.

Signed-off-by: Boris Ostrovsky 
---
v2:
* Deal with multiple acpi_modules.

 tools/libxl/libxl_dom.c |  8 
 tools/libxl/libxl_x86.c | 15 +++
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 22d6868..4d2bc0c 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1134,16 +1134,16 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 dom->vnode_to_pnode[i] = info->vnuma_nodes[i].pnode;
 }
 
+rc = libxl__build_dom(gc, domid, info, state, dom);
+if (rc != 0)
+goto out;
+
 rc = libxl__arch_domain_construct_memmap(gc, d_config, domid, dom);
 if (rc != 0) {
 LOG(ERROR, "setting domain memory map failed");
 goto out;
 }
 
-rc = libxl__build_dom(gc, domid, info, state, dom);
-if (rc != 0)
-goto out;
-
 rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
>store_mfn, state->console_port,
>console_mfn, state->store_domid,
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 46cfafb..7654e20 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -492,6 +492,7 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 uint64_t highmem_size =
 dom->highmem_end ? dom->highmem_end - (1ull << 32) : 0;
 uint32_t lowmem_start = dom->device_model ? GUEST_LOW_MEM_START_DEFAULT : 
0;
+unsigned page_size = XC_DOM_PAGE_SIZE(dom);
 
 /* Add all rdm entries. */
 for (i = 0; i < d_config->num_rdms; i++)
@@ -503,6 +504,10 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 if (highmem_size)
 e820_entries++;
 
+for (i=0; iacpi_modules[i].length)
+e820_entries++;
+
 if (e820_entries >= E820MAX) {
 LOG(ERROR, "Ooops! Too many entries in the memory map!");
 rc = ERROR_INVAL;
@@ -528,6 +533,16 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 nr++;
 }
 
+for (i=0; iacpi_modules[i].length) {
+e820[nr].addr = dom->acpi_modules[i].guest_addr_out & ~(page_size 
- 1);
+e820[nr].size = dom->acpi_modules[i].length +
+(dom->acpi_modules[i].guest_addr_out & (page_size - 1));
+e820[nr].type = E820_ACPI;
+nr++;
+}
+}
+
 /* High memory */
 if (highmem_size) {
 e820[nr].addr = ((uint64_t)1 << 32);
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 16/23] x86: Allow LAPIC-only emulation_flags for HVM guests

2016-08-04 Thread Boris Ostrovsky 
PVHv2 guests may request LAPIC emulation (and nothing else)

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
v2:
* Note: I kept the code as is (with minor style adjustments). Roger's
  version (with emulation_flags_ok()) has slighly more logic to account
  for dom0. Without that I didn't feel it's worth factoring this code
  into a separate routine.


 xen/arch/x86/domain.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 1133ea2..34a4eb5 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -545,25 +545,31 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 }
 else
 {
-if ( (config->emulation_flags & ~XEN_X86_EMU_ALL) != 0 )
+uint32_t emflags;
+
+if ( is_hardware_domain(d) )
+config->emulation_flags |= XEN_X86_EMU_PIT;
+
+emflags = config->emulation_flags;
+if ( emflags & ~XEN_X86_EMU_ALL )
 {
 printk(XENLOG_G_ERR "d%d: Invalid emulation bitmap: %#x\n",
-   d->domain_id, config->emulation_flags);
+   d->domain_id, emflags);
 return -EINVAL;
 }
-if ( is_hardware_domain(d) )
-config->emulation_flags |= XEN_X86_EMU_PIT;
-if ( config->emulation_flags != 0 &&
- (config->emulation_flags !=
-  (is_hvm_domain(d) ? XEN_X86_EMU_ALL : XEN_X86_EMU_PIT)) )
+
+/* PVHv2 guests can request emulated APIC. */
+if ( emflags &&
+(is_hvm_domain(d) ? ((emflags != XEN_X86_EMU_ALL) &&
+ (emflags != XEN_X86_EMU_LAPIC)) :
+(emflags != XEN_X86_EMU_PIT)) )
 {
 printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
"with the current selection of emulators: %#x\n",
-   d->domain_id, is_hvm_domain(d) ? "HVM" : "PV",
-   config->emulation_flags);
+   d->domain_id, is_hvm_domain(d) ? "HVM" : "PV", emflags);
 return -EOPNOTSUPP;
 }
-d->arch.emulation_flags = config->emulation_flags;
+d->arch.emulation_flags = emflags;
 }
 
 if ( has_hvm_container_domain(d) )
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 23/23] libxc/xc_dom_core: Copy ACPI tables to guest space

2016-08-04 Thread Boris Ostrovsky 
Load ACPI modules into guest space

Signed-off-by: Boris Ostrovsky 
---
v2:
* New patch, loosely based on Shannon's ARM patch

 tools/libxc/xc_dom_core.c | 92 +++
 1 file changed, 92 insertions(+)

diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index ebada89..00d870f 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -1040,6 +1040,94 @@ static int xc_dom_build_ramdisk(struct xc_dom_image *dom)
 return -1;
 }
 
+static int populate_acpi_pages(struct xc_dom_image *dom,
+   xen_pfn_t *extents,
+   unsigned int num_pages)
+{
+int rc;
+xc_interface *xch = dom->xch;
+uint32_t domid = dom->guest_domid;
+unsigned long idx, first_high_idx = (1ull << (32 - 12));
+
+for ( ; num_pages; num_pages--, extents++ )
+{
+
+if ( xc_domain_populate_physmap(xch, domid, 1, 0, 0, extents) == 1 )
+continue;
+
+if (dom->highmem_end)
+{
+idx = --dom->highmem_end;
+if ( idx == first_high_idx )
+dom->highmem_end = 0;
+}
+else
+idx = --dom->lowmem_end;
+
+rc = xc_domain_add_to_physmap(xch, domid,
+  XENMAPSPACE_gmfn,
+  idx, *extents);
+if (rc)
+return rc;
+}
+
+return 0;
+}
+
+static int xc_dom_load_acpi(struct xc_dom_image *dom)
+{
+int j, i = 0;
+unsigned num_pages;
+xen_pfn_t *extents, base;
+void *ptr;
+
+while ( (i < MAX_ACPI_MODULES) && dom->acpi_modules[i].length )
+{
+DOMPRINTF("%s: %d bytes at address %lx\n", __FUNCTION__,
+  dom->acpi_modules[i].length,
+  dom->acpi_modules[i].guest_addr_out);
+
+num_pages = (dom->acpi_modules[i].length + (XC_PAGE_SIZE - 1)) >>
+   XC_PAGE_SHIFT;
+extents = malloc(num_pages * sizeof(*extents));
+if ( !extents )
+{
+DOMPRINTF("%s: Out of memory", __FUNCTION__);
+goto err;
+}
+
+base = dom->acpi_modules[i].guest_addr_out >> XC_PAGE_SHIFT;
+for (j=0; jxch, dom->guest_domid,
+  XC_PAGE_SIZE * num_pages,
+  PROT_READ | PROT_WRITE, base);
+if ( !ptr )
+{
+DOMPRINTF("%s: Can't map %d pages at 0x%lx",
+  __FUNCTION__, num_pages, base);
+goto err;
+}
+
+memcpy(ptr, dom->acpi_modules[i].data, dom->acpi_modules[i].length);
+
+free(extents);
+i++;
+}
+
+return 0;
+
+err:
+free(extents);
+return -1;
+}
+
 int xc_dom_build_image(struct xc_dom_image *dom)
 {
 unsigned int page_size;
@@ -1097,6 +1185,10 @@ int xc_dom_build_image(struct xc_dom_image *dom)
 memcpy(devicetreemap, dom->devicetree_blob, dom->devicetree_size);
 }
 
+/* load ACPI tables */
+if ( xc_dom_load_acpi(dom) != 0 )
+goto err;
+
 /* allocate other pages */
 if ( !dom->arch_hooks->p2m_base_supported ||
  dom->parms.p2m_base >= dom->parms.virt_base ||
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 18/23] libxc/libxl: Allow multiple ACPI modules

2016-08-04 Thread Boris Ostrovsky 
Provide ability to load multiple ACPI modules. Thie feature is needed
by PVHv2 guests and will be used in subsequent patches.

We assume that PVHv2 guests do not load their ACPI modules specified
in the configuration file. We can extend support for that in the future
if desired.

Signed-off-by: Boris Ostrovsky 
---
v2:
* New patch. PVH uses 3 modules:
- rsdp (8 bytes that store RSDT address)
- acpi_info (1 page, Xen-specific)
- ACPI tables (multiple pages)
  As an alternative, we could add rsdp_val and rsdp_ptr and
  keep acpi_module as a scalar (acpi_info and ACPI tables are
  usually laid out contiguously). This patch provides a more
  general solution (IMO).

 tools/libxc/include/xc_dom.h   |  5 +++--
 tools/libxc/xc_dom_hvmloader.c |  3 ++-
 tools/libxl/libxl_dom.c| 26 ++
 3 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index de7dca9..608cbc2 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -212,8 +212,9 @@ struct xc_dom_image {
 /* BIOS/Firmware passed to HVMLOADER */
 struct xc_hvm_firmware_module system_firmware_module;
 
-/* Extra ACPI tables passed to HVMLOADER */
-struct xc_hvm_firmware_module acpi_module;
+/* Extra ACPI tables */
+#define MAX_ACPI_MODULES4
+struct xc_hvm_firmware_module acpi_modules[MAX_ACPI_MODULES];
 
 /* Extra SMBIOS structures passed to HVMLOADER */
 struct xc_hvm_firmware_module smbios_module;
diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
index 6eb8516..59f94e5 100644
--- a/tools/libxc/xc_dom_hvmloader.c
+++ b/tools/libxc/xc_dom_hvmloader.c
@@ -172,7 +172,8 @@ static int modules_init(struct xc_dom_image *dom)
 rc = module_init_one(dom, >system_firmware_module,
  "System Firmware module");
 if ( rc ) goto err;
-rc = module_init_one(dom, >acpi_module, "ACPI module");
+/* Only one module can be added */
+rc = module_init_one(dom, >acpi_modules[0], "ACPI module");
 if ( rc ) goto err;
 rc = module_init_one(dom, >smbios_module, "SMBIOS module");
 if ( rc ) goto err;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 2a1793d..22d6868 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -818,7 +818,8 @@ static int hvm_build_set_params(xc_interface *handle, 
uint32_t domid,
 
 static int hvm_build_set_xs_values(libxl__gc *gc,
uint32_t domid,
-   struct xc_dom_image *dom)
+   struct xc_dom_image *dom,
+   libxl_domain_build_info *info)
 {
 char *path = NULL;
 int ret = 0;
@@ -839,18 +840,20 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
 goto err;
 }
 
-if (dom->acpi_module.guest_addr_out) {
+/* Only one module can be passed. PVHv2 guests do not support this. */
+if (dom->acpi_modules[0].guest_addr_out && 
+info->device_model_version !=LIBXL_DEVICE_MODEL_VERSION_NONE) {
 path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_ADDRESS, domid);
 
 ret = libxl__xs_printf(gc, XBT_NULL, path, "0x%"PRIx64,
-   dom->acpi_module.guest_addr_out);
+   dom->acpi_modules[0].guest_addr_out);
 if (ret)
 goto err;
 
 path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_LENGTH, domid);
 
 ret = libxl__xs_printf(gc, XBT_NULL, path, "0x%x",
-   dom->acpi_module.length);
+   dom->acpi_modules[0].length);
 if (ret)
 goto err;
 }
@@ -994,6 +997,13 @@ static int libxl__domain_firmware(libxl__gc *gc,
 }
 
 if (info->u.hvm.acpi_firmware) {
+
+if (info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_NONE) {
+LOGE(ERROR, "PVH guests do not allow loading ACPI modules");
+rc = ERROR_FAIL;
+goto out;
+}
+
 data = NULL;
 e = libxl_read_file_contents(ctx, info->u.hvm.acpi_firmware,
  , );
@@ -1005,9 +1015,9 @@ static int libxl__domain_firmware(libxl__gc *gc,
 }
 libxl__ptr_add(gc, data);
 if (datalen) {
-/* Only accept non-empty files */
-dom->acpi_module.data = data;
-dom->acpi_module.length = (uint32_t)datalen;
+/* Only accept a non-empty file */
+dom->acpi_modules[0].data = data;
+dom->acpi_modules[0].length = (uint32_t)datalen;
 }
 }
 
@@ -1143,7 +1153,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 goto out;
 }
 
-rc = hvm_build_set_xs_values(gc, domid, dom);
+rc = hvm_build_set_xs_values(gc, domid, dom, info);
 if (rc != 0) {
 LOG(ERROR, "hvm build set

[Xen-devel] [PATCH v2 06/23] acpi/hvmloader: Collect processor and NUMA info in hvmloader

2016-08-04 Thread Boris Ostrovsky 
No need for ACPI code to rely on hvm_info variable.

Signed-off-by: Boris Ostrovsky 
---
v2:
* Note: struct acpi_numa's pointers can't be constified due to their
  use in later patches

 tools/firmware/hvmloader/acpi/build.c   | 50 +
 tools/firmware/hvmloader/acpi/libacpi.h | 13 +
 tools/firmware/hvmloader/util.c |  9 ++
 3 files changed, 48 insertions(+), 24 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 8ca7e69..075d8d7 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -70,7 +70,8 @@ static void set_checksum(
 p[checksum_offset] = -sum;
 }
 
-static struct acpi_20_madt *construct_madt(struct acpi_info *info)
+static struct acpi_20_madt *construct_madt(struct acpi_config *config,
+   struct acpi_info *info)
 {
 struct acpi_20_madt   *madt;
 struct acpi_20_madt_intsrcovr *intsrcovr;
@@ -81,7 +82,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_info 
*info)
 sz  = sizeof(struct acpi_20_madt);
 sz += sizeof(struct acpi_20_madt_intsrcovr) * 16;
 sz += sizeof(struct acpi_20_madt_ioapic);
-sz += sizeof(struct acpi_20_madt_lapic) * hvm_info->nr_vcpus;
+sz += sizeof(struct acpi_20_madt_lapic) * config->hvminfo->nr_vcpus;
 
 madt = mem_alloc(sz, 16);
 if (!madt) return NULL;
@@ -134,9 +135,9 @@ static struct acpi_20_madt *construct_madt(struct acpi_info 
*info)
 io_apic->ioapic_addr = IOAPIC_BASE_ADDRESS;
 
 lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
-info->nr_cpus = hvm_info->nr_vcpus;
+info->nr_cpus = config-> hvminfo->nr_vcpus;
 info->madt_lapic0_addr = (uint32_t)lapic;
-for ( i = 0; i < hvm_info->nr_vcpus; i++ )
+for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
 {
 memset(lapic, 0, sizeof(*lapic));
 lapic->type= ACPI_PROCESSOR_LOCAL_APIC;
@@ -144,7 +145,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_info 
*info)
 /* Processor ID must match processor-object IDs in the DSDT. */
 lapic->acpi_processor_id = i;
 lapic->apic_id = LAPIC_ID(i);
-lapic->flags = (test_bit(i, hvm_info->vcpu_online)
+lapic->flags = (test_bit(i, config->hvminfo->vcpu_online)
 ? ACPI_LOCAL_APIC_ENABLED : 0);
 lapic++;
 }
@@ -195,7 +196,7 @@ static struct acpi_20_waet *construct_waet(void)
 return waet;
 }
 
-static struct acpi_20_srat *construct_srat(void)
+static struct acpi_20_srat *construct_srat(struct acpi_config *config)
 {
 struct acpi_20_srat *srat;
 struct acpi_20_srat_processor *processor;
@@ -204,8 +205,8 @@ static struct acpi_20_srat *construct_srat(void)
 void *p;
 unsigned int i;
 
-size = sizeof(*srat) + sizeof(*processor) * hvm_info->nr_vcpus +
-   sizeof(*memory) * nr_vmemranges;
+size = sizeof(*srat) + sizeof(*processor) * config->hvminfo->nr_vcpus +
+   sizeof(*memory) * config->numa.nr_vmemranges;
 
 p = mem_alloc(size, 16);
 if ( !p )
@@ -222,25 +223,26 @@ static struct acpi_20_srat *construct_srat(void)
 srat->table_revision  = ACPI_SRAT_TABLE_REVISION;
 
 processor = (struct acpi_20_srat_processor *)(srat + 1);
-for ( i = 0; i < hvm_info->nr_vcpus; i++ )
+for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
 {
 processor->type = ACPI_PROCESSOR_AFFINITY;
 processor->length   = sizeof(*processor);
-processor->domain   = vcpu_to_vnode[i];
+processor->domain   = config->numa.vcpu_to_vnode[i];
 processor->apic_id  = LAPIC_ID(i);
 processor->flags= ACPI_LOCAL_APIC_AFFIN_ENABLED;
 processor++;
 }
 
 memory = (struct acpi_20_srat_memory *)processor;
-for ( i = 0; i < nr_vmemranges; i++ )
+for ( i = 0; i < config->numa.nr_vmemranges; i++ )
 {
 memory->type  = ACPI_MEMORY_AFFINITY;
 memory->length= sizeof(*memory);
-memory->domain= vmemrange[i].nid;
+memory->domain= config->numa.vmemrange[i].nid;
 memory->flags = ACPI_MEM_AFFIN_ENABLED;
-memory->base_address  = vmemrange[i].start;
-memory->mem_length= vmemrange[i].end - vmemrange[i].start;
+memory->base_address  = config->numa.vmemrange[i].start;
+memory->mem_length= config->numa.vmemrange[i].end -
+config->numa.vmemrange[i].start;
 memory++;
 }
 
@@ -252,12 +254,12 @@ static struct acpi_20_srat *construct_srat(void)
 return srat;
 }
 
-static struct acpi_20_slit *construct_slit(void)
+static struct acpi_20_slit *construct_slit(struct acpi_config *config)
 {
 struct acpi_20_slit *slit;
 unsigned int i, num, size;
 
-num = nr_vnodes * nr_vnodes;
+num = config->numa.nr_vnodes * config->numa.nr_vnodes;

[Xen-devel] [PATCH v2 13/23] acpi/hvmloader: Include file/paths adjustments

2016-08-04 Thread Boris Ostrovsky 
In prepearation to moving acpi sources into generally available
libacpi:

1. Move certain x86-specific definitions into acpi's x86.h
2. Modify include files serach paths to point to acpi
3. Macro-ise include file for build.c that defines various
   utilities used by that file. Users of libacpi will be expected
   to define this macro when compiling build.c

Signed-off-by: Boris Ostrovsky 
---
v2:
* Note: hvmloader.c needs  due to its use of
  ACPI_PM1A_CNT_BLK_ADDRESS_V1 and ACPI_PM1C_SCI_EN

 tools/firmware/hvmloader/Makefile |  3 ++-
 tools/firmware/hvmloader/acpi/README  | 16 
 tools/firmware/hvmloader/acpi/build.c |  5 ++---
 tools/firmware/hvmloader/acpi/x86.h   | 30 ++
 tools/firmware/hvmloader/config.h |  6 --
 tools/firmware/hvmloader/hvmloader.c  |  3 ++-
 tools/firmware/hvmloader/mp_tables.c  |  1 +
 tools/firmware/hvmloader/pci.c|  1 +
 tools/firmware/hvmloader/pir.c|  1 +
 tools/firmware/hvmloader/rombios.c|  2 +-
 tools/firmware/hvmloader/seabios.c|  4 ++--
 tools/firmware/hvmloader/smp.c|  1 +
 tools/firmware/hvmloader/util.c   |  5 +++--
 13 files changed, 58 insertions(+), 20 deletions(-)
 create mode 100644 tools/firmware/hvmloader/acpi/x86.h

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index a1ab170..db64a61 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -76,7 +76,8 @@ smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 ACPI_PATH = ./acpi
 ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
 ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
-$(ACPI_OBJS): CFLAGS += -I$(ACPI_PATH) -I.
+$(ACPI_OBJS): CFLAGS += -I. -DSTDUTILS=\"../util.h\"
+CFLAGS += -I$(ACPI_PATH)
 vpath build.c $(ACPI_PATH)
 vpath static_tables.c $(ACPI_PATH)
 OBJS += $(ACPI_OBJS)
diff --git a/tools/firmware/hvmloader/acpi/README 
b/tools/firmware/hvmloader/acpi/README
index 210d5ba..ef4063b 100644
--- a/tools/firmware/hvmloader/acpi/README
+++ b/tools/firmware/hvmloader/acpi/README
@@ -1,11 +1,19 @@
-ACPI Table for domain firmware
+ACPI builder for domain firmware
 
 
-INSTALL
+BUILDING ACPI
 -
-Simply make is OK.
-# make 
+Users of ACPI builder are expected to provide an include file that defines
+the following:
+* strncpy
+* printf
+* NULL
+* test_bit
+* offsetof
 
+When compiling build.c, the name of this include file should be given to
+compiler as -DSTDUTILS=\"\". See tools/firmware/hvmloader/Makefile
+for an example.
 
 Note on DSDT Table
 --
diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index c0e0915..2432eb9 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -13,15 +13,14 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include STDUTILS
 #include "acpi2_0.h"
 #include "libacpi.h"
 #include "ssdt_s3.h"
 #include "ssdt_s4.h"
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
-#include "../config.h"
-#include "../util.h"
-#include "../vnuma.h"
+#include "x86.h"
 #include 
 #include 
 
diff --git a/tools/firmware/hvmloader/acpi/x86.h 
b/tools/firmware/hvmloader/acpi/x86.h
new file mode 100644
index 000..f305414
--- /dev/null
+++ b/tools/firmware/hvmloader/acpi/x86.h
@@ -0,0 +1,30 @@
+/**
+ * x86.h
+ *
+ * x86-specific interfaces used by ACPI builder and its callers
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ *
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ */
+
+#ifndef __ACPI_X86_H__
+#define __ACPI_X86_H__
+
+#define IOAPIC_BASE_ADDRESS 0xfec0
+#define IOAPIC_ID   0x01
+
+#define LAPIC_BASE_ADDRESS  0xfee0
+#define LAPIC_ID(vcpu_id)   ((vcpu_id) * 2)
+
+#define PCI_ISA_IRQ_MASK0x0c20U /* ISA IRQs 5,10,11 are PCI connected */
+
+#endif /* __ACPI_X86_H__ */
diff --git a/tools/firmware/hvmloader/config.h 
b/tools/firmware/hvmloader/config.h
index c9526e3..5116d96 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -42,15 +42,9 @@ extern struct bios_config ovmf_config;
 #define PAGE_SHIFT 12
 #define PAGE_SIZE  (1ul << PAGE_SHIFT)
 
-#define IOAPIC_BASE_ADDRESS 0xfec0
-#define IOAPIC_ID   0x01
 #define IOAPIC_VERSION  0x11
 
-#define LAPIC_BASE_ADDRESS  0xfee0
-#define

[Xen-devel] [PATCH v2 03/23] acpi/hvmloader: Initialize vm_gid data outside ACPI code

2016-08-04 Thread Boris Ostrovsky 
This way ACPI code won't use xenstore-read() and hvm_param_set()
which are private to hvmloader.

Signed-off-by: Boris Ostrovsky 
---
v2:
* Pass VM GID address back via acpi_config.vm_gid_addr.

 tools/firmware/hvmloader/acpi/build.c   | 34 ++---
 tools/firmware/hvmloader/acpi/libacpi.h |  3 +++
 tools/firmware/hvmloader/util.c | 16 
 3 files changed, 33 insertions(+), 20 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index f251c05..df104a3 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -462,32 +462,26 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
  *
  * Return 0 if memory failure, != 0 if success
  */
-static int new_vm_gid(struct acpi_info *acpi_info)
+static int new_vm_gid(struct acpi_config *config,
+  struct acpi_info *info)
 {
-uint64_t vm_gid[2], *buf;
-const char * s;
-char *end;
-
-acpi_info->vm_gid_addr = 0;
-
-/* read ID and check for 0 */
-s = xenstore_read("platform/generation-id", "0:0");
-vm_gid[0] = strtoll(s, , 0);
-vm_gid[1] = 0;
-if ( end && end[0] == ':' )
-vm_gid[1] = strtoll(end+1, NULL, 0);
-if ( !vm_gid[0] && !vm_gid[1] )
+uint64_t *buf;
+
+info->vm_gid_addr = 0;
+
+/* check for 0 ID*/
+if ( !config->vm_gid[0] && !config->vm_gid[1] )
 return 1;
 
 /* copy to allocate BIOS memory */
-buf = (uint64_t *) mem_alloc(sizeof(vm_gid), 8);
+buf = mem_alloc(sizeof(config->vm_gid), 8);
 if ( !buf )
 return 0;
-memcpy(buf, vm_gid, sizeof(vm_gid));
+memcpy(buf, config->vm_gid, sizeof(config->vm_gid));
 
-/* set into ACPI table and HVM param the address */
-acpi_info->vm_gid_addr = virt_to_phys(buf);
-hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, acpi_info->vm_gid_addr);
+/* set the address into ACPI table and also pass it back to the caller */
+info->vm_gid_addr = virt_to_phys(buf);
+config->vm_gid_addr = virt_to_phys(buf);
 
 return 1;
 }
@@ -623,7 +617,7 @@ void acpi_build_tables(struct acpi_config *config)
  offsetof(struct acpi_20_rsdp, extended_checksum),
  sizeof(struct acpi_20_rsdp));
 
-if ( !new_vm_gid(acpi_info) )
+if ( !new_vm_gid(config, acpi_info) )
 goto oom;
 
 return;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index 5e0f400..4cbd41e 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -37,6 +37,9 @@ struct acpi_config {
 
 uint32_t table_flags;
 
+uint64_t vm_gid[2];
+unsigned long vm_gid_addr; /* OUT parameter */
+
 /*
  * Address where acpi_info should be placed.
  * This must match the OperationRegion(BIOS, SystemMemory, )
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 7de2fb6..e8ce12b 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Check whether there exists overlap in the specified memory range.
@@ -861,6 +862,8 @@ int hpet_exists(unsigned long hpet_base)
 void hvmloader_acpi_build_tables(struct acpi_config *config,
  unsigned int physical)
 {
+const char *s;
+
 /* Allocate and initialise the acpi info area. */
 mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
 
@@ -881,10 +884,23 @@ void hvmloader_acpi_build_tables(struct acpi_config 
*config,
 config->pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
 }
 
+s = xenstore_read("platform/generation-id", "0:0");
+if ( s )
+{
+char *end;
+
+config->vm_gid[0] = strtoll(s, , 0);
+config->vm_gid[1] = 0;
+if ( end && end[0] == ':' )
+config->vm_gid[1] = strtoll(end+1, NULL, 0);
+}
+
 config->rsdp = physical;
 config->infop = ACPI_INFO_PHYSICAL_ADDRESS;
 
 acpi_build_tables(config);
+
+hvm_param_set(HVM_PARAM_VM_GENERATION_ID_ADDR, config->vm_gid_addr);
 }
 
 /*
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 12/23] acpi/hvmloader: Link ACPI object files directly

2016-08-04 Thread Boris Ostrovsky 
ACPI sources will be available to various component which will build
them according to their own rules. ACPI's Makefile will only generate
necessary source files.

Signed-off-by: Boris Ostrovsky 
---
v2:
* Reordered .gitignore changes alphabetically
* Dropped trailing slashes
* Use relative path for ACPI_PATH
* Use $(addprefix...)
* Dropped use of 'cd' in rules and instead add $(ACPI_BUILD_DIR)/ to $*

 .gitignore |  8 +++
 tools/firmware/hvmloader/Makefile  | 11 +-
 tools/firmware/hvmloader/acpi/Makefile | 39 --
 3 files changed, 32 insertions(+), 26 deletions(-)

diff --git a/.gitignore b/.gitignore
index e019f2e..d6ba3dd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -126,13 +126,13 @@ tools/firmware/*bios/*bios*.txt
 tools/firmware/etherboot/gpxe/*
 tools/firmware/extboot/extboot.img
 tools/firmware/extboot/signrom
-tools/firmware/hvmloader/acpi/mk_dsdt
-tools/firmware/hvmloader/acpi/dsdt*.c
-tools/firmware/hvmloader/acpi/dsdt_*.asl
-tools/firmware/hvmloader/acpi/ssdt_*.h
+tools/firmware/hvmloader/dsdt*.c
+tools/firmware/hvmloader/dsdt_*.asl
 tools/firmware/hvmloader/hvmloader
+tools/firmware/hvmloader/mk_dsdt
 tools/firmware/hvmloader/roms.h
 tools/firmware/hvmloader/roms.inc
+tools/firmware/hvmloader/ssdt_*.h
 tools/firmware/rombios/BIOS-bochs-[^/]*
 tools/firmware/rombios/_rombios[^/]*_.c
 tools/firmware/rombios/rombios[^/]*.s
diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 9f7357f..a1ab170 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -20,6 +20,7 @@
 XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
+export ACPI_BUILD_DIR=$(shell pwd)
 SUBDIRS := acpi
 
 # The HVM loader is started in 32-bit mode at the address below:
@@ -72,7 +73,15 @@ all: subdirs-all
 rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
-hvmloader: $(OBJS) acpi/acpi.a
+ACPI_PATH = ./acpi
+ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
+ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
+$(ACPI_OBJS): CFLAGS += -I$(ACPI_PATH) -I.
+vpath build.c $(ACPI_PATH)
+vpath static_tables.c $(ACPI_PATH)
+OBJS += $(ACPI_OBJS)
+
+hvmloader: $(OBJS)
$(LD) $(LDFLAGS_DIRECT) -N -Ttext $(LOADADDR) -o hvmloader.tmp $^
$(OBJCOPY) hvmloader.tmp hvmloader
rm -f hvmloader.tmp
diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index 703d67b..6937ff4 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -15,36 +15,39 @@
 XEN_ROOT = $(CURDIR)/../../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-C_SRC = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c 
dsdt_anycpu_qemu_xen.c
-OBJS  = $(patsubst %.c,%.o,$(C_SRC))
+MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
 
-CFLAGS += $(CFLAGS_xeninclude)
+# Sources to be generated
+C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c  
dsdt_anycpu_qemu_xen.c)
+H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
ssdt_tpm.h)
 
 vpath iasl $(PATH)
-all: acpi.a
+all: $(C_SRC) $(H_SRC)
 
-ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
+$(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
+   cd $(ACPI_BUILD_DIR)
iasl -vs -p $* -tc $<
sed -e 's/AmlCode/$*/g' $*.hex >$@
rm -f $*.hex $*.aml
+   cd $(CURDIR)
 
-mk_dsdt: mk_dsdt.c
+$(MK_DSDT): mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
-dsdt_anycpu_qemu_xen.asl: dsdt.asl mk_dsdt
+$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
-   ./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@
+   $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-dsdt_%cpu.asl: dsdt.asl mk_dsdt
+$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
-   ./mk_dsdt --debug=$(debug) --maxcpu $*  >> $@
+   $(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $@
 
-$(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
-   iasl -vs -p $* -tc $*.asl
-   sed -e 's/AmlCode/$*/g' $*.hex >$@
+$(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
+   iasl -vs -p $(ACPI_BUILD_DIR)/$* -tc $(ACPI_BUILD_DIR)/$*.asl
+   sed -e 's/AmlCode/$*/g' $(ACPI_BUILD_DIR)/$*.hex >$@
echo "int $*_len=sizeof($*);" >>$@
-   rm -f $*.aml $*.hex
+   rm -f $(ACPI_BUILD_DIR)/$*.aml $(ACPI_BUILD_DIR)/$*.hex
 
 iasl:
@echo
@@ -54,14 +57,8 @@ iasl:
@echo 
@exit 1
 
-build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
-
-acpi.a: $(OBJS)
-   $(AR) rc $@ $(OBJS)
-
 clean:
-   rm -rf *.a *.o $(IASL_VER) $(IASL_VER).tar.gz $(DEPS)
-   rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*.asl
+   rm -fr

[Xen-devel] [PATCH v2 09/23] acpi/hvmloader: Build WAET optionally

2016-08-04 Thread Boris Ostrovsky 
Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
v2:
* Note: didn't break "if ( !waet ) return -1" line since that's the style
  of the file.

 tools/firmware/hvmloader/acpi/build.c   | 9 ++---
 tools/firmware/hvmloader/acpi/libacpi.h | 1 +
 tools/firmware/hvmloader/util.c | 2 +-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 6ec8739..e362ccd 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -358,9 +358,12 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 }
 
 /* WAET. */
-waet = construct_waet();
-if (!waet) return -1;
-table_ptrs[nr_tables++] = (unsigned long)waet;
+if ( config->table_flags & ACPI_HAS_WAET )
+{
+waet = construct_waet();
+if ( !waet ) return -1;
+table_ptrs[nr_tables++] = (unsigned long)waet;
+}
 
 if ( config->table_flags & ACPI_HAS_SSDT_PM )
 {
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index e15abf7..a251d7c 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -31,6 +31,7 @@
 #define ACPI_HAS_SSDT_S4 (1<<6)
 #define ACPI_HAS_TCPA(1<<7)
 #define ACPI_HAS_IOAPIC  (1<<8)
+#define ACPI_HAS_WAET(1<<9)
 
 
 struct acpi_numa {
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 325c0a2..61018ea 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -919,7 +919,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
-config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC);
+config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC | ACPI_HAS_WAET);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 02/23] acpi/hvmloader: Allow acpi_build_tables() callers specify acpi_info values

2016-08-04 Thread Boris Ostrovsky 
By doing this we can move hvmloader-private interfaces (such as
uart_exists(), lpt_exists() etc.) out of the ACPI builder. This will
help us with allowing to call the builder from places other than
hvmloader.

Signed-off-by: Boris Ostrovsky 
---
v2:
* Keep struct acpi_info private to build.c and instead pass information
  necessary to set its fields via acpi_config's flags.

 tools/firmware/hvmloader/acpi/acpi2_0.h |  9 -
 tools/firmware/hvmloader/acpi/build.c   | 34 +-
 tools/firmware/hvmloader/acpi/libacpi.h | 63 +
 tools/firmware/hvmloader/ovmf.c |  2 +-
 tools/firmware/hvmloader/seabios.c  |  1 +
 tools/firmware/hvmloader/util.c | 26 +-
 6 files changed, 106 insertions(+), 29 deletions(-)
 create mode 100644 tools/firmware/hvmloader/acpi/libacpi.h

diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h 
b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 6fa3452..775eb7a 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -448,15 +448,6 @@ struct acpi_20_slit {
 
 #pragma pack ()
 
-struct acpi_config {
-unsigned char *dsdt_anycpu;
-int dsdt_anycpu_len;
-unsigned char *dsdt_15cpu;
-int dsdt_15cpu_len;
-};
-
-void acpi_build_tables(struct acpi_config *config, unsigned int physical);
-
 #endif /* _ACPI_2_0_H_ */
 
 /*
diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 8be9b90..f251c05 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -14,6 +14,7 @@
  */
 
 #include "acpi2_0.h"
+#include "libacpi.h"
 #include "ssdt_s3.h"
 #include "ssdt_s4.h"
 #include "ssdt_tpm.h"
@@ -356,7 +357,7 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 }
 
 /* HPET. */
-if ( hpet_exists(ACPI_HPET_ADDRESS) )
+if ( info->hpet_present )
 {
 hpet = construct_hpet();
 if (!hpet) return -1;
@@ -491,7 +492,7 @@ static int new_vm_gid(struct acpi_info *acpi_info)
 return 1;
 }
 
-void acpi_build_tables(struct acpi_config *config, unsigned int physical)
+void acpi_build_tables(struct acpi_config *config)
 {
 struct acpi_info *acpi_info;
 struct acpi_20_rsdp *rsdp;
@@ -504,10 +505,19 @@ void acpi_build_tables(struct acpi_config *config, 
unsigned int physical)
 unsigned longsecondary_tables[ACPI_MAX_SECONDARY_TABLES];
 int  nr_secondaries, i;
 
-/* Allocate and initialise the acpi info area. */
-mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
-acpi_info = (struct acpi_info *)ACPI_INFO_PHYSICAL_ADDRESS;
+acpi_info = (struct acpi_info *)config->infop;
 memset(acpi_info, 0, sizeof(*acpi_info));
+acpi_info->com1_present = !!(config->table_flags & ACPI_HAS_COM1);
+acpi_info->com2_present = !!(config->table_flags & ACPI_HAS_COM2);
+acpi_info->lpt1_present = !!(config->table_flags & ACPI_HAS_LPT1);
+acpi_info->hpet_present = !!(config->table_flags & ACPI_HAS_HPET);
+acpi_info->pci_min = config->pci_start;
+acpi_info->pci_len = config->pci_len;
+if ( config->pci_hi_len )
+{
+acpi_info->pci_hi_min = config->pci_hi_start;
+acpi_info->pci_hi_len = config->pci_hi_len;
+}
 
 /*
  * Fill in high-memory data structures, starting at @buf.
@@ -601,7 +611,7 @@ void acpi_build_tables(struct acpi_config *config, unsigned 
int physical)
 /*
  * Fill in low-memory data structures: acpi_info and RSDP.
  */
-rsdp = (struct acpi_20_rsdp *)physical;
+rsdp = (struct acpi_20_rsdp *)config->rsdp;
 
 memcpy(rsdp, , sizeof(struct acpi_20_rsdp));
 rsdp->rsdt_address = (unsigned long)rsdt;
@@ -616,18 +626,6 @@ void acpi_build_tables(struct acpi_config *config, 
unsigned int physical)
 if ( !new_vm_gid(acpi_info) )
 goto oom;
 
-acpi_info->com1_present = uart_exists(0x3f8);
-acpi_info->com2_present = uart_exists(0x2f8);
-acpi_info->lpt1_present = lpt_exists(0x378);
-acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
-acpi_info->pci_min = pci_mem_start;
-acpi_info->pci_len = pci_mem_end - pci_mem_start;
-if ( pci_hi_mem_end > pci_hi_mem_start )
-{
-acpi_info->pci_hi_min = pci_hi_mem_start;
-acpi_info->pci_hi_len = pci_hi_mem_end - pci_hi_mem_start;
-}
-
 return;
 
 oom:
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
new file mode 100644
index 000..5e0f400
--- /dev/null
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -0,0 +1,63 @@
+/**
+ * libacpi.h
+ * 
+ * libacpi interfaces
+ * 
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only.

[Xen-devel] [PATCH v2 14/23] acpi: Move ACPI code to tools/libacpi

2016-08-04 Thread Boris Ostrovsky 
Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
v2:
* Minor cleanup of hvmloader's Makefile

 tools/firmware/hvmloader/Makefile  | 14 --
 tools/firmware/hvmloader/ovmf.c|  2 +-
 tools/{firmware/hvmloader/acpi => libacpi}/Makefile|  2 +-
 tools/{firmware/hvmloader/acpi => libacpi}/README  |  0
 tools/{firmware/hvmloader/acpi => libacpi}/acpi2_0.h   |  0
 tools/{firmware/hvmloader/acpi => libacpi}/build.c |  0
 tools/{firmware/hvmloader/acpi => libacpi}/dsdt.asl|  0
 tools/{firmware/hvmloader/acpi => libacpi}/libacpi.h   |  0
 tools/{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c   |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_pm.asl |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s3.asl |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s4.asl |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_tpm.asl|  0
 tools/{firmware/hvmloader/acpi => libacpi}/static_tables.c |  0
 tools/{firmware/hvmloader/acpi => libacpi}/x86.h   |  0
 15 files changed, 10 insertions(+), 8 deletions(-)
 rename tools/{firmware/hvmloader/acpi => libacpi}/Makefile (98%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/README (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/acpi2_0.h (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/build.c (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/dsdt.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/libacpi.h (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_pm.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s3.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s4.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_tpm.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/static_tables.c (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/x86.h (100%)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index db64a61..694d9f1 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -20,9 +20,6 @@
 XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-export ACPI_BUILD_DIR=$(shell pwd)
-SUBDIRS := acpi
-
 # The HVM loader is started in 32-bit mode at the address below:
 LOADADDR = 0x10
 
@@ -67,16 +64,20 @@ ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) 
$(ETHERBOOT_ROMS)
 endif
 
 .PHONY: all
-all: subdirs-all
+all: acpi subdirs-all
$(MAKE) hvmloader
 
+.PHONY: acpi
+acpi:
+   $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(CURDIR)
+
 rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
-ACPI_PATH = ./acpi
+ACPI_PATH = ../../libacpi
 ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
 ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
-$(ACPI_OBJS): CFLAGS += -I. -DSTDUTILS=\"../util.h\"
+$(ACPI_OBJS): CFLAGS += -I. -DSTDUTILS=\"$(CURDIR)/util.h\"
 CFLAGS += -I$(ACPI_PATH)
 vpath build.c $(ACPI_PATH)
 vpath static_tables.c $(ACPI_PATH)
@@ -118,6 +119,7 @@ endif
 clean: subdirs-clean
rm -f roms.inc roms.inc.new acpi.h
rm -f hvmloader hvmloader.tmp *.o $(DEPS)
+   $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(CURDIR) clean
 
 .PHONY: distclean
 distclean: clean
diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index b4bcc93..7878276 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -23,7 +23,7 @@
 
 #include "config.h"
 #include "smbios_types.h"
-#include "acpi/libacpi.h"
+#include "libacpi.h"
 #include "apic_regs.h"
 #include "../rombios/config.h"
 #include "util.h"
diff --git a/tools/firmware/hvmloader/acpi/Makefile b/tools/libacpi/Makefile
similarity index 98%
rename from tools/firmware/hvmloader/acpi/Makefile
rename to tools/libacpi/Makefile
index 6937ff4..816322f 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -12,7 +12,7 @@
 # NU Lesser General Public License for more details.
 #
 
-XEN_ROOT = $(CURDIR)/../../../..
+XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
 MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
diff --git a/tools/firmware/hvmloader/acpi/README b/tools/libacpi/README
similarity index 100%
rename from tools/firmware/hvmloader/acpi/README
rename to tools/libacpi/README
diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
similarity index 100%
rename from tools/firmware/hvmloader/acpi/acpi2_0.h
rename to tools/libacpi/acpi2_0.h
diff --git a/tools/firmware/hvmloader/acpi/build.c b/tools/libacpi/build.c
similarity index 100%
rename from tools/firmware/hvmloader/acpi/build.c
rename to tools/libacpi/build.c
diff --git a/tools/firmware/hvmloader/acpi/dsdt.asl

[Xen-devel] [PATCH v2 11/23] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables

2016-08-04 Thread Boris Ostrovsky 
Non-hvmloader users may be building tables in virtual address space
and therefore we need to make sure that values that end up in tables
are physical addresses.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 tools/firmware/hvmloader/acpi/build.c | 47 ++-
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 7302c35..c0e0915 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -143,7 +143,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 lapic = (struct acpi_20_madt_lapic *)(madt + 1);
 
 info->nr_cpus = config-> hvminfo->nr_vcpus;
-info->madt_lapic0_addr = (uint32_t)lapic;
+info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, lapic);;
 for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
 {
 memset(lapic, 0, sizeof(*lapic));
@@ -160,7 +160,8 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 madt->header.length = (unsigned char *)lapic - (unsigned char *)madt;
 set_checksum(madt, offsetof(struct acpi_header, checksum),
  madt->header.length);
-info->madt_csum_addr = (uint32_t)>header.checksum;
+info->madt_csum_addr =
+ctxt->mem_ops.v2p(ctxt, >header.checksum);
 
 return madt;
 }
@@ -326,7 +327,7 @@ static int construct_passthrough_tables(struct acpi_ctxt 
*ctxt,
 break;
 memcpy(buffer, header, header->length);
 
-table_ptrs[nr_tables++] = (unsigned long)buffer;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, buffer);
 total += header->length;
 pt_addr += header->length;
 }
@@ -353,7 +354,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 {
 madt = construct_madt(ctxt, config, info);
 if (!madt) return -1;
-table_ptrs[nr_tables++] = (unsigned long)madt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, madt);
 }
 
 /* HPET. */
@@ -361,7 +362,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 {
 hpet = construct_hpet(ctxt, config);
 if (!hpet) return -1;
-table_ptrs[nr_tables++] = (unsigned long)hpet;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, hpet);
 }
 
 /* WAET. */
@@ -369,7 +370,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 {
 waet = construct_waet(ctxt, config);
 if ( !waet ) return -1;
-table_ptrs[nr_tables++] = (unsigned long)waet;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, waet);
 }
 
 if ( config->table_flags & ACPI_HAS_SSDT_PM )
@@ -377,7 +378,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_pm), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_pm, sizeof(ssdt_pm));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 }
 
 if ( config->table_flags & ACPI_HAS_SSDT_S3 )
@@ -385,7 +386,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_s3), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 } else {
 printf("S3 disabled\n");
 }
@@ -395,7 +396,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_s4), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 } else {
 printf("S4 disabled\n");
 }
@@ -409,12 +410,12 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_tpm), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_tpm, sizeof(ssdt_tpm));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 
 tcpa = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_tcpa), 16);
 if (!tcpa) return -1;
 memset(tcpa, 0, sizeof(*tcpa));
-table_ptrs[nr_tables++] = (unsigned long)tcpa;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, tcpa);
 
 tcpa->header.signature = ACPI_2_0_TCPA_SIGNATURE;
 tcpa->header.length= sizeof(*tcpa);
@@ -442,11 +443,11 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 struct acpi_20_slit *slit = construct_slit(ctxt, config);
 
 if ( srat )
-table_ptrs[nr_tables++] = (unsigned long)srat;
+

[Xen-devel] [PATCH v2 20/23] libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests

2016-08-04 Thread Boris Ostrovsky 
Signed-off-by: Boris Ostrovsky 
---
 tools/libxl/Makefile|  2 ++
 tools/libxl/libxl_dom.c | 22 ++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 9fee752..3a2d64a 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -165,6 +165,8 @@ $(XL_OBJS) $(TEST_PROG_OBJS) _libxl.api-for-check: \
 $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs 
it.
 
+libxl_dom.o: CFLAGS += -I$(XEN_ROOT)/tools  # include libacpi/x86.h
+
 SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
 $(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenevtchn)
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 4d2bc0c..3a1daae 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -24,6 +24,9 @@
 #include 
 #include 
 #include 
+#if defined(__i386__) || defined(__x86_64__)
+#include 
+#endif
 
 #include "_paths.h"
 
@@ -1077,10 +1080,21 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 dom->target_pages = mem_size >> XC_PAGE_SHIFT;
 if (dom->mmio_size == 0 && device_model)
 dom->mmio_size = HVM_BELOW_4G_MMIO_LENGTH;
-else if (dom->mmio_size == 0 && !device_model)
-dom->mmio_size = GB(4) -
-((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
-<< XC_PAGE_SHIFT);
+else if (dom->mmio_size == 0 && !device_model) {
+#if defined(__i386__) || defined(__x86_64__)
+if (libxl_defbool_val(info->u.hvm.apic)) {
+/* Make sure LAPIC_BASE_ADDRESS is below special pages */
+assert(X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
+  << XC_PAGE_SHIFT) - LAPIC_BASE_ADDRESS)) >= 
XC_PAGE_SIZE);
+dom->mmio_size = GB(4) - LAPIC_BASE_ADDRESS;
+} else
+dom->mmio_size = GB(4) -
+((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
+ << XC_PAGE_SHIFT);
+#else
+assert(1);
+#endif
+}
 lowmem_end = mem_size;
 highmem_end = 0;
 mmio_start = (1ull << 32) - dom->mmio_size;
-- 
1.8.3.1


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

[Xen-devel] [qemu-mainline baseline-only test] 66917: tolerable FAIL

2016-08-04 Thread Platform Team regression test user 
This run is configured for baseline tests only.

flight 66917 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66917/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail blocked 
in 66889
 test-amd64-amd64-amd64-pvgrub 10 guest-start fail blocked in 66889

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-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-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail 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-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu6eac5f7bad6cd8f56b3514ac485dd35d79abff66
baseline version:
 qemuu8b54a6a6c63dc84f2744f6b125c1a6c5a16ee10b

Last test of basis66889  2016-08-02 20:44:55 Z2 days
Testing same since66917  2016-08-04 14:46:50 Z0 days1 attempts


People who touched revisions under test:
  Alexey Kardashevskiy 
  Anthony PERARD 
  Bharata B Rao 
  Daniel P. Berrange 
  David Gibson 
  Denis V. Lunev 
  Evgeny Yakovlev 
  Gerd Hoffmann 
  Juergen Gross 
  Peter Maydell 
  Peter Xu 
  Stefan Weil 

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-xl

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

2016-08-04 Thread osstest service owner 
flight 99947 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99947/

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  0a7ba29364576deb4c13b3bb4cf7d03136bead98
baseline version:
 xen  e67f56bbeccbb2b3e1fbe605b83c08918f19bf7c

Last test of basis99945  2016-08-04 15:01:35 Z0 days
Testing same since99947  2016-08-04 18:01:52 Z0 days1 attempts


People who touched revisions under test:
  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=0a7ba29364576deb4c13b3bb4cf7d03136bead98
+ . ./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 
0a7ba29364576deb4c13b3bb4cf7d03136bead98
+ branch=xen-unstable-smoke
+ revision=0a7ba29364576deb4c13b3bb4cf7d03136bead98
+ . ./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
+ '[' x0a7ba29364576deb4c13b3bb4cf7d03136bead98 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '['

Re: [Xen-devel] [PATCH v2 2/3] symbols: Generate an xen-sym.map

2016-08-04 Thread Konrad Rzeszutek Wilk 
On August 4, 2016 11:49:23 AM EDT, Konrad Rzeszutek Wilk 
 wrote:
>You could construct _most_ of the names of the functions
>by doing 'nm --defined' but unfortunatly you do not get the
> prefix that is added on in Xen . For example:
>
>$ cat xen-syms.symbols |grep do_domain_pause
>0x82d080104920 t domain.c#do_domain_pause
>$ nm --defined xen-syms|grep do_domain_pause
>82d080104920 t do_domain_pause
>
>This is normally not an issue, but if one is doing livepatching and
>wants during build-time verify that the symbols the livepatch payloads
>will patch do correspond to the one the hypervisor has built - this
>helps a lot.
>
>Note that during runtime one can do:


Odd. I remeber updating the commit to have:

#cat /proc/xen/xensyms | grep do_domain_pause
>82d080104920 t domain.c#do_domain_pause
>



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

Re: [Xen-devel] HVMOP_guest_request_vm_event only works from guest in ring0

2016-08-04 Thread Razvan Cojocaru 
On 08/04/16 22:03, Bread Cutter wrote:
> My workaround for now is just something like
> 
>  int mode = hvm_guest_x86_mode(curr);
> 
>  uint32_t eax = regs->eax;
> 
> 
> +if(eax == 0xFACE) {
> +hvm_event_guest_request();
> +return 1;
> +}
> +
> 
>  switch ( mode )
>  {
>  case 8:
> 
> This way I don't have to worry about if it's a 32 or 64 bit guest. As
> long as I set EAX to 0xFACE before VMCALL, I can define my own calling
> convention for the rest of the registers.
> 
> Might not be what you'd want, but just thought I'd share.

Thanks for sharing. Since there appear to be many people needing / doing
these workarounds, this would IMHO justify at least considering the
official patch for upstream.

Unless someone strongly objects, I'll redo the patch with the modified
comparison for 32-bit guests, as suggested by Jan, and submit it
tomorrow. Whether it's accepted or not is of course up to the
maintainers, but it might be nice to just have an archived patch
suggesting how interested parties can achieve this.


Thanks,
Razvan

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

Re: [Xen-devel] HVMOP_guest_request_vm_event only works from guest in ring0

2016-08-04 Thread Bread Cutter 
My workaround for now is just something like

 int mode = hvm_guest_x86_mode(curr);

 uint32_t eax = regs->eax;


+if(eax == 0xFACE) {
+hvm_event_guest_request();
+return 1;
+}
+

 switch ( mode )
 {
 case 8:

This way I don't have to worry about if it's a 32 or 64 bit guest. As
long as I set EAX to 0xFACE before VMCALL, I can define my own calling
convention for the rest of the registers.

Might not be what you'd want, but just thought I'd share.

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

Re: [Xen-devel] [PATCH RFC 06/12] xen/x86: populate PVHv2 Dom0 physical memory map

2016-08-04 Thread Andrew Cooper 
On 02/08/16 10:19, Roger Pau Monne wrote:
> On Fri, Jul 29, 2016 at 08:04:12PM +0100, Andrew Cooper wrote:
>> On 29/07/16 17:29, Roger Pau Monne wrote:
>>> Craft the Dom0 e820 memory map and populate it.
>>>
>>> Signed-off-by: Roger Pau Monné 
>>> ---
>>> Cc: Jan Beulich 
>>> Cc: Andrew Cooper 
>>> ---
>>>  xen/arch/x86/domain_build.c | 199 
>>> ++--
>>>  1 file changed, 193 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
>>> index c0ef40f..cb8ecbd 100644
>>> --- a/xen/arch/x86/domain_build.c
>>> +++ b/xen/arch/x86/domain_build.c
>>> @@ -43,6 +43,11 @@ static long __initdata dom0_nrpages;
>>>  static long __initdata dom0_min_nrpages;
>>>  static long __initdata dom0_max_nrpages = LONG_MAX;
>>>  
>>> +/* GFN of the identity map for EPT. */
>>> +#define HVM_IDENT_PT_GFN  0xfeffeu
>> The IDENT_PT is only needed on Gen1 VT-x hardware which doesn't support
>> unrestricted-guest mode.  OTOH, it needs to be matched with VM86_TSS,
>> which is also needed if hardware doesn't support unrestricted-guest. 
>> Also, the IDENT_PT can live anywhere in GFN space.  0xfeffe is just
>> convention for HVM guests as nothing else interesting lives there, but a
>> PVH dom0 will want to ensure it doesn't alias anything interesting it
>> might wish to map.
>>
>> Now I look at it, there is substantial WTF.  The domain builder makes
>> IDENT_PT, but HVMLoader makes VM86_TSS.  I presume this is a historical
>> side effect of IDENT_PT being a prerequisite to even executing
>> hvmloader, while VM86_TSS was only a prerequisite to executing the
>> rombios payload.  Either way, eww :(
>>
>> I think the VM86_TSS setup needs to move to unconditionally being beside
>> IDENT_PT setup in the domain builder, and mirrored here in dom0_hvm()
>> creation.  I don't think it is reasonable to expect an HVMLite payload
>> to set up its own VM86_TSS if it didn't set up IDENT_PT.  (OTOH, the
>> chances of an HVMLite guest ever needing to return to real mode is slim,
>> but in the name of flexibility, it would be nice not to rule it out).
>>
>> Longterm, it would be nice to disentangle the unrestricted-guest support
>> from the main vmx code, and make it able to be compiled out.  There is
>> lots of it, and it all-but-dead on modern hardware.
> Thanks! I didn't know anything about the VM86 TSS stuff, the fact that the 
> identity page tables and the VM86 TSS are set at completely different points 
> makes it quite hard to follow :/.
>
> I've now moved the setup of the VM86 TSS inside the domain builder for both 
> DomU and Dom0.

Thanks.  (Guess who has recently had to delve back into this code^W swamp.)

>
>>> +}
>>> +
>>> +/* Calculate the biggest usable order given a size in bytes. */
>>> +static inline unsigned int get_order(uint64_t size)
>>> +{
>>> +unsigned int order;
>>> +uint64_t pg;
>>> +
>>> +ASSERT((size & ~PAGE_MASK) == 0);
>>> +pg = PFN_DOWN(size);
>>> +for ( order = 0; pg >= (1 << (order + 1)); order++ );
>>> +
>>> +return order;
>>> +}
>> We already have get_order_from_bytes() and get_order_from_pages(), the
>> latter of which looks like it will suit your usecase.
> Not really, or at least they don't do the same as get_order. This function 
> calculates the maximum order you can use so that there are no pages left 
> over, (ie: if you have a size of 3145728bytes (3MiB), this function will 
> return order 9 (2MiB), while the other ones will return order 10 (4MiB)). I 
> don't really understand while other places in code request bigger orders and 
> then free the leftovers, isn't this also causing memory shattering?

Sounds like we want something like get_order_{floor,ceil}() which makes
it obvious which way non-power-of-two get rounded.

>
>> As a TODO item, I really would like to borrow some of the Linux
>> infrastructure to calculate orders of constants at compile time, because
>> a large number of callers of the existing get_order_*() functions are
>> performing unnecessary runtime calculation.  For those which need
>> runtime calculation, some careful use of ffs() would be preferable to a
>> loop.
>>
>>> +
>>> +/* Populate an HVM memory range using the biggest possible order. */
>>> +static void __init hvm_populate_memory_range(struct domain *d, uint64_t 
>>> start,
>>> + uint64_t size)
>>> +{
>>> +static unsigned int __initdata memflags = MEMF_no_dma|MEMF_exact_node;
>>> +unsigned int order;
>>> +struct page_info *page;
>>> +int rc;
>>> +
>>> +ASSERT((size & ~PAGE_MASK) == 0 && (start & ~PAGE_MASK) == 0);
>>> +
>>> +order = MAX_ORDER;
>>> +while ( size != 0 )
>>> +{
>>> +order = min(get_order(size), order);
>>> +page = alloc_domheap_pages(d, order, memflags);
>>> +if ( page == NULL )
>>> +{
>>> +if ( order == 0 && memflags )

Re: [Xen-devel] [PATCH RFC 04/12] xen/x86: split Dom0 build into PV and PVHv2

2016-08-04 Thread Andrew Cooper 
On 01/08/16 12:36, Roger Pau Monne wrote:
> On Fri, Jul 29, 2016 at 06:57:08PM +0100, Andrew Cooper wrote:
>> On 29/07/16 17:28, Roger Pau Monne wrote:
>>> Split the Dom0 builder into two different functions, one for PV (and classic
>>> PVH), and another one for PVHv2. Introduce a new command line parameter,
>>> dom0hvm in order to request the creation of a PVHv2 Dom0.
>>>
>>> Signed-off-by: Roger Pau Monné 
>>> ---
>>> Cc: Jan Beulich 
>>> Cc: Andrew Cooper 
>>> ---
>>>  xen/arch/x86/domain_build.c | 27 ++-
>>>  xen/arch/x86/setup.c|  9 +
>> A patch to docs/misc/xen-command-line.markdown please.
> OK, I wasn't really sure if we want to introduce a new command line option, 
> or just use dom0pvh. In any case I will add it, we can always alias dom0pvh 
> to dom0pvh (or the other way around) when classic PVH support is 
> removed.

I am not terribly fussed, so long as the docs match the hypervisor
behaviour :)

>  
>>>  2 files changed, 35 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
>>> index 09d79be..c0ef40f 100644
>>> --- a/xen/arch/x86/domain_build.c
>>> +++ b/xen/arch/x86/domain_build.c
>>> @@ -952,7 +952,7 @@ static int __init setup_permissions(struct domain *d)
>>>  return rc;
>>>  }
>>>  
>>> -int __init construct_dom0(
>>> +static int __init construct_dom0_pv(
>>>  struct domain *d,
>>>  const module_t *image, unsigned long image_headroom,
>>>  module_t *initrd,
>>> @@ -1647,6 +1647,31 @@ out:
>>>  return rc;
>>>  }
>>>  
>>> +static int __init construct_dom0_hvm(struct domain *d, const module_t 
>>> *image,
>>> + unsigned long image_headroom,
>>> + module_t *initrd,
>>> + void *(*bootstrap_map)(const module_t 
>>> *),
>>> + char *cmdline)
>>> +{
>>> +
>>> +printk("** Building a PVH Dom0 **\n");
>> Some naming curiosities here, especially given the parameter name.
> Hm, AFAIK we agreed on keeping the 'PVH' naming, but since internally Xen 
> has no concept of 'PVH' I think the constructor is better named as HVM (and 
> in fact if PVH wasn't there before I would just consider this a HVM Dom0).
>
> If people prefer HVM I can certainly change it, but I think it's going to 
> get messy.

Fair enough.

~Andrew

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

Re: [Xen-devel] [PATCH] xen/arm: p2m: Don't use default access permission when shattering a superpage

2016-08-04 Thread Stefano Stabellini 
On Fri, 29 Jul 2016, Julien Grall wrote:
> The following message flood the console when memaccess is enabled on
> various platforms:
> 
> traps.c:2510:d1v0 HSR=0x9383004f pc=0x08b7d4c4 gva=0x08eeb8e0 
> gpa=0x004903f8e0
> 
> This is because a data abort from a guest was received due to a
> permission fault but memaccess thought there are no permission fault.
> 
> On ARM, memaccess permissions are stored in a radix tree because there
> are not enough available bits in the p2m entry to store the access
> restriction. When memaccess is restricting the access (i.e any other
> access than p2m_access_rwx), the access will be added in the radix tree
> using the GFN as a key. This will be done for all 4KB pages.
> 
> This means that memaccess has to shatter all the superpages in a given
> region to set the permission on a 4KB granularity. Currently, when a
> superpage is shattered, the new entries are using the value
> p2m->default_access which will restrict permission (because memaccess
> has been enabled). However the radix tree does not yet contain
> an entry for this GFN.
> 
> If a guest VCPU is running at the same time and trying to access the
> modified region, it will result to a stage-2 permission fault. As
> the radix tree does not yet contain an entry for the GFN, memaccess will
> deduce that the fault was not valid and a data abort will be injecting
> to the guest (and crash it).
> 
> Furthermore, the permission may be restricted outside of the requested
> region if it is only a subset of a 1GB/2MB superpage.
> 
> The two issues can be fixed by re-using the permission of the superpage
> entry and override the necessary fields. This is not a problem because
> memaccess cannot work on superpage.
> 
> Lastly, document the code which call mfn_to_p2m_entry when creating a
> the p2m entry for a table to explain that create the p2m entry to page table
> to explain that permission are ignored by the hardware (See D4.3.1 in ARM DDI
> 0487A.j). so the value of the parameter 'access' of mfn_to_p2m_entry does
> not matter.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> This patch needs to be backported up to Xen 4.6 (first release
> which introduced memaccess on ARM). This may require few adjustement
> because the code has changed a bit.
> 
> Without it, the guest will randomly crash because the permission has
> been overriden whilst shattering a superpage and before adding the access
> permission in the radix tree.
> 
> Also I am wondering if it would be better to pass p2m_access_rwx
> to mfn_to_p2m_entry when creating a table entry. This would save
> a couple of instructions.
> ---
>  xen/arch/arm/p2m.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 40a0b80..d60fbbf 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -434,7 +434,6 @@ static int p2m_create_table(struct p2m_domain *p2m, 
> lpae_t *entry,
>  p = __map_domain_page(page);
>  if ( splitting )
>  {
> -p2m_type_t t = entry->p2m.type;
>  mfn_t mfn = _mfn(entry->p2m.base);
>  int i;
>  
> @@ -444,15 +443,20 @@ static int p2m_create_table(struct p2m_domain *p2m, 
> lpae_t *entry,
>   */
>   for ( i=0 ; i < LPAE_ENTRIES; i++ )
>   {
> - pte = mfn_to_p2m_entry(mfn_add(mfn, i << (level_shift - 
> LPAE_SHIFT)),
> -t, p2m->default_access);
> + /*
> +  * Use the content of the superpage entry and override
> +  * the necessary fields. So the correct permissions are
> +  * kept.
> +  */
> + pte = *entry;
> + pte.p2m.base = mfn_x(mfn_add(mfn,
> +  i << (level_shift - LPAE_SHIFT)));
>  
>   /*
>* First and second level super pages set p2m.table = 0, but
>* third level entries set table = 1.
>*/
> - if ( level_shift - LPAE_SHIFT )
> - pte.p2m.table = 0;
> + pte.p2m.table = !(level_shift - LPAE_SHIFT);
>  
>   write_pte([i], pte);
>   }
> @@ -467,6 +471,10 @@ static int p2m_create_table(struct p2m_domain *p2m, 
> lpae_t *entry,
>  
>  unmap_domain_page(p);
>  
> +/*
> + * The access value does not matter because the hardware will ignore
> + * the permission fields for table entry.
> + */
>  pte = mfn_to_p2m_entry(_mfn(page_to_mfn(page)), p2m_invalid,
> p2m->default_access);
>  
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [OSSTEST PATCH RFC 04/14] ap-common: add xtf tree

2016-08-04 Thread Andrew Cooper 
On 04/08/16 17:13, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [OSSTEST PATCH RFC 04/14] ap-common: add xtf 
> tree"):
>> On 04/08/16 16:21, Ian Jackson wrote:
>>> Andrew Cooper writes ("Re: [OSSTEST PATCH RFC 04/14] ap-common: add xtf 
>>> tree"):
 We should also clarify the force push criteria.  It is moderately likely
 that we get a fix or extension to an existing test which starts showing
 up a new bug in the code under test.
>>> Can this not be made into a new test ?
>> That very much depends, and probably needs deciding on a case by case basis.
>>
>> What absolutely shouldn't happen is ending up with test-$FOO,
>> test-$FOO-2, test-more-$FOO, test-$FOO-again because that will result in
>> the same logical test being split up in ad-hoc ways.  While XTF is
>> useful for automation, it is first and foremost a tool for humans.
> You mean that this would contort the code for the test ?
>
> Here is another approach that could be used to satisfy osstest's
> desire for stability in the meaning of test names: you could
> explicitly copy the entire source of the test to a new test name, and
> deprecate the old test.  Later, if the old versions of Xen are fixed,
> or after they are retired you would delete the old test.
>
> The result would be that the old, less-good, test would still exist
> and still detect regressions.  The new, better test, would be seen to
> have never passed on old branches.
>
> Force pushing XTF is not an answer to this problem, for two reasons:
>
> Firstly, if the improved test correctly fails on old versions of Xen,
> this will appear as a regression in each old version of Xen.  Each old
> Xen tree would need to be force pushed, every time this happened.
>
> Secondly, in any case, force pushing XTF might not be necessary.  In
> the usual case, one would expect xen-unstable (which is what would
> drive the XTF push gate) to be fixed so that the improved test
> passes.  So osstest wouldn't spot the issue until it ran the new XTF
> with old Xen.
>
> Another possibility would be to have the capability for an single XTF
> test execution to return multiple statuses.

After an IRL discussion, the following has been proposed.

Each test can have a revision number associated with it.  The revision
gets bumped every time there is a change to the test which adds new
functionality (including bugfixes which cause it to spot a preexisting
error).

By default, a human will just want the latest and greatest.  Test
systems on the other hand will want to test "the same thing as before".

The XTF build system will support a way to build older revisions of the
tests.  It is likely that this will involve recompiling the current code
with an older revision id, and leave the onus on the programmer to
ensure that the result is functionally equivalent to the older test.

This way, test automation systems can internal treat different revisions
of the test as logically separate, for the purpose of identifying
regressions.

~Andrew

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

Re: [Xen-devel] [OSSTEST PATCH RFC 06/14] Introduce ts-xtf-build [and 1 more messages]

2016-08-04 Thread Ian Jackson 
Andrew Cooper writes ("Re: [Xen-devel] [OSSTEST PATCH RFC 06/14] Introduce 
ts-xtf-build [and 1 more messages]"):
> The current hard-coded paths exist only because of current limitiations
> in xl/libxl (identified here:
> http://xenbits.xen.org/people/andrewcoop/xen-test-framework/#errata)
> 
> With those issues fixed, XTF can be made to be entirely filesystem
> location independent.

Great.  If that ever happens we can make osstest install its xtf(s)
whereever it likes and the build location will be irrelevant.

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH RFC 06/14] Introduce ts-xtf-build [and 1 more messages]

2016-08-04 Thread Andrew Cooper 
On 04/08/16 17:05, Ian Jackson wrote:
> Wei Liu writes ("Re: [OSSTEST PATCH RFC 06/14] Introduce ts-xtf-build [and 1 
> more messages]"):
>> On Thu, Aug 04, 2016 at 04:17:45PM +0100, Ian Jackson wrote:
>>> The ability to coinstall multiple different xtfs was my reason for
>>> suggesting that the xtfdist should be unpacked into a job-specific
>>> subdirectory of /home/osstest.  Obviously that would have to be a
>>> directory specific to the _test job_, not the build job.
> ...
>> Note that xtf won't generate any artefacts during runtime.
> Yes.
>
>> The test jobs are tied to a specific build job in one flight, so I think
>> a build job specific path (as coded) would be the same as test job
>> specific path.
> That is how the flights are constructed right now, yes.
>
> But it is not in general a good idea to bake too many of these
> assumptions into the ts-* scripts.  It's not easy to imagine today why
> a single test host might want to be subjected to multiple xtf runs,
> but it seems hard to rule out.
>
> For example, in the future, host sharing may mean that different test
> jobs for the same flight are run on the same host.  Of course these
> wouldn't be your existing multiple xtf jobs (for several reasons).
>
> But if there were ever some xtf test jobs which were different in some
> way, then in principle it would be possible for each xtf test job to
> specify a differnet xtf build job.  This would mean installing xtf
> more than once, from what may be different build jobs or what may be
> the same build job.
>
> Whether they are the same build job might not depend on things
> specified directly in make-flight and mfi-*.  Automatic job
> constructors can reuse jobs from other flights and/or construct new
> flights using old ones as templates.  The bisector will choose build
> jobs as it sees fit.
>
> If an xtfdist would work if unpacked in a different directory, which
> wasn't known at build time, it would be possible for each xtf test job
> to unpack its xtfdist in the directory corresponding to the test job.
>
> Thus multiple test jobs with potentially-different xtfs could run
> sequentially on the same host.
>
> However, that is not possible.  (Unpacking the same xtf over the top
> of itself might not be safe and wouldn't be a good idea.)
>
> Therefore, we will have to remember this limitation if we ever are
> likely to come across it.  Fine.
>
> But that does mean that my suggestion for using a job-specific
> location for the xtf installed version is pointless.  The
> (impossible) scheme depends on a _test_-job-specific location.  There
> is no point embedding the _build_ job info in the pathnames.
>
> And as you discover, doing so means that the pathname needs to be made
> available in a runvar.  This is pointless complexity.
>
>> If you have different test jobs that depend the same build job, using
>> the same build should be fine. If you have test jobs that depend on
>> different build job, obviously the path would be different, too.
> This seems to contemplate unpacking the same xtf over the top of
> itself.  I don't think this is a good idea.  For example, if we ever
> do parallel runs, it would break.  It might also overwrite useful logs
> etc.

The current hard-coded paths exist only because of current limitiations
in xl/libxl (identified here:
http://xenbits.xen.org/people/andrewcoop/xen-test-framework/#errata)

With those issues fixed, XTF can be made to be entirely filesystem
location independent.

~Andrew

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

Re: [Xen-devel] [PATCH v3 0/6] xen/arm: Simplify do_trap_*_abort_guest

2016-08-04 Thread Stefano Stabellini 
On Thu, 4 Aug 2016, Julien Grall wrote:
> The current data/instruction abort paths contain unnecessary code and
> translate too often a VA to a IPA. This series aim to simplify this path.
> 
> Now that the register HPFAR_EL2 is read in some case that can be affected
> by the erratum 834220 on Cortex-A57, we need to implement a workaround
> for it (see patch #6).
> 
> A branch with this series applied can be found on xenbits:
> git://xenbits.xen.org/people/julieng/xen-unstable.git branch abort-handlers-v3

committed, thank you


> Yours sincerely,
> 
> Julien Grall (6):
>   xen/arm: traps: Simplify the switch in do_trap_*_abort_guest
>   xen/arm: Provide macros to help creating workaround helpers
>   xen/arm: Use check_workaround to handle the erratum 766422
>   xen/arm: traps: MMIO should only be emulated for fault translation
>   xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort
> handlers
>   xen/arm: arm64: Add Cortex-A57 erratum 834220 workaround
> 
>  docs/misc/arm/silicon-errata.txt  |  1 +
>  xen/arch/arm/Kconfig  | 21 +
>  xen/arch/arm/cpuerrata.c  | 15 +++
>  xen/arch/arm/traps.c  | 81 
> ++-
>  xen/include/asm-arm/arm32/processor.h |  4 --
>  xen/include/asm-arm/arm64/processor.h |  2 -
>  xen/include/asm-arm/cpuerrata.h   | 42 ++
>  xen/include/asm-arm/cpufeature.h  |  4 +-
>  xen/include/asm-arm/processor.h   |  2 +
>  9 files changed, 136 insertions(+), 36 deletions(-)
> 
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH v3 3/6] xen/arm: Use check_workaround to handle the erratum 766422

2016-08-04 Thread Julien Grall 

Hi,

On 04/08/16 18:50, Julien Grall wrote:

Currently, Xen is accessing the stored MIDR everytime it has to check
whether the processor is affected by the erratum 766422.

This could take advantage of the new capability bitfields to detect
whether the processor is affected at boot time.

With this patch, the number of instructions to check the erratum is
going down from ~13 (including 2 loads and a co-processor access) to
~6 instructions (include 1 load).

Signed-off-by: Julien Grall 


Likewise, I forgot to add Stefano's reviewed-by:

Reviewed-by: Stefano Stabellini 



---
Changes in v2:
- Update the commit message
---
 xen/arch/arm/cpuerrata.c  | 6 ++
 xen/arch/arm/traps.c  | 3 ++-
 xen/include/asm-arm/arm32/processor.h | 4 
 xen/include/asm-arm/arm64/processor.h | 2 --
 xen/include/asm-arm/cpuerrata.h   | 2 ++
 xen/include/asm-arm/cpufeature.h  | 3 ++-
 xen/include/asm-arm/processor.h   | 2 ++
 7 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 3ac97b3..748e02e 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -17,6 +17,12 @@ is_affected_midr_range(const struct arm_cpu_capabilities 
*entry)
 }

 static const struct arm_cpu_capabilities arm_errata[] = {
+{
+/* Cortex-A15 r0p4 */
+.desc = "ARM erratum 766422",
+.capability = ARM32_WORKAROUND_766422,
+MIDR_RANGE(MIDR_CORTEX_A15, 0x04, 0x04),
+},
 #if defined(CONFIG_ARM64_ERRATUM_827319) || \
 defined(CONFIG_ARM64_ERRATUM_824069)
 {
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index b11d2e5..7206a7e 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -46,6 +46,7 @@
 #include "vtimer.h"
 #include 
 #include 
+#include 

 /* The base of the stack must always be double-word aligned, which means
  * that both the kernel half of struct cpu_user_regs (which is pushed in
@@ -2481,7 +2482,7 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
  * Erratum 766422: Thumb store translation fault to Hypervisor may
  * not have correct HSR Rt value.
  */
-if ( cpu_has_erratum_766422() && (regs->cpsr & PSR_THUMB) && dabt.write )
+if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) && dabt.write )
 {
 rc = decode_instruction(regs, );
 if ( rc )
diff --git a/xen/include/asm-arm/arm32/processor.h 
b/xen/include/asm-arm/arm32/processor.h
index f41644d..11366bb 100644
--- a/xen/include/asm-arm/arm32/processor.h
+++ b/xen/include/asm-arm/arm32/processor.h
@@ -115,10 +115,6 @@ struct cpu_user_regs
 #define READ_SYSREG(R...)   READ_SYSREG32(R)
 #define WRITE_SYSREG(V, R...)   WRITE_SYSREG32(V, R)

-/* Erratum 766422: only Cortex A15 r0p4 is affected */
-#define cpu_has_erratum_766422() \
-(unlikely(current_cpu_data.midr.bits == 0x410fc0f4))
-
 #endif /* __ASSEMBLY__ */

 #endif /* __ASM_ARM_ARM32_PROCESSOR_H */
diff --git a/xen/include/asm-arm/arm64/processor.h 
b/xen/include/asm-arm/arm64/processor.h
index fef35a5..b0726ff 100644
--- a/xen/include/asm-arm/arm64/processor.h
+++ b/xen/include/asm-arm/arm64/processor.h
@@ -111,8 +111,6 @@ struct cpu_user_regs
 #define READ_SYSREG(name) READ_SYSREG64(name)
 #define WRITE_SYSREG(v, name) WRITE_SYSREG64(v, name)

-#define cpu_has_erratum_766422() 0
-
 #endif /* __ASSEMBLY__ */

 #endif /* __ASM_ARM_ARM64_PROCESSOR_H */
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 2982a92..5880e77 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -40,6 +40,8 @@ static inline bool_t check_workaround_##erratum(void) 
  \

 #endif

+CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
+
 #undef CHECK_WORKAROUND_HELPER

 #endif /* __ARM_CPUERRATA_H__ */
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index 78e2263..ac6eaf0 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -37,8 +37,9 @@

 #define ARM64_WORKAROUND_CLEAN_CACHE0
 #define ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE1
+#define ARM32_WORKAROUND_766422 2

-#define ARM_NCAPS   2
+#define ARM_NCAPS   3

 #ifndef __ASSEMBLY__

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 1708253..15bf890 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -46,9 +46,11 @@

 #define ARM_CPU_IMP_ARM 0x41

+#define ARM_CPU_PART_CORTEX_A15 0xC0F
 #define ARM_CPU_PART_CORTEX_A53 0xD03
 #define ARM_CPU_PART_CORTEX_A57 0xD07

+#define MIDR_CORTEX_A15 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A15)
 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A53)
 #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A57)

Re: [Xen-devel] [PATCH v3 2/6] xen/arm: Provide macros to help creating workaround helpers

2016-08-04 Thread Julien Grall 

Hi,

On 04/08/16 18:50, Julien Grall wrote:

Workarounds may require to execute a different path when the platform
is affected by the associated erratum. Furthermore, this may need to
be called in the common code.

To avoid too much intrusion/overhead, the workaround helpers need to
be a nop on architecture which will never have the workaround and have
to be quick to check whether the platform requires it.

The alternative framework is used to transform the check in a single
instruction. When the framework is not available, the helper will have
~6 instructions including 1 instruction load.

The macro will create a handler called check_workaround_x with
 the erratum number.

For instance, the line bellow will create a workaround helper for
erratum #424242 which is enabled when the capability
ARM64_WORKAROUND_424242 is set and only available for ARM64:

CHECK_WORKAROUND_HELPER(424242, ARM64_WORKAROUND_42424242, CONFIG_ARM64)

Signed-off-by: Julien Grall 
Reviewed-by: Konrad Rzeszutek Wilk 


Similar here, I forgot to add the acked-by from Stefano:

Acked-by: Stefano Stabellini 



---
Changes in v2:
- Add Konrad's reviewed-by
---
 xen/include/asm-arm/cpuerrata.h | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index c495ee5..2982a92 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -1,8 +1,47 @@
 #ifndef __ARM_CPUERRATA_H__
 #define __ARM_CPUERRATA_H__

+#include 
+#include 
+#include 
+
 void check_local_cpu_errata(void);

+#ifdef CONFIG_ALTERNATIVE
+
+#define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
+static inline bool_t check_workaround_##erratum(void)   \
+{   \
+if ( !IS_ENABLED(arch) )\
+return 0;   \
+else\
+{   \
+bool_t ret; \
+\
+asm volatile (ALTERNATIVE("mov %0, #0", \
+  "mov %0, #1", \
+  feature)  \
+  : "=r" (ret));\
+\
+return unlikely(ret);   \
+}   \
+}
+
+#else /* CONFIG_ALTERNATIVE */
+
+#define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
+static inline bool_t check_workaround_##erratum(void)   \
+{   \
+if ( !IS_ENABLED(arch) )\
+return 0;   \
+else\
+return unlikely(cpus_have_cap(feature));\
+}
+
+#endif
+
+#undef CHECK_WORKAROUND_HELPER
+
 #endif /* __ARM_CPUERRATA_H__ */
 /*
  * Local variables:



--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 1/6] xen/arm: traps: Simplify the switch in do_trap_*_abort_guest

2016-08-04 Thread Julien Grall 

Hi,

On 04/08/16 18:50, Julien Grall wrote:

The fault status we care are in the form xx where xx is the lookup
level that gave the fault. We can simplify the code by masking the 2 least
significant bits.

Signed-off-by: Julien Grall 


I forgot to retain the reviewed-by from Stefano given on the last version:

Reviewed-by: Stefano Stabellini 



---
The switch has not been replaced by a simple if because more case
will be added in follow-up patches.

Changes in v2:
- Fix typoes in the commit message
---
 xen/arch/arm/traps.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 0f78d21..b11d2e5 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2387,9 +2387,9 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 int rc;
 register_t gva = READ_SYSREG(FAR_EL2);

-switch ( hsr.iabt.ifsc & 0x3f )
+switch ( hsr.iabt.ifsc & ~FSC_LL_MASK )
 {
-case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
+case FSC_FLT_PERM:
 {
 paddr_t gpa;
 const struct npfec npfec = {
@@ -2450,9 +2450,9 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
 return; /* Try again */
 }

-switch ( dabt.dfsc & 0x3f )
+switch ( dabt.dfsc & ~FSC_LL_MASK )
 {
-case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
+case FSC_FLT_PERM:
 {
 const struct npfec npfec = {
 .read_access = !dabt.write,



--
Julien Grall

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

[Xen-devel] [PATCH v3 2/6] xen/arm: Provide macros to help creating workaround helpers

2016-08-04 Thread Julien Grall 
Workarounds may require to execute a different path when the platform
is affected by the associated erratum. Furthermore, this may need to
be called in the common code.

To avoid too much intrusion/overhead, the workaround helpers need to
be a nop on architecture which will never have the workaround and have
to be quick to check whether the platform requires it.

The alternative framework is used to transform the check in a single
instruction. When the framework is not available, the helper will have
~6 instructions including 1 instruction load.

The macro will create a handler called check_workaround_x with
 the erratum number.

For instance, the line bellow will create a workaround helper for
erratum #424242 which is enabled when the capability
ARM64_WORKAROUND_424242 is set and only available for ARM64:

CHECK_WORKAROUND_HELPER(424242, ARM64_WORKAROUND_42424242, CONFIG_ARM64)

Signed-off-by: Julien Grall 
Reviewed-by: Konrad Rzeszutek Wilk 

---
Changes in v2:
- Add Konrad's reviewed-by
---
 xen/include/asm-arm/cpuerrata.h | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index c495ee5..2982a92 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -1,8 +1,47 @@
 #ifndef __ARM_CPUERRATA_H__
 #define __ARM_CPUERRATA_H__
 
+#include 
+#include 
+#include 
+
 void check_local_cpu_errata(void);
 
+#ifdef CONFIG_ALTERNATIVE
+
+#define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
+static inline bool_t check_workaround_##erratum(void)   \
+{   \
+if ( !IS_ENABLED(arch) )\
+return 0;   \
+else\
+{   \
+bool_t ret; \
+\
+asm volatile (ALTERNATIVE("mov %0, #0", \
+  "mov %0, #1", \
+  feature)  \
+  : "=r" (ret));\
+\
+return unlikely(ret);   \
+}   \
+}
+
+#else /* CONFIG_ALTERNATIVE */
+
+#define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
+static inline bool_t check_workaround_##erratum(void)   \
+{   \
+if ( !IS_ENABLED(arch) )\
+return 0;   \
+else\
+return unlikely(cpus_have_cap(feature));\
+}
+
+#endif
+
+#undef CHECK_WORKAROUND_HELPER
+
 #endif /* __ARM_CPUERRATA_H__ */
 /*
  * Local variables:
-- 
1.9.1


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

[Xen-devel] [PATCH v3 6/6] xen/arm: arm64: Add Cortex-A57 erratum 834220 workaround

2016-08-04 Thread Julien Grall 
The ARM erratum applies to certain revisions of Cortex-A57. The
processor may report a Stage 2 translation fault as the result of
Stage 1 fault for load crossing a page boundary when there is a
permission fault or device memory fault at stage 1 and a translation
fault at Stage 2.

So Xen needs to check that Stage 1 translation does not generate a fault
before handling the Stage 2 fault. If it is a Stage 1 translation fault,
return to the guest to let the processor injecting the correct fault.

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

---
Changes in v2:
- Add Stefano's reviewed-by
---
 docs/misc/arm/silicon-errata.txt |  1 +
 xen/arch/arm/Kconfig | 21 +
 xen/arch/arm/cpuerrata.c |  9 +
 xen/arch/arm/traps.c |  5 +++--
 xen/include/asm-arm/cpuerrata.h  |  1 +
 xen/include/asm-arm/cpufeature.h |  3 ++-
 6 files changed, 37 insertions(+), 3 deletions(-)

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index 220f724..c9854c3 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -47,3 +47,4 @@ stable hypervisors.
 | ARM| Cortex-A53  | #819472 | ARM64_ERRATUM_819472
|
 | ARM| Cortex-A57  | #852523 | N/A 
|
 | ARM| Cortex-A57  | #832075 | ARM64_ERRATUM_832075
|
+| ARM| Cortex-A57  | #834220 | ARM64_ERRATUM_834220
|
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index e26c4c8..871c243 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -142,6 +142,27 @@ config ARM64_ERRATUM_832075
 
  If unsure, say Y.
 
+config ARM64_ERRATUM_834220
+   bool "Cortex-A57: 834220: Stage 2 translation fault might be 
incorrectly reported in presence of a Stage 1 fault"
+   default y
+   depends on ARM_64
+   help
+ This option adds an alternative code sequence to work around ARM
+ erratum 834220 on Cortex-A57 parts up to r1p2.
+
+ Affected Cortex-A57 parts might report a Stage 2 translation
+ fault as the result of a Stage 1 fault for load crossing a
+ page boundary when there is a permission or device memory
+ alignment fault at Stage 1 and a translation fault at Stage 2.
+
+ The workaround is to verify that the Stage 1 translation
+ doesn't generate a fault before handling the Stage 2 fault.
+ Please note that this does not necessarily enable the workaround,
+ as it depends on the alternative framework, which will only patch
+ the kernel if an affected CPU is detected.
+
+ If unsure, say Y.
+
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 748e02e..a3e8dda 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -49,6 +49,15 @@ static const struct arm_cpu_capabilities arm_errata[] = {
(1 << MIDR_VARIANT_SHIFT) | 2),
 },
 #endif
+#ifdef CONFIG_ARM64_ERRATUM_834220
+{
+/* Cortex-A57 r0p0 - r1p2 */
+.desc = "ARM erratum 834220",
+.capability = ARM64_WORKAROUND_834220,
+MIDR_RANGE(MIDR_CORTEX_A57, 0x00,
+   (1 << MIDR_VARIANT_SHIFT) | 2),
+},
+#endif
 {},
 };
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 0ec0361..683bcb2 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2388,12 +2388,13 @@ static inline bool hpfar_is_valid(bool s1ptw, uint8_t 
fsc)
  * HPFAR is valid if one of the following cases are true:
  *  1. the stage 2 fault happen during a stage 1 page table walk
  *  (the bit ESR_EL2.S1PTW is set)
- *  2. the fault was due to a translation fault
+ *  2. the fault was due to a translation fault and the processor
+ *  does not carry erratum #8342220
  *
  * Note that technically HPFAR is valid for other cases, but they
  * are currently not supported by Xen.
  */
-return s1ptw || (fsc == FSC_FLT_TRANS);
+return s1ptw || (fsc == FSC_FLT_TRANS && !check_workaround_834220());
 }
 
 static void do_trap_instr_abort_guest(struct cpu_user_regs *regs,
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 5880e77..5e35b4f 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -41,6 +41,7 @@ static inline bool_t check_workaround_##erratum(void) 
  \
 #endif
 
 CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
+CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
 
 #undef CHECK_WORKAROUND_HELPER
 
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index ac6eaf0..66e930f 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -38,8 +38,9 @@
 #define

[Xen-devel] [PATCH v3 1/6] xen/arm: traps: Simplify the switch in do_trap_*_abort_guest

2016-08-04 Thread Julien Grall 
The fault status we care are in the form xx where xx is the lookup
level that gave the fault. We can simplify the code by masking the 2 least
significant bits.

Signed-off-by: Julien Grall 

---
The switch has not been replaced by a simple if because more case
will be added in follow-up patches.

Changes in v2:
- Fix typoes in the commit message
---
 xen/arch/arm/traps.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 0f78d21..b11d2e5 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2387,9 +2387,9 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 int rc;
 register_t gva = READ_SYSREG(FAR_EL2);
 
-switch ( hsr.iabt.ifsc & 0x3f )
+switch ( hsr.iabt.ifsc & ~FSC_LL_MASK )
 {
-case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
+case FSC_FLT_PERM:
 {
 paddr_t gpa;
 const struct npfec npfec = {
@@ -2450,9 +2450,9 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
 return; /* Try again */
 }
 
-switch ( dabt.dfsc & 0x3f )
+switch ( dabt.dfsc & ~FSC_LL_MASK )
 {
-case FSC_FLT_PERM ... FSC_FLT_PERM + 3:
+case FSC_FLT_PERM:
 {
 const struct npfec npfec = {
 .read_access = !dabt.write,
-- 
1.9.1


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

[Xen-devel] [PATCH v3 3/6] xen/arm: Use check_workaround to handle the erratum 766422

2016-08-04 Thread Julien Grall 
Currently, Xen is accessing the stored MIDR everytime it has to check
whether the processor is affected by the erratum 766422.

This could take advantage of the new capability bitfields to detect
whether the processor is affected at boot time.

With this patch, the number of instructions to check the erratum is
going down from ~13 (including 2 loads and a co-processor access) to
~6 instructions (include 1 load).

Signed-off-by: Julien Grall 

---
Changes in v2:
- Update the commit message
---
 xen/arch/arm/cpuerrata.c  | 6 ++
 xen/arch/arm/traps.c  | 3 ++-
 xen/include/asm-arm/arm32/processor.h | 4 
 xen/include/asm-arm/arm64/processor.h | 2 --
 xen/include/asm-arm/cpuerrata.h   | 2 ++
 xen/include/asm-arm/cpufeature.h  | 3 ++-
 xen/include/asm-arm/processor.h   | 2 ++
 7 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 3ac97b3..748e02e 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -17,6 +17,12 @@ is_affected_midr_range(const struct arm_cpu_capabilities 
*entry)
 }
 
 static const struct arm_cpu_capabilities arm_errata[] = {
+{
+/* Cortex-A15 r0p4 */
+.desc = "ARM erratum 766422",
+.capability = ARM32_WORKAROUND_766422,
+MIDR_RANGE(MIDR_CORTEX_A15, 0x04, 0x04),
+},
 #if defined(CONFIG_ARM64_ERRATUM_827319) || \
 defined(CONFIG_ARM64_ERRATUM_824069)
 {
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index b11d2e5..7206a7e 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -46,6 +46,7 @@
 #include "vtimer.h"
 #include 
 #include 
+#include 
 
 /* The base of the stack must always be double-word aligned, which means
  * that both the kernel half of struct cpu_user_regs (which is pushed in
@@ -2481,7 +2482,7 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
  * Erratum 766422: Thumb store translation fault to Hypervisor may
  * not have correct HSR Rt value.
  */
-if ( cpu_has_erratum_766422() && (regs->cpsr & PSR_THUMB) && dabt.write )
+if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) && dabt.write )
 {
 rc = decode_instruction(regs, );
 if ( rc )
diff --git a/xen/include/asm-arm/arm32/processor.h 
b/xen/include/asm-arm/arm32/processor.h
index f41644d..11366bb 100644
--- a/xen/include/asm-arm/arm32/processor.h
+++ b/xen/include/asm-arm/arm32/processor.h
@@ -115,10 +115,6 @@ struct cpu_user_regs
 #define READ_SYSREG(R...)   READ_SYSREG32(R)
 #define WRITE_SYSREG(V, R...)   WRITE_SYSREG32(V, R)
 
-/* Erratum 766422: only Cortex A15 r0p4 is affected */
-#define cpu_has_erratum_766422() \
-(unlikely(current_cpu_data.midr.bits == 0x410fc0f4))
-
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ASM_ARM_ARM32_PROCESSOR_H */
diff --git a/xen/include/asm-arm/arm64/processor.h 
b/xen/include/asm-arm/arm64/processor.h
index fef35a5..b0726ff 100644
--- a/xen/include/asm-arm/arm64/processor.h
+++ b/xen/include/asm-arm/arm64/processor.h
@@ -111,8 +111,6 @@ struct cpu_user_regs
 #define READ_SYSREG(name) READ_SYSREG64(name)
 #define WRITE_SYSREG(v, name) WRITE_SYSREG64(v, name)
 
-#define cpu_has_erratum_766422() 0
-
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ASM_ARM_ARM64_PROCESSOR_H */
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 2982a92..5880e77 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -40,6 +40,8 @@ static inline bool_t check_workaround_##erratum(void) 
  \
 
 #endif
 
+CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
+
 #undef CHECK_WORKAROUND_HELPER
 
 #endif /* __ARM_CPUERRATA_H__ */
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index 78e2263..ac6eaf0 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -37,8 +37,9 @@
 
 #define ARM64_WORKAROUND_CLEAN_CACHE0
 #define ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE1
+#define ARM32_WORKAROUND_766422 2
 
-#define ARM_NCAPS   2
+#define ARM_NCAPS   3
 
 #ifndef __ASSEMBLY__
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 1708253..15bf890 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -46,9 +46,11 @@
 
 #define ARM_CPU_IMP_ARM 0x41
 
+#define ARM_CPU_PART_CORTEX_A15 0xC0F
 #define ARM_CPU_PART_CORTEX_A53 0xD03
 #define ARM_CPU_PART_CORTEX_A57 0xD07
 
+#define MIDR_CORTEX_A15 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A15)
 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A53)
 #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A57)
 
-- 
1.9.1


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

[Xen-devel] [PATCH v3 0/6] xen/arm: Simplify do_trap_*_abort_guest

2016-08-04 Thread Julien Grall 
The current data/instruction abort paths contain unnecessary code and
translate too often a VA to a IPA. This series aim to simplify this path.

Now that the register HPFAR_EL2 is read in some case that can be affected
by the erratum 834220 on Cortex-A57, we need to implement a workaround
for it (see patch #6).

A branch with this series applied can be found on xenbits:
git://xenbits.xen.org/people/julieng/xen-unstable.git branch abort-handlers-v3

Yours sincerely,

Julien Grall (6):
  xen/arm: traps: Simplify the switch in do_trap_*_abort_guest
  xen/arm: Provide macros to help creating workaround helpers
  xen/arm: Use check_workaround to handle the erratum 766422
  xen/arm: traps: MMIO should only be emulated for fault translation
  xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort
handlers
  xen/arm: arm64: Add Cortex-A57 erratum 834220 workaround

 docs/misc/arm/silicon-errata.txt  |  1 +
 xen/arch/arm/Kconfig  | 21 +
 xen/arch/arm/cpuerrata.c  | 15 +++
 xen/arch/arm/traps.c  | 81 ++-
 xen/include/asm-arm/arm32/processor.h |  4 --
 xen/include/asm-arm/arm64/processor.h |  2 -
 xen/include/asm-arm/cpuerrata.h   | 42 ++
 xen/include/asm-arm/cpufeature.h  |  4 +-
 xen/include/asm-arm/processor.h   |  2 +
 9 files changed, 136 insertions(+), 36 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH v3 4/6] xen/arm: traps: MMIO should only be emulated for fault translation

2016-08-04 Thread Julien Grall 
The function do_trap_data_abort_guest assumes that a stage-2 data abort
can only be taken for a translation fault or permission fault today.

Whilst this is true today, it might not be in the future. Rather than
emulating the MMIO for any fault other than the permission one, print
a warning message when the fault is not handled by Xen.

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

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/traps.c | 51 ---
 1 file changed, 28 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 7206a7e..46922eb 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2467,35 +2467,40 @@ static void do_trap_data_abort_guest(struct 
cpu_user_regs *regs,
 /* Trap was triggered by mem_access, work here is done */
 if ( !rc )
 return;
+break;
 }
-break;
-}
-
-if ( dabt.s1ptw )
-goto bad_data_abort;
+case FSC_FLT_TRANS:
+if ( dabt.s1ptw )
+goto bad_data_abort;
 
-/* XXX: Decode the instruction if ISS is not valid */
-if ( !dabt.valid )
-goto bad_data_abort;
+/* XXX: Decode the instruction if ISS is not valid */
+if ( !dabt.valid )
+goto bad_data_abort;
 
-/*
- * Erratum 766422: Thumb store translation fault to Hypervisor may
- * not have correct HSR Rt value.
- */
-if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) && dabt.write )
-{
-rc = decode_instruction(regs, );
-if ( rc )
+/*
+ * Erratum 766422: Thumb store translation fault to Hypervisor may
+ * not have correct HSR Rt value.
+ */
+if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) &&
+ dabt.write )
 {
-gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
-goto bad_data_abort;
+rc = decode_instruction(regs, );
+if ( rc )
+{
+gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
+goto bad_data_abort;
+}
 }
-}
 
-if (handle_mmio())
-{
-advance_pc(regs, hsr);
-return;
+if ( handle_mmio() )
+{
+advance_pc(regs, hsr);
+return;
+}
+break;
+default:
+gprintk(XENLOG_WARNING, "Unsupported DFSC: HSR=%#x DFSC=%#x\n",
+hsr.bits, dabt.dfsc);
 }
 
 bad_data_abort:
-- 
1.9.1


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

[Xen-devel] [PULL 1/1] Xen PCI passthrough: fix passthrough failure when no interrupt pin

2016-08-04 Thread Stefano Stabellini 
From: Bruce Rogers 

Commit 5a11d0f7 mistakenly converted a log message into an error
condition when no pin interrupt is found for the pci device being
passed through. Revert that part of the commit.

Signed-off-by: Bruce Rogers 
Signed-off-by: Stefano Stabellini 
Acked-by: Anthony PERARD 
---
 hw/xen/xen_pt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index f593b04..b6d71bb 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -842,7 +842,7 @@ static void xen_pt_realize(PCIDevice *d, Error **errp)
 goto err_out;
 }
 if (!scratch) {
-error_setg(errp, "no pin interrupt");
+XEN_PT_LOG(d, "no pin interrupt\n");
 goto out;
 }
 
-- 
1.9.1


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

[Xen-devel] xen-20160804-tag

2016-08-04 Thread Stefano Stabellini 
The following changes since commit 09704e6ded83fa0bec14baf32f800f6512156ca0:

  Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging 
(2016-08-04 10:24:27 +0100)

are available in the git repository at:


  git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160804-tag

for you to fetch changes up to 0968c91ce00f42487fb11de5da38e53b5dc6bc7f:

  Xen PCI passthrough: fix passthrough failure when no interrupt pin 
(2016-08-04 10:42:48 -0700)


Xen 2016/08/04


Bruce Rogers (1):
  Xen PCI passthrough: fix passthrough failure when no interrupt pin

 hw/xen/xen_pt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

[Xen-devel] [DRAFT v5] PV Calls protocol design document (former XenSock)

2016-08-04 Thread Stefano Stabellini 
Hi all,

This is the design document of the PV Calls protocol. You can find
prototypes of the Linux frontend and backend drivers here:

git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git pvcalls-5

To use them, make sure to enable CONFIG_PVCALLS in your kernel config
and add "pvcalls=1" to the command line of your DomU Linux kernel. You
also need the toolstack to create the initial xenstore nodes for the
protocol. To do that, please apply the attached patch to libxl (the
patch is based on Xen 4.7.0-rc3) and add "pvcalls=1" to your DomU config
file.

Note that previous versions of the protocols were named XenSock. It has
been renamed for clarity of scope and to avoid confusion with hv_sock
and vsock, which are used for inter-VMs communications.

Cheers,

Stefano

Changes in v5:
- clarify text
- rename id to req_id
- rename sockid to id
- move id to request and response specific fields
- add version node to xenstore

Changes in v4:
- rename xensock to pvcalls

Changes in v3:
- add a dummy element to struct xen_xensock_request to make sure the
  size of the struct is the same on both x86_32 and x86_64

Changes in v2:
- add max-dataring-page-order
- add "Publish backend features and transport parameters" to backend
  xenbus workflow
- update new cmd values
- update xen_xensock_request
- add backlog parameter to listen and binary layout
- add description of new data ring format (interface+data)
- modify connect and accept to reflect new data ring format
- add link to POSIX docs
- add error numbers
- add address format section and relevant numeric definitions
- add explicit mention of unimplemented commands
- add protocol node name
- add xenbus shutdown diagram
- add socket operation

---

# PV Calls Protocol version 1

## Rationale

PV Calls is a paravirtualized protocol that allows the implementation of
a set of POSIX functions in a different domain. The PV Calls frontend
sends POSIX function calls to the backend, which implements them and
returns a value to the frontend.

This version of the document covers networking function calls, such as
connect, accept, bind, release, listen, poll, recvmsg and sendmsg; but
the protocol is meant to be easily extended to cover different sets of
calls. Unimplemented commands return ENOTSUPP.

PV Calls provide the following benefits:
* full visibility of the guest behavior on the backend domain, allowing
  for inexpensive filtering and manipulation of any guest calls
* excellent performance

Specifically, PV Calls for networking offer these advantages:
* guest networking works out of the box with VPNs, wireless networks and
  any other complex configurations on the host
* guest services listen on ports bound directly to the backend domain IP
  addresses
* localhost becomes a secure namespace for inter-VMs communications


## Design

### Xenstore

The frontend and the backend connect to each other exchanging information via
xenstore. The toolstack creates front and back nodes with state
XenbusStateInitialising. The protocol node name is **pvcalls**. There can only
be one PV Calls frontend per domain.

 Frontend XenBus Nodes

port
 Values: 

 The identifier of the Xen event channel used to signal activity
 in the ring buffer.

ring-ref
 Values: 

 The Xen grant reference granting permission for the backend to map
 the sole page in a single page sized ring buffer.

 Backend XenBus Nodes

version
 Values: 

 Protocol version supported by the backend.

max-dataring-page-order
 Values: 

 The maximum supported size of the data ring in units of lb(machine
 pages). (e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages, etc.).

 State Machine

Initialization:

*Front*   *Back*
XenbusStateInitialising   XenbusStateInitialising
- Query virtual device- Query backend device
  properties.   identification data.
- Setup OS device instance.   - Publish backend features
- Allocate and initialize the   and transport parameters
  request ring.  |
- Publish transport parameters   |
  that will be in effect during  V
  this connection.XenbusStateInitWait
 |
 |
 V
   XenbusStateInitialised

  - Query frontend transport parameters.
  - Connect to the request ring and
event channel.
 |
 |
 V
 XenbusStateConnected

 - Query backend device properties.
 - Finalize OS virtual

Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

2016-08-04 Thread Tamas K Lengyel 
On Thu, Aug 4, 2016 at 10:45 AM, Julien Grall  wrote:
> Hello Tamas,
>
> On 04/08/16 17:12, Tamas K Lengyel wrote:
>>
>> On Thu, Aug 4, 2016 at 8:10 AM, George Dunlap 
>> wrote:
>>>
>>> On 03/08/16 17:31, Tamas K Lengyel wrote:

 I understand and that's fine. However, for our components we may
 prefer a different style of workflow on occasion as our definition of
 what constitutes difficult-to-review might be different. That's why
 moving it out from the common p2m codebase should help with avoiding
 this type of arguments in the future and also remove the burden of
 having to have maintainers of other components review it either though
 it doesn't touch anything outside of what we are maintaining.
>>>
>>>
>>> Well you still need to get an ack from someone even if it only touches
>>> code that you maintain.
>>
>>
>> Yes, but we would have been done with this patch days ago as the other
>> maintainer of this component, Razvan, has already acked it days ago.
>
>
> I think this is the first time we had an issue about the workflow. All the
> other comments on separate series were valid and related to interaction with
> the hardware and the rest of the code.
>
> I think this is a good idea to move memaccess code out of the P2M code (see
> [1]), however this should not be done only because we differ about the
> workflow. Whilst I agree you know really well the interaction of memaccess
> with the userspace, I have got some concerns about your knowledge of the ARM
> architecture.
>
> Your last few contributions (SMC trapping, VM event set/get registers and
> memaccess race condition) led to prolonged discussion about how the platform
> behaves.
>

I'm not going to argue about that - I'm certainly still catching up on
many of the nuances of ARM. Having you review parts and point out
corner-cases has been very valuable and it's certainly most welcome.
However, there are times where it seems patches are being blocked on
grounds that are flimsy, like arguing for breaking up the patch into
multiple pieces or adding periods into the end of comments, when us,
the maintainers of the subsystem, have already acked it and would
rather move on to more productive things.

As for the SMC trapping, the patch I sent doesn't introduce any
regression compared to what is already present, yet you blocked it
until further notice. IMHO it would be totally fine to send the SMC
events as they are, including the failed condition SMC checks, and
later tune it to filter those out, yet it doesn't seem we will have
any of that in the short term. For the VM event register setting you
argued either we get/set all registers or none at all when from our
perspective it is not required - again, doesn't introduce any
regression anywhere and only touches code that we are the maintainers
of.

So no, I think this has been an ongoing issue over multiple patches in
the last couple months.

Tamas

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

Re: [Xen-devel] [PATCH v2 20/25] arm/altp2m: Add altp2m paging mechanism.

2016-08-04 Thread Julien Grall 

Hi Sergej,

On 01/08/16 18:10, Sergej Proskurin wrote:

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 12be7c9..628abd7 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c


[...]


@@ -2403,35 +2405,64 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,


[...]


 switch ( fsc )
 {
+case FSC_FLT_TRANS:
+{
+if ( altp2m_active(d) )
+{
+const struct npfec npfec = {
+.insn_fetch = 1,
+.gla_valid = 1,
+.kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt : 
npfec_kind_with_gla
+};
+
+/*
+ * Copy the entire page of the failing instruction into the
+ * currently active altp2m view.
+ */
+if ( altp2m_lazy_copy(v, gpa, gva, npfec, ) )
+return;


I forgot to mention that I think there is a race condition here. If 
multiple vCPU (let say A and B) use the same altp2m, they may fault here.


If vCPU A already fixed the fault, this function will return false and 
continue. So this will lead to inject an instruction abort to the guest.



+
+rc = p2m_mem_access_check(gpa, gva, npfec);
+
+/* Trap was triggered by mem_access, work here is done */
+if ( !rc )
+return;
+}
+
+break;
+}


[...]


@@ -2470,23 +2503,31 @@ static void do_trap_data_abort_guest(struct 
cpu_user_regs *regs,

 switch ( fsc )
 {
-case FSC_FLT_PERM:
+case FSC_FLT_TRANS:
 {
-const struct npfec npfec = {
-.read_access = !dabt.write,
-.write_access = dabt.write,
-.gla_valid = 1,
-.kind = dabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
-};
+if ( altp2m_active(current->domain) )
+{
+const struct npfec npfec = {
+.read_access = !dabt.write,
+.write_access = dabt.write,
+.gla_valid = 1,
+.kind = dabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
+};

-rc = p2m_mem_access_check(info.gpa, info.gva, npfec);
+/*
+ * Copy the entire page of the failing data access into the
+ * currently active altp2m view.
+ */
+if ( altp2m_lazy_copy(v, info.gpa, info.gva, npfec, ) )
+return;


Ditto.


+
+rc = p2m_mem_access_check(info.gpa, info.gva, npfec);
+
+/* Trap was triggered by mem_access, work here is done */
+if ( !rc )
+return;
+}


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 01/25] arm/altp2m: Add first altp2m HVMOP stubs.

2016-08-04 Thread Julien Grall 



On 04/08/16 17:22, Sergej Proskurin wrote:


On 08/04/2016 06:04 PM, Julien Grall wrote:



On 04/08/16 17:01, Sergej Proskurin wrote:

Hi Julien,


On 08/03/2016 06:54 PM, Julien Grall wrote:

Hello Sergej,

On 01/08/16 18:10, Sergej Proskurin wrote:

This commit moves the altp2m-related code from x86 to ARM. Functions
that are no yet supported notify the caller or print a BUG message
stating their absence.

Also, the struct arch_domain is extended with the altp2m_active
attribute, representing the current altp2m activity configuration
of the
domain.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v2: Removed altp2m command-line option: Guard through
HVM_PARAM_ALTP2M.
Removed not used altp2m helper stubs in altp2m.h.
---
 xen/arch/arm/hvm.c   | 79

 xen/include/asm-arm/altp2m.h |  4 +--
 xen/include/asm-arm/domain.h |  3 ++
 3 files changed, 84 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index d999bde..eb524ae 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -32,6 +32,81 @@

 #include 

+#include 
+
+static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+struct xen_hvm_altp2m_op a;
+struct domain *d = NULL;
+int rc = 0;
+
+if ( copy_from_guest(, arg, 1) )
+return -EFAULT;
+
+if ( a.pad1 || a.pad2 ||
+ (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
+ (a.cmd < HVMOP_altp2m_get_domain_state) ||
+ (a.cmd > HVMOP_altp2m_change_gfn) )
+return -EINVAL;
+
+d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
+rcu_lock_domain_by_any_id(a.domain) :
rcu_lock_current_domain();
+
+if ( d == NULL )
+return -ESRCH;
+
+if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
+ (a.cmd != HVMOP_altp2m_set_domain_state) &&
+ !d->arch.altp2m_active )


Why not using altp2m_active(d) here?



I have already changed that within the next patch version. Thank you.


Also this check looks quite racy. What does prevent another CPU to
disable altp2m at the same time? How the code would behave?



Thank you. I will protect this part with the altp2m_lock.


I have noticed that you use the altp2m_lock (it is a spinlock) in
multiple places. So you will serialize a lot of code. Is it fine for you?



I would need to move the lock from altp2m_init_by_id to the outside.
This would not lock much more code as it already does. Apart from that,
since activating/deactivating altp2m on a specific domain should be used
very rarely (including the first time when no altp2m structures are
initialized), it is fine to me. Unless, you would like me to use a
different lock instead?


I don't know, it was an open question. There are a couple of places 
where you may need to add lock atlp2m_lock (such altp2m_copy_lazy), so 
you would serialize all the access. If you care about performance, then 
you may want to use a different lock or method of locking (such as 
read-write-lock).


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] domctl: relax getdomaininfo permissions

2016-08-04 Thread Andrew Cooper 
On 04/08/16 17:07, Jan Beulich wrote:
 On 04.08.16 at 17:55,  wrote:
>> On 04/08/16 16:44, Jan Beulich wrote:
>> On 04.08.16 at 17:22,  wrote:
 On 04/08/16 09:41, Jan Beulich wrote:
> @@ -817,14 +816,22 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>  
>  case XEN_DOMCTL_getdomaininfo:
>  {
> -domid_t dom = op->domain;
> -
> -rcu_read_lock(_read_lock);
> +domid_t dom = DOMID_INVALID;
>  
> -for_each_domain ( d )
> -if ( d->domain_id >= dom )
> +if ( !d )
> +{
> +ret = -EINVAL;
> +if ( op->domain >= DOMID_FIRST_RESERVED )
>  break;
>  
> +rcu_read_lock(_read_lock);
> +
> +dom = op->domain;
> +for_each_domain ( d )
> +if ( d->domain_id >= dom )
> +break;
> +}
> +
>  ret = -ESRCH;
>  if ( d == NULL )
>  goto getdomaininfo_out;
> @@ -839,6 +846,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>  copyback = 1;
>  
>  getdomaininfo_out:
> +if ( dom == DOMID_INVALID )
> +break;
 What is this hunk for?  If you fail the "op->domain >=
 DOMID_FIRST_RESERVED" check we break out of the entire
 XEN_DOMCTL_getdomaininfo case.
>>> If we start out with a non-NULL d, we have to avoid the
>>> rcu_read_unlock() as well as the setting of d to NULL at the
>>> end.
>> Would you mind adding a short comment to that effect?  It is certainly
>> not obvious from just looking at the code.
> How about:
>
> @@ -839,6 +846,10 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>  copyback = 1;
>  
>  getdomaininfo_out:
> +/* When d was non-NULL upon entry, no cleanup is needed. */
> +if ( dom == DOMID_INVALID )
> +break;
> +
>  rcu_read_unlock(_read_lock);
>  d = NULL;
>  break;

Looks good.

~Andrew

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

Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

2016-08-04 Thread Julien Grall 

Hello Tamas,

On 04/08/16 17:12, Tamas K Lengyel wrote:

On Thu, Aug 4, 2016 at 8:10 AM, George Dunlap  wrote:

On 03/08/16 17:31, Tamas K Lengyel wrote:

I understand and that's fine. However, for our components we may
prefer a different style of workflow on occasion as our definition of
what constitutes difficult-to-review might be different. That's why
moving it out from the common p2m codebase should help with avoiding
this type of arguments in the future and also remove the burden of
having to have maintainers of other components review it either though
it doesn't touch anything outside of what we are maintaining.


Well you still need to get an ack from someone even if it only touches
code that you maintain.


Yes, but we would have been done with this patch days ago as the other
maintainer of this component, Razvan, has already acked it days ago.


I think this is the first time we had an issue about the workflow. All 
the other comments on separate series were valid and related to 
interaction with the hardware and the rest of the code.


I think this is a good idea to move memaccess code out of the P2M code 
(see [1]), however this should not be done only because we differ about 
the workflow. Whilst I agree you know really well the interaction of 
memaccess with the userspace, I have got some concerns about your 
knowledge of the ARM architecture.


Your last few contributions (SMC trapping, VM event set/get registers 
and memaccess race condition) led to prolonged discussion about how the 
platform behaves.


Regards,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg00037.html


--
Julien Grall

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

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

2016-08-04 Thread osstest service owner 
flight 99943 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99943/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf afd6b28915cac422294a28033ef83727b27ce216
baseline version:
 ovmf 365a3aab857a2820d36d2ae9b3b62f06230b295a

Last test of basis99933  2016-08-04 01:15:36 Z0 days
Testing same since99943  2016-08-04 14:13:37 Z0 days1 attempts


People who touched revisions under test:
  Daniil Egranov 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH] domctl: relax getdomaininfo permissions

2016-08-04 Thread Ian Jackson 
Jan Beulich writes ("[PATCH] domctl: relax getdomaininfo permissions"):
> Qemu needs access to this for the domain it controls, both due to it
> being used by xc_domain_memory_mapping() (which qemu calls) and the
> explicit use in hw/xenpv/xen_domainbuild.c:xen_domain_poll().
> 
> This at once avoids a for_each_domain() loop when the ID of an
> existing domain gets passed in.
> 
> Reported-by: Marek Marczykowski-Górecki 
> Signed-off-by: Jan Beulich 

This commit message does not seem to say, AFAICT, what the new
permissions check is.  Do you mean to make this available to all
domains, or just to device model domains ?  (I wasn't able to figure
that out easily by reading the patch...)

I don't think we want to expose the getdomaininfo to random other
guests.

Ian.

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

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

2016-08-04 Thread osstest service owner 
flight 99945 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/99945/

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  e67f56bbeccbb2b3e1fbe605b83c08918f19bf7c
baseline version:
 xen  350bc1a9d4ebc03b18a43cdafcb626618caace55

Last test of basis99940  2016-08-04 09:01:30 Z0 days
Testing same since99945  2016-08-04 15:01:35 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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=e67f56bbeccbb2b3e1fbe605b83c08918f19bf7c
+ . ./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 
e67f56bbeccbb2b3e1fbe605b83c08918f19bf7c
+ branch=xen-unstable-smoke
+ revision=e67f56bbeccbb2b3e1fbe605b83c08918f19bf7c
+ . ./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
+ '[' xe67f56bbeccbb2b3e1fbe605b83c08918f19bf7c = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo

Re: [Xen-devel] [PATCH v3] mem_access: sanitize code around sending vm_event request

2016-08-04 Thread Jan Beulich 
>>> On 04.08.16 at 18:16,  wrote:
> On Thu, Aug 4, 2016 at 1:51 AM, Jan Beulich  wrote:
> On 04.08.16 at 08:36,  wrote:
>>> On Thu, Aug 4, 2016 at 12:29 AM, Jan Beulich  wrote:
>>> On 03.08.16 at 20:41,  wrote:
> @@ -1846,11 +1846,15 @@ int hvm_hap_nested_page_fault(paddr_t gpa, 
> unsigned 
> long gla,
>  }
>  }
>
> -if ( p2m_mem_access_check(gpa, gla, npfec, _ptr) )
> -{
> +sync = p2m_mem_access_check(gpa, gla, npfec, _ptr);
> +
> +if ( !sync )
>  fall_through = 1;
> -} else {
> -/* Rights not promoted, vcpu paused, work here is done */
> +else
> +{
> +/*
> + * Rights not promoted (aka. sync event), work here is 
> done
> + */

 Comment style.
>>>
>>> Alright, you had an issue with the pre-existing comment style but you
>>> also have an issue with this. What exactly is the issue here?
>>
>> See ./CODING_STYLE: This is a single line comment, and what was
>> and is missing is the full stop at the end.
> 
> Well, thanks for spotting it but I'm not going to resend resend the
> patch for this. If that's seriously all that's missing and you feel
> really strongly about it things like that have routinely been
> corrected when the patch is applied.

Sure, no problem if I end up committing it. As it stands, it's not fully
acked, so I can't apply it just yet.

Jan


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

Re: [Xen-devel] [PATCH v2 01/25] arm/altp2m: Add first altp2m HVMOP stubs.

2016-08-04 Thread Sergej Proskurin 

On 08/04/2016 06:04 PM, Julien Grall wrote:
>
>
> On 04/08/16 17:01, Sergej Proskurin wrote:
>> Hi Julien,
>>
>>
>> On 08/03/2016 06:54 PM, Julien Grall wrote:
>>> Hello Sergej,
>>>
>>> On 01/08/16 18:10, Sergej Proskurin wrote:
 This commit moves the altp2m-related code from x86 to ARM. Functions
 that are no yet supported notify the caller or print a BUG message
 stating their absence.

 Also, the struct arch_domain is extended with the altp2m_active
 attribute, representing the current altp2m activity configuration
 of the
 domain.

 Signed-off-by: Sergej Proskurin 
 ---
 Cc: Stefano Stabellini 
 Cc: Julien Grall 
 ---
 v2: Removed altp2m command-line option: Guard through
 HVM_PARAM_ALTP2M.
 Removed not used altp2m helper stubs in altp2m.h.
 ---
  xen/arch/arm/hvm.c   | 79
 
  xen/include/asm-arm/altp2m.h |  4 +--
  xen/include/asm-arm/domain.h |  3 ++
  3 files changed, 84 insertions(+), 2 deletions(-)

 diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
 index d999bde..eb524ae 100644
 --- a/xen/arch/arm/hvm.c
 +++ b/xen/arch/arm/hvm.c
 @@ -32,6 +32,81 @@

  #include 

 +#include 
 +
 +static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
 +{
 +struct xen_hvm_altp2m_op a;
 +struct domain *d = NULL;
 +int rc = 0;
 +
 +if ( copy_from_guest(, arg, 1) )
 +return -EFAULT;
 +
 +if ( a.pad1 || a.pad2 ||
 + (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
 + (a.cmd < HVMOP_altp2m_get_domain_state) ||
 + (a.cmd > HVMOP_altp2m_change_gfn) )
 +return -EINVAL;
 +
 +d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
 +rcu_lock_domain_by_any_id(a.domain) :
 rcu_lock_current_domain();
 +
 +if ( d == NULL )
 +return -ESRCH;
 +
 +if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
 + (a.cmd != HVMOP_altp2m_set_domain_state) &&
 + !d->arch.altp2m_active )
>>>
>>> Why not using altp2m_active(d) here?
>>>
>>
>> I have already changed that within the next patch version. Thank you.
>>
>>> Also this check looks quite racy. What does prevent another CPU to
>>> disable altp2m at the same time? How the code would behave?
>>>
>>
>> Thank you. I will protect this part with the altp2m_lock.
>
> I have noticed that you use the altp2m_lock (it is a spinlock) in
> multiple places. So you will serialize a lot of code. Is it fine for you?
>

I would need to move the lock from altp2m_init_by_id to the outside.
This would not lock much more code as it already does. Apart from that,
since activating/deactivating altp2m on a specific domain should be used
very rarely (including the first time when no altp2m structures are
initialized), it is fine to me. Unless, you would like me to use a
different lock instead?

Best regards,
~Sergej


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

Re: [Xen-devel] [PATCH v3] mem_access: sanitize code around sending vm_event request

2016-08-04 Thread Tamas K Lengyel 
On Thu, Aug 4, 2016 at 1:51 AM, Jan Beulich  wrote:
 On 04.08.16 at 08:36,  wrote:
>> On Thu, Aug 4, 2016 at 12:29 AM, Jan Beulich  wrote:
>> On 03.08.16 at 20:41,  wrote:
 @@ -1846,11 +1846,15 @@ int hvm_hap_nested_page_fault(paddr_t gpa, 
 unsigned long gla,
  }
  }

 -if ( p2m_mem_access_check(gpa, gla, npfec, _ptr) )
 -{
 +sync = p2m_mem_access_check(gpa, gla, npfec, _ptr);
 +
 +if ( !sync )
  fall_through = 1;
 -} else {
 -/* Rights not promoted, vcpu paused, work here is done */
 +else
 +{
 +/*
 + * Rights not promoted (aka. sync event), work here is 
 done
 + */
>>>
>>> Comment style.
>>
>> Alright, you had an issue with the pre-existing comment style but you
>> also have an issue with this. What exactly is the issue here?
>
> See ./CODING_STYLE: This is a single line comment, and what was
> and is missing is the full stop at the end.
>

Well, thanks for spotting it but I'm not going to resend resend the
patch for this. If that's seriously all that's missing and you feel
really strongly about it things like that have routinely been
corrected when the patch is applied.

Tamas

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

Re: [Xen-devel] [PATCH v2 03/25] arm/altp2m: Add struct vttbr.

2016-08-04 Thread Julien Grall 



On 04/08/16 17:11, Sergej Proskurin wrote:

diff --git a/xen/include/asm-arm/processor.h
b/xen/include/asm-arm/processor.h
index 15bf890..f8ca18c 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -529,6 +529,22 @@ union hsr {


 };
+
+/* VTTBR: Virtualization Translation Table Base Register */
+struct vttbr {
+union {
+struct {
+u64 baddr :40, /* variable res0: from 0-(x-1) bit */


As mentioned on the previous series, this field is 48 bits for ARMv8
(see ARM D7.2.102 in DDI 0487A.j).



I must have missed it during refactoring. At this point, I will
distinguish between __arm__ and __aarch64__, thank you.


After reading this series I see no point having this union. So I would 
much prefer to see this patch dropped.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [OSSTEST PATCH RFC 04/14] ap-common: add xtf tree

2016-08-04 Thread Ian Jackson 
Andrew Cooper writes ("Re: [OSSTEST PATCH RFC 04/14] ap-common: add xtf tree"):
> On 04/08/16 16:21, Ian Jackson wrote:
> > Andrew Cooper writes ("Re: [OSSTEST PATCH RFC 04/14] ap-common: add xtf 
> > tree"):
> >> We should also clarify the force push criteria.  It is moderately likely
> >> that we get a fix or extension to an existing test which starts showing
> >> up a new bug in the code under test.
> > Can this not be made into a new test ?
> 
> That very much depends, and probably needs deciding on a case by case basis.
> 
> What absolutely shouldn't happen is ending up with test-$FOO,
> test-$FOO-2, test-more-$FOO, test-$FOO-again because that will result in
> the same logical test being split up in ad-hoc ways.  While XTF is
> useful for automation, it is first and foremost a tool for humans.

You mean that this would contort the code for the test ?

Here is another approach that could be used to satisfy osstest's
desire for stability in the meaning of test names: you could
explicitly copy the entire source of the test to a new test name, and
deprecate the old test.  Later, if the old versions of Xen are fixed,
or after they are retired you would delete the old test.

The result would be that the old, less-good, test would still exist
and still detect regressions.  The new, better test, would be seen to
have never passed on old branches.

Force pushing XTF is not an answer to this problem, for two reasons:

Firstly, if the improved test correctly fails on old versions of Xen,
this will appear as a regression in each old version of Xen.  Each old
Xen tree would need to be force pushed, every time this happened.

Secondly, in any case, force pushing XTF might not be necessary.  In
the usual case, one would expect xen-unstable (which is what would
drive the XTF push gate) to be fixed so that the improved test
passes.  So osstest wouldn't spot the issue until it ran the new XTF
with old Xen.

Another possibility would be to have the capability for an single XTF
test execution to return multiple statuses.

Ian.

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

Re: [Xen-devel] [PATCH v2] mem_access: sanitize code around sending vm_event request

2016-08-04 Thread Tamas K Lengyel 
On Thu, Aug 4, 2016 at 8:10 AM, George Dunlap  wrote:
> On 03/08/16 17:31, Tamas K Lengyel wrote:
>> On Wed, Aug 3, 2016 at 10:10 AM, George Dunlap  
>> wrote:
>>> On 03/08/16 16:58, Tamas K Lengyel wrote:
 On Wed, Aug 3, 2016 at 9:44 AM, George Dunlap  
 wrote:
> On 03/08/16 16:40, Tamas K Lengyel wrote:
>> On Wed, Aug 3, 2016 at 9:30 AM, George Dunlap  
>> wrote:
>>> On 03/08/16 16:18, Tamas K Lengyel wrote:
 On Wed, Aug 3, 2016 at 8:41 AM, George Dunlap 
  wrote:
> On 01/08/16 17:52, Tamas K Lengyel wrote:
>> The two functions monitor_traps and mem_access_send_req duplicate 
>> some of the
>> same functionality. The mem_access_send_req however leaves a lot of 
>> the
>> standard vm_event fields to be filled by other functions.
>>
>> Remove mem_access_send_req() completely, making use of 
>> monitor_traps() to put
>> requests into the monitor ring.  This in turn causes some cleanup 
>> around the
>> old callsites of mem_access_send_req(), and on ARM, the introduction 
>> of the
>> __p2m_mem_access_send_req() helper to fill in common mem_access 
>> information.
>> We also update monitor_traps to now include setting the common 
>> vcpu_id field
>> so that all other call-sites can ommit this step.
>>
>> Finally, this change identifies that errors from 
>> mem_access_send_req() were
>> never checked.  As errors constitute a problem with the monitor ring,
>> crashing the domain is the most appropriate action to take.
>>
>> Signed-off-by: Tamas K Lengyel 
>> Reviewed-by: Andrew Cooper 
>
> This appears to be v3, not v2?

 No, it's still just v2.

>
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index 812dbf6..27f9d26 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -1728,13 +1728,8 @@ bool_t p2m_mem_access_check(paddr_t gpa, 
>> unsigned long gla,
>>  if ( req )
>>  {
>>  *req_ptr = req;
>> -req->reason = VM_EVENT_REASON_MEM_ACCESS;
>> -
>> -/* Pause the current VCPU */
>> -if ( p2ma != p2m_access_n2rwx )
>> -req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
>>
>> -/* Send request to mem event */
>> +req->reason = VM_EVENT_REASON_MEM_ACCESS;
>>  req->u.mem_access.gfn = gfn;
>>  req->u.mem_access.offset = gpa & ((1 << PAGE_SHIFT) - 1);
>>  if ( npfec.gla_valid )
>> @@ -1750,23 +1745,10 @@ bool_t p2m_mem_access_check(paddr_t gpa, 
>> unsigned long gla,
>>  req->u.mem_access.flags |= npfec.read_access? 
>> MEM_ACCESS_R : 0;
>>  req->u.mem_access.flags |= npfec.write_access   ? 
>> MEM_ACCESS_W : 0;
>>  req->u.mem_access.flags |= npfec.insn_fetch ? 
>> MEM_ACCESS_X : 0;
>> -req->vcpu_id = v->vcpu_id;
>> -
>> -vm_event_fill_regs(req);
>> -
>> -if ( altp2m_active(v->domain) )
>> -{
>> -req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
>> -req->altp2m_idx = vcpu_altp2m(v).p2midx;
>> -}
>>  }
>>
>> -/* Pause the current VCPU */
>> -if ( p2ma != p2m_access_n2rwx )
>> -vm_event_vcpu_pause(v);
>> -
>> -/* VCPU may be paused, return whether we promoted automatically 
>> */
>> -return (p2ma == p2m_access_n2rwx);
>> +/* Return whether vCPU pause is required (aka. sync event) */
>> +return (p2ma != p2m_access_n2rwx);
>>  }
>>
>>  static inline
>
> p2m-bits:
>
> Acked-by: George Dunlap 
>
> But I agree with Julien -- this patch has several independent changes
> which makes it quite difficult to tell what's going on.  I'm sure it's
> taken the two of us a lot more time together to figure out what is and
> is not happening than it would have for you to break it down into
> several little chunks.
>
> If you're not already familiar with it, I would recommend looking into
> stackgit.  My modus operandi for things like this is to get things
> working in one big patch, then pop it off the stack and apply bits of 
> it
> at a time to make a series.
>

Re: [Xen-devel] [PATCH v2 03/25] arm/altp2m: Add struct vttbr.

2016-08-04 Thread Sergej Proskurin 
Hi Julien,

>> Hello Sergej,
>>
>> Title: s/altp2m/p2m/

I will adapt the titles of all patches, thank you.

>>
>> On 01/08/16 18:10, Sergej Proskurin wrote:
>>> The struct vttbr introduces a simple way to precisely access the
>>> individual fields of the vttbr.
>>
>> I am not sure whether this is really helpful. You don't seem to take
>> often advantage of those fields and the actual accesses don't seem
>> necessary (I will comment on the usage).
>>
>>> ---
>>>  xen/arch/arm/p2m.c  |  8 
>>>  xen/arch/arm/traps.c|  2 +-
>>>  xen/include/asm-arm/p2m.h   |  2 +-
>>>  xen/include/asm-arm/processor.h | 16 
>>>  4 files changed, 22 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>>> index 40a0b80..cbc64a1 100644
>>> --- a/xen/arch/arm/p2m.c
>>> +++ b/xen/arch/arm/p2m.c
>>> @@ -122,7 +122,7 @@ void p2m_restore_state(struct vcpu *n)
>>>  WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
>>>  isb();
>>>
>>> -WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
>>> +WRITE_SYSREG64(p2m->vttbr.vttbr, VTTBR_EL2);
>>>  isb();
>>>
>>>  if ( is_32bit_domain(n->domain) )
>>> @@ -147,10 +147,10 @@ static void p2m_flush_tlb(struct p2m_domain *p2m)
>>>   * VMID. So switch to the VTTBR of a given P2M if different.
>>>   */
>>>  ovttbr = READ_SYSREG64(VTTBR_EL2);
>>> -if ( ovttbr != p2m->vttbr )
>>> +if ( ovttbr != p2m->vttbr.vttbr )
>>>  {
>>>  local_irq_save(flags);
>>> -WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
>>> +WRITE_SYSREG64(p2m->vttbr.vttbr, VTTBR_EL2);
>>>  isb();
>>>  }
>>>
>>> @@ -1293,7 +1293,7 @@ static int p2m_alloc_table(struct domain *d)
>>>
>>>  p2m->root = page;
>>>
>>> -p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid &
>>> 0xff) << 48;
>>> +p2m->vttbr.vttbr = page_to_maddr(p2m->root) |
>>> ((uint64_t)p2m->vmid & 0xff) << 48;
>>>
>>>  /*
>>>   * Make sure that all TLBs corresponding to the new VMID are
>>> flushed
>>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>>> index 06f06e3..12be7c9 100644
>>> --- a/xen/arch/arm/traps.c
>>> +++ b/xen/arch/arm/traps.c
>>> @@ -881,7 +881,7 @@ void vcpu_show_registers(const struct vcpu *v)
>>>  ctxt.ifsr32_el2 = v->arch.ifsr;
>>>  #endif
>>>
>>> -ctxt.vttbr_el2 = v->domain->arch.p2m.vttbr;
>>> +ctxt.vttbr_el2 = v->domain->arch.p2m.vttbr.vttbr;
>>>
>>>  _show_registers(>arch.cpu_info->guest_cpu_user_regs, , 1,
>>> v);
>>>  }
>>> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
>>> index 53c4d78..5c7cd1a 100644
>>> --- a/xen/include/asm-arm/p2m.h
>>> +++ b/xen/include/asm-arm/p2m.h
>>> @@ -33,7 +33,7 @@ struct p2m_domain {
>>>  uint8_t vmid;
>>>
>>>  /* Current Translation Table Base Register for the p2m */
>>> -uint64_t vttbr;
>>> +struct vttbr vttbr;
>>>
>>>  /*
>>>   * Highest guest frame that's ever been mapped in the p2m
>>> diff --git a/xen/include/asm-arm/processor.h
>>> b/xen/include/asm-arm/processor.h
>>> index 15bf890..f8ca18c 100644
>>> --- a/xen/include/asm-arm/processor.h
>>> +++ b/xen/include/asm-arm/processor.h
>>> @@ -529,6 +529,22 @@ union hsr {
>>>
>>>
>>>  };
>>> +
>>> +/* VTTBR: Virtualization Translation Table Base Register */
>>> +struct vttbr {
>>> +union {
>>> +struct {
>>> +u64 baddr :40, /* variable res0: from 0-(x-1) bit */
>>
>> As mentioned on the previous series, this field is 48 bits for ARMv8
>> (see ARM D7.2.102 in DDI 0487A.j).
>>

I must have missed it during refactoring. At this point, I will
distinguish between __arm__ and __aarch64__, thank you.

>>> +res1  :8,
>>> +vmid  :8,
>>> +res2  :8;
>>> +};
>>> +u64 vttbr;
>>> +};
>>> +};
>>> +
>>> +#define INVALID_VTTBR (0UL)
>>> +
>>>  #endif
>>>
>>>  /* HSR.EC == HSR_CP{15,14,10}_32 */
>>>
>>
>> Regards,
>>
>

Best regards,
~Sergej


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

Re: [Xen-devel] [PATCHv2 2/2] xen/privcmd: add ioctls for locking/unlocking hypercall buffers

2016-08-04 Thread Jan Beulich 
>>> On 04.08.16 at 17:16,  wrote:
> Using mlock() for hypercall buffers is not sufficient since mlocked
> pages are still subject to compaction and page migration.  Page
> migration can be prevented by taking additional references to the
> pages.
> 
> Introduce two new ioctls: IOCTL_PRIVCMD_HCALL_BUF_LOCK and
> IOCTL_PRIVCMD_HCALL_BUF_UNLOCK which get and put the necessary page
> references.  The buffers do not need to be page aligned and they may
> overlap with other buffers.  However, it is not possible to partially
> unlock a buffer (i.e., the LOCK/UNLOCK must always be paired).  Any
> locked buffers are automatically unlocked when the file descriptor is
> closed.
> 
> An alternative approach would be to extend the driver with an ioctl to
> populate a VMA with "special", non-migratable pages.  But the
> LOCK/UNLOCK ioctls are more flexible as they allow any page to be used
> for hypercalls (e.g., stack, mmap'd files, etc.).  This could be used
> to minimize bouncing for performance critical hypercalls.
> 
> Signed-off-by: David Vrabel 

Reviewed-by: Jan Beulich 

with two remarks: Do you not care about compat mode callers? In
case you indeed mean to not support them, does the default
handling ensure they will see an error instead of you mis-interpreting
(and overrunning) the presented structure?

> +static struct privcmd_hbuf *privcmd_hbuf_alloc(struct privcmd_hcall_buf *buf)
> +{
> + struct privcmd_hbuf *hbuf;
> + unsigned long start, end, nr_pages;
> + int ret;
> +
> + start = (unsigned long)buf->start & PAGE_MASK;
> + end = ALIGN((unsigned long)buf->start + buf->len, PAGE_SIZE);
> + nr_pages = (end - start) / PAGE_SIZE;

So entry re-use is based on the actual length the caller passed,
while page tracking of course is page granular. Wouldn't it make
sense to re-use entries based on the pages they encompass,
which in particular would mean that two distinct buffers on the
same page would get just a single entry?

Jan


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

Re: [Xen-devel] [PATCH] domctl: relax getdomaininfo permissions

2016-08-04 Thread Jan Beulich 
>>> On 04.08.16 at 17:55,  wrote:
> On 04/08/16 16:44, Jan Beulich wrote:
> On 04.08.16 at 17:22,  wrote:
>>> On 04/08/16 09:41, Jan Beulich wrote:
 @@ -817,14 +816,22 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
  
  case XEN_DOMCTL_getdomaininfo:
  {
 -domid_t dom = op->domain;
 -
 -rcu_read_lock(_read_lock);
 +domid_t dom = DOMID_INVALID;
  
 -for_each_domain ( d )
 -if ( d->domain_id >= dom )
 +if ( !d )
 +{
 +ret = -EINVAL;
 +if ( op->domain >= DOMID_FIRST_RESERVED )
  break;
  
 +rcu_read_lock(_read_lock);
 +
 +dom = op->domain;
 +for_each_domain ( d )
 +if ( d->domain_id >= dom )
 +break;
 +}
 +
  ret = -ESRCH;
  if ( d == NULL )
  goto getdomaininfo_out;
 @@ -839,6 +846,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
  copyback = 1;
  
  getdomaininfo_out:
 +if ( dom == DOMID_INVALID )
 +break;
>>> What is this hunk for?  If you fail the "op->domain >=
>>> DOMID_FIRST_RESERVED" check we break out of the entire
>>> XEN_DOMCTL_getdomaininfo case.
>> If we start out with a non-NULL d, we have to avoid the
>> rcu_read_unlock() as well as the setting of d to NULL at the
>> end.
> 
> Would you mind adding a short comment to that effect?  It is certainly
> not obvious from just looking at the code.

How about:

@@ -839,6 +846,10 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
 copyback = 1;
 
 getdomaininfo_out:
+/* When d was non-NULL upon entry, no cleanup is needed. */
+if ( dom == DOMID_INVALID )
+break;
+
 rcu_read_unlock(_read_lock);
 d = NULL;
 break;

Jan


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

Re: [Xen-devel] [OSSTEST PATCH RFC 06/14] Introduce ts-xtf-build [and 1 more messages]

2016-08-04 Thread Ian Jackson 
Wei Liu writes ("Re: [OSSTEST PATCH RFC 06/14] Introduce ts-xtf-build [and 1 
more messages]"):
> On Thu, Aug 04, 2016 at 04:17:45PM +0100, Ian Jackson wrote:
> > The ability to coinstall multiple different xtfs was my reason for
> > suggesting that the xtfdist should be unpacked into a job-specific
> > subdirectory of /home/osstest.  Obviously that would have to be a
> > directory specific to the _test job_, not the build job.
...
> Note that xtf won't generate any artefacts during runtime.

Yes.

> The test jobs are tied to a specific build job in one flight, so I think
> a build job specific path (as coded) would be the same as test job
> specific path.

That is how the flights are constructed right now, yes.

But it is not in general a good idea to bake too many of these
assumptions into the ts-* scripts.  It's not easy to imagine today why
a single test host might want to be subjected to multiple xtf runs,
but it seems hard to rule out.

For example, in the future, host sharing may mean that different test
jobs for the same flight are run on the same host.  Of course these
wouldn't be your existing multiple xtf jobs (for several reasons).

But if there were ever some xtf test jobs which were different in some
way, then in principle it would be possible for each xtf test job to
specify a differnet xtf build job.  This would mean installing xtf
more than once, from what may be different build jobs or what may be
the same build job.

Whether they are the same build job might not depend on things
specified directly in make-flight and mfi-*.  Automatic job
constructors can reuse jobs from other flights and/or construct new
flights using old ones as templates.  The bisector will choose build
jobs as it sees fit.

If an xtfdist would work if unpacked in a different directory, which
wasn't known at build time, it would be possible for each xtf test job
to unpack its xtfdist in the directory corresponding to the test job.

Thus multiple test jobs with potentially-different xtfs could run
sequentially on the same host.

However, that is not possible.  (Unpacking the same xtf over the top
of itself might not be safe and wouldn't be a good idea.)

Therefore, we will have to remember this limitation if we ever are
likely to come across it.  Fine.

But that does mean that my suggestion for using a job-specific
location for the xtf installed version is pointless.  The
(impossible) scheme depends on a _test_-job-specific location.  There
is no point embedding the _build_ job info in the pathnames.

And as you discover, doing so means that the pathname needs to be made
available in a runvar.  This is pointless complexity.

> If you have different test jobs that depend the same build job, using
> the same build should be fine. If you have test jobs that depend on
> different build job, obviously the path would be different, too.

This seems to contemplate unpacking the same xtf over the top of
itself.  I don't think this is a good idea.  For example, if we ever
do parallel runs, it would break.  It might also overwrite useful logs
etc.

Ian.

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

Re: [Xen-devel] [PATCH v2 01/25] arm/altp2m: Add first altp2m HVMOP stubs.

2016-08-04 Thread Julien Grall 



On 04/08/16 17:01, Sergej Proskurin wrote:

Hi Julien,


On 08/03/2016 06:54 PM, Julien Grall wrote:

Hello Sergej,

On 01/08/16 18:10, Sergej Proskurin wrote:

This commit moves the altp2m-related code from x86 to ARM. Functions
that are no yet supported notify the caller or print a BUG message
stating their absence.

Also, the struct arch_domain is extended with the altp2m_active
attribute, representing the current altp2m activity configuration of the
domain.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v2: Removed altp2m command-line option: Guard through HVM_PARAM_ALTP2M.
Removed not used altp2m helper stubs in altp2m.h.
---
 xen/arch/arm/hvm.c   | 79

 xen/include/asm-arm/altp2m.h |  4 +--
 xen/include/asm-arm/domain.h |  3 ++
 3 files changed, 84 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index d999bde..eb524ae 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -32,6 +32,81 @@

 #include 

+#include 
+
+static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+struct xen_hvm_altp2m_op a;
+struct domain *d = NULL;
+int rc = 0;
+
+if ( copy_from_guest(, arg, 1) )
+return -EFAULT;
+
+if ( a.pad1 || a.pad2 ||
+ (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
+ (a.cmd < HVMOP_altp2m_get_domain_state) ||
+ (a.cmd > HVMOP_altp2m_change_gfn) )
+return -EINVAL;
+
+d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
+rcu_lock_domain_by_any_id(a.domain) :
rcu_lock_current_domain();
+
+if ( d == NULL )
+return -ESRCH;
+
+if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
+ (a.cmd != HVMOP_altp2m_set_domain_state) &&
+ !d->arch.altp2m_active )


Why not using altp2m_active(d) here?



I have already changed that within the next patch version. Thank you.


Also this check looks quite racy. What does prevent another CPU to
disable altp2m at the same time? How the code would behave?



Thank you. I will protect this part with the altp2m_lock.


I have noticed that you use the altp2m_lock (it is a spinlock) in 
multiple places. So you will serialize a lot of code. Is it fine for you?


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 01/25] arm/altp2m: Add first altp2m HVMOP stubs.

2016-08-04 Thread Sergej Proskurin 
Hi Julien,


On 08/03/2016 06:54 PM, Julien Grall wrote:
> Hello Sergej,
>
> On 01/08/16 18:10, Sergej Proskurin wrote:
>> This commit moves the altp2m-related code from x86 to ARM. Functions
>> that are no yet supported notify the caller or print a BUG message
>> stating their absence.
>>
>> Also, the struct arch_domain is extended with the altp2m_active
>> attribute, representing the current altp2m activity configuration of the
>> domain.
>>
>> Signed-off-by: Sergej Proskurin 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>> v2: Removed altp2m command-line option: Guard through HVM_PARAM_ALTP2M.
>> Removed not used altp2m helper stubs in altp2m.h.
>> ---
>>  xen/arch/arm/hvm.c   | 79
>> 
>>  xen/include/asm-arm/altp2m.h |  4 +--
>>  xen/include/asm-arm/domain.h |  3 ++
>>  3 files changed, 84 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
>> index d999bde..eb524ae 100644
>> --- a/xen/arch/arm/hvm.c
>> +++ b/xen/arch/arm/hvm.c
>> @@ -32,6 +32,81 @@
>>
>>  #include 
>>
>> +#include 
>> +
>> +static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
>> +{
>> +struct xen_hvm_altp2m_op a;
>> +struct domain *d = NULL;
>> +int rc = 0;
>> +
>> +if ( copy_from_guest(, arg, 1) )
>> +return -EFAULT;
>> +
>> +if ( a.pad1 || a.pad2 ||
>> + (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
>> + (a.cmd < HVMOP_altp2m_get_domain_state) ||
>> + (a.cmd > HVMOP_altp2m_change_gfn) )
>> +return -EINVAL;
>> +
>> +d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
>> +rcu_lock_domain_by_any_id(a.domain) :
>> rcu_lock_current_domain();
>> +
>> +if ( d == NULL )
>> +return -ESRCH;
>> +
>> +if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
>> + (a.cmd != HVMOP_altp2m_set_domain_state) &&
>> + !d->arch.altp2m_active )
>
> Why not using altp2m_active(d) here?
>

I have already changed that within the next patch version. Thank you.

> Also this check looks quite racy. What does prevent another CPU to
> disable altp2m at the same time? How the code would behave?
>

Thank you. I will protect this part with the altp2m_lock.

Best regards,
~Sergej

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

[Xen-devel] [PATCH v2 1/3] livepach: Add .livepatch.hooks functions and test-case

2016-08-04 Thread Konrad Rzeszutek Wilk 
From: Ross Lagerwall 

Add hook functions which run during patch apply and patch revert.
Hook functions are used by livepatch payloads to manipulate data
structures during patching, etc.

One use case is the XSA91. As Martin mentions it:
"If we have shadow variables, we also need an unload hook to garbage
collect all the variables introduced by a hotpatch to prevent memory
leaks.  Potentially, we also want to pre-reserve memory for static or
existing dynamic objects in the load-hook instead of on the fly.

For testing and debugging, various applications are possible.

In general, the hooks provide flexibility when having to deal with
unforeseen cases, but their application should be rarely required (<
10%)."

Furthermore include a test-case for it.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
---
v12: s/xsplice/livepatch/

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 docs/misc/livepatch.markdown| 23 +
 xen/arch/x86/test/xen_hello_world.c | 36 ++
 xen/common/livepatch.c  | 50 -
 xen/include/xen/livepatch_payload.h | 49 
 4 files changed, 157 insertions(+), 1 deletion(-)
 create mode 100644 xen/include/xen/livepatch_payload.h

diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 89c1050..e0fc5e4 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -340,6 +340,13 @@ When reverting a patch, the hypervisor iterates over each 
`livepatch_func`
 and the core code copies the data from the undo buffer (private internal copy)
 to `old_addr`.
 
+It optionally may contain the address of functions to be called right before
+being applied and after being reverted:
+
+ * `.livepatch.hooks.load` - an array of function pointers.
+ * `.livepatch.hooks.unload` - an array of function pointers.
+
+
 ### Example of .livepatch.funcs
 
 A simple example of what a payload file can be:
@@ -377,6 +384,22 @@ struct livepatch_func livepatch_hello_world = {
 
 Code must be compiled with -fPIC.
 
+### .livepatch.hooks.load and .livepatch.hooks.unload
+
+This section contains an array of function pointers to be executed
+before payload is being applied (.livepatch.funcs) or after reverting
+the payload. This is useful to prepare data structures that need to
+be modified patching.
+
+Each entry in this array is eight bytes.
+
+The type definition of the function are as follow:
+
+
+typedef void (*livepatch_loadcall_t)(void);  
+typedef void (*livepatch_unloadcall_t)(void);   
+
+
 ### .livepatch.depends and .note.gnu.build-id
 
 To support dependencies checking and safe loading (to load the
diff --git a/xen/arch/x86/test/xen_hello_world.c 
b/xen/arch/x86/test/xen_hello_world.c
index 422bdf1..e6a095b 100644
--- a/xen/arch/x86/test/xen_hello_world.c
+++ b/xen/arch/x86/test/xen_hello_world.c
@@ -4,14 +4,50 @@
  */
 
 #include "config.h"
+#include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
 static char hello_world_patch_this_fnc[] = "xen_extra_version";
 extern const char *xen_hello_world(void);
+static unsigned int cnt;
+
+static void apply_hook(void)
+{
+printk(KERN_DEBUG "Hook executing.\n");
+}
+
+static void revert_hook(void)
+{
+printk(KERN_DEBUG "Hook unloaded.\n");
+}
+
+static void hi_func(void)
+{
+printk(KERN_DEBUG "%s: Hi! (called %u times)\n", __func__, ++cnt);
+};
+
+/* If we are sorted we _MUST_ be the last .livepatch.hook section. */
+static void Z_check_fnc(void)
+{
+printk(KERN_DEBUG "%s: Hi func called %u times\n", __func__, cnt);
+BUG_ON(cnt == 0 || cnt > 2);
+cnt = 0; /* Otherwise if you revert, apply, revert the value will be 4! */
+}
+
+LIVEPATCH_LOAD_HOOK(apply_hook);
+LIVEPATCH_UNLOAD_HOOK(revert_hook);
+
+/* Imbalance here. Two load and three unload. */
+
+LIVEPATCH_LOAD_HOOK(hi_func);
+LIVEPATCH_UNLOAD_HOOK(hi_func);
+
+LIVEPATCH_UNLOAD_HOOK(Z_check_fnc);
 
 struct livepatch_func __section(".livepatch.funcs") livepatch_xen_hello_world 
= {
 .version = LIVEPATCH_PAYLOAD_VERSION,
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 5da28a3..f6dbd51 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -70,7 +71,11 @@ struct payload {
 unsigned int nsyms;  /* Nr of entries in .strtab and 
symbols. */
 struct livepatch_build_id id;/* ELFNOTE_DESC(.note.gnu.build-id) 
of the payload. */
 struct livepatch_build_id dep;   /* ELFNOTE_DESC(.livepatch.depends). 
*/
-char name[XEN_LIVEPATCH_NAME_SIZE]; /* Name

[Xen-devel] [PATCH v2 2/3] symbols: Generate an xen-sym.map

2016-08-04 Thread Konrad Rzeszutek Wilk 
You could construct _most_ of the names of the functions
by doing 'nm --defined' but unfortunatly you do not get the
 prefix that is added on in Xen . For example:

$ cat xen-syms.symbols |grep do_domain_pause
0x82d080104920 t domain.c#do_domain_pause
$ nm --defined xen-syms|grep do_domain_pause
82d080104920 t do_domain_pause

This is normally not an issue, but if one is doing livepatching and
wants during build-time verify that the symbols the livepatch payloads
will patch do correspond to the one the hypervisor has built - this helps a lot.

Note that during runtime one can do:
82d080104920 t domain.c#do_domain_pause

But one may not want to build and verify a livepatch on the same host.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc:Ross Lagerwall 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 .gitignore|  1 +
 xen/Makefile  |  4 +++-
 xen/arch/arm/Makefile |  3 +++
 xen/arch/x86/Makefile |  4 
 xen/tools/symbols.c   | 12 +++-
 5 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 9b8dece..51c7283 100644
--- a/.gitignore
+++ b/.gitignore
@@ -286,6 +286,7 @@ tools/flask/policy/policy.conf
 tools/flask/policy/xenpolicy-*
 xen/xen
 xen/xen-syms
+xen/xen-syms.map
 xen/xen.*
 unmodified_drivers/linux-2.6/.tmp_versions
 unmodified_drivers/linux-2.6/*.cmd
diff --git a/xen/Makefile b/xen/Makefile
index ee8ce8e..3198d28 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -62,6 +62,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
ln -f -s $(T)-$(XEN_FULLVERSION)$(Z) $(D)$(BOOT_DIR)/$(T)$(Z)
[ -d "$(D)$(DEBUG_DIR)" ] || $(INSTALL_DIR) $(D)$(DEBUG_DIR)
$(INSTALL_DATA) $(TARGET)-syms 
$(D)$(DEBUG_DIR)/$(T)-syms-$(XEN_FULLVERSION)
+   $(INSTALL_DATA) $(TARGET)-syms.map 
$(D)$(DEBUG_DIR)/$(T)-syms-$(XEN_FULLVERSION).map
$(INSTALL_DATA) $(KCONFIG_CONFIG) 
$(D)$(BOOT_DIR)/$(T)-$(XEN_FULLVERSION).config
if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
[ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
@@ -91,6 +92,7 @@ _uninstall:
rm -f $(D)$(BOOT_DIR)/$(T)-$(XEN_VERSION)$(Z)
rm -f $(D)$(BOOT_DIR)/$(T)$(Z)
rm -f $(D)$(DEBUG_DIR)/$(T)-syms-$(XEN_FULLVERSION)
+   rm -f $(D)$(DEBUG_DIR)/$(T)-syms-$(XEN_FULLVERSION).map
rm -f $(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi
rm -f $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).$(XEN_SUBVERSION).efi
rm -f $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi
@@ -112,7 +114,7 @@ _clean: delete-unfresh-files
$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) clean
find . \( -name "*.o" -o -name ".*.d" \) -exec rm -f {} \;
-   rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi $(TARGET)-syms 
*~ core
+   rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi $(TARGET)-syms 
$(TARGET)-syms.map *~ core
rm -f include/asm-*/asm-offsets.h
rm -f .banner
 
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 23aaf52..4311083 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -99,6 +99,9 @@ $(TARGET)-syms: prelink.o xen.lds 
$(BASEDIR)/common/symbols-dummy.o
$(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
$(NM) -pa --format=sysv $(@D)/.$(@F).1 \
| $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).1.S
+   $(NM) -pa --format=sysv $(@D)/.$(@F).1 \
+   | $(BASEDIR)/tools/symbols --xensyms --sysv --sort \
+   >$(@D)/$(@F).map
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
$(LD) $(LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
$(@D)/.$(@F).1.o -o $@
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index b18f033..10a7022 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -135,6 +135,10 @@ $(TARGET)-syms: prelink.o xen.lds 
$(BASEDIR)/common/symbols-dummy.o
$(NM) -pa --format=sysv $(@D)/.$(@F).1 \
| $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort 
--warn-dup \
>$(@D)/.$(@F).1.S
+   $(NM) -pa --format=sysv $(@D)/.$(@F).1 \
+   | $(BASEDIR)/tools/symbols --xensyms --sysv --sort --warn-dup \
+   >$(@D)/$(@F).map
+   $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
$(LD) $(LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
$(@D)/.$(@F).1.o -o $@
diff --git a/xen/tools/symbols.c b/xen/tools/symbols.c
index 941fbe7..8c5842d 100644
--- a/xen/tools/symbols.c
+++ b/xen/tools/symbols.c
@@ -52,6 +52,7 @@ static

Re: [Xen-devel] [PATCH] domctl: relax getdomaininfo permissions

2016-08-04 Thread Andrew Cooper 
On 04/08/16 16:44, Jan Beulich wrote:
 On 04.08.16 at 17:22,  wrote:
>> On 04/08/16 09:41, Jan Beulich wrote:
>>> @@ -817,14 +816,22 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>>>  
>>>  case XEN_DOMCTL_getdomaininfo:
>>>  {
>>> -domid_t dom = op->domain;
>>> -
>>> -rcu_read_lock(_read_lock);
>>> +domid_t dom = DOMID_INVALID;
>>>  
>>> -for_each_domain ( d )
>>> -if ( d->domain_id >= dom )
>>> +if ( !d )
>>> +{
>>> +ret = -EINVAL;
>>> +if ( op->domain >= DOMID_FIRST_RESERVED )
>>>  break;
>>>  
>>> +rcu_read_lock(_read_lock);
>>> +
>>> +dom = op->domain;
>>> +for_each_domain ( d )
>>> +if ( d->domain_id >= dom )
>>> +break;
>>> +}
>>> +
>>>  ret = -ESRCH;
>>>  if ( d == NULL )
>>>  goto getdomaininfo_out;
>>> @@ -839,6 +846,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>>>  copyback = 1;
>>>  
>>>  getdomaininfo_out:
>>> +if ( dom == DOMID_INVALID )
>>> +break;
>> What is this hunk for?  If you fail the "op->domain >=
>> DOMID_FIRST_RESERVED" check we break out of the entire
>> XEN_DOMCTL_getdomaininfo case.
> If we start out with a non-NULL d, we have to avoid the
> rcu_read_unlock() as well as the setting of d to NULL at the
> end.

Would you mind adding a short comment to that effect?  It is certainly
not obvious from just looking at the code.

~Andrew

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

[Xen-devel] [PATCH v2 3/3] livepatch: Sync cache of build-id before using it first time.

2016-08-04 Thread Konrad Rzeszutek Wilk 
We don't print at bootup time the build-id. The reason is
that xen_build_init and livepatch_init are both __initcall
type routines. This meant that when livepatch_init called
xen_build_id, it would return -ENODATA as build_id_len was
not setup yet (b/c xen_build_init would be called later).

We fix this by calling xen_build_init in livepatch_init which
allows us to print the build-id of the hypervisor.

We also keep xen_build_init as __initcall because build-id
can be built without livepatching being enabled (so
no livepatch_init being called).

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Ross Lagerwall 
Cc: Andrew Cooper 
Cc: Jan Beulich 
---
 xen/common/livepatch.c  | 1 +
 xen/common/version.c| 6 +-
 xen/include/xen/livepatch.h | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index f6dbd51..88a79d8 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1597,6 +1597,7 @@ static int __init livepatch_init(void)
 const void *binary_id;
 unsigned int len;
 
+xen_build_init();
 if ( !xen_build_id(_id, ) )
 printk(XENLOG_INFO LIVEPATCH ": build-id: %*phN\n", len, binary_id);
 
diff --git a/xen/common/version.c b/xen/common/version.c
index 0f96849..4114664 100644
--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -117,11 +117,15 @@ int xen_build_id_check(const Elf_Note *n, unsigned int 
n_sz,
 return 0;
 }
 
-static int __init xen_build_init(void)
+int __init xen_build_init(void)
 {
 const Elf_Note *n = __note_gnu_build_id_start;
 unsigned int sz;
 
+/* We may have been called already. */
+if ( build_id_len )
+return 0;
+
 /* --build-id invoked with wrong parameters. */
 if ( __note_gnu_build_id_end <= [0] )
 return -ENODATA;
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index ed49843..cfc9601 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -44,7 +44,7 @@ unsigned long livepatch_symbols_lookup_by_name(const char 
*symname);
 bool_t is_patch(const void *addr);
 int xen_build_id_check(const Elf_Note *n, unsigned int n_sz,
const void **p, unsigned int *len);
-
+void xen_build_init(void);
 /* Arch hooks. */
 int arch_livepatch_verify_elf(const struct livepatch_elf *elf);
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
-- 
2.5.5


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

[Xen-devel] [PATCH v1] Livepatch patches for v4.8 (v1)

2016-08-04 Thread Konrad Rzeszutek Wilk 
Attached are thee patches for v4.8. The first one had been posted
during v4.7 but we decided to punt to v4.8:
 [PATCH v2 1/3] livepach: Add .livepatch.hooks functions and test-case

The other one is to make it easier to make sure that the livepatch
symbols match with the hypervisor one and not have to figure this
out when loading the payloads:
 [PATCH v2 2/3] symbols: Generate an xen-sym.map

And the last one is a bug-fix:
 [PATCH v2 3/3] livepatch: Sync cache of build-id before using it


 .gitignore  |  1 +
 docs/misc/livepatch.markdown| 23 +
 xen/Makefile|  4 ++-
 xen/arch/arm/Makefile   |  3 +++
 xen/arch/x86/Makefile   |  4 +++
 xen/arch/x86/test/xen_hello_world.c | 36 ++
 xen/common/livepatch.c  | 51 -
 xen/common/version.c|  6 -
 xen/include/xen/livepatch.h |  2 +-
 xen/include/xen/livepatch_payload.h | 49 +++
 xen/tools/symbols.c | 12 -
 11 files changed, 186 insertions(+), 5 deletions(-)


Konrad Rzeszutek Wilk (2):
  symbols: Generate an xen-sym.map
  livepatch: Sync cache of build-id before using it first time.

Ross Lagerwall (1):
  livepach: Add .livepatch.hooks functions and test-case


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

Re: [Xen-devel] [PATCH] domctl: relax getdomaininfo permissions

2016-08-04 Thread Jan Beulich 
>>> On 04.08.16 at 17:22,  wrote:
> On 04/08/16 09:41, Jan Beulich wrote:
>> @@ -817,14 +816,22 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>>  
>>  case XEN_DOMCTL_getdomaininfo:
>>  {
>> -domid_t dom = op->domain;
>> -
>> -rcu_read_lock(_read_lock);
>> +domid_t dom = DOMID_INVALID;
>>  
>> -for_each_domain ( d )
>> -if ( d->domain_id >= dom )
>> +if ( !d )
>> +{
>> +ret = -EINVAL;
>> +if ( op->domain >= DOMID_FIRST_RESERVED )
>>  break;
>>  
>> +rcu_read_lock(_read_lock);
>> +
>> +dom = op->domain;
>> +for_each_domain ( d )
>> +if ( d->domain_id >= dom )
>> +break;
>> +}
>> +
>>  ret = -ESRCH;
>>  if ( d == NULL )
>>  goto getdomaininfo_out;
>> @@ -839,6 +846,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>>  copyback = 1;
>>  
>>  getdomaininfo_out:
>> +if ( dom == DOMID_INVALID )
>> +break;
> 
> What is this hunk for?  If you fail the "op->domain >=
> DOMID_FIRST_RESERVED" check we break out of the entire
> XEN_DOMCTL_getdomaininfo case.

If we start out with a non-NULL d, we have to avoid the
rcu_read_unlock() as well as the setting of d to NULL at the
end.

Jan


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

Re: [Xen-devel] [OSSTEST PATCH RFC 04/14] ap-common: add xtf tree

2016-08-04 Thread Andrew Cooper 
On 04/08/16 16:21, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [OSSTEST PATCH RFC 04/14] ap-common: add xtf 
> tree"):
>> On 04/08/16 12:49, Ian Jackson wrote:
>>> Andrew, do you want to have osstest run its xtf push gate between
>>> `staging' and `master' branches of xtf, or do you want to just push to
>>> xtf master, and have a separate `osstest/tested' or some such branch
>>> for the osstest push gate output ?
>> The latter please.
> NP.
>
>> We should also clarify the force push criteria.  It is moderately likely
>> that we get a fix or extension to an existing test which starts showing
>> up a new bug in the code under test.
> Can this not be made into a new test ?

That very much depends, and probably needs deciding on a case by case basis.

What absolutely shouldn't happen is ending up with test-$FOO,
test-$FOO-2, test-more-$FOO, test-$FOO-again because that will result in
the same logical test being split up in ad-hoc ways.  While XTF is
useful for automation, it is first and foremost a tool for humans.

~Andrew

>
> osstest would like such an extension to an existing test to be a new
> `step' (in osstest terminology).  That would mean that the fact that
> it fails with old versions of Xen can be seen not to be a regression.
>
> Ie, osstest would like to be able to distinguish:
>   * this version of xtf didn't have the new part of the test
>   * old part of the test failed (and presumably new part was not run)
>   * old part succeeded and new part failed
>   * both parts were run and succeeded
>
>> In this case, OSSTest will identify a regression, but it isn't a
>> regression isn't in XTF, nor is it reasonable to call it a regression in
>> Xen.  We would absolutely want to fix it in upstream, but there are no
>> guarentees that the bugfix would be suitable for backport to older trees.
> Indeed.
>
> Ian.


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

Re: [Xen-devel] [OSSTEST PATCH RFC 06/14] Introduce ts-xtf-build [and 1 more messages]

2016-08-04 Thread Wei Liu 
On Thu, Aug 04, 2016 at 04:17:45PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[OSSTEST PATCH RFC 06/14] Introduce ts-xtf-build"):
> > > > +sub stash () {
> > > > +built_stash($ho, $builddir, "xtfdist", "xtfdist");
> > > > +}
> > > 
> > > Can you post a tar zvvtf of a sample xtfdist tarball ?
> > 
> > drwxr-xr-x osstest/osstest   0 2016-08-04 08:30 home/
> > drwxr-xr-x osstest/osstest   0 2016-08-04 08:30 home/osstest/
> ...
> > -rw-r--r-- osstest/osstest 563 2016-08-04 08:30 
> > home/osstest/build.66916.build-amd64-xtf/xtf/tests/xsa-168/test-hvm64-xsa-168.cfg
> 
> This is quite odd.
> 
> AFAICT this means that the original path of that file, as generated by
> the invocation of `make install DESTDIR=...', was:
> 
>  
> /home/osstest/build.66916/build-amd64-xtf/xtf/xtfdist/home/osstest/build.66916/build-amd64-xtf/xtf/xtfdist/tests/xsa-168/test-hvm64-xsa-168.cfg
> 
> This seems perverse.  Read on...
> 
> Wei Liu writes ("Re: [OSSTEST PATCH RFC 08/14] Introduce ts-xtf-install"):
> > On Thu, Aug 04, 2016 at 12:54:41PM +0100, Ian Jackson wrote:
> > > Surely the extracting job should just put it wherever it wants.
> > 
> > No, it can't.
> > 
> > It has to be in the location specified during build because there are
> > hard-coded paths inside test case config files.
> 
> That's a bit sad.  But, fine.
> 
> But, in that case it is not possible to coinstall multiple different
> versions of xtf.
> 
> The ability to coinstall multiple different xtfs was my reason for
> suggesting that the xtfdist should be unpacked into a job-specific
> subdirectory of /home/osstest.  Obviously that would have to be a
> directory specific to the _test job_, not the build job.
> 

I'm confused.

Note that xtf won't generate any artefacts during runtime.

The test jobs are tied to a specific build job in one flight, so I think
a build job specific path (as coded) would be the same as test job
specific path.

If you have different test jobs that depend the same build job, using
the same build should be fine. If you have test jobs that depend on
different build job, obviously the path would be different, too.

But I guess this point is moot now because I'm fine with your suggestion
below.

> As I say, if xtfdists aren't portable to different install locations,
> then this is not possible and there is no reason not to use a fixed
> install location.
> 
> That is:
> 
>   Build host:
> 
>  cd /home/osstest/build.66916.build-amd64-xtf/xtf
>  make xtfdir=/home/xtf
>  make xtfdir=/home/xtf DESTDIR=`pwd`/xtfdist
> 
>   Resulting in, on build host, for example:
> 
>  
> /home/osstest/build.66916.build-amd64-xtf/xtf/xtfdist/home/xtf/tests/xsa-168/test-hvm64-xsa-168.cfg
> 
>   Note that this does not actually create anything in /home/xtf on the
>   build host.  So different builds do not interfere with each other.
> 
>   Test host, for example:
> 
>  /home/xtf/tests/xsa-168/test-hvm64-xsa-168.cfg
> 
> Then there is no need for the xtfdir runvar, because the answer is
> always the same.
> 
> Thanks,
> Ian.

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

Re: [Xen-devel] [OSSTEST PATCH RFC 01/14] ts-xen-build: always compile in FEP support

2016-08-04 Thread Ian Jackson 
Wei Liu writes ("Re: [Xen-devel] [OSSTEST PATCH RFC 01/14] ts-xen-build: always 
compile in FEP support"):
> On Thu, Aug 04, 2016 at 04:22:58PM +0100, Ian Jackson wrote:
> > Why not just report the fep test as having failed, in old branches,
> > and then carry on ?
> 
> How to do that? If the test script fails, surely sg-run-job would not
> run the rest of the job.

sg-run-job can be told that this script failing is not fatal.  This is
done by calling spawn-ts and reap-ts explicitly.  See test-guest-migr
for an example.

> Or do you mean the script should still pass, but print the result in the
> log?

No.

>  But then, how to express the expected result for different
> branches? Runvar? Script argument?

You do not need to encode this in osstest at all.  The database will
record that FEP never worked for Xen 4.4 the same way that it records
that ARM migration never worked for 4.7.  It will show up as `fail
never pass'.

Ian.

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

Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabled by default

2016-08-04 Thread Jan Beulich 
>>> On 04.08.16 at 17:08,  wrote:
> crash> x /130x 0x830bd0da1000
> 0x830bd0da1000: 0x000e  0x
> 0x830bd0da1010: 0x  0x
> 0x830bd0da1020: 0x  0x
> 0x830bd0da1030: 0x  0x
> 0x830bd0da1040: 0x  0x
> 0x830bd0da1050: 0x  0x
> 0x830bd0da1060: 0x  0x
> 0x830bd0da1070: 0x  0x000bd0da3000
> 0x830bd0da1080: 0x000c17e36000  0x
> 0x830bd0da1090: 0x  0x
> 0x830bd0da10a0: 0xe7512000  0xe7513000
> 0x830bd0da10b0: 0x000bd0da  0x
> 0x830bd0da10c0: 0x  0x
> 0x830bd0da10d0: 0x  0x006fedea809b
> 0x830bd0da10e0: 0x0001a379e000  0x000610f9101e
> 0x830bd0da10f0: 0x  0x
> 0x830bd0da1100: 0x  0x0007010600070106
> 0x830bd0da1110: 0x  0x
> 0x830bd0da1120: 0x006bb6a075fa  0x00060042003f
> 0x830bd0da1130: 0x  0x000fefff
> 0x830bd0da1140: 0x  0x51ff
> 0x830bd0da1150: 0x0041  0x
> 0x830bd0da1160: 0x  0x000c
> 0x830bd0da1170: 0x  0x
> 0x830bd0da1180: 0x0001  0x
> 0x830bd0da1190: 0x0008  0x
> 0x830bd0da11a0: 0x0001  0x0096
> 0x830bd0da11b0: 0x82d0802bc208  0x806f6dbc
> 0x830bd0da11c0: 0x  0x0400
> 0x830bd0da11d0: 0x80550f34  0xf0e48161
> 0x830bd0da11e0: 0x0246  0x
> 0x830bd0da11f0: 0xf79c3000  0x804de6f0
> 0x830bd0da1200: 0x0023  0x
> 0x830bd0da1210: 0x00c0f300  0x0008
> 0x830bd0da1220: 0x  0x00c09b00
> 0x830bd0da1230: 0x0010  0x
> 0x830bd0da1240: 0x00c09300  0x0023
> 0x830bd0da1250: 0x  0x00c0f300
> 0x830bd0da1260: 0x0030  0xffdff000
> 0x830bd0da1270: 0x00c093001fff  0x
> 0x830bd0da1280: 0x  0x01c0
> 0x830bd0da1290: 0x  0x
> 0x830bd0da12a0: 0x01c0  0x0028
> 0x830bd0da12b0: 0x80042000  0x8b0020ab
> 0x830bd0da12c0: 0x8003f000  0x8003f400
> 0x830bd0da12d0: 0x07ff03ff  0x8001003b
> 0x830bd0da12e0: 0x00039000  0x26d9
> 0x830bd0da12f0: 0xdc3c  0x
> 0x830bd0da1300: 0xe008  0x
> 0x830bd0da1310: 0x  0xe040
> 0x830bd0da1320: 0x050100070406  0x
> 0x830bd0da1330: 0x  0x80050033
> 0x830bd0da1340: 0x0001bd665000  0x26e0
> 0x830bd0da1350: 0x  0x
> 0x830bd0da1360: 0x830c17e38c80  0x830617fd3000
> 0x830bd0da1370: 0x830617fcf000  0x830617fd7fc0
> 0x830bd0da1380: 0x82d08024e150  0x830617fd7f90
> 0x830bd0da1390: 0x82d080201bb0  0xe008
> 0x830bd0da13a0: 0x0060  0x
> 0x830bd0da13b0: 0x  0x
> 0x830bd0da13c0: 0x  0x
> 0x830bd0da13d0: 0x8001003b  0x06d9
> 0x830bd0da13e0: 0x  0x
> 0x830bd0da13f0: 0x  0x
> 0x830bd0da1400: 0x  0x
> 
> I don't quite understand the Intel developer manual at this point. How do I 
> have to read this data?

I don't think this is formally specified anywhere (publicly). After all that's
why one has to use vmread/vmwrite. 

> Since if ( !(v->arch.hvm_vmx.host_cr0 & X86_CR0_TS) ) must be true I assume 
> the 
> __vmwrite tries to | 0x8 into the host_cr0 leading to the 0x80050033 
> for the current host_cr0 (

Re: [Xen-devel] [OSSTEST PATCH RFC 11/14] Introduce ts-xtf-run

2016-08-04 Thread Ian Jackson 
Wei Liu writes ("Re: [OSSTEST PATCH RFC 11/14] Introduce ts-xtf-run"):
> On Thu, Aug 04, 2016 at 01:19:15PM +0100, Ian Jackson wrote:
> > Please arrange that all problems which ought to cause "record step as
> > `fail' and run no more tests" are handled by:
> >
> > - having the code which detects the problem calling die
> > - that die being caught by a single eval instance
> > - the code after the eval handling all exceptions that way
> > 
> 
> I will see what I can do regarding this. I'm not very familiar with
> perl, will need to read some docs first.

Sure.  I'm happy to handwave IRL or on IRC if you prefer.

If you want some full-on examples of the use of eval and indeed die,
there are:
  ts-logs-capture  (several smallish examples)
  cs-bisection-step
  Osstest::db_retry(subrefs, hairy)
  Osstest::Executive::alloc_resources  (one nested inside another)

> > Also there is a latent bug here.  You have xtf_result_defined accept
> > exit statuses 1 and 2, but those are actually not defined exit
> > statuses for the xtf runner.
> 
> FAOD, 1 and 2 are defined xtf exit statuses -- reserved for anything
> python interpreter related. But I think this is going to be moot because
> they are going to be mapped to fail anyway.

What I meant was that exit statuses 1 and 2 mean `it has all gone
horribly wrong'.  They are not supposed to occur.  (They may be
`defined' by the xtf runner spec, but only to reserve them.)

> The XTF exit status is already available in the log, as is the
> osstest result (in substep status line).

Oh good.  Sorry for quibbling, then.

> I guess you want them on the same line? One logm would do.

But, yes, that would be nice.

> > It might be worth recording the environment for each test, for the
> > log, unless the xtf runner prints that.
> 
> It is encoded in test case name.

Jolly good.

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH RFC 01/14] ts-xen-build: always compile in FEP support

2016-08-04 Thread Wei Liu 
On Thu, Aug 04, 2016 at 04:22:58PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [OSSTEST PATCH RFC 01/14] ts-xen-build: 
> always compile in FEP support"):
> > On Thu, Aug 04, 2016 at 02:28:01PM +0100, Andrew Cooper wrote:
> > > However, it might be useful to confirm that fep doesn't accidentally
> > > disappear, or a load of tests which were previously passing will turn
> > > into skip, which I presume OSSTest isn't going to be overly concerned 
> > > with.
> 
> Yes, indeed.  That should be detected by spotting that the fep test
> fails.
> 
> > OK. I will adjust that test to check a runvar for expected result.
> 
> No, that is not the right approach.
> 
> > For 4.8 onwards, the expected result of fep test is SUCCESS and for (to
> > be implemented) older versions the expected result is ERROR (or FAILURE?
> > Doesn't matter from OSSTest's PoV) because branches for older versions
> > always have FEP to be off.
> 
> Why not just report the fep test as having failed, in old branches,
> and then carry on ?
> 

How to do that? If the test script fails, surely sg-run-job would not
run the rest of the job.

Or do you mean the script should still pass, but print the result in the
log? But then, how to express the expected result for different
branches? Runvar? Script argument?

Wei.

> Ian.

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

[Xen-devel] [PATCHv2 2/2] xen/privcmd: add ioctls for locking/unlocking hypercall buffers

2016-08-04 Thread David Vrabel 
Using mlock() for hypercall buffers is not sufficient since mlocked
pages are still subject to compaction and page migration.  Page
migration can be prevented by taking additional references to the
pages.

Introduce two new ioctls: IOCTL_PRIVCMD_HCALL_BUF_LOCK and
IOCTL_PRIVCMD_HCALL_BUF_UNLOCK which get and put the necessary page
references.  The buffers do not need to be page aligned and they may
overlap with other buffers.  However, it is not possible to partially
unlock a buffer (i.e., the LOCK/UNLOCK must always be paired).  Any
locked buffers are automatically unlocked when the file descriptor is
closed.

An alternative approach would be to extend the driver with an ioctl to
populate a VMA with "special", non-migratable pages.  But the
LOCK/UNLOCK ioctls are more flexible as they allow any page to be used
for hypercalls (e.g., stack, mmap'd files, etc.).  This could be used
to minimize bouncing for performance critical hypercalls.

Signed-off-by: David Vrabel 
---
v2:
- Only take one reference per buffer.
- Interate over the tree to unlock/free all buffers.
- Max 1GB size per buffer.
- Only use one memory allocation per buffer.
- Fix overflow issues in privcmd_hbuf_compare().
- Return -ENXIO when unlocking an unlocked buffer.
---
 drivers/xen/privcmd.c  | 216 +
 include/uapi/xen/privcmd.h |  38 
 2 files changed, 254 insertions(+)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ac76bc4..5419b31 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -43,6 +44,19 @@ MODULE_LICENSE("GPL");
 
 #define PRIV_VMA_LOCKED ((void *)1)
 
+struct privcmd_data {
+   struct rb_root hbuf_root;
+   struct mutex hbuf_mutex;
+};
+
+struct privcmd_hbuf {
+   struct rb_node node;
+   struct privcmd_hcall_buf buf;
+   unsigned int count;
+   unsigned int nr_pages;
+   struct page *pages[0];
+};
+
 static int privcmd_vma_range_is_mapped(
struct vm_area_struct *vma,
unsigned long addr,
@@ -548,9 +562,175 @@ out_unlock:
goto out;
 }
 
+static void privcmd_hbuf_free(struct privcmd_hbuf *hbuf)
+{
+   unsigned int i;
+
+   for (i = 0; i < hbuf->nr_pages; i++)
+   put_page(hbuf->pages[i]);
+
+   kfree(hbuf);
+}
+
+static struct privcmd_hbuf *privcmd_hbuf_alloc(struct privcmd_hcall_buf *buf)
+{
+   struct privcmd_hbuf *hbuf;
+   unsigned long start, end, nr_pages;
+   int ret;
+
+   start = (unsigned long)buf->start & PAGE_MASK;
+   end = ALIGN((unsigned long)buf->start + buf->len, PAGE_SIZE);
+   nr_pages = (end - start) / PAGE_SIZE;
+
+   hbuf = kzalloc(sizeof(*hbuf) + nr_pages * sizeof(hbuf->pages[0]),
+  GFP_KERNEL);
+   if (!hbuf)
+   return ERR_PTR(-ENOMEM);
+
+   /*
+* Take a reference to each page, this will prevent swapping
+* and page migration.
+*/
+   ret = get_user_pages_fast(start, nr_pages, 1, hbuf->pages);
+   if (ret < 0)
+   goto error;
+
+   hbuf->buf = *buf;
+   hbuf->count = 1;
+   hbuf->nr_pages = ret;
+
+   if (hbuf->nr_pages != nr_pages) {
+   ret = -ENOMEM;
+   goto error;
+   }
+
+   return hbuf;
+
+  error:
+   privcmd_hbuf_free(hbuf);
+   return ERR_PTR(ret);
+}
+
+static int privcmd_hbuf_compare(struct privcmd_hcall_buf *a,
+   struct privcmd_hcall_buf *b)
+{
+   if (b->start > a->start)
+   return 1;
+   if (b->start < a->start)
+   return -1;
+   if (b->len > a->len)
+   return 1;
+   if (b->len < a->len)
+   return -1;
+   return 0;
+}
+
+static int privcmd_hbuf_insert(struct privcmd_data *priv,
+   struct privcmd_hcall_buf *buf)
+{
+   struct rb_node **new = >hbuf_root.rb_node, *parent = NULL;
+   struct privcmd_hbuf *hbuf;
+
+   /* Figure out where to put new node */
+   while (*new) {
+   struct privcmd_hbuf *this = container_of(*new, struct 
privcmd_hbuf, node);
+   int result = privcmd_hbuf_compare(buf, >buf);
+
+   parent = *new;
+   if (result < 0)
+   new = &(*new)->rb_left;
+   else if (result > 0)
+   new = &(*new)->rb_right;
+   else {
+   this->count++;
+   return 0;
+   }
+   }
+
+   /* Allocate and insert a new node. */
+   hbuf = privcmd_hbuf_alloc(buf);
+   if (IS_ERR(hbuf))
+   return PTR_ERR(hbuf);
+
+   rb_link_node(>node, parent, new);
+   rb_insert_color(>node, >hbuf_root);
+
+   return 0;
+}
+
+static int privcmd_hbuf_remove(struct privcmd_data *priv,
+  struct

Re: [Xen-devel] [PATCH] domctl: relax getdomaininfo permissions

2016-08-04 Thread Andrew Cooper 
On 04/08/16 09:41, Jan Beulich wrote:
> Qemu needs access to this for the domain it controls, both due to it
> being used by xc_domain_memory_mapping() (which qemu calls) and the
> explicit use in hw/xenpv/xen_domainbuild.c:xen_domain_poll().
>
> This at once avoids a for_each_domain() loop when the ID of an
> existing domain gets passed in.
>
> Reported-by: Marek Marczykowski-Górecki 
> Signed-off-by: Jan Beulich 
> ---
> I know there had been an alternative patch suggestion, but that one
> doesn't seem have seen a formal submission so far, so here is my
> original proposal.
>
> I wonder what good the duplication of the returned domain ID does: I'm
> tempted to remove the one in the command-specific structure. Does
> anyone have insight into why it was done that way?
>
> I further wonder why we have XSM_OTHER: The respective conversion into
> other XSM_* values in xsm/dummy.h could as well move into the callers,
> making intentions more obvious when looking at the actual code.
>
> --- a/tools/flask/policy/modules/xen.if
> +++ b/tools/flask/policy/modules/xen.if
> @@ -149,7 +149,7 @@ define(`device_model', `
>   create_channel($2, $1, $2_channel)
>   allow $1 $2_channel:event create;
>  
> - allow $1 $2_target:domain shutdown;
> + allow $1 $2_target:domain { getdomaininfo shutdown };
>   allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack 
> };
>   allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl 
> irqlevel pciroute pcilevel cacheattr send_irq };
>  ')
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -396,14 +396,13 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>  switch ( op->cmd )
>  {
>  case XEN_DOMCTL_createdomain:
> -case XEN_DOMCTL_getdomaininfo:
>  case XEN_DOMCTL_test_assign_device:
>  case XEN_DOMCTL_gdbsx_guestmemio:
>  d = NULL;
>  break;
>  default:
>  d = rcu_lock_domain_by_id(op->domain);
> -if ( d == NULL )
> +if ( !d && op->cmd != XEN_DOMCTL_getdomaininfo )
>  return -ESRCH;
>  }
>  
> @@ -817,14 +816,22 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>  
>  case XEN_DOMCTL_getdomaininfo:
>  {
> -domid_t dom = op->domain;
> -
> -rcu_read_lock(_read_lock);
> +domid_t dom = DOMID_INVALID;
>  
> -for_each_domain ( d )
> -if ( d->domain_id >= dom )
> +if ( !d )
> +{
> +ret = -EINVAL;
> +if ( op->domain >= DOMID_FIRST_RESERVED )
>  break;
>  
> +rcu_read_lock(_read_lock);
> +
> +dom = op->domain;
> +for_each_domain ( d )
> +if ( d->domain_id >= dom )
> +break;
> +}
> +
>  ret = -ESRCH;
>  if ( d == NULL )
>  goto getdomaininfo_out;
> @@ -839,6 +846,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>  copyback = 1;
>  
>  getdomaininfo_out:
> +if ( dom == DOMID_INVALID )
> +break;

What is this hunk for?  If you fail the "op->domain >=
DOMID_FIRST_RESERVED" check we break out of the entire
XEN_DOMCTL_getdomaininfo case.

(I think - but I am finding this logic surprisingly difficult to follow.)

~Andrew

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

Re: [Xen-devel] [OSSTEST PATCH RFC 01/14] ts-xen-build: always compile in FEP support

2016-08-04 Thread Ian Jackson 
Wei Liu writes ("Re: [Xen-devel] [OSSTEST PATCH RFC 01/14] ts-xen-build: always 
compile in FEP support"):
> On Thu, Aug 04, 2016 at 02:28:01PM +0100, Andrew Cooper wrote:
> > However, it might be useful to confirm that fep doesn't accidentally
> > disappear, or a load of tests which were previously passing will turn
> > into skip, which I presume OSSTest isn't going to be overly concerned with.

Yes, indeed.  That should be detected by spotting that the fep test
fails.

> OK. I will adjust that test to check a runvar for expected result.

No, that is not the right approach.

> For 4.8 onwards, the expected result of fep test is SUCCESS and for (to
> be implemented) older versions the expected result is ERROR (or FAILURE?
> Doesn't matter from OSSTest's PoV) because branches for older versions
> always have FEP to be off.

Why not just report the fep test as having failed, in old branches,
and then carry on ?

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH RFC 04/14] ap-common: add xtf tree

2016-08-04 Thread Ian Jackson 
Andrew Cooper writes ("Re: [OSSTEST PATCH RFC 04/14] ap-common: add xtf tree"):
> On 04/08/16 12:49, Ian Jackson wrote:
> > Andrew, do you want to have osstest run its xtf push gate between
> > `staging' and `master' branches of xtf, or do you want to just push to
> > xtf master, and have a separate `osstest/tested' or some such branch
> > for the osstest push gate output ?
> 
> The latter please.

NP.

> We should also clarify the force push criteria.  It is moderately likely
> that we get a fix or extension to an existing test which starts showing
> up a new bug in the code under test.

Can this not be made into a new test ?

osstest would like such an extension to an existing test to be a new
`step' (in osstest terminology).  That would mean that the fact that
it fails with old versions of Xen can be seen not to be a regression.

Ie, osstest would like to be able to distinguish:
  * this version of xtf didn't have the new part of the test
  * old part of the test failed (and presumably new part was not run)
  * old part succeeded and new part failed
  * both parts were run and succeeded

> In this case, OSSTest will identify a regression, but it isn't a
> regression isn't in XTF, nor is it reasonable to call it a regression in
> Xen.  We would absolutely want to fix it in upstream, but there are no
> guarentees that the bugfix would be suitable for backport to older trees.

Indeed.

Ian.

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

Re: [Xen-devel] Xen 4.7.0 boot PANIC on kernel 4.7.0-4 + UEFI ?

2016-08-04 Thread lists 


On Wed, Aug 3, 2016, at 02:01 AM, Jan Beulich wrote:
> > with the 'baseline' as referenced + a patched kernel
> > 
> > > Can you try
> > >((void *)(md) + (m)->desc_size - 1) < (m)->map_end;
> >\
> > 
> > with efi cmd line opts: +"/mapbs"
> > 
> > The system now boots correctly

fyi, there's at least one disagreement re: the suggested - and ack'd as working 
- patch,

  https://lists.opensuse.org/opensuse-kernel/2016-08/msg8.html

"That's incorrect IMO. Either -1 or <. Not both -1 and <."

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

Re: [Xen-devel] [OSSTEST PATCH RFC 06/14] Introduce ts-xtf-build [and 1 more messages]

2016-08-04 Thread Ian Jackson 
Wei Liu writes ("[OSSTEST PATCH RFC 06/14] Introduce ts-xtf-build"):
> > > +sub stash () {
> > > +built_stash($ho, $builddir, "xtfdist", "xtfdist");
> > > +}
> > 
> > Can you post a tar zvvtf of a sample xtfdist tarball ?
> 
> drwxr-xr-x osstest/osstest   0 2016-08-04 08:30 home/
> drwxr-xr-x osstest/osstest   0 2016-08-04 08:30 home/osstest/
...
> -rw-r--r-- osstest/osstest 563 2016-08-04 08:30 
> home/osstest/build.66916.build-amd64-xtf/xtf/tests/xsa-168/test-hvm64-xsa-168.cfg

This is quite odd.

AFAICT this means that the original path of that file, as generated by
the invocation of `make install DESTDIR=...', was:

 
/home/osstest/build.66916/build-amd64-xtf/xtf/xtfdist/home/osstest/build.66916/build-amd64-xtf/xtf/xtfdist/tests/xsa-168/test-hvm64-xsa-168.cfg

This seems perverse.  Read on...

Wei Liu writes ("Re: [OSSTEST PATCH RFC 08/14] Introduce ts-xtf-install"):
> On Thu, Aug 04, 2016 at 12:54:41PM +0100, Ian Jackson wrote:
> > Surely the extracting job should just put it wherever it wants.
> 
> No, it can't.
> 
> It has to be in the location specified during build because there are
> hard-coded paths inside test case config files.

That's a bit sad.  But, fine.

But, in that case it is not possible to coinstall multiple different
versions of xtf.

The ability to coinstall multiple different xtfs was my reason for
suggesting that the xtfdist should be unpacked into a job-specific
subdirectory of /home/osstest.  Obviously that would have to be a
directory specific to the _test job_, not the build job.

As I say, if xtfdists aren't portable to different install locations,
then this is not possible and there is no reason not to use a fixed
install location.

That is:

  Build host:

 cd /home/osstest/build.66916.build-amd64-xtf/xtf
 make xtfdir=/home/xtf
 make xtfdir=/home/xtf DESTDIR=`pwd`/xtfdist

  Resulting in, on build host, for example:

 
/home/osstest/build.66916.build-amd64-xtf/xtf/xtfdist/home/xtf/tests/xsa-168/test-hvm64-xsa-168.cfg

  Note that this does not actually create anything in /home/xtf on the
  build host.  So different builds do not interfere with each other.

  Test host, for example:

 /home/xtf/tests/xsa-168/test-hvm64-xsa-168.cfg

Then there is no need for the xtfdir runvar, because the answer is
always the same.

Thanks,
Ian.

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

[Xen-devel] [PATCHv2 1/2] xen/prvicmd: use ENOTTY if the IOCTL is not supported

2016-08-04 Thread David Vrabel 
The standard return value for ioctl(2) where the cmd is not supported
is ENOTTY, not EINVAL.

Signed-off-by: David Vrabel 
---
 drivers/xen/privcmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 702040f..ac76bc4 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -572,7 +572,7 @@ static long privcmd_ioctl(struct file *file,
break;
 
default:
-   ret = -EINVAL;
+   ret = -ENOTTY;
break;
}
 
-- 
2.1.4


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

[Xen-devel] [PATCHv2 0/2] xen/privcmd: prevent page migration for hypercall buffers

2016-08-04 Thread David Vrabel 
Currently libxencall using mlocked buffers for hypercall buffers.
This pages are subject to compaction and page migration. A userspace
process may see a hypercall fail with -EFAULT if a page backing a
hypercall buffer is in the process of being migrated.

Page migration can be prevented by taking an additional reference to
the page.

There are three possible ways to do this:

1. Add a new device which when mmap()'d populated the VMA with
   suitable memory that has an additional reference.  This would give
   VMAs that have appropriate properties set (e.g., VM_DONTCOPY)
   without having to do additional madvise() calls.

2. Add a new ioctl to privcmd to populate a VMA with suitably
   ref-counted pages.  However, mmap() on privcmd is already used for
   foreign mappings and the VMA properties for hypercall buffers and
   foreign mappings might need to be different and the handling of
   unmap will need to be different.  This might be tricky.

3. Add a pair of ioctls to privcmd to lock/unlock a buffer by
   getting/putting an additional reference to the page.  This is
   what's implemented in this series.

Any thoughts on which is the best approach?

Changes in v2:
- Addressed Jan's feedback for #2 (see patch for details).

David


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

Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabled by default

2016-08-04 Thread Kevin.Mayer 
According to the crash-dump ( output of vcpu ) the v->arch.hvm_vmx.host_cr0 is 
" 0 ".
This cannot be the correct result because of

if ( !(v->arch.hvm_vmx.host_cr0 & X86_CR0_TS) )
{
v->arch.hvm_vmx.host_cr0 |= X86_CR0_TS;
__vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0);
}
It should at least be 0x8.
Also the v->arch.hvm_vmx.vmcs is " 0 " which I assume leads to the crash.


Since I assumed that somehow the wrong VCPU is used I tried to find the correct 
one:

vcpus gives
   VCID  PCID   VCPU   ST T DOMID  DOMAIN 
> 0 0 8300e7557000 RU I 32767 830c14ee1000
> 1 1 8300e75f2000 RU I 32767 830c14ee1000
  2 2 8300e72fe000 RU I 32767 830c14ee1000
> 3 3 8300e75f1000 RU I 32767 830c14ee1000
> 4 4 8300e75f RU I 32767 830c14ee1000
> 5 5 8300e72fd000 RU I 32767 830c14ee1000
>*6 6 8300e72fc000 RU I 32767 830c14ee1000
> 7 7 8300e72fb000 RU I 32767 830c14ee1000
> 0 2 8300e72f9000 RU 0 0 830c17e32000
  1 3 8300e72f8000 BL 0 0 830c17e32000
  2 5 8300e755f000 BL 0 0 830c17e32000
  3 0 8300e755e000 BL 0 0 830c17e32000
  4 6 8300e755d000 BL 0 0 830c17e32000
  5 4 8300e755c000 BL 0 0 830c17e32000
  6 7 8300e755b000 BL 0 0 830c17e32000
  7 5 8300e755a000 BL 0 0 830c17e32000
  0 1 8300e6fc7000 BL U   162 830bdee8f000
  0 3 8300e6fc9000 BL U   163 830be20d3000
  0 6 8300e6fc BL U   164 830be8dc9000
  0 0 8300e6fc6000 BL U   165 830bd0cc

Since I see the domain 830be8dc9000 all over the xen dmesg this should be 
the correct VCPU.
On this CPU the v->arch.hvm_vmx.host_cr0 is 2147811387 (0x 8005003B) which 
corresponds to the cr0 in the xen dmesg.
v->arch.hvm_vmx.vmcs is 0x830bd0da1000

crash> x /10x 0x830bd0da1000
0x830bd0da1000: 0x000e  0x
0x830bd0da1010: 0x  0x
0x830bd0da1020: 0x  0x
0x830bd0da1030: 0x  0x
0x830bd0da1040: 0x  0x

So the vmcs revision id is 0xe.
rdmsr 0x480 (the IA32_VMX_BASIC MSR ) gives da040e which confirms the 
revision ID.
Size should be 0x400 bytes.

crash> x /130x 0x830bd0da1000
0x830bd0da1000: 0x000e  0x
0x830bd0da1010: 0x  0x
0x830bd0da1020: 0x  0x
0x830bd0da1030: 0x  0x
0x830bd0da1040: 0x  0x
0x830bd0da1050: 0x  0x
0x830bd0da1060: 0x  0x
0x830bd0da1070: 0x  0x000bd0da3000
0x830bd0da1080: 0x000c17e36000  0x
0x830bd0da1090: 0x  0x
0x830bd0da10a0: 0xe7512000  0xe7513000
0x830bd0da10b0: 0x000bd0da  0x
0x830bd0da10c0: 0x  0x
0x830bd0da10d0: 0x  0x006fedea809b
0x830bd0da10e0: 0x0001a379e000  0x000610f9101e
0x830bd0da10f0: 0x  0x
0x830bd0da1100: 0x  0x0007010600070106
0x830bd0da1110: 0x  0x
0x830bd0da1120: 0x006bb6a075fa  0x00060042003f
0x830bd0da1130: 0x  0x000fefff
0x830bd0da1140: 0x  0x51ff
0x830bd0da1150: 0x0041  0x
0x830bd0da1160: 0x  0x000c
0x830bd0da1170: 0x  0x
0x830bd0da1180: 0x0001  0x
0x830bd0da1190: 0x0008  0x
0x830bd0da11a0: 0x0001  0x0096
0x830bd0da11b0: 0x82d0802bc208  0x806f6dbc
0x830bd0da11c0: 0x  0x0400
0x830bd0da11d0: 0x80550f34  0xf0e48161
0x830bd0da11e0: 0x0246  0x
0x830bd0da11f0: 0xf79c3000  0x804de6f0
0x830bd0da1200: 0x0023  0x
0x830bd0da1210: 0x00c0f300  0x0008
0x830bd0da1220: 0x  0x00c09b00
0x830bd0da1230: 0x0010  0x
0x830bd0da1240:

  1   2   3   >