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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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-i386-libvirt-xsm  12 migrate-support-checkfail   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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuuf419a626c76bcb26697883af702862e8623056f9
baseline version:
 qemuu53343338a6e7b83777b82803398572b40afc8c0f

Last test of basis92382  2016-04-22 19:42:54 Z3 days
Failing since 92701  2016-04-25 11:42:57 Z0 days2 attempts
Testing same since92767  2016-04-25 23:46:54 Z0 days1 attempts


People who touched revisions under test:
  David Gibson 
  Gerd Hoffmann 
  Joe Clifford 
  Peter Maydell 
  Thomas Huth 

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  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/arm64/kernel/setup.c

between commit:

  3194ac6e66cc ("arm64: Move unflatten_device_tree() call earlier.")

from the arm64 tree and commit:

  3915fea959b6 ("ARM: XEN: Move xen_early_init() before efi_init()")

from the xen-tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/kernel/setup.c
index 65f515949baa,7cf992fe6684..
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@@ -277,13 -336,13 +278,11 @@@ void __init setup_arch(char **cmdline_p
  
early_ioremap_reset();
  
 -  if (acpi_disabled) {
 -  unflatten_device_tree();
 +  if (acpi_disabled)
psci_dt_init();
 -  } else {
 +  else
psci_acpi_init();
 -  }
  
-   xen_early_init();
- 
cpu_read_bootcpu_ops();
smp_init_cpus();
smp_build_mpidr_hash();

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

[Xen-devel] [PATCH] add info to p2m_pod_dump_data

[zhangcy]

just for debug.
'xl debug-key q' do not dump d->tot_pages,
so it hard to understand p2m_pod_set_mem_target.

Signed-off-by: zhangcy 
---
 xen/arch/x86/mm/p2m-pod.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index 35835d1..a931f2c 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -660,8 +660,8 @@ void p2m_pod_dump_data(struct domain *d)
 {
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
-printk("PoD entries=%ld cachesize=%ld\n",
-   p2m->pod.entry_count, p2m->pod.count);
+printk("Total pages=%d PoD entries=%ld cachesize=%ld\n",
+   d->tot_pages, p2m->pod.entry_count, p2m->pod.count);
 }
 
 
-- 
1.7.12.4




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

Re: [Xen-devel] [PATCH] Fix cpumap setting before passing to XEN

[Zhenzhong Duan]

On 2016/4/25 21:26, Ian Jackson wrote:

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH] Fix cpumap setting before 
passing to XEN"):

On Wed, Apr 20, 2016 at 03:33:13PM +0100, Wei Liu wrote:

In principle I think having python binding and xl/libxl behave more or less
the same is the right direction. I'm a bit nervous about the change of
behaviour on the other hand.

Let's wait for a few more days to see if other people have any comment on
this.

Reviewed-by: Konrad Rzeszutek Wilk  ?

Does this bug report mean that `xm vcpu-pin ... all' has never
worked properly ?  Can that really be the case ?

Xen 4.3 doesn't work, Xen 3.4 works.
I have no Xen 4.4 around to test that, but checked code, it will not.
Then I found below commit involved.

commit 41abbadef60e5fccdfd688579dd458f7f7887cf5
Author: Ian Jackson 
Date:   Wed May 29 15:48:11 2013 +0100

libxc: limit cpu values when setting vcpu affinity

When support for pinning more than 64 cpus was added, check for cpu
out-of-range values was removed. This can lead to subsequent
out-of-bounds cpumap array accesses in case the cpu number is higher
than the actual count.

This patch returns the check.

This is CVE-2013-2072 / XSA-56

Signed-off-by: Petr Matousek 


Also, xm exists in Xen 4.4 and earlier, only.  Xen 4.4 is no longer
supported upstream, so we would not apply this patch to Xen 4.4.  So
whatever we do, this is not going to fix any bug in `xm vcpu-pin' in
4.4.
The only impact is upper layer or the user need to pass a correct cpumap 
param not beyond the real cpu map to avoid the error.
But I am not clear if python binding is still used or will be removed 
just as Xend.


This doesn't necessarily mean that I object to changing the behaviour
of the python xc module in still-supported Xen releases.  But I'm not
sure the reasoning behind the behaviour of the libxl bitmap functions
applies to the Python interface.

Zhenzhong Duan, are you using an out-of-tree copy of xm and xend ?

I am using xen-4.3.0-55.el6.47.33 which is Xen 4.3 variant

thanks
zduan

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

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

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt   3 host-install(3) broken REGR. vs. 92651

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

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

version targeted for testing:
 xen  bd6ad54403019f213e18791b9856e4b7b71a4d47
baseline version:
 xen  e0ec0a717d882ff0c0935b4893792d6aa95df3ef

Last test of basis92651  2016-04-25 02:00:45 Z1 days
Testing same since92720  2016-04-25 15:15:39 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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  broken  
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops 

Re: [Xen-devel] [PATCH v2 01/11] vt-d: fix the IOMMU flush issue

[Xu, Quan]

On April 25, 2016 5:22 PM, Jan Beulich  wrote:
> >>> On 18.04.16 at 16:00,  wrote:
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -558,14 +558,16 @@ static void iommu_flush_all(void)
> >  }
> >  }
> >
> > -static void __intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
> > -int dma_old_pte_present, unsigned int page_count)
> > +static int iommu_flush_iotlb(struct domain *d, unsigned long gfn,
> > + int dma_old_pte_present,
> > + unsigned int page_count)
> >  {
> >  struct hvm_iommu *hd = domain_hvm_iommu(d);
> >  struct acpi_drhd_unit *drhd;
> >  struct iommu *iommu;
> >  int flush_dev_iotlb;
> >  int iommu_domid;
> > +int rc = 0;
> 
> Pointless initializer.
> 

I am afraid not.
In case I don't initialize 'rc', the compiler prints out  " error: 'rc' may be 
used uninitialized in this function [-Werror=maybe-uninitialized]".

Quan


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

[Xen-devel] Should we mark RTDS as supported feature from experimental feature?

[Meng Xu]

Hi Dario and all,

When RTDS scheduler is initialized, it will print out that the
scheduler is an experimental feature with the following lines:

printk("Initializing RTDS scheduler\n"

   "WARNING: This is experimental software in development.\n"

   "Use at your own risk.\n");

On RTDS' wiki [1], it says the RTDS scheduler is experimental feature.

All of the above information haven't been updated since Xen 4.5.

However, inside MAINTAINERS file, the status of RTDS scheduler is
marked as Supported (refer to commit point 28041371 by Dario Faggioli
on 2015-06-25).

In my opinion, the RTDS scheduler's functionality is finished and
tested. So should I send a patch to change the message printed out
when the scheduler is initialized?

If I understand correctly, the status in MAINTAINERS file should have
the highest priority and information from other sources should keep
updated with what the MAINTAINERS file says?

Please correct me if I'm wrong.

[1] http://wiki.xenproject.org/wiki/RTDS-Based-Scheduler

Thanks,

Meng

-- 
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH v2 01/11] vt-d: fix the IOMMU flush issue

[Xu, Quan]

On April 25, 2016 5:22 PM, Jan Beulich  wrote:
> >>> On 18.04.16 at 16:00,  wrote:
> 
> I thought we had agreed on best effort flushing when an error occurs. That
> means you shouldn't break out of the loop here, but accumulate errors.
> (Breaking out of the loop would be okay if it was conditional upon the domain
> having got crashed.)
> 
I will follow it for coming version.
I indeed agreed to that single point, however, I wondered whether I could 
extend it as a pattern for this series or not.
Now I am clear.

Quan

> (The same issue exists again near the end of the patch).
> 

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

[Xen-devel] [xen-4.3-testing test] 92725: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 87893
 build-i3863 host-install(3) broken REGR. vs. 87893
 build-amd64   3 host-install(3) broken REGR. vs. 87893
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 87893

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-rumpuserxen1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 build-check(1)  blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass
 test-armhf-armhf-xl   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt  6 xen-boot fail   never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass

version targeted for testing:
 xen  c04846eeb3d96cf670dc5894b66f3f6e61c2531d
baseline version:
 xen  8fa31952e2d08ef63897c43b5e8b33475ebf5d93

Last test of basis87893  2016-03-29 13:49:52 Z   27 days
Testing same since92180  2016-04-20 17:49:21 Z5 days   12 attempts

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf cf6c1550cbf80423a9c058a52f7708db09dd4883
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  139 days
Failing since 65593  2015-12-08 23:44:51 Z  139 days  178 attempts
Testing same since92732  2016-04-25 17:16:17 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zeng, Star 
  Zhang Lubo 
  

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 92382
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
REGR. vs. 92382

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

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-i386-libvirt-xsm  12 migrate-support-checkfail   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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu3123bd8ebf3749be5b6ef815229c8c9dfb13c16d
baseline version:
 qemuu53343338a6e7b83777b82803398572b40afc8c0f

Last test of basis92382  2016-04-22 19:42:54 Z3 days
Testing same since92701  2016-04-25 11:42:57 Z0 days1 attempts


People who touched revisions under test:
  David Gibson 
  Peter Maydell 
  Thomas Huth 

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  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass  

Re: [Xen-devel] [PATCH] altp2m: Allow the hostp2m to be shared

[Konrad Rzeszutek Wilk]

Sadly I only have little nitpicks. Feel free to ignore them.

> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index a522423..d5b4b2d 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "mm-locks.h"
> @@ -1026,6 +1027,16 @@ int mem_sharing_share_pages(struct domain *sd, 
> unsigned long sgfn, shr_handle_t
>  /* We managed to free a domain page. */
>  atomic_dec(_shared_mfns);
>  atomic_inc(_saved_mfns);
> +
> +if( altp2m_active(cd) )

Missing space.
> +{
> +p2m_access_t a;

Newline.
> +struct p2m_domain *p2m = p2m_get_hostp2m(cd);
> +p2m->get_entry(p2m, cgfn, NULL, , 0, NULL, NULL);
> +p2m_altp2m_propagate_change(cd, _gfn(cgfn), smfn, PAGE_ORDER_4K,
> +p2m_ram_shared, a);
> +}
> +
>  ret = 0;
>  
>  err_out:
> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> index 3cb6868..1ac3018 100644
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -846,7 +846,7 @@ out:
>  if ( is_epte_present(_entry) )
>  ept_free_entry(p2m, _entry, target);
>  
> -if ( rc == 0 && p2m_is_hostp2m(p2m) )
> +if ( rc == 0 && p2m_is_hostp2m(p2m) && p2mt != p2m_ram_shared )
>  p2m_altp2m_propagate_change(d, _gfn(gfn), mfn, order, p2mt, p2ma);
>  
>  return rc;
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index b3fce1b..d2aebf7 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1739,11 +1739,10 @@ int p2m_set_altp2m_mem_access(struct domain *d, 
> struct p2m_domain *hp2m,
>  /* Check host p2m if no valid entry in alternate */
>  if ( !mfn_valid(mfn) )
>  {
> -mfn = hp2m->get_entry(hp2m, gfn_l, , _a,
> -  P2M_ALLOC | P2M_UNSHARE, _order, NULL);
> +mfn = hp2m->get_entry(hp2m, gfn_l, , _a, 0, _order, NULL);
>  
>  rc = -ESRCH;
> -if ( !mfn_valid(mfn) || t != p2m_ram_rw )
> +if ( !mfn_valid(mfn) || (t != p2m_ram_rw && t != p2m_ram_shared) )

Would it be easier to read if there were more of ()?

>  return rc;
>  
>  /* If this is a superpage, copy that first */
> @@ -1760,7 +1759,7 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct 
> p2m_domain *hp2m,
>  }
>  
>  return ap2m->set_entry(ap2m, gfn_l, mfn, PAGE_ORDER_4K, t, a,
> - (current->domain != d));
> +   (current->domain != d));

That looks like a cleanup? Perhaps a different patch?

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

Re: [Xen-devel] [Hackathon 16] Notes from Security Session

[Daniel De Graaf]

On 04/25/2016 02:32 PM, Konrad Rzeszutek Wilk wrote:

On Tue, Apr 19, 2016 at 10:11:28AM +0100, Andrew Cooper wrote:

On 19/04/16 10:02, Doug Goldstein wrote:

On 4/18/16 12:20 PM, Lars Kurth wrote:

Hi all,


CC-ing XSM maintainer :-)


Thanks. I'm going to comment on this and the wiki.

[...]

=== Enabling XSM By default ===
Andrew: There are some issues which we need to work through; a lot of little 
paper cuts
Rich: Could we create a list of issues on the wiki?
Lars: Definitely
Doug: Could we not have a policy which is equivalent to XSM being compiled out
Andrew: Could make policy more modular instead of one big global policy

Re-apply policy of guest after running

ACTION: Need a wiki page, Konrad can start one and we can collaboratively flesh 
it out
Lars: See http://wiki.xenproject.org/wiki/XSMAsDefault_TODO_List

ACTION: Konrad and others to add detail to it



It was pointed out to me that I did not get my comments about XSM across
clearly. I believe we need to improve the default policy to be
equivalent to disabling XSM and/or create a policy called "dummy" that
is the same as XSM disabled. To make XSM usage more smooth I propose we
bake the default policy into .initdata so that when you boot Xen
compiled with XSM you are no worse off than compiling XSM out.

The rationale here is that prior to a recent commit when you compiled
Xen with XSM enabled but did not provide a default policy then any domUs
that you ran had as much access as dom0. The recent commit changed it so
that Xen by default does not boot without a policy.

With my proposed change we would have "dummy" that would compile in and
if you provided another policy it would be used instead or you could
late load a replacement policy. Basically filling the gap of turning on
XSM and having a system less secure than XSM off until you developed
your policy.


+1.  It also avoids needing to play around loading an extra file as a grub
module, which makes distro-integration easer.

~Andrew


This should be doable, though it will require moving the rest of
tools/flask/policy under xen/ for proper dependencies. Beyond that, it
would need either a script or a careful invocation of objcopy to convert
the policy output to an array in initdata, and then that policy would be
used if the bootloader one is not present.

From the wiki:

XSM with default policy will have:

  - Same functionality exposed to guests without regressions
  - Have at minimum the same security as we have without XSM enabled.
  - Have set of policies for device driver domains vs control domains.


The first two bullets should be true with the current policy. The third
needs to be more precisely defined: any operation on a group it
controls, or limited operations (such as adjusting memory size) on all
guests?  The latter will probably need a custom policy (module) for
exactly what the control domain does.


Known Issues

  - Cannot re-apply a new policy after guests have been running.


This is possible via "xl loadpolicy".  There is no (exposed) way to
re-label existing domains, but you can create new domains using new
types in the policy.  The new policy rules will be enforced immediately
on existing domains, but this may not fully tighten restrictions: for
example, if a passthrough device is newly disallowed but already mapped
by a domain, it will not be unmapped.


TODO List

  - Could initial build of Xen hypervisor include a built-in (inside 
.init.data) policy file?

(Above).

  - Can we make policies modularized? A core (perhaps built-in?) with 
amendments loaded later?


There is already some support for modules in the XSM policy: see
tools/flask/policy/policy/modules.conf.  Currently this is not really
used: all rules are in the "xen" module.  However, it could be split up
into a real core module (probably still named "xen") and other modules
that would be available to turn on/off.

The process of assembling the modules into a single XSM policy is done
in userspace, not the hypervisor, so "xl loadpolicy" would not change.

--
Daniel De Graaf
National Security Agency

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

[Xen-devel] [4.2.y-ckt stable] Patch "x86/mm/xen: Suppress hugetlbfs in PV guests" has been added to the 4.2.y-ckt tree

[Kamal Mostafa]

This is a note to let you know that I have just added a patch titled

x86/mm/xen: Suppress hugetlbfs in PV guests

to the linux-4.2.y-queue branch of the 4.2.y-ckt extended stable tree 
which can be found at:

http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-4.2.y-queue

This patch is scheduled to be released in version 4.2.8-ckt9.

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 4.2.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Kamal

---8<

From 6b573233de517e24ffd20d02374f0a5048285f5b Mon Sep 17 00:00:00 2001
From: Jan Beulich 
Date: Thu, 21 Apr 2016 00:27:04 -0600
Subject: x86/mm/xen: Suppress hugetlbfs in PV guests

commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream.

Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:

  kernel BUG at .../fs/hugetlbfs/inode.c:428!
  invalid opcode:  [#1] SMP
  ...
  RIP: e030:[]  [] 
remove_inode_hugepages+0x25b/0x320
  ...
  Call Trace:
   [] hugetlbfs_evict_inode+0x15/0x40
   [] evict+0xbd/0x1b0
   [] __dentry_kill+0x19a/0x1f0
   [] dput+0x1fe/0x220
   [] __fput+0x155/0x200
   [] task_work_run+0x60/0xa0
   [] do_exit+0x160/0x400
   [] do_group_exit+0x3b/0xa0
   [] get_signal+0x1ed/0x470
   [] do_signal+0x14/0x110
   [] prepare_exit_to_usermode+0xe9/0xf0
   [] retint_user+0x8/0x13

This is CVE-2016-3961 / XSA-174.

Reported-by: Vitaly Kuznetsov 
Signed-off-by: Jan Beulich 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: David Vrabel 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: xen-devel 
Link: http://lkml.kernel.org/r/57188ed80278000e4...@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Kamal Mostafa 
---
 arch/x86/include/asm/hugetlb.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetlb.h
index f8a29d2..e6a8613 100644
--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -4,6 +4,7 @@
 #include 
 #include 

+#define hugepages_supported() cpu_has_pse

 static inline int is_hugepage_only_range(struct mm_struct *mm,
 unsigned long addr,
--
2.7.4


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  488c2a860a6d7eb69f4acfeb349b457aaba76dfa
baseline version:
 xen  bd6ad54403019f213e18791b9856e4b7b71a4d47

Last test of basis92710  2016-04-25 13:01:06 Z0 days
Testing same since92731  2016-04-25 17:04:22 Z0 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Doug Goldstein 
  Fu Wei 
  Ian Jackson 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=488c2a860a6d7eb69f4acfeb349b457aaba76dfa
+ . ./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 
488c2a860a6d7eb69f4acfeb349b457aaba76dfa
+ branch=xen-unstable-smoke
+ revision=488c2a860a6d7eb69f4acfeb349b457aaba76dfa
+ . ./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.6-testing
+ '[' x488c2a860a6d7eb69f4acfeb349b457aaba76dfa = 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();
   

Re: [Xen-devel] Outreachy bite-sized tasks

[Konrad Rzeszutek Wilk]

On Wed, Apr 20, 2016 at 12:06:48PM +0200, Paulina Szubarczyk wrote:
> On Fri, 2016-04-01 at 15:35 +0200, Roger Pau Monné wrote:
> > Please don't top post, it breaks the flow of the conversation.
> > 
> > I'm also adding Anthony (one of the QEMU/Xen maintainers).
> > On Fri, 1 Apr 2016, Paulina Szubarczyk wrote:
> > 
> > > Hi Roger,
> > > 
> > > An another point that needs to be filled up in the application is 
> > > timeline.
> > > I made the proposition of it, I am not sure if it should be more complex. 
> > > Could you look at it in your free time?
> > > 
> > > Timeline:
> > > 
> > > 22 April - 22 May [Before the intership]
> > >  * Elaborate performance measurement methodology. That may include 
> > > putting trace
> > > points using TRDCS and performing read operation with varying block 
> > > sizes on 
> > > different storage devices as in [3].
> > 
> > Could you elaborate on TRDCS? I've tried googling for it, but nothing came 
> > up.
> I mistyped TRDCS, I meant putting trace points in the application to
> measure the time spent in each place as shown in the talk[3]. But is I
> did more research concerning the measurement I think that the good idea
> would be using fio and make similar test as Adriana did during her
> OWP[4] when she worked on implementing multi-queue support for
> xen_backend in Linux.  
> 
> > Also, I think it would be good to write down which tool are you going to 
> > use in order to perform those measurements, and how/which block sizes are 
> > you going to test. Also keep into account that apart from block sizes you 
> > also have to take into account the number of parallel workers and the 
> > queue depth of each one.
> > 
> > Regarding the different storage devices, we usually did benchmarks using a 
> > ramdisk, but Linux intorduced a null-block device [0] not long ago that I 
> > think could be used to model different storage devices without actually 
> > having to buy them.
> I make myself familiar with the protocol and I debug the qdisk during
> attaching one of ram devices to follow how it works. I also wondered if
> maybe I could make a change to 'xl create' such as when it is run in the
> qemu debug mode doesn't terminate when Device Mode isn't ready yet,
> because sometimes is hard to catch the moment when the connection to
> gdbserver is possible.
> 
> Whereas I saw the implementation of indirect descriptors and the
> multi-queue support by creating multiple rings, I couldn't find the
> information of grant copy. Do you mean by that hypervisor-driven copy of
> grant pages between domains instead of mapping them? 

Yup. The hypervisor does the memcpy. The grant mapping system has an impact
that is felt when you are done with the grant - you need to unmap it.

And when you unmap it - you need to flush out the virtual address out of
the guests vCPUS (if the guests are runninig) - otherwise the CPU could
use an stale virtual address (they are cached) and reference an memory
that now points to somewhere else. Hence the unmap means also doing an
TLB shootdown which is expensive as it flushes out the CPU cache.

There have been improvements in this - David Vrabel had posted some patches
for this I think..

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 59254
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 59254
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 59254
 test-amd64-i386-xl-xsm   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-libvirt-xsm 16 guest-stopfail REGR. vs. 59254
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-amd64-i386-pair   22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
59254
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. 
vs. 59254
 build-armhf-pvops 5 kernel-build  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline 
untested
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass

version targeted for testing:
 linux02da2d72174c61988eb4456b53f405e3ebdebce4
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  291 days
Failing since 59348  2015-07-10 04:24:05 Z  290 days  215 attempts
Testing same since92668  2016-04-25 04:27:07 Z0 days1 attempts


4920 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [Hackathon 16] Notes from Security Session

[Konrad Rzeszutek Wilk]

On Tue, Apr 19, 2016 at 10:11:28AM +0100, Andrew Cooper wrote:
> On 19/04/16 10:02, Doug Goldstein wrote:
> >On 4/18/16 12:20 PM, Lars Kurth wrote:
> >>Hi all,

CC-ing XSM maintainer :-)
> >>
> >>I took notes as much as I could. CC'ed the people who participated most. If 
> >>I missed/misrepresented something, please add to the discussion. I know 
> >>that George for example took some extra notes in the one or other area.
> >>
> >>Regards
> >>Lars
> >>
> >>== Topics discussed ==
> >>QEMU
> >>De-privilige of QEMU
> >>XSA
> >>x-Splice
> >>x86 Emulator
> >>Enabling XSM By default
> >>
> >>=== Slimline QEMU ===
> >>
> >>Konrad: Some inroads on making QEMU better
> >>Konrad: QEMU is too big and it is hard to strip down the platform : how can 
> >>we chop it up
> >>
> >>Wei: Wei attempted this 2 years ago : Wei defined some Xen stub CPU model, 
> >>which was rejected at the time
> >>Stefano: Maybe what we need is different
> >>Stefano: Containers / Intel have similar issues
> >>Stefano: Intel have a very similar problem with ClearContainer
> >>Stefano: Re-implementing ClearContainers with QEMU because of market needs
> >>Stefano: QEMU does have already a no-default option
> >>
> >>Doug: In the QEMU model: you cannot run a board without a CPU
> >>Doug: KConfig may be acceptable, but re4moving boards may not (initially 
> >>discussed with Antony L)
> >>
> >>George: Distros don't want to ship two versions of QEMU
> >>George: Compile configurability doesn't help with distros
> >>
> >>Konrad: PVH/HVMLite does not use QEMU (or only as a back)
> >>
> >>Lars: If we had a proposal, working with Intel and the QEMU community, we 
> >>could discuss at Xen Summit / KVM Forum is co-located
> >>
> >>James: If we had a future with OVMF, then we probably wouldn't need QEMU 
> >>(aka if you want security use PVH with OVMF)
> >>James: Proposal for security conscious applications we could fork and use a 
> >>stubbed out version of QEMU
> >>
> >>Options:
> >>- KConfig
> >>- Run-time disablement
> >>- Xen Summit / KVM Forum
> >>- Intel work / collaboration
> >>- PIX3 > 935
> >>- OVMF
> >>- Remove xl.cfg (stop configs - in fact we probably only can print a 
> >>warning "this is not secure and has no security support" or something 
> >>similar)
> >>
> >>Doug: Issue
> >>- For example Oracle could deal with Config
> >>- BUT, this approach won't work for distros
> >>
> >>ACTION: Konrad is volunteering to drive this discussion
> >>
> >>=== De-privilige Qemu ===
> >>Konrad: What's the status
> >>Stefano: not done, you need
> >>- QEMU as non-root (that is in 4.7 and QEMU part is there)
> >>- Now you still have a libxc and xenstore interface that needs to be 
> >>de-priviliged
> >>   - There is a patch for QEMI and xenstore to deal with the libxc part 
> >> (not upstreamed) ... pretty big series, but won't make it for 4.7 - QEMU 
> >> part is tiny
> >>   - Libxc is sizeable (Ian Campbell was working on it), but it is now 
> >> dormant : QEMU support is there, but Dom0 interface is missing
> >> - Ideas: Do registration in Dom0
> >>[George has some additional notes]
> >>
> >>ISSUE: A proposal and a plan, but nobody to do this. Without this what we 
> >>have is not useful
> >>Andrew: XenServer still using qemu-trad because of some gaps in emu-upstream
> >>Andrew: XS may end up working on this at some undefined point in the future
> >>
> >>There is a problem with using CD drive's to open ISOs as you need to be 
> >>privileged to do this
> >>Andy Cooper: there may be real end-user issues
> >>Stefano: Could change ownership
> >>Doug: Issue was tried to be fixed in libvirt and went nowhere
> >>Andy: Qemu-trad does it wrong (QEMU in libxenlight does not do that)
> >>
> >>ACTION: High;right lack of owner
> >>
> >>Konrad: Seccomp may work
> >>Doug: everything has to be passed as file descriptor
> >>
> >>=== Narrower XSA Coverage ===
> >>Jan: XSA 77 (whitelisted a set of dom control and sys control) which are 
> >>supposedly ... http://xenbits.xen.org/xsa/advisory-77.html
> >>  See http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt (Security 
> >> Status of dom0 disaggregation)
> >>Jan: Who runs this in production: running part of toolstack not in Dom0 - 
> >>OpenXT wants to do this
> >>Jan: The observation is that we went to far with the XSA 77 => if we had a 
> >>shorter whitelist, and reduce whitelist
> >>Jan: If there was agreement, then the security team
> >>  would not handle issues in these areas as XSA's
> >>
> >>Ross Phillipson: Typic ally we have only higher level stuff in a different 
> >>xl, but lower level stuff runs on Dom0. So there should be no issue
> >>
> >>George: QEMU stub domains should have security support
> >>George: There are a whole set of other things, which we don't know whether 
> >>they are used
> >>George: Do we want to security support of disaggregated tools-stub
> >>
> >>Agreed: Propose patch to change 
> >>http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt on the list
> >>Jan: We can only discuss in 

Re: [Xen-devel] [for-4.7] xen/arm: Force broadcast of TLB and instruction cache maintenance instructions

[Konrad Rzeszutek Wilk]

On Mon, Apr 18, 2016 at 10:29:51AM +0100, Julien Grall wrote:
> UP guest usually uses TLB instruction to flush only on the local CPU. The
> TLB flush won't be broadcasted across all the CPUs within the same
> innershareable domain.
> 
> When the vCPU is migrated between different CPUs, it may be rescheduled
> to a previous CPU where the TLB has not been flushed. The TLB may
> contain stale entries which will result to translate incorrectly a VA to
> IPA or even cause TLB conflicts.
> 
> To avoid a such situation, always set HCR_EL2.FB which will force the
> broadcast of TLB and instruction cache maintenance instructions.
> Cheers,
> 
> Signed-off-by: Julien Grall 

Hey!

I presume this needs an Release-Ack ?

> ---
> 
> This is a bug fix for Xen 4.7 and should be backported up to Xen 4.4
> (first official release for ARM). Without this patch, UP guest will
> crash if it gets migrated on a physical CPU with stale TLBs for this
> guest.
> ---
>  xen/arch/arm/traps.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 5e865cf..9926a57 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -124,7 +124,8 @@ void init_traps(void)
>  
>  /* Setup hypervisor traps */
>  WRITE_SYSREG(HCR_PTW|HCR_BSU_INNER|HCR_AMO|HCR_IMO|HCR_FMO|HCR_VM|
> - HCR_TWE|HCR_TWI|HCR_TSC|HCR_TAC|HCR_SWIO|HCR_TIDCP, 
> HCR_EL2);
> + HCR_TWE|HCR_TWI|HCR_TSC|HCR_TAC|HCR_SWIO|HCR_TIDCP|HCR_FB,
> + HCR_EL2);
>  isb();
>  }
>  
> -- 
> 1.9.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

[David Vrabel]

On 24/04/16 21:23, Borislav Petkov wrote:
> On Mon, Feb 01, 2016 at 10:38:48AM -0500, Boris Ostrovsky wrote:
>> Start HVMlite guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall
>> page, initialize boot_params, enable early page tables.
>>
>> Since this stub is executed before kernel entry point we cannot use
>> variables in .bss which is cleared by kernel. We explicitly place
>> variables that are initialized here into .data.
>>
>> Signed-off-by: Boris Ostrovsky 
>> ---
>>  arch/x86/xen/Makefile  |1 +
>>  arch/x86/xen/enlighten.c   |   86 +-
>>  arch/x86/xen/xen-hvmlite.S |  175 
>> 
>>  include/xen/xen.h  |6 ++
>>  4 files changed, 267 insertions(+), 1 deletions(-)
>>  create mode 100644 arch/x86/xen/xen-hvmlite.S
>>
>> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
>> index e47e527..1d913d7 100644
>> --- a/arch/x86/xen/Makefile
>> +++ b/arch/x86/xen/Makefile
>> @@ -23,3 +23,4 @@ obj-$(CONFIG_XEN_DEBUG_FS) += debugfs.o
>>  obj-$(CONFIG_XEN_DOM0)  += vga.o
>>  obj-$(CONFIG_SWIOTLB_XEN)   += pci-swiotlb-xen.o
>>  obj-$(CONFIG_XEN_EFI)   += efi.o
>> +obj-$(CONFIG_XEN_PVHVM) += xen-hvmlite.o
>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>> index 5774800..5f05fa2 100644
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -118,7 +118,8 @@ DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
>>   */
>>  DEFINE_PER_CPU(struct vcpu_info, xen_vcpu_info);
>>  
>> -enum xen_domain_type xen_domain_type = XEN_NATIVE;
>> +enum xen_domain_type xen_domain_type
>> +__attribute__((section(".data"))) = XEN_NATIVE;
>>  EXPORT_SYMBOL_GPL(xen_domain_type);
>>  
>>  unsigned long *machine_to_phys_mapping = (void *)MACH2PHYS_VIRT_START;
>> @@ -171,6 +172,17 @@ struct tls_descs {
>>   */
>>  static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
>>  
>> +#ifdef CONFIG_XEN_PVHVM
>> +/*
>> + * HVMlite variables. These need to live in data segment since they are
>> + * initialized before startup_{32|64}, which clear .bss, are invoked.
> 
> So this jumps into startup_32/64 and I don't think we have talked about
> it yet, have we? I'm not aware of any threads about it. Are we fine with
> it, are we not?
> 
> I think we need to agree on API where xen guests should jump into
> arch/x86/ and adhere to it. Otherwise, we will break xen again if we change
> stuff in x86 and we do like to change stuff in x86 all the time.
> 
> Adding tip guys and leaving in the rest for reference.

It would be good if we could start in the decompresser, but we would
need to be able to:

a) identify that the image is PVH-capable.
b) call a PVH specific entry point that builds the expected struct
boot_params.

I don't see any scope in the existing boot protocol to allow this. Hence
we get Xen to decompress the image and look at ELF notes etc.

We want PVH to be a drop-in replacement for PV as much as possible so
this excludes using a bootloader or post-processing the bzImage into a
PVH-compatible ELF image.

I'm open to other suggestions but what's proposed here seems the least
intrusive and with minimal risk for future breakage.  I don't think the
decompressor to kernel ABI changes often does it?

David


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

Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

[Paul Durrant]

> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 25 April 2016 17:16
> To: Yu, Zhang; Jan Beulich; Paul Durrant
> Cc: Andrew Cooper; Wei Liu; Jun Nakajima; Kevin Tian; Zhiyuan Lv; xen-
> de...@lists.xen.org; Keir (Xen.org); Tim (Xen.org)
> Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
> Rename p2m_mmio_write_dm to p2m_ioreq_server.
> 
> On 25/04/16 16:53, Yu, Zhang wrote:
> >
> >
> > On 4/25/2016 11:38 PM, Jan Beulich wrote:
> > On 25.04.16 at 17:29,  wrote:
>   -Original Message-
>  From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
>  Sent: 25 April 2016 16:22
>  To: Paul Durrant; George Dunlap
>  Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
>  Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan; Jan Beulich; Wei Liu
>  Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for
>  4.7):
>  Rename p2m_mmio_write_dm to p2m_ioreq_server.
> 
> 
> 
>  On 4/25/2016 10:01 PM, Paul Durrant wrote:
> >> -Original Message-
> >> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf
> Of
> >> George Dunlap
> >> Sent: 25 April 2016 14:39
> >> To: Yu Zhang
> >> Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun
> >> Nakajima;
> >> Andrew Cooper; Tim (Xen.org); Paul Durrant; Lv, Zhiyuan; Jan
> >> Beulich; Wei
>  Liu
> >> Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for
> >> 4.7):
> >> Rename p2m_mmio_write_dm to p2m_ioreq_server.
> >>
> >> On Mon, Apr 25, 2016 at 11:35 AM, Yu Zhang
>  
> >> wrote:
> >>> Previously p2m type p2m_mmio_write_dm was introduced for
> write-
> >>> protected memory pages whose write operations are supposed to
> be
> >>> forwarded to and emulated by an ioreq server. Yet limitations of
> >>> rangeset restrict the number of guest pages to be write-protected.
> >>>
> >>> This patch replaces the p2m type p2m_mmio_write_dm with a new
>  name:
> >>> p2m_ioreq_server, which means this p2m type can be claimed by
> one
> >>> ioreq server, instead of being tracked inside the rangeset of ioreq
> >>> server. Patches following up will add the related hvmop handling
> >>> code which map/unmap type p2m_ioreq_server to/from an ioreq
>  server.
> >>>
> >>> changes in v3:
> >>>   - According to Jan & George's comments, keep
> >> HVMMEM_mmio_write_dm
> >>> for old xen interface versions, and replace it with
> >>> HVMMEM_unused
> >>> for xen interfaces newer than 4.7.0; For p2m_ioreq_server, a
> new
> >>> enum - HVMMEM_ioreq_server is introduced for the get/set
> mem
>  type
> >>> interfaces;
> >>>   - Add George's Reviewed-by and Acked-by from Tim & Andrew.
> >>
> >> Unfortunately these rather contradict each other -- I consider
> >> Reviewed-by to only stick if the code I've specified hasn't changed
> >> (or has only changed trivially).
> >>
> >> Also...
> >>
> >>>
> >>> changes in v2:
> >>>   - According to George Dunlap's comments, only rename the p2m
> type,
> >>> with no behavior changes.
> >>>
> >>> Signed-off-by: Paul Durrant 
> >>> Signed-off-by: Yu Zhang 
> >>> Acked-by: Tim Deegan 
> >>> Acked-by: Andrew Cooper 
> >>> Reviewed-by: George Dunlap 
> >>> Cc: Keir Fraser 
> >>> Cc: Jan Beulich 
> >>> Cc: Andrew Cooper 
> >>> Cc: Jun Nakajima 
> >>> Cc: Kevin Tian 
> >>> Cc: George Dunlap 
> >>> Cc: Tim Deegan 
> >>> ---
> >>>  xen/arch/x86/hvm/hvm.c  | 14 --
> >>>  xen/arch/x86/mm/p2m-ept.c   |  2 +-
> >>>  xen/arch/x86/mm/p2m-pt.c|  2 +-
> >>>  xen/arch/x86/mm/shadow/multi.c  |  2 +-
> >>>  xen/include/asm-x86/p2m.h   |  4 ++--
> >>>  xen/include/public/hvm/hvm_op.h |  8 +++-
> >>>  6 files changed, 20 insertions(+), 12 deletions(-)
> >>>
> >>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> >>> index f24126d..874cb0f 100644
> >>> --- a/xen/arch/x86/hvm/hvm.c
> >>> +++ b/xen/arch/x86/hvm/hvm.c
> >>> @@ -1857,7 +1857,7 @@ int hvm_hap_nested_page_fault(paddr_t
> gpa,
> >> unsigned long gla,
> >>>   */
> >>>  if ( (p2mt == p2m_mmio_dm) ||
> >>>   (npfec.write_access &&
> >>> -  (p2m_is_discard_write(p2mt) || (p2mt ==
>  p2m_mmio_write_dm))) )
> >>> +  (p2m_is_discard_write(p2mt) || (p2mt ==
> >>> p2m_ioreq_server))) )
> >>>  {
> >>> 

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf fa8ee0ad6dbb22bb9962c3e32c091f29c2e0d5d8
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  139 days
Failing since 65593  2015-12-08 23:44:51 Z  138 days  177 attempts
Testing same since92695  2016-04-25 10:19:59 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zeng, Star 
  Zhang Lubo 
  

Re: [Xen-devel] [PATCH v2] docs/arm64: clarify the documention for loading XSM support

[Wei Liu]

On Mon, Apr 25, 2016 at 05:45:58PM +0100, Julien Grall wrote:
> Hi Ian,
> 
> On 25/04/16 17:38, Ian Jackson wrote:
> >From: Fu Wei 
> >
> >Improve the clarity of the wording introduced in 67831c4c
> >"docs/arm64: update the documentation for loading XSM support"
> >
> >Signed-off-by: Ian Jackson 
> >CC: Fu Wei 
> >CC: Julien Grall 
> 
> Reviewed-by: Julien Grall 
> 

Queued. Thanks.

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

Re: [Xen-devel] [PATCH v2] docs/arm64: clarify the documention for loading XSM support

[Julien Grall]

Hi Ian,

On 25/04/16 17:38, Ian Jackson wrote:

From: Fu Wei 

Improve the clarity of the wording introduced in 67831c4c
"docs/arm64: update the documentation for loading XSM support"

Signed-off-by: Ian Jackson 
CC: Fu Wei 
CC: Julien Grall 


Reviewed-by: Julien Grall 

Regards,


CC: Stefano Stabellini 
---
v2: Tabify (to conform to the rest of the file)
---
  docs/misc/arm/device-tree/booting.txt |   29 +
  1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/docs/misc/arm/device-tree/booting.txt 
b/docs/misc/arm/device-tree/booting.txt
index cae46eda..ce2d0dc 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -26,19 +26,24 @@ Each node contains the following properties:
Xen will assume that the first module which lacks a more
specific compatible string is a "multiboot,kernel".

-   Xen will check all the modules for the XSM Magic from the second
-   module that lacks a specific compatible string. According to the
-   result of the detection:
-   - if it's an XSM, Xen will assume its compatible string is
+   Xen will examine each module, starting from the second
+   module that lacks a specific compatible string.  Xen will
+   check each such module for the XSM Magic number:
+
+   - For a module which has the XSM Magic number: it will be
+ treated by Xen as if its compatible string was
  "xen,xsm-policy";
-   - if it's not an XSM, for the second module that lacks a specific
- compatible string, Xen will assume its compatible string is
- "multiboot,ramdisk"; the third and subsequent modules that
- lack a specific compatible string will not receive any special
- treatment.
-   This means that if the ramdisk module is present and does not have
-   the compatible string "multiboot,ramdisk", then it must always be
-   the second module.
+
+   - For a module which does not have the XSM Magic: the second
+ module lacking a compatible string will be treated by Xen as
+ if its compatible string was "multiboot,ramdisk"; for the
+ third and subsequent modules which lack a specific
+ compatible string, Xen will not apply any special treatment.
+
+   This means if the ramdisk module is present and does not have the
+   compatible string "multiboot,ramdisk", then it must always be the
+   second module.
+
Note: This XSM Magic detection behavior was introduced by Xen 4.7.
Xen 4.6 (and downwards) still requires the XSM module to have the
compatible string "xen,xsm-policy".



--
Julien Grall

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

[Xen-devel] [PATCH v2] docs/arm64: clarify the documention for loading XSM support

[Ian Jackson]

From: Fu Wei 

Improve the clarity of the wording introduced in 67831c4c
"docs/arm64: update the documentation for loading XSM support"

Signed-off-by: Ian Jackson 
CC: Fu Wei 
CC: Julien Grall 
CC: Stefano Stabellini 
---
v2: Tabify (to conform to the rest of the file)
---
 docs/misc/arm/device-tree/booting.txt |   29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/docs/misc/arm/device-tree/booting.txt 
b/docs/misc/arm/device-tree/booting.txt
index cae46eda..ce2d0dc 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -26,19 +26,24 @@ Each node contains the following properties:
Xen will assume that the first module which lacks a more
specific compatible string is a "multiboot,kernel".
 
-   Xen will check all the modules for the XSM Magic from the second
-   module that lacks a specific compatible string. According to the
-   result of the detection:
-   - if it's an XSM, Xen will assume its compatible string is
+   Xen will examine each module, starting from the second
+   module that lacks a specific compatible string.  Xen will
+   check each such module for the XSM Magic number:
+
+   - For a module which has the XSM Magic number: it will be
+ treated by Xen as if its compatible string was
  "xen,xsm-policy";
-   - if it's not an XSM, for the second module that lacks a specific
- compatible string, Xen will assume its compatible string is
- "multiboot,ramdisk"; the third and subsequent modules that
- lack a specific compatible string will not receive any special
- treatment.
-   This means that if the ramdisk module is present and does not have
-   the compatible string "multiboot,ramdisk", then it must always be
-   the second module.
+
+   - For a module which does not have the XSM Magic: the second
+ module lacking a compatible string will be treated by Xen as
+ if its compatible string was "multiboot,ramdisk"; for the
+ third and subsequent modules which lack a specific
+ compatible string, Xen will not apply any special treatment.
+
+   This means if the ramdisk module is present and does not have the
+   compatible string "multiboot,ramdisk", then it must always be the
+   second module.
+
Note: This XSM Magic detection behavior was introduced by Xen 4.7.
Xen 4.6 (and downwards) still requires the XSM module to have the
compatible string "xen,xsm-policy".
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH] docs/arm64: clarify the documention for loading XSM support

[Ian Jackson]

Julien Grall writes ("Re: [Xen-devel] [PATCH] docs/arm64: clarify the
> Somehow, I am not in the mail CC. Maybe because of the "," at the end?

How odd.

> Otherwise, the text looks good to me. I have some questions about the 
> formatting, see below.

I think there has been some damage from repeated tab<->space
conversions.

I will resend.

Ian.

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

Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

[Yu, Zhang]

On 4/26/2016 12:15 AM, George Dunlap wrote:

On 25/04/16 16:53, Yu, Zhang wrote:



On 4/25/2016 11:38 PM, Jan Beulich wrote:

On 25.04.16 at 17:29,  wrote:

 -Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 25 April 2016 16:22
To: Paul Durrant; George Dunlap
Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan; Jan Beulich; Wei Liu
Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for
4.7):
Rename p2m_mmio_write_dm to p2m_ioreq_server.



On 4/25/2016 10:01 PM, Paul Durrant wrote:

-Original Message-
From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
George Dunlap
Sent: 25 April 2016 14:39
To: Yu Zhang
Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun
Nakajima;
Andrew Cooper; Tim (Xen.org); Paul Durrant; Lv, Zhiyuan; Jan
Beulich; Wei

Liu

Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for
4.7):
Rename p2m_mmio_write_dm to p2m_ioreq_server.

On Mon, Apr 25, 2016 at 11:35 AM, Yu Zhang



wrote:

Previously p2m type p2m_mmio_write_dm was introduced for write-
protected memory pages whose write operations are supposed to be
forwarded to and emulated by an ioreq server. Yet limitations of
rangeset restrict the number of guest pages to be write-protected.

This patch replaces the p2m type p2m_mmio_write_dm with a new

name:

p2m_ioreq_server, which means this p2m type can be claimed by one
ioreq server, instead of being tracked inside the rangeset of ioreq
server. Patches following up will add the related hvmop handling
code which map/unmap type p2m_ioreq_server to/from an ioreq

server.


changes in v3:
  - According to Jan & George's comments, keep

HVMMEM_mmio_write_dm

for old xen interface versions, and replace it with
HVMMEM_unused
for xen interfaces newer than 4.7.0; For p2m_ioreq_server, a new
enum - HVMMEM_ioreq_server is introduced for the get/set mem

type

interfaces;
  - Add George's Reviewed-by and Acked-by from Tim & Andrew.


Unfortunately these rather contradict each other -- I consider
Reviewed-by to only stick if the code I've specified hasn't changed
(or has only changed trivially).

Also...



changes in v2:
  - According to George Dunlap's comments, only rename the p2m type,
with no behavior changes.

Signed-off-by: Paul Durrant 
Signed-off-by: Yu Zhang 
Acked-by: Tim Deegan 
Acked-by: Andrew Cooper 
Reviewed-by: George Dunlap 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Tim Deegan 
---
 xen/arch/x86/hvm/hvm.c  | 14 --
 xen/arch/x86/mm/p2m-ept.c   |  2 +-
 xen/arch/x86/mm/p2m-pt.c|  2 +-
 xen/arch/x86/mm/shadow/multi.c  |  2 +-
 xen/include/asm-x86/p2m.h   |  4 ++--
 xen/include/public/hvm/hvm_op.h |  8 +++-
 6 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index f24126d..874cb0f 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1857,7 +1857,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,

unsigned long gla,

  */
 if ( (p2mt == p2m_mmio_dm) ||
  (npfec.write_access &&
-  (p2m_is_discard_write(p2mt) || (p2mt ==

p2m_mmio_write_dm))) )

+  (p2m_is_discard_write(p2mt) || (p2mt ==
p2m_ioreq_server))) )
 {
 __put_gfn(p2m, gfn);
 if ( ap2m_active )
@@ -5499,8 +5499,8 @@ long do_hvm_op(unsigned long op,

XEN_GUEST_HANDLE_PARAM(void) arg)

 get_gfn_query_unlocked(d, a.pfn, );
 if ( p2m_is_mmio(t) )
 a.mem_type =  HVMMEM_mmio_dm;
-else if ( t == p2m_mmio_write_dm )
-a.mem_type = HVMMEM_mmio_write_dm;
+else if ( t == p2m_ioreq_server )
+a.mem_type = HVMMEM_ioreq_server;
 else if ( p2m_is_readonly(t) )
 a.mem_type =  HVMMEM_ram_ro;
 else if ( p2m_is_ram(t) )
@@ -5531,7 +5531,8 @@ long do_hvm_op(unsigned long op,

XEN_GUEST_HANDLE_PARAM(void) arg)

 [HVMMEM_ram_rw]  = p2m_ram_rw,
 [HVMMEM_ram_ro]  = p2m_ram_ro,
 [HVMMEM_mmio_dm] = p2m_mmio_dm,
-[HVMMEM_mmio_write_dm] = p2m_mmio_write_dm
+[HVMMEM_unused] = p2m_invalid,
+[HVMMEM_ioreq_server] = p2m_ioreq_server
 };

 if ( copy_from_guest(, arg, 1) )
@@ -,7 +5556,8 @@ long do_hvm_op(unsigned long op,

XEN_GUEST_HANDLE_PARAM(void) arg)

  ((a.first_pfn + a.nr - 1) >
domain_get_maximum_gpfn(d)) )
 goto setmemtype_fail;

-if ( a.hvmmem_type >= ARRAY_SIZE(memtype) )
+ 

Re: [Xen-devel] [PATCH v2] docs: update FLASK cmd line instructions

[Wei Liu]

On Mon, Apr 25, 2016 at 04:34:06PM +0100, Wei Liu wrote:
> On Mon, Apr 25, 2016 at 11:24:59AM -0400, Daniel De Graaf wrote:
> > On 04/25/2016 08:17 AM, Jan Beulich wrote:
> > On 18.03.16 at 17:46,  wrote:
> > >>The command line instructions for FLASK include a note on how to compile
> > >>Xen with FLASK but the note was out of date after the change to Kconfig.
> > >>
> > >>Signed-off-by: Doug Goldstein 
> > >>---
> > >>CC: Ian Jackson 
> > >>CC: Jan Beulich 
> > >>CC: Keir Fraser 
> > >>CC: Tim Deegan 
> > >>CC: Konrad Rzeszutek Wilk 
> > >>CC: Daniel De Graaf 
> > >
> > >Daniel,
> > >
> > >any chance we could get your ack (or otherwise) on this?
> > >
> > >Thanks, Jan
> > >
> > >
> > 
> > Sure, I didn't realize you were waiting on it.  The patch looks good.
> > 
> > Acked-by: Daniel De Graaf 
> > 
> 
> Thank you all. Queued.
> 

Strangely this patch doesn't apply cleanly for me. I fixed it up by
hand. Please check the patch in staging if you are keen. :-)

Wei.

> Wei.

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

Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

[George Dunlap]

On 25/04/16 16:53, Yu, Zhang wrote:
> 
> 
> On 4/25/2016 11:38 PM, Jan Beulich wrote:
> On 25.04.16 at 17:29,  wrote:
  -Original Message-
 From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
 Sent: 25 April 2016 16:22
 To: Paul Durrant; George Dunlap
 Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
 Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan; Jan Beulich; Wei Liu
 Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for
 4.7):
 Rename p2m_mmio_write_dm to p2m_ioreq_server.



 On 4/25/2016 10:01 PM, Paul Durrant wrote:
>> -Original Message-
>> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
>> George Dunlap
>> Sent: 25 April 2016 14:39
>> To: Yu Zhang
>> Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun
>> Nakajima;
>> Andrew Cooper; Tim (Xen.org); Paul Durrant; Lv, Zhiyuan; Jan
>> Beulich; Wei
 Liu
>> Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for
>> 4.7):
>> Rename p2m_mmio_write_dm to p2m_ioreq_server.
>>
>> On Mon, Apr 25, 2016 at 11:35 AM, Yu Zhang
 
>> wrote:
>>> Previously p2m type p2m_mmio_write_dm was introduced for write-
>>> protected memory pages whose write operations are supposed to be
>>> forwarded to and emulated by an ioreq server. Yet limitations of
>>> rangeset restrict the number of guest pages to be write-protected.
>>>
>>> This patch replaces the p2m type p2m_mmio_write_dm with a new
 name:
>>> p2m_ioreq_server, which means this p2m type can be claimed by one
>>> ioreq server, instead of being tracked inside the rangeset of ioreq
>>> server. Patches following up will add the related hvmop handling
>>> code which map/unmap type p2m_ioreq_server to/from an ioreq
 server.
>>>
>>> changes in v3:
>>>   - According to Jan & George's comments, keep
>> HVMMEM_mmio_write_dm
>>> for old xen interface versions, and replace it with
>>> HVMMEM_unused
>>> for xen interfaces newer than 4.7.0; For p2m_ioreq_server, a new
>>> enum - HVMMEM_ioreq_server is introduced for the get/set mem
 type
>>> interfaces;
>>>   - Add George's Reviewed-by and Acked-by from Tim & Andrew.
>>
>> Unfortunately these rather contradict each other -- I consider
>> Reviewed-by to only stick if the code I've specified hasn't changed
>> (or has only changed trivially).
>>
>> Also...
>>
>>>
>>> changes in v2:
>>>   - According to George Dunlap's comments, only rename the p2m type,
>>> with no behavior changes.
>>>
>>> Signed-off-by: Paul Durrant 
>>> Signed-off-by: Yu Zhang 
>>> Acked-by: Tim Deegan 
>>> Acked-by: Andrew Cooper 
>>> Reviewed-by: George Dunlap 
>>> Cc: Keir Fraser 
>>> Cc: Jan Beulich 
>>> Cc: Andrew Cooper 
>>> Cc: Jun Nakajima 
>>> Cc: Kevin Tian 
>>> Cc: George Dunlap 
>>> Cc: Tim Deegan 
>>> ---
>>>  xen/arch/x86/hvm/hvm.c  | 14 --
>>>  xen/arch/x86/mm/p2m-ept.c   |  2 +-
>>>  xen/arch/x86/mm/p2m-pt.c|  2 +-
>>>  xen/arch/x86/mm/shadow/multi.c  |  2 +-
>>>  xen/include/asm-x86/p2m.h   |  4 ++--
>>>  xen/include/public/hvm/hvm_op.h |  8 +++-
>>>  6 files changed, 20 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>>> index f24126d..874cb0f 100644
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -1857,7 +1857,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
>> unsigned long gla,
>>>   */
>>>  if ( (p2mt == p2m_mmio_dm) ||
>>>   (npfec.write_access &&
>>> -  (p2m_is_discard_write(p2mt) || (p2mt ==
 p2m_mmio_write_dm))) )
>>> +  (p2m_is_discard_write(p2mt) || (p2mt ==
>>> p2m_ioreq_server))) )
>>>  {
>>>  __put_gfn(p2m, gfn);
>>>  if ( ap2m_active )
>>> @@ -5499,8 +5499,8 @@ long do_hvm_op(unsigned long op,
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>  get_gfn_query_unlocked(d, a.pfn, );
>>>  if ( p2m_is_mmio(t) )
>>>  a.mem_type =  HVMMEM_mmio_dm;
>>> -else if ( t == p2m_mmio_write_dm )
>>> -a.mem_type = HVMMEM_mmio_write_dm;
>>> +else if ( t == p2m_ioreq_server )
>>> +a.mem_type = HVMMEM_ioreq_server;
>>>  else if ( p2m_is_readonly(t) )
>>>  

Re: [Xen-devel] [PATCH] docs/arm64: clarify the documention for loading XSM support

[Julien Grall]

Hi Ian,

On 25/04/16 16:35, Ian Jackson wrote:

From: Fu Wei 

Improve the clarity of the wording introduced in 67831c4c
"docs/arm64: update the documentation for loading XSM support"

Signed-off-by: Ian Jackson 
CC: Fu Wei 
CC: Julien Grall ,


Somehow, I am not in the mail CC. Maybe because of the "," at the end?

Otherwise, the text looks good to me. I have some questions about the 
formatting, see below.



CC: Stefano Stabellini 
---
  docs/misc/arm/device-tree/booting.txt |   31 ++-
  1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/docs/misc/arm/device-tree/booting.txt 
b/docs/misc/arm/device-tree/booting.txt
index cae46eda..f3179d6 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -26,19 +26,24 @@ Each node contains the following properties:
Xen will assume that the first module which lacks a more
specific compatible string is a "multiboot,kernel".

-   Xen will check all the modules for the XSM Magic from the second
-   module that lacks a specific compatible string. According to the
-   result of the detection:
-   - if it's an XSM, Xen will assume its compatible string is
- "xen,xsm-policy";
-   - if it's not an XSM, for the second module that lacks a specific
- compatible string, Xen will assume its compatible string is
- "multiboot,ramdisk"; the third and subsequent modules that
- lack a specific compatible string will not receive any special
- treatment.
-   This means that if the ramdisk module is present and does not have
-   the compatible string "multiboot,ramdisk", then it must always be
-   the second module.
+   Xen will examine each module, starting from the second
+   module that lacks a specific compatible string.  Xen will


NIT: there is 2 spaces rather than 1 before "Xen".


+check each such module for the XSM Magic number:


I am not sure sure why the extra spaces before "check"?


+
+   - For a module which has the XSM Magic number: it will be
+  treated by Xen as if its compatible string was
+  "xen,xsm-policy";


Ditto


+
+   - For a module which does not have the XSM Magic: the second
+  module lacking a compatible string will be treated by Xen as
+  if its compatible string was "multiboot,ramdisk"; for the
+  third and subsequent modules which lack a specific
+  compatible string, Xen will not apply any special treatment.


Ditto


+
+   This means if the ramdisk module is present and does not have the
+   compatible string "multiboot,ramdisk", then it must always be the
+   second module.
+
Note: This XSM Magic detection behavior was introduced by Xen 4.7.
Xen 4.6 (and downwards) still requires the XSM module to have the
compatible string "xen,xsm-policy".



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

[Yu, Zhang]

On 4/25/2016 11:38 PM, Jan Beulich wrote:

On 25.04.16 at 17:29,  wrote:

 -Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 25 April 2016 16:22
To: Paul Durrant; George Dunlap
Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan; Jan Beulich; Wei Liu
Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
Rename p2m_mmio_write_dm to p2m_ioreq_server.



On 4/25/2016 10:01 PM, Paul Durrant wrote:

-Original Message-
From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
George Dunlap
Sent: 25 April 2016 14:39
To: Yu Zhang
Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
Andrew Cooper; Tim (Xen.org); Paul Durrant; Lv, Zhiyuan; Jan Beulich; Wei

Liu

Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
Rename p2m_mmio_write_dm to p2m_ioreq_server.

On Mon, Apr 25, 2016 at 11:35 AM, Yu Zhang



wrote:

Previously p2m type p2m_mmio_write_dm was introduced for write-
protected memory pages whose write operations are supposed to be
forwarded to and emulated by an ioreq server. Yet limitations of
rangeset restrict the number of guest pages to be write-protected.

This patch replaces the p2m type p2m_mmio_write_dm with a new

name:

p2m_ioreq_server, which means this p2m type can be claimed by one
ioreq server, instead of being tracked inside the rangeset of ioreq
server. Patches following up will add the related hvmop handling
code which map/unmap type p2m_ioreq_server to/from an ioreq

server.


changes in v3:
  - According to Jan & George's comments, keep

HVMMEM_mmio_write_dm

for old xen interface versions, and replace it with HVMMEM_unused
for xen interfaces newer than 4.7.0; For p2m_ioreq_server, a new
enum - HVMMEM_ioreq_server is introduced for the get/set mem

type

interfaces;
  - Add George's Reviewed-by and Acked-by from Tim & Andrew.


Unfortunately these rather contradict each other -- I consider
Reviewed-by to only stick if the code I've specified hasn't changed
(or has only changed trivially).

Also...



changes in v2:
  - According to George Dunlap's comments, only rename the p2m type,
with no behavior changes.

Signed-off-by: Paul Durrant 
Signed-off-by: Yu Zhang 
Acked-by: Tim Deegan 
Acked-by: Andrew Cooper 
Reviewed-by: George Dunlap 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Tim Deegan 
---
 xen/arch/x86/hvm/hvm.c  | 14 --
 xen/arch/x86/mm/p2m-ept.c   |  2 +-
 xen/arch/x86/mm/p2m-pt.c|  2 +-
 xen/arch/x86/mm/shadow/multi.c  |  2 +-
 xen/include/asm-x86/p2m.h   |  4 ++--
 xen/include/public/hvm/hvm_op.h |  8 +++-
 6 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index f24126d..874cb0f 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1857,7 +1857,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,

unsigned long gla,

  */
 if ( (p2mt == p2m_mmio_dm) ||
  (npfec.write_access &&
-  (p2m_is_discard_write(p2mt) || (p2mt ==

p2m_mmio_write_dm))) )

+  (p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
 {
 __put_gfn(p2m, gfn);
 if ( ap2m_active )
@@ -5499,8 +5499,8 @@ long do_hvm_op(unsigned long op,

XEN_GUEST_HANDLE_PARAM(void) arg)

 get_gfn_query_unlocked(d, a.pfn, );
 if ( p2m_is_mmio(t) )
 a.mem_type =  HVMMEM_mmio_dm;
-else if ( t == p2m_mmio_write_dm )
-a.mem_type = HVMMEM_mmio_write_dm;
+else if ( t == p2m_ioreq_server )
+a.mem_type = HVMMEM_ioreq_server;
 else if ( p2m_is_readonly(t) )
 a.mem_type =  HVMMEM_ram_ro;
 else if ( p2m_is_ram(t) )
@@ -5531,7 +5531,8 @@ long do_hvm_op(unsigned long op,

XEN_GUEST_HANDLE_PARAM(void) arg)

 [HVMMEM_ram_rw]  = p2m_ram_rw,
 [HVMMEM_ram_ro]  = p2m_ram_ro,
 [HVMMEM_mmio_dm] = p2m_mmio_dm,
-[HVMMEM_mmio_write_dm] = p2m_mmio_write_dm
+[HVMMEM_unused] = p2m_invalid,
+[HVMMEM_ioreq_server] = p2m_ioreq_server
 };

 if ( copy_from_guest(, arg, 1) )
@@ -,7 +5556,8 @@ long do_hvm_op(unsigned long op,

XEN_GUEST_HANDLE_PARAM(void) arg)

  ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d)) )
 goto setmemtype_fail;

-if ( a.hvmmem_type >= ARRAY_SIZE(memtype) )
+if ( a.hvmmem_type >= ARRAY_SIZE(memtype) ||
+ 

[Xen-devel] [xen-4.3-testing test] 92677: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 87893
 build-i3863 host-install(3) broken REGR. vs. 87893
 build-amd64   3 host-install(3) broken REGR. vs. 87893
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 87893

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-rumpuserxen1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 build-check(1)  blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass
 test-armhf-armhf-xl   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt  6 xen-boot fail   never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass

version targeted for testing:
 xen  c04846eeb3d96cf670dc5894b66f3f6e61c2531d
baseline version:
 xen  8fa31952e2d08ef63897c43b5e8b33475ebf5d93

Last test of basis87893  2016-03-29 13:49:52 Z   27 days
Testing same since92180  2016-04-20 17:49:21 Z4 days   11 attempts

Re: [Xen-devel] [PATCH 9] xSplice v1 design and implementation.

[Jan Beulich]

>>> On 25.04.16 at 17:47,  wrote:
> On Mon, Apr 25, 2016 at 11:41 AM, Jan Beulich  wrote:
> On 25.04.16 at 17:34,  wrote:
>>> Hey!
>>>
>>> Changelog:
>>> v8.1: http://lists.xen.org/archives/html/xen-devel/2016-04/msg01903.html 
>>
>> Old changelog?
>>
> 
> It should have said: "Since v8.1:":

Ah, okay. No need for anything else if detail are in each patch.

Jan

>  Worked on Jan's comments.
> 
> I could enumerate _all_ of them here if you would like? But figured it
> would be easier to have them patch-by-patch? What is your preference?
> Both places?
> And if here - enumerate also by patch number?




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

Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

[Yu, Zhang]

On 4/25/2016 11:29 PM, Paul Durrant wrote:

-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 25 April 2016 16:22
To: Paul Durrant; George Dunlap
Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan; Jan Beulich; Wei Liu
Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
Rename p2m_mmio_write_dm to p2m_ioreq_server.



On 4/25/2016 10:01 PM, Paul Durrant wrote:

-Original Message-
From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
George Dunlap
Sent: 25 April 2016 14:39
To: Yu Zhang
Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
Andrew Cooper; Tim (Xen.org); Paul Durrant; Lv, Zhiyuan; Jan Beulich; Wei

Liu

Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
Rename p2m_mmio_write_dm to p2m_ioreq_server.

On Mon, Apr 25, 2016 at 11:35 AM, Yu Zhang



wrote:

Previously p2m type p2m_mmio_write_dm was introduced for write-
protected memory pages whose write operations are supposed to be
forwarded to and emulated by an ioreq server. Yet limitations of
rangeset restrict the number of guest pages to be write-protected.

This patch replaces the p2m type p2m_mmio_write_dm with a new

name:

p2m_ioreq_server, which means this p2m type can be claimed by one
ioreq server, instead of being tracked inside the rangeset of ioreq
server. Patches following up will add the related hvmop handling
code which map/unmap type p2m_ioreq_server to/from an ioreq

server.


changes in v3:
  - According to Jan & George's comments, keep

HVMMEM_mmio_write_dm

for old xen interface versions, and replace it with HVMMEM_unused
for xen interfaces newer than 4.7.0; For p2m_ioreq_server, a new
enum - HVMMEM_ioreq_server is introduced for the get/set mem

type

interfaces;
  - Add George's Reviewed-by and Acked-by from Tim & Andrew.


Unfortunately these rather contradict each other -- I consider
Reviewed-by to only stick if the code I've specified hasn't changed
(or has only changed trivially).

Also...



changes in v2:
  - According to George Dunlap's comments, only rename the p2m type,
with no behavior changes.

Signed-off-by: Paul Durrant 
Signed-off-by: Yu Zhang 
Acked-by: Tim Deegan 
Acked-by: Andrew Cooper 
Reviewed-by: George Dunlap 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Tim Deegan 
---
 xen/arch/x86/hvm/hvm.c  | 14 --
 xen/arch/x86/mm/p2m-ept.c   |  2 +-
 xen/arch/x86/mm/p2m-pt.c|  2 +-
 xen/arch/x86/mm/shadow/multi.c  |  2 +-
 xen/include/asm-x86/p2m.h   |  4 ++--
 xen/include/public/hvm/hvm_op.h |  8 +++-
 6 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index f24126d..874cb0f 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1857,7 +1857,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,

unsigned long gla,

  */
 if ( (p2mt == p2m_mmio_dm) ||
  (npfec.write_access &&
-  (p2m_is_discard_write(p2mt) || (p2mt ==

p2m_mmio_write_dm))) )

+  (p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
 {
 __put_gfn(p2m, gfn);
 if ( ap2m_active )
@@ -5499,8 +5499,8 @@ long do_hvm_op(unsigned long op,

XEN_GUEST_HANDLE_PARAM(void) arg)

 get_gfn_query_unlocked(d, a.pfn, );
 if ( p2m_is_mmio(t) )
 a.mem_type =  HVMMEM_mmio_dm;
-else if ( t == p2m_mmio_write_dm )
-a.mem_type = HVMMEM_mmio_write_dm;
+else if ( t == p2m_ioreq_server )
+a.mem_type = HVMMEM_ioreq_server;
 else if ( p2m_is_readonly(t) )
 a.mem_type =  HVMMEM_ram_ro;
 else if ( p2m_is_ram(t) )
@@ -5531,7 +5531,8 @@ long do_hvm_op(unsigned long op,

XEN_GUEST_HANDLE_PARAM(void) arg)

 [HVMMEM_ram_rw]  = p2m_ram_rw,
 [HVMMEM_ram_ro]  = p2m_ram_ro,
 [HVMMEM_mmio_dm] = p2m_mmio_dm,
-[HVMMEM_mmio_write_dm] = p2m_mmio_write_dm
+[HVMMEM_unused] = p2m_invalid,
+[HVMMEM_ioreq_server] = p2m_ioreq_server
 };

 if ( copy_from_guest(, arg, 1) )
@@ -,7 +5556,8 @@ long do_hvm_op(unsigned long op,

XEN_GUEST_HANDLE_PARAM(void) arg)

  ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d)) )
 goto setmemtype_fail;

-if ( a.hvmmem_type >= ARRAY_SIZE(memtype) )
+if ( a.hvmmem_type >= ARRAY_SIZE(memtype) ||
+ unlikely(a.hvmmem_type == HVMMEM_unused) )
 goto setmemtype_fail;

Re: [Xen-devel] [PATCH v9 01/27] Revert "libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall"

[Wei Liu]

On Mon, Apr 25, 2016 at 09:48:37AM -0600, Jan Beulich wrote:
> >>> On 25.04.16 at 17:34,  wrote:
> > This reverts commit d275ec9ca8a86f7c9c213f3551194d471ce90fbd.
> > 
> > As we prefer to still utilize the old XENVER_ hypercall.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > Requested-and-acked-by: Jan Beulich 
> 
> Either I replied to the wrong one last time round, or this went into
> the wrong one - it really applies to 02/27. The one here needs a
> tools maintainer's ack.
> 

Thanks for prodding.

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

[Boris Ostrovsky]

On 04/25/2016 11:22 AM, Borislav Petkov wrote:

On Mon, Apr 25, 2016 at 10:42:15AM -0400, Boris Ostrovsky wrote:

Hmm... I thought that everything specified in boot.txt was ABI.

But those are not there.




https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/x86/boot.txt#n1060

and

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/x86/boot.txt#n1096

is what I was referring to.

-boris

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

Re: [Xen-devel] [PATCH v9 01/27] Revert "libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall"

[Jan Beulich]

>>> On 25.04.16 at 17:34,  wrote:
> This reverts commit d275ec9ca8a86f7c9c213f3551194d471ce90fbd.
> 
> As we prefer to still utilize the old XENVER_ hypercall.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> Requested-and-acked-by: Jan Beulich 

Either I replied to the wrong one last time round, or this went into
the wrong one - it really applies to 02/27. The one here needs a
tools maintainer's ack.

Jan


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

Re: [Xen-devel] [PATCH 9] xSplice v1 design and implementation.

[Konrad Rzeszutek Wilk]

On Mon, Apr 25, 2016 at 11:41 AM, Jan Beulich  wrote:
 On 25.04.16 at 17:34,  wrote:
>> Hey!
>>
>> Changelog:
>> v8.1: http://lists.xen.org/archives/html/xen-devel/2016-04/msg01903.html
>
> Old changelog?
>

It should have said: "Since v8.1:":
 Worked on Jan's comments.

I could enumerate _all_ of them here if you would like? But figured it
would be easier to have them patch-by-patch? What is your preference?
Both places?
And if here - enumerate also by patch number?

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

[Xen-devel] [PATCH v9 25/27] xsplice/xen_replace_world: Test-case for XSPLICE_ACTION_REPLACE

[Konrad Rzeszutek Wilk]

With this third payload one can do:

-bash-4.1# xen-xsplice load xen_hello_world.xsplice
Uploading xen_hello_world.xsplice (10148 bytes)
Performing check: completed
Performing apply:. completed

[xen_hello_world depends on hypervisor build-id]
-bash-4.1# xen-xsplice load xen_bye_world.xsplice
Uploading xen_bye_world.xsplice (7076 bytes)
Performing check: completed
Performing apply:. completed
[xen_bye_world depends on xen_hello_world build-id]
-bash-4.1# xen-xsplice upload xen_replace_world xen_replace_world.xsplice
Uploading xen_replace_world.xsplice (7148 bytes)
-bash-4.1# xen-xsplice list
 ID | status
+
xen_hello_world | APPLIED
xen_bye_world   | APPLIED
xen_replace_world   | CHECKED
-bash-4.1# xen-xsplice replace xen_replace_world
Performing replace:. completed
-bash-4.1# xl info | grep extra
xen_extra  : Hello Again World!
-bash-4.1# xen-xsplice list
 ID | status
+
xen_hello_world | CHECKED
xen_bye_world   | CHECKED
xen_replace_world   | APPLIED

and revert both of the previous payloads and apply
the xen_replace_world.

All the magic of this is in the Makefile - we extract
the build-id from the hypervisor (xen-syms) and jam it
in the xen_replace_world as .xsplice.depends.

We also make .old_addr be zero, forcing the hypervisor
to lookup the xen_extra_version.

Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 

---
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v4: New. Make the objcopy use -S to strip the name.
v7: Added Andrew's Reviewed-by
v9: Drop (unsignd long) casts on new_addr and old_addr as they are
void pointers.
Make the build section use $(XSPLICE_REPLACE)
Make the test-case include 
Don't set .old_addr - let the hypervisor look it up.
---
 .gitignore |  1 +
 xen/arch/x86/test/Makefile | 14 +++--
 xen/arch/x86/test/xen_replace_world.c  | 32 ++
 xen/arch/x86/test/xen_replace_world_func.c | 22 
 4 files changed, 67 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/x86/test/xen_replace_world.c
 create mode 100644 xen/arch/x86/test/xen_replace_world_func.c

diff --git a/.gitignore b/.gitignore
index 88cec1d..1b73293 100644
--- a/.gitignore
+++ b/.gitignore
@@ -249,6 +249,7 @@ xen/arch/x86/efi/mkreloc
 xen/arch/x86/test/config.h
 xen/arch/x86/test/xen_hello_world.xsplice
 xen/arch/x86/test/xen_bye_world.xsplice
+xen/arch/x86/test/xen_replace_world.xsplice
 xen/arch/*/efi/boot.c
 xen/arch/*/efi/compat.c
 xen/arch/*/efi/efi.h
diff --git a/xen/arch/x86/test/Makefile b/xen/arch/x86/test/Makefile
index 83d4c06..e7d75b9 100644
--- a/xen/arch/x86/test/Makefile
+++ b/xen/arch/x86/test/Makefile
@@ -7,15 +7,18 @@ CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ 
print "0x"$$2}')
 
 XSPLICE := xen_hello_world.xsplice
 XSPLICE_BYE := xen_bye_world.xsplice
+XSPLICE_REPLACE := xen_replace_world.xsplice
 
 default: xsplice
 
 install: xsplice
$(INSTALL_DATA) $(XSPLICE) $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE)
$(INSTALL_DATA) $(XSPLICE_BYE) $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE_BYE)
+   $(INSTALL_DATA) $(XSPLICE_REPLACE) 
$(DESTDIR)$(DEBUG_DIR)/$(XSPLICE_REPLACE)
 uninstall:
rm -f $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE)
rm -f $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE_BYE)
+   rm -f $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE_REPLACE)
 
 .PHONY: clean
 clean::
@@ -28,7 +31,7 @@ clean::
 .PHONY: config.h
 config.h: OLD_CODE_SZ=$(call CODE_SZ,$(BASEDIR)/xen-syms,xen_extra_version)
 config.h: NEW_CODE_SZ=$(call CODE_SZ,$<,xen_hello_world)
-config.h: xen_hello_world_func.o xen_bye_world_func.o
+config.h: xen_hello_world_func.o xen_bye_world_func.o xen_replace_world_func.o
(set -e; \
 echo "#define NEW_CODE_SZ $(NEW_CODE_SZ)"; \
 echo "#define OLD_CODE_SZ $(OLD_CODE_SZ)") > $@
@@ -73,6 +76,13 @@ $(XSPLICE_BYE): $(XSPLICE) config.h xen_bye_world_func.o 
xen_bye_world.o hello_w
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(XSPLICE_BYE) \
xen_bye_world_func.o xen_bye_world.o hello_world_note.o
 
+xen_replace_world.o: xen_replace_world_func.o
+
+.PHONY: $(XSPLICE_REPLACE)
+$(XSPLICE_REPLACE): config.h xen_replace_world_func.o xen_replace_world.o 
note.o
+   $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(XSPLICE_REPLACE) \
+xen_replace_world_func.o xen_replace_world.o note.o
+
 
 .PHONY: xsplice
-xsplice: $(XSPLICE) $(XSPLICE_BYE)
+xsplice: $(XSPLICE) $(XSPLICE_BYE) $(XSPLICE_REPLACE)
diff --git a/xen/arch/x86/test/xen_replace_world.c 

[Xen-devel] [PATCH v3] xen: arm: doc: Add firmware requirements

[Dirk Behme]

From: Dirk Behme 

Add a section about what the firmware should do in EL3 before starting Xen.

E.g guest will use HVC instruction to issue hypercall. As this can be set only
at EL3, i.e. outside Xen, document this boot requirement.

Signed-off-by: Dirk Behme 
---
 docs/misc/arm/booting.txt | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
index 9802e5e..c7c1d7e 100644
--- a/docs/misc/arm/booting.txt
+++ b/docs/misc/arm/booting.txt
@@ -23,6 +23,17 @@ The exceptions to this on 32-bit ARM are as follows:
 
 There are no exception on 64-bit ARM.
 
+
+Firmware/bootloader requirements
+
+
+Xen relies on some settings the firmware has to configure in EL3 before 
starting Xen.
+
+* Xen must be entered in NS EL2 mode
+
+* The bit SCR_EL3.HCR (resp. SCR.HCE for 32-bit ARM) must be set to 1.
+
+
 [1] linux/Documentation/arm/Booting
 Latest version: 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Booting
 
-- 
2.8.1


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

Re: [Xen-devel] [PATCH 9] xSplice v1 design and implementation.

[Jan Beulich]

>>> On 25.04.16 at 17:34,  wrote:
> Hey!
> 
> Changelog:
> v8.1: http://lists.xen.org/archives/html/xen-devel/2016-04/msg01903.html 

Old changelog?

Jan


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

Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

[Jan Beulich]

>>> On 25.04.16 at 17:29,  wrote:
>>  -Original Message-
>> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
>> Sent: 25 April 2016 16:22
>> To: Paul Durrant; George Dunlap
>> Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
>> Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan; Jan Beulich; Wei Liu
>> Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
>> Rename p2m_mmio_write_dm to p2m_ioreq_server.
>> 
>> 
>> 
>> On 4/25/2016 10:01 PM, Paul Durrant wrote:
>> >> -Original Message-
>> >> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
>> >> George Dunlap
>> >> Sent: 25 April 2016 14:39
>> >> To: Yu Zhang
>> >> Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
>> >> Andrew Cooper; Tim (Xen.org); Paul Durrant; Lv, Zhiyuan; Jan Beulich; Wei
>> Liu
>> >> Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
>> >> Rename p2m_mmio_write_dm to p2m_ioreq_server.
>> >>
>> >> On Mon, Apr 25, 2016 at 11:35 AM, Yu Zhang
>> 
>> >> wrote:
>> >>> Previously p2m type p2m_mmio_write_dm was introduced for write-
>> >>> protected memory pages whose write operations are supposed to be
>> >>> forwarded to and emulated by an ioreq server. Yet limitations of
>> >>> rangeset restrict the number of guest pages to be write-protected.
>> >>>
>> >>> This patch replaces the p2m type p2m_mmio_write_dm with a new
>> name:
>> >>> p2m_ioreq_server, which means this p2m type can be claimed by one
>> >>> ioreq server, instead of being tracked inside the rangeset of ioreq
>> >>> server. Patches following up will add the related hvmop handling
>> >>> code which map/unmap type p2m_ioreq_server to/from an ioreq
>> server.
>> >>>
>> >>> changes in v3:
>> >>>   - According to Jan & George's comments, keep
>> >> HVMMEM_mmio_write_dm
>> >>> for old xen interface versions, and replace it with HVMMEM_unused
>> >>> for xen interfaces newer than 4.7.0; For p2m_ioreq_server, a new
>> >>> enum - HVMMEM_ioreq_server is introduced for the get/set mem
>> type
>> >>> interfaces;
>> >>>   - Add George's Reviewed-by and Acked-by from Tim & Andrew.
>> >>
>> >> Unfortunately these rather contradict each other -- I consider
>> >> Reviewed-by to only stick if the code I've specified hasn't changed
>> >> (or has only changed trivially).
>> >>
>> >> Also...
>> >>
>> >>>
>> >>> changes in v2:
>> >>>   - According to George Dunlap's comments, only rename the p2m type,
>> >>> with no behavior changes.
>> >>>
>> >>> Signed-off-by: Paul Durrant 
>> >>> Signed-off-by: Yu Zhang 
>> >>> Acked-by: Tim Deegan 
>> >>> Acked-by: Andrew Cooper 
>> >>> Reviewed-by: George Dunlap 
>> >>> Cc: Keir Fraser 
>> >>> Cc: Jan Beulich 
>> >>> Cc: Andrew Cooper 
>> >>> Cc: Jun Nakajima 
>> >>> Cc: Kevin Tian 
>> >>> Cc: George Dunlap 
>> >>> Cc: Tim Deegan 
>> >>> ---
>> >>>  xen/arch/x86/hvm/hvm.c  | 14 --
>> >>>  xen/arch/x86/mm/p2m-ept.c   |  2 +-
>> >>>  xen/arch/x86/mm/p2m-pt.c|  2 +-
>> >>>  xen/arch/x86/mm/shadow/multi.c  |  2 +-
>> >>>  xen/include/asm-x86/p2m.h   |  4 ++--
>> >>>  xen/include/public/hvm/hvm_op.h |  8 +++-
>> >>>  6 files changed, 20 insertions(+), 12 deletions(-)
>> >>>
>> >>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> >>> index f24126d..874cb0f 100644
>> >>> --- a/xen/arch/x86/hvm/hvm.c
>> >>> +++ b/xen/arch/x86/hvm/hvm.c
>> >>> @@ -1857,7 +1857,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
>> >> unsigned long gla,
>> >>>   */
>> >>>  if ( (p2mt == p2m_mmio_dm) ||
>> >>>   (npfec.write_access &&
>> >>> -  (p2m_is_discard_write(p2mt) || (p2mt ==
>> p2m_mmio_write_dm))) )
>> >>> +  (p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
>> >>>  {
>> >>>  __put_gfn(p2m, gfn);
>> >>>  if ( ap2m_active )
>> >>> @@ -5499,8 +5499,8 @@ long do_hvm_op(unsigned long op,
>> >> XEN_GUEST_HANDLE_PARAM(void) arg)
>> >>>  get_gfn_query_unlocked(d, a.pfn, );
>> >>>  if ( p2m_is_mmio(t) )
>> >>>  a.mem_type =  HVMMEM_mmio_dm;
>> >>> -else if ( t == p2m_mmio_write_dm )
>> >>> -a.mem_type = HVMMEM_mmio_write_dm;
>> >>> +else if ( t == p2m_ioreq_server )
>> >>> +a.mem_type = HVMMEM_ioreq_server;
>> >>>  else if ( p2m_is_readonly(t) )
>> >>>  a.mem_type =  HVMMEM_ram_ro;
>> >>>  else if ( p2m_is_ram(t) )
>> >>> @@ -5531,7 +5531,8 @@ long do_hvm_op(unsigned long op,
>> >> XEN_GUEST_HANDLE_PARAM(void) arg)
>> >>>  [HVMMEM_ram_rw]  = p2m_ram_rw,
>> >>>  

Re: [Xen-devel] [PATCH v2] docs: update FLASK cmd line instructions

[Wei Liu]

On Mon, Apr 25, 2016 at 11:24:59AM -0400, Daniel De Graaf wrote:
> On 04/25/2016 08:17 AM, Jan Beulich wrote:
> On 18.03.16 at 17:46,  wrote:
> >>The command line instructions for FLASK include a note on how to compile
> >>Xen with FLASK but the note was out of date after the change to Kconfig.
> >>
> >>Signed-off-by: Doug Goldstein 
> >>---
> >>CC: Ian Jackson 
> >>CC: Jan Beulich 
> >>CC: Keir Fraser 
> >>CC: Tim Deegan 
> >>CC: Konrad Rzeszutek Wilk 
> >>CC: Daniel De Graaf 
> >
> >Daniel,
> >
> >any chance we could get your ack (or otherwise) on this?
> >
> >Thanks, Jan
> >
> >
> 
> Sure, I didn't realize you were waiting on it.  The patch looks good.
> 
> Acked-by: Daniel De Graaf 
> 

Thank you all. Queued.

Wei.

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

Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

[Paul Durrant]

> -Original Message-
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 25 April 2016 16:22
> To: Paul Durrant; George Dunlap
> Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
> Andrew Cooper; Tim (Xen.org); Lv, Zhiyuan; Jan Beulich; Wei Liu
> Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
> Rename p2m_mmio_write_dm to p2m_ioreq_server.
> 
> 
> 
> On 4/25/2016 10:01 PM, Paul Durrant wrote:
> >> -Original Message-
> >> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
> >> George Dunlap
> >> Sent: 25 April 2016 14:39
> >> To: Yu Zhang
> >> Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
> >> Andrew Cooper; Tim (Xen.org); Paul Durrant; Lv, Zhiyuan; Jan Beulich; Wei
> Liu
> >> Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
> >> Rename p2m_mmio_write_dm to p2m_ioreq_server.
> >>
> >> On Mon, Apr 25, 2016 at 11:35 AM, Yu Zhang
> 
> >> wrote:
> >>> Previously p2m type p2m_mmio_write_dm was introduced for write-
> >>> protected memory pages whose write operations are supposed to be
> >>> forwarded to and emulated by an ioreq server. Yet limitations of
> >>> rangeset restrict the number of guest pages to be write-protected.
> >>>
> >>> This patch replaces the p2m type p2m_mmio_write_dm with a new
> name:
> >>> p2m_ioreq_server, which means this p2m type can be claimed by one
> >>> ioreq server, instead of being tracked inside the rangeset of ioreq
> >>> server. Patches following up will add the related hvmop handling
> >>> code which map/unmap type p2m_ioreq_server to/from an ioreq
> server.
> >>>
> >>> changes in v3:
> >>>   - According to Jan & George's comments, keep
> >> HVMMEM_mmio_write_dm
> >>> for old xen interface versions, and replace it with HVMMEM_unused
> >>> for xen interfaces newer than 4.7.0; For p2m_ioreq_server, a new
> >>> enum - HVMMEM_ioreq_server is introduced for the get/set mem
> type
> >>> interfaces;
> >>>   - Add George's Reviewed-by and Acked-by from Tim & Andrew.
> >>
> >> Unfortunately these rather contradict each other -- I consider
> >> Reviewed-by to only stick if the code I've specified hasn't changed
> >> (or has only changed trivially).
> >>
> >> Also...
> >>
> >>>
> >>> changes in v2:
> >>>   - According to George Dunlap's comments, only rename the p2m type,
> >>> with no behavior changes.
> >>>
> >>> Signed-off-by: Paul Durrant 
> >>> Signed-off-by: Yu Zhang 
> >>> Acked-by: Tim Deegan 
> >>> Acked-by: Andrew Cooper 
> >>> Reviewed-by: George Dunlap 
> >>> Cc: Keir Fraser 
> >>> Cc: Jan Beulich 
> >>> Cc: Andrew Cooper 
> >>> Cc: Jun Nakajima 
> >>> Cc: Kevin Tian 
> >>> Cc: George Dunlap 
> >>> Cc: Tim Deegan 
> >>> ---
> >>>  xen/arch/x86/hvm/hvm.c  | 14 --
> >>>  xen/arch/x86/mm/p2m-ept.c   |  2 +-
> >>>  xen/arch/x86/mm/p2m-pt.c|  2 +-
> >>>  xen/arch/x86/mm/shadow/multi.c  |  2 +-
> >>>  xen/include/asm-x86/p2m.h   |  4 ++--
> >>>  xen/include/public/hvm/hvm_op.h |  8 +++-
> >>>  6 files changed, 20 insertions(+), 12 deletions(-)
> >>>
> >>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> >>> index f24126d..874cb0f 100644
> >>> --- a/xen/arch/x86/hvm/hvm.c
> >>> +++ b/xen/arch/x86/hvm/hvm.c
> >>> @@ -1857,7 +1857,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
> >> unsigned long gla,
> >>>   */
> >>>  if ( (p2mt == p2m_mmio_dm) ||
> >>>   (npfec.write_access &&
> >>> -  (p2m_is_discard_write(p2mt) || (p2mt ==
> p2m_mmio_write_dm))) )
> >>> +  (p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
> >>>  {
> >>>  __put_gfn(p2m, gfn);
> >>>  if ( ap2m_active )
> >>> @@ -5499,8 +5499,8 @@ long do_hvm_op(unsigned long op,
> >> XEN_GUEST_HANDLE_PARAM(void) arg)
> >>>  get_gfn_query_unlocked(d, a.pfn, );
> >>>  if ( p2m_is_mmio(t) )
> >>>  a.mem_type =  HVMMEM_mmio_dm;
> >>> -else if ( t == p2m_mmio_write_dm )
> >>> -a.mem_type = HVMMEM_mmio_write_dm;
> >>> +else if ( t == p2m_ioreq_server )
> >>> +a.mem_type = HVMMEM_ioreq_server;
> >>>  else if ( p2m_is_readonly(t) )
> >>>  a.mem_type =  HVMMEM_ram_ro;
> >>>  else if ( p2m_is_ram(t) )
> >>> @@ -5531,7 +5531,8 @@ long do_hvm_op(unsigned long op,
> >> XEN_GUEST_HANDLE_PARAM(void) arg)
> >>>  [HVMMEM_ram_rw]  = p2m_ram_rw,
> >>>  [HVMMEM_ram_ro]  = p2m_ram_ro,
> >>>  [HVMMEM_mmio_dm] = p2m_mmio_dm,
> >>> -[HVMMEM_mmio_write_dm] = p2m_mmio_write_dm
> >>> +[HVMMEM_unused] = 

[Xen-devel] [PATCH v9 02/27] Revert "HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."

[Konrad Rzeszutek Wilk]

This reverts commit 2716d875379d538c1dfccad78a99ca7db2e09f90.

As it was decided that the existing XENVER hypercall - while having
grown organically over the years can still be expanded.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 tools/flask/policy/policy/modules/xen/xen.te |   7 +-
 xen/arch/arm/traps.c |   1 -
 xen/arch/x86/hvm/hvm.c   |   1 -
 xen/arch/x86/x86_64/compat/entry.S   |   2 -
 xen/arch/x86/x86_64/entry.S  |   2 -
 xen/common/compat/kernel.c   |   2 -
 xen/common/kernel.c  | 212 +--
 xen/include/public/arch-arm.h|   2 -
 xen/include/public/version.h |  72 +
 xen/include/public/xen.h |   1 -
 xen/include/xen/hypercall.h  |   4 -
 xen/include/xsm/dummy.h  |  21 ---
 xen/include/xsm/xsm.h|   6 -
 xen/xsm/dummy.c  |   1 -
 xen/xsm/flask/hooks.c|  35 -
 xen/xsm/flask/policy/access_vectors  |  21 +--
 16 files changed, 43 insertions(+), 347 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
b/tools/flask/policy/policy/modules/xen/xen.te
index a551756..2a2630d 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -76,12 +76,11 @@ allow dom0_t xen_t:xen2 {
 get_cpu_featureset
 };
 
-# Allow dom0 to use all XENVER_ subops and VERSION subops that have checks.
+# Allow dom0 to use all XENVER_ subops that have checks.
 # Note that dom0 is part of domain_type so this has duplicates.
 allow dom0_t xen_t:version {
 xen_extraversion xen_compile_info xen_capabilities
 xen_changeset xen_pagesize xen_guest_handle xen_commandline
-extraversion capabilities changeset pagesize guest_handle commandline
 };
 
 allow dom0_t xen_t:mmu memorymap;
@@ -148,12 +147,10 @@ if (guest_writeconsole) {
 # pmu_ctrl is for)
 allow domain_type xen_t:xen2 pmu_use;
 
-# For normal guests all possible except XENVER_commandline, VERSION_changeset,
-# and VERSION_commandline
+# For normal guests all possible except XENVER_commandline.
 allow domain_type xen_t:version {
 xen_extraversion xen_compile_info xen_capabilities
 xen_changeset xen_pagesize xen_guest_handle
-extraversion capabilities pagesize guest_handle
 };
 
 ###
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 1516abd..9abfc3c 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1274,7 +1274,6 @@ static arm_hypercall_t arm_hypercall_table[] = {
 HYPERCALL(multicall, 2),
 HYPERCALL(platform_op, 1),
 HYPERCALL_ARM(vcpu_op, 3),
-HYPERCALL(version_op, 3),
 };
 
 #ifndef NDEBUG
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e9d4c6b..8cb6e9e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4053,7 +4053,6 @@ static const struct {
 COMPAT_CALL(platform_op),
 COMPAT_CALL(mmuext_op),
 HYPERCALL(xenpmu_op),
-HYPERCALL(version_op),
 HYPERCALL(arch_1)
 };
 
diff --git a/xen/arch/x86/x86_64/compat/entry.S 
b/xen/arch/x86/x86_64/compat/entry.S
index 0ff6818..6ca4a54 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -399,7 +399,6 @@ ENTRY(compat_hypercall_table)
 .quad do_tmem_op
 .quad do_ni_hypercall   /* reserved for XenClient */
 .quad do_xenpmu_op  /* 40 */
-.quad do_version_op
 .rept __HYPERVISOR_arch_0-((.-compat_hypercall_table)/8)
 .quad compat_ni_hypercall
 .endr
@@ -451,7 +450,6 @@ ENTRY(compat_hypercall_args_table)
 .byte 1 /* do_tmem_op   */
 .byte 0 /* reserved for XenClient   */
 .byte 2 /* do_xenpmu_op */  /* 40 */
-.byte 3 /* do_version_op*/
 .rept __HYPERVISOR_arch_0-(.-compat_hypercall_args_table)
 .byte 0 /* compat_ni_hypercall  */
 .endr
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 6866e8f..d0f3259 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -735,7 +735,6 @@ ENTRY(hypercall_table)
 .quad do_tmem_op
 .quad do_ni_hypercall   /* reserved for XenClient */
 .quad do_xenpmu_op  /* 40 */
-.quad do_version_op
 .rept __HYPERVISOR_arch_0-((.-hypercall_table)/8)
 .quad do_ni_hypercall
 .endr
@@ -787,7 +786,6 @@ ENTRY(hypercall_args_table)
 .byte 1 /* do_tmem_op   */
 .byte 0 /* reserved for XenClient */
 .byte 2 /* do_xenpmu_op */  /* 40 */
-.byte 3 /* do_version_op*/
 .rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
 .byte 0 /* do_ni_hypercall  

[Xen-devel] [PATCH v9 09/27] x86/mm: Introduce modify_xen_mappings()

[Konrad Rzeszutek Wilk]

From: Andrew Cooper 

To simply change the permissions on existing Xen mappings.  The existing
destroy_xen_mappings() is altered to support changing the PTE permissions.

A new destroy_xen_mappings() is introduced, as the special case of not passing
_PAGE_PRESENT to modify_xen_mappings().

As cleanup (and an ideal functional test), the boot logic which remaps Xen's
code and data with reduced permissions is altered to use
modify_xen_mappings(), rather than map_pages_to_xen() passing the same mfn's
back in.

Signed-off-by: Andrew Cooper 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: George Dunlap 
Reviewed-by: Jan Beulich 

---
CC: Jan Beulich 
CC: George Dunlap 

v7: New
v8:
 * Allow callers to pass PAGE_HYPERVISOR_xxx constants, for consistently with
   similar functions.
 * Replace one opencoded 0 with its logical equivalent, _PAGE_NONE.
 * Add check for creating new mappings of 4K entries.
 * Correct the continue logic.  Invert the sense of the comment to match the
   code.
 * Added Reviewed-by George and Jan. Fix missing "are" in comment.
v9: Add missing second 'are'.
---
---
 xen/arch/x86/mm.c| 75 +---
 xen/arch/x86/setup.c | 22 +++
 xen/include/xen/mm.h |  2 ++
 3 files changed, 76 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 633f0dc..2bb920b 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5956,7 +5956,19 @@ int populate_pt_range(unsigned long virt, unsigned long 
mfn,
 return map_pages_to_xen(virt, mfn, nr_mfns, MAP_SMALL_PAGES);
 }
 
-void destroy_xen_mappings(unsigned long s, unsigned long e)
+/*
+ * Alter the permissions of a range of Xen virtual address space.
+ *
+ * Does not create new mappings, and does not modify the mfn in existing
+ * mappings, but will shatter superpages if necessary, and will destroy
+ * mappings if not passed _PAGE_PRESENT.
+ *
+ * The only flags considered are NX, RW and PRESENT.  All other input flags
+ * are ignored.
+ *
+ * It is an error to call with present flags over an unpopulated range.
+ */
+void modify_xen_mappings(unsigned long s, unsigned long e, unsigned int nf)
 {
 bool_t locking = system_state > SYS_STATE_boot;
 l2_pgentry_t *pl2e;
@@ -5964,6 +5976,10 @@ void destroy_xen_mappings(unsigned long s, unsigned long 
e)
 unsigned int  i;
 unsigned long v = s;
 
+/* Set of valid PTE bits which may be altered. */
+#define FLAGS_MASK (_PAGE_NX|_PAGE_RW|_PAGE_PRESENT)
+nf &= FLAGS_MASK;
+
 ASSERT(IS_ALIGNED(s, PAGE_SIZE));
 ASSERT(IS_ALIGNED(e, PAGE_SIZE));
 
@@ -5973,6 +5989,9 @@ void destroy_xen_mappings(unsigned long s, unsigned long 
e)
 
 if ( !(l3e_get_flags(*pl3e) & _PAGE_PRESENT) )
 {
+/* Confirm the caller isn't trying to create new mappings. */
+ASSERT(!(nf & _PAGE_PRESENT));
+
 v += 1UL << L3_PAGETABLE_SHIFT;
 v &= ~((1UL << L3_PAGETABLE_SHIFT) - 1);
 continue;
@@ -5984,8 +6003,12 @@ void destroy_xen_mappings(unsigned long s, unsigned long 
e)
  l1_table_offset(v) == 0 &&
  ((e - v) >= (1UL << L3_PAGETABLE_SHIFT)) )
 {
-/* PAGE1GB: whole superpage is destroyed. */
-l3e_write_atomic(pl3e, l3e_empty());
+/* PAGE1GB: whole superpage is modified. */
+l3_pgentry_t nl3e = !(nf & _PAGE_PRESENT) ? l3e_empty()
+: l3e_from_pfn(l3e_get_pfn(*pl3e),
+   (l3e_get_flags(*pl3e) & ~FLAGS_MASK) | nf);
+
+l3e_write_atomic(pl3e, nl3e);
 v += 1UL << L3_PAGETABLE_SHIFT;
 continue;
 }
@@ -6016,6 +6039,9 @@ void destroy_xen_mappings(unsigned long s, unsigned long 
e)
 
 if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
 {
+/* Confirm the caller isn't trying to create new mappings. */
+ASSERT(!(nf & _PAGE_PRESENT));
+
 v += 1UL << L2_PAGETABLE_SHIFT;
 v &= ~((1UL << L2_PAGETABLE_SHIFT) - 1);
 continue;
@@ -6026,8 +6052,12 @@ void destroy_xen_mappings(unsigned long s, unsigned long 
e)
 if ( (l1_table_offset(v) == 0) &&
  ((e-v) >= (1UL << L2_PAGETABLE_SHIFT)) )
 {
-/* PSE: whole superpage is destroyed. */
-l2e_write_atomic(pl2e, l2e_empty());
+/* PSE: whole superpage is modified. */
+l2_pgentry_t nl2e = !(nf & _PAGE_PRESENT) ? l2e_empty()
+: l2e_from_pfn(l2e_get_pfn(*pl2e),
+   (l2e_get_flags(*pl2e) & ~FLAGS_MASK) | nf);
+
+l2e_write_atomic(pl2e, nl2e);
 v += 1UL << L2_PAGETABLE_SHIFT;
 }
   

[Xen-devel] [PATCH] docs/arm64: clarify the documention for loading XSM support

[Ian Jackson]

From: Fu Wei 

Improve the clarity of the wording introduced in 67831c4c
"docs/arm64: update the documentation for loading XSM support"

Signed-off-by: Ian Jackson 
CC: Fu Wei 
CC: Julien Grall ,
CC: Stefano Stabellini 
---
 docs/misc/arm/device-tree/booting.txt |   31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/docs/misc/arm/device-tree/booting.txt 
b/docs/misc/arm/device-tree/booting.txt
index cae46eda..f3179d6 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -26,19 +26,24 @@ Each node contains the following properties:
Xen will assume that the first module which lacks a more
specific compatible string is a "multiboot,kernel".
 
-   Xen will check all the modules for the XSM Magic from the second
-   module that lacks a specific compatible string. According to the
-   result of the detection:
-   - if it's an XSM, Xen will assume its compatible string is
- "xen,xsm-policy";
-   - if it's not an XSM, for the second module that lacks a specific
- compatible string, Xen will assume its compatible string is
- "multiboot,ramdisk"; the third and subsequent modules that
- lack a specific compatible string will not receive any special
- treatment.
-   This means that if the ramdisk module is present and does not have
-   the compatible string "multiboot,ramdisk", then it must always be
-   the second module.
+   Xen will examine each module, starting from the second
+   module that lacks a specific compatible string.  Xen will
+check each such module for the XSM Magic number:
+
+   - For a module which has the XSM Magic number: it will be
+  treated by Xen as if its compatible string was
+  "xen,xsm-policy";
+
+   - For a module which does not have the XSM Magic: the second
+  module lacking a compatible string will be treated by Xen as
+  if its compatible string was "multiboot,ramdisk"; for the
+  third and subsequent modules which lack a specific
+  compatible string, Xen will not apply any special treatment.
+
+   This means if the ramdisk module is present and does not have the
+   compatible string "multiboot,ramdisk", then it must always be the
+   second module.
+
Note: This XSM Magic detection behavior was introduced by Xen 4.7.
Xen 4.6 (and downwards) still requires the XSM module to have the
compatible string "xen,xsm-policy".
-- 
1.7.10.4


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

[Xen-devel] [PATCH v9 08/27] arm/x86/vmap: Add v[z|m]alloc_xen and vm_init_type

[Konrad Rzeszutek Wilk]

For those users who want to use the virtual addresses that
are in the hypervisor's code/data region address space -
these three new functions allow that.

Implementation wise the vmap API keeps track of two virtual
address regions now:
 a) VMAP_VIRT_START
 b) Any provided virtual address space (need start and end).

The a) one is the default one and the existing behavior
for users of vmalloc, vmap, etc is the same.

If however one wishes to use the b) one only has to use
the vm_init_type to initialize and the v[m|z]alloc_xen to utilize
it (vfree is capable of searching both address spaces).

This allows users (such as xSplice) to provide their own
mechanism to change the the page flags, and also use virtual
addresses closer to the hypervisor virtual addresses (at least
on x86) while not having to deal with the allocation of
pages.

For example of users, see patch titled "xsplice: Implement payload
loading", where we parse the payload's ELF relocations - which
is defined to be signed 32-bit (on x86) (max displacement hence
is 2GB virtual space, ARM32 is 128MB). The displacement of the
hypervisor virtual addresses to the vmalloc (on x86)
is more than 32-bits - which means that ELF relocations would
truncate the 34 and 33th bit. Hence this alternate API.

We also add add extra checks in case the b) range has not been
initialized.

Part of this patch also removes 'vm_alloc' decleration as
we do not have any users of it - and if there ever will be - we
will have to expose and vm_alloc_xen variant.

Signed-off-by: Konrad Rzeszutek Wilk 
Suggested-by: Jan Beulich 
Acked-by: Julien Grall  [ARM]
Reviewed-by: Andrew Cooper 
Acked-by: Jan Beulich 

---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
Cc: Stefano Stabellini 
Cc: Julien Grall 

v4: New patch.
v5: Update per Jan's comments.
v6: Drop the stray parentheses on typedefs.
Ditch the vunmap callback. Stash away the virtual addresses in lists.
Ditch the vmap callback. Just provide virtual address.
Ditch the vmalloc_range. Require users of alternative virtual address
to call vmap_init_type first.
v7: Don't expose the vmalloc_type and such. Instead provide an wrapper
called vmalloc_xen for those.
Rename the enum, change one of the names.
Moved the vunmap_type around in c file so we don't have to declare
it in the header.
v9: Remove the vunmap_xen, removed vm_alloc from header.
Add vzalloc_xen
---
 xen/arch/arm/kernel.c   |   2 +-
 xen/arch/arm/mm.c   |   2 +-
 xen/arch/x86/mm.c   |   2 +-
 xen/common/virtual_region.c |   1 -
 xen/common/vmap.c   | 205 +++-
 xen/drivers/acpi/osl.c  |   2 +-
 xen/include/xen/vmap.h  |  22 -
 7 files changed, 150 insertions(+), 86 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 61808ac..9871bd9 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -299,7 +299,7 @@ static __init int kernel_decompress(struct bootmodule *mod)
 return -ENOMEM;
 }
 mfn = _mfn(page_to_mfn(pages));
-output = __vmap(, 1 << kernel_order_out, 1, 1, PAGE_HYPERVISOR);
+output = __vmap(, 1 << kernel_order_out, 1, 1, PAGE_HYPERVISOR, 
VMAP_DEFAULT);
 
 rc = perform_gunzip(output, input, size);
 clean_dcache_va_range(output, output_size);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7065c3e..94ea054 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -807,7 +807,7 @@ void *ioremap_attr(paddr_t pa, size_t len, unsigned int 
attributes)
 mfn_t mfn = _mfn(PFN_DOWN(pa));
 unsigned int offs = pa & (PAGE_SIZE - 1);
 unsigned int nr = PFN_UP(offs + len);
-void *ptr = __vmap(, nr, 1, 1, attributes);
+void *ptr = __vmap(, nr, 1, 1, attributes, VMAP_DEFAULT);
 
 if ( ptr == NULL )
 return NULL;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index ca26f49..633f0dc 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -6124,7 +6124,7 @@ void __iomem *ioremap(paddr_t pa, size_t len)
 unsigned int offs = pa & (PAGE_SIZE - 1);
 unsigned int nr = PFN_UP(offs + len);
 
-va = __vmap(, nr, 1, 1, PAGE_HYPERVISOR_NOCACHE) + offs;
+va = __vmap(, nr, 1, 1, PAGE_HYPERVISOR_NOCACHE, VMAP_DEFAULT) + 
offs;
 }
 
 return (void __force __iomem *)va;
diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c
index d75b75d..41f8c28 100644
--- a/xen/common/virtual_region.c
+++ b/xen/common/virtual_region.c
@@ -33,7 +33,6 @@ static struct virtual_region core_init __initdata = {
  * on deletion.
  *
  * All readers of virtual_region_list MUST use list list_for_each_entry_rcu.
- *
  */
 static LIST_HEAD(virtual_region_list);
 static 

[Xen-devel] [PATCH v9 26/27] xsplice: Prevent duplicate payloads from being loaded.

[Konrad Rzeszutek Wilk]

From: Ross Lagerwall 

Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 

---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 

v6: Drop recursive lock - also now the caller is holding the lock
Move the code up in the code above.
v7: Add Andrew's Reviewed-by
v9: Add const on struct payload.
Check data->id.len != payload->id.len in the loop
---
---
 xen/common/xsplice.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index a8b208d..b5e2135 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -520,6 +520,8 @@ static int prepare_payload(struct payload *payload,
 sec = xsplice_elf_sec_by_name(elf, ELF_BUILD_ID_NOTE);
 if ( sec )
 {
+const struct payload *data;
+
 n = sec->load_addr;
 
 if ( sec->sec->sh_size <= sizeof(*n) )
@@ -531,6 +533,20 @@ static int prepare_payload(struct payload *payload,
 
 if ( !payload->id.len || !payload->id.p )
 return -EINVAL;
+
+/* Make sure it is not a duplicate. */
+list_for_each_entry ( data, _list, list )
+{
+/* No way _this_ payload is on the list. */
+ASSERT(data != payload);
+if ( data->id.len != payload->id.len ||
+ !memcmp(data->id.p, payload->id.p, data->id.len) )
+{
+dprintk(XENLOG_DEBUG, XSPLICE "%s: Already loaded as %s!\n",
+elf->name, data->name);
+return -EEXIST;
+}
+}
 }
 
 sec = xsplice_elf_sec_by_name(elf, ELF_XSPLICE_DEPENDS);
-- 
2.5.0


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

[Xen-devel] [PATCH v9 14/27] xsplice, symbols: Implement symbol name resolution on address.

[Konrad Rzeszutek Wilk]

From: Ross Lagerwall 

If in the payload we do not have the old_addr we can resolve
the virtual address based on the UNDEFined symbols.

We also use an boolean flag: new_symbol to track symbols. The usual
case this is used is by:

* A payload may introduce a new symbol
* A payload may override an existing symbol (introduced in Xen or another
  payload)
* Overriding symbols must exist in the symtab for backtraces.
* A payload must always link against the object which defines the new symbol.

Considering that payloads may be loaded in any order it would be incorrect to
link against a payload which simply overrides a symbol because you could end
up with a chain of jumps which is inefficient and may result in the expected
function not being executed.

Since the payload we get is an relocatable image (partial linked ELF file)
we have to match up the symbols. We follow the ELF visibility rules for that
and for local symbols do what bintutils ld does.

Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ross Lagerwall 
Reviewed-by: Andrew Cooper 

---
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v1: Ross original version.
v2: Include test-case and document update.
v2: s/size_t/ssize_t/
Include core_text_size, core_text calculation
v4: Cast on dprintk to uint64_t to make ELF 32bit build.
v6: Rebase where the spinlock is no more recursive. Drop the spinlock
usage in xsplice_symbols_lookup_by_name
v7: Add Andrew's Reviewed-by
Initialize addr and symname to zero as xensyms_read uses it.
v8: Change one XENLOG_DEBUG to XENLOG_ERR.
Change printk to dprintk on symbols and one error case.
v9: 'new_addr' is now void, so change it to from unsigned long
to void *.
Include  header in test case.
Drop initialized for name in symbols_lookup_by_name.
Make ->symtab and ->strtab of struct payload const. As such
cast void* when freeing it.`
Drop 'size' from xsplice_symbol struct.
Make return value be void*
Make 'is_core_symbol' code have the same behavior as what binutils linker
has.
---
 xen/arch/x86/Makefile   |  16 +++-
 xen/arch/x86/platform_hypercall.c   |   5 +-
 xen/arch/x86/test/Makefile  |   4 +-
 xen/arch/x86/test/xen_hello_world.c |   3 +-
 xen/common/symbols.c|  36 +++-
 xen/common/xsplice.c| 179 +++-
 xen/common/xsplice_elf.c|  20 +++-
 xen/include/xen/elfstructs.h|   1 +
 xen/include/xen/symbols.h   |   4 +-
 xen/include/xen/xsplice.h   |   7 ++
 10 files changed, 259 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index f8f6eeb..fdf4202 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -72,6 +72,12 @@ efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h 
-o \
   -O $(BASEDIR)/include/xen/compile.h ]; then \
  echo '$(TARGET).efi'; fi)
 
+ifdef CONFIG_XSPLICE
+all_symbols = --all-symbols
+else
+all_symbols =
+endif
+
 $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x10 \
`$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
@@ -111,12 +117,14 @@ $(TARGET)-syms: prelink.o xen.lds 
$(BASEDIR)/common/symbols-dummy.o
$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
$(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
$(NM) -pa --format=sysv $(@D)/.$(@F).0 \
-   | $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).0.S
+   | $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort \
+   >$(@D)/.$(@F).0.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
$(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
$(NM) -pa --format=sysv $(@D)/.$(@F).1 \
-   | $(BASEDIR)/tools/symbols --sysv --sort --warn-dup 
>$(@D)/.$(@F).1.S
+   | $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort 
--warn-dup \
+   >$(@D)/.$(@F).1.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
$(@D)/.$(@F).1.o -o $@
@@ -140,14 +148,14 @@ $(TARGET).efi: prelink-efi.o efi.lds efi/relocs-dummy.o 
$(BASEDIR)/common/symbol
$(BASEDIR)/common/symbols-dummy.o -o 
$(@D)/.$(@F).$(base).0 &&) :
$(guard) efi/mkreloc $(foreach base,$(VIRT_BASE) 
$(ALT_BASE),$(@D)/.$(@F).$(base).0) >$(@D)/.$(@F).0r.S
$(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).0 \
-   | $(guard) $(BASEDIR)/tools/symbols --sysv --sort 
>$(@D)/.$(@F).0s.S
+   | $(guard) $(BASEDIR)/tools/symbols $(all_symbols) --sysv 
--sort >$(@D)/.$(@F).0s.S
$(guard) $(MAKE) -f 

[Xen-devel] [PATCH v9 21/27] xsplice: Print build_id in keyhandler and on bootup.

[Konrad Rzeszutek Wilk]

As it should be an useful debug mechanism.

Signed-off-by: Konrad Rzeszutek Wilk 
Acked-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

--
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 

v2: s/char */const void *
v5: s/ssize_t/unsigned int/
v6: Remove pointless initializers, use string literal instead of %s,
add Jan's Ack.
v7: Add Andrew's Reviewed-by
---
---
 xen/common/xsplice.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 05064ae..934dd22 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1363,10 +1364,15 @@ static const char *state2str(uint32_t state)
 static void xsplice_printall(unsigned char key)
 {
 struct payload *data;
+const void *binary_id = NULL;
+unsigned int len = 0;
 unsigned int i;
 
 printk("'%c' pressed - Dumping all xsplice patches\n", key);
 
+if ( !xen_build_id(_id, ) )
+printk("build-id: %*phN\n", len, binary_id);
+
 if ( !spin_trylock(_lock) )
 {
 printk("Lock held. Try again.\n");
@@ -1403,6 +1409,12 @@ static void xsplice_printall(unsigned char key)
 
 static int __init xsplice_init(void)
 {
+const void *binary_id;
+unsigned int len;
+
+if ( !xen_build_id(_id, ) )
+printk(XENLOG_INFO XSPLICE ": build-id: %*phN\n", len, binary_id);
+
 register_keyhandler('x', xsplice_printall, "print xsplicing info", 1);
 
 arch_xsplice_init();
-- 
2.5.0


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

[Xen-devel] [PATCH v9 23/27] libxl: info: Display build_id of the hypervisor.

[Konrad Rzeszutek Wilk]

If the hypervisor is built with we will display it.

Signed-off-by: Konrad Rzeszutek Wilk 
Acked-by: Wei Liu 

---
CC: Ian Jackson 
CC: Wei Liu 

v2: Include HAVE_*, use libxl_zalloc, s/rc/ret/
v3: Retry with different size if 1020 is not enough.
v4: Use VERSION_OP subops instead of the XENVER_ subops
v5: Change it per Wei's review. s/VERSION_OP/VERSION/
And actually use the proper Style!
v8: VERSION_OP was reverted, resurrect v3 version.
v9: Made the if (r) LOGEV adhere to StyleGuide
---
 tools/libxl/libxl.c | 44 
 tools/libxl/libxl.h |  6 ++
 tools/libxl/libxl_types.idl |  1 +
 tools/libxl/xl_cmdimpl.c|  1 +
 4 files changed, 52 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index eec899d..c39d745 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5353,6 +5353,38 @@ libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int 
*nr)
 return ret;
 }
 
+static const int libxl__xc_version_wrap(libxl__gc *gc, libxl_version_info 
*info,
+xen_build_id_t *build)
+{
+int r;
+
+r = xc_version(CTX->xch, XENVER_build_id, build);
+switch (r) {
+case -EPERM:
+case -ENODATA:
+case 0:
+info->build_id = libxl__strdup(NOGC, "");
+break;
+
+case -ENOBUFS:
+break;
+
+default:
+if (r > 0) {
+unsigned int i;
+
+info->build_id = libxl__zalloc(NOGC, (r * 2) + 1);
+
+for (i = 0; i < r ; i++)
+snprintf(>build_id[i * 2], 3, "%02hhx", build->buf[i]);
+
+r = 0;
+}
+break;
+}
+return r;
+}
+
 const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
 {
 GC_INIT(ctx);
@@ -5363,8 +5395,10 @@ const libxl_version_info* 
libxl_get_version_info(libxl_ctx *ctx)
 xen_capabilities_info_t xen_caps;
 xen_platform_parameters_t p_parms;
 xen_commandline_t xen_commandline;
+xen_build_id_t build_id;
 } u;
 long xen_version;
+int r;
 libxl_version_info *info = >version_info;
 
 if (info->xen_version_extra != NULL)
@@ -5397,6 +5431,16 @@ const libxl_version_info* 
libxl_get_version_info(libxl_ctx *ctx)
 xc_version(ctx->xch, XENVER_commandline, _commandline);
 info->commandline = libxl__strdup(NOGC, u.xen_commandline);
 
+u.build_id.len = sizeof(u) - sizeof(u.build_id);
+r = libxl__xc_version_wrap(gc, info, _id);
+if (r == -ENOBUFS) {
+xen_build_id_t *build_id;
+
+build_id = libxl__zalloc(gc, info->pagesize);
+build_id->len = info->pagesize - sizeof(*build_id);
+r = libxl__xc_version_wrap(gc, info, build_id);
+if (r) LOGEV(ERROR, r, "getting build_id");
+}
  out:
 GC_FREE;
 return info;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 8ff5f31..2c0f868 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -247,6 +247,12 @@
 #define LIBXL_HAVE_APIC_ASSIST 1
 
 /*
+ * LIBXL_HAVE_BUILD_ID means that libxl_version_info has the extra
+ * field for the hypervisor build_id.
+ */
+#define LIBXL_HAVE_BUILD_ID 1
+
+/*
  * libxl ABI compatibility
  *
  * The only guarantee which libxl makes regarding ABI compatibility
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index c3161f3..9840f3b 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -365,6 +365,7 @@ libxl_version_info = Struct("version_info", [
 ("virt_start",uint64),
 ("pagesize",  integer),
 ("commandline",   string),
+("build_id",  string),
 ], dir=DIR_OUT)
 
 libxl_domain_create_info = Struct("domain_create_info",[
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 6346017..ac7d759 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5920,6 +5920,7 @@ static void output_xeninfo(void)
 printf("cc_compile_by  : %s\n", info->compile_by);
 printf("cc_compile_domain  : %s\n", info->compile_domain);
 printf("cc_compile_date: %s\n", info->compile_date);
+printf("build_id   : %s\n", info->build_id);
 
 return;
 }
-- 
2.5.0


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

[Xen-devel] [PATCH v9 07/27] arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables lookup.

[Konrad Rzeszutek Wilk]

During execution of the hypervisor we have two regions of
executable code - stext -> _etext, and _sinittext -> _einitext.

The later is not needed after bootup.

We also have various built-in macros and functions to search
in between those two swaths depending on the state of the system.

That is either for bug_frames, exceptions (x86) or symbol
names for the instruction.

With xSplice in the picture - we need a mechanism for new payloads
to searched as well for all of this.

Originally we had extra 'if (xsplice)...' but that gets
a bit tiring and does not hook up nicely.

This 'struct virtual_region' and virtual_region_list provide a
mechanism to search for the bug_frames, exception table,
and symbol names entries without having various calls in
other sub-components in the system.

Code which wishes to participate in bug_frames and exception table
entries search has to only use two public APIs:
 - register_virtual_region
 - unregister_virtual_region

to let the core code know.

If the ->lookup_symbol is not then the default internal symbol lookup
mechanism is used.

Suggested-by: Andrew Cooper 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 
Acked-by: Julien Grall  [ARM]

---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v4: New patch.
v5:
 - Rename to virtual_region.
 - Ditch the 'skip' function.
 - Remove the _stext.
 - Use RCU lists.
 - Add a search function.
 - Remove extern, add rcu_read_lock. remove __ from name.
v6: s/search_for_text/find_text_region/.
 - Drop the uaccess.h need. Make setup_virtual_regions accept two parameters.
   Remove #ifdef.
 - Constify struct exception_table_entry.
 - Remove some newlines.
 - Change header file guard #define to proper name.
v9:
 - Proper #define (was missing _H)
 - s/big/bit/
 - Change 'start' and 'end' to void* to not do casting in xSplice code.
 - Make 'start' and 'end' be const void *.
---
 xen/arch/arm/setup.c |   4 ++
 xen/arch/arm/traps.c |  39 +++
 xen/arch/x86/extable.c   |  12 +++-
 xen/arch/x86/setup.c |   6 ++
 xen/arch/x86/traps.c |  40 ++-
 xen/common/Makefile  |   1 +
 xen/common/symbols.c |  11 ++-
 xen/common/virtual_region.c  | 148 +++
 xen/include/xen/symbols.h|   9 +++
 xen/include/xen/virtual_region.h |  47 +
 10 files changed, 280 insertions(+), 37 deletions(-)
 create mode 100644 xen/common/virtual_region.c
 create mode 100644 xen/include/xen/virtual_region.h

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 6d205a9..09ff1ea 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -860,6 +861,9 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 system_state = SYS_STATE_active;
 
+/* Must be done past setting system_state. */
+unregister_init_virtual_region();
+
 domain_unpause_by_systemcontroller(dom0);
 
 /* Switch on to the dynamically allocated stack for the idle vcpu
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9abfc3c..d9ffcc3 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -101,6 +102,8 @@ integer_param("debug_stack_lines", debug_stack_lines);
 
 void init_traps(void)
 {
+setup_virtual_regions(NULL, NULL);
+
 /* Setup Hyp vector base */
 WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
 
@@ -1116,27 +1119,33 @@ void do_unexpected_trap(const char *msg, struct 
cpu_user_regs *regs)
 
 int do_bug_frame(struct cpu_user_regs *regs, vaddr_t pc)
 {
-const struct bug_frame *bug;
+const struct bug_frame *bug = NULL;
 const char *prefix = "", *filename, *predicate;
 unsigned long fixup;
-int id, lineno;
-static const struct bug_frame *const stop_frames[] = {
-__stop_bug_frames_0,
-__stop_bug_frames_1,
-__stop_bug_frames_2,
-NULL
-};
+int id = -1, lineno;
+const struct virtual_region *region;
 
-for ( bug = __start_bug_frames, id = 0; stop_frames[id]; ++bug )
+region = find_text_region(pc);
+if ( region )
 {
-while ( unlikely(bug == stop_frames[id]) )
-++id;
+for ( id = 0; id < BUGFRAME_NR; id++ )
+{
+const struct bug_frame *b;
+unsigned int i;
 
-if ( ((vaddr_t)bug_loc(bug)) == pc )
-break;
+for ( i = 0, b = region->frame[id].bugs;
+  i < region->frame[id].n_bugs; b++, i++ )
+{
+if ( ((vaddr_t)bug_loc(b)) == pc )
+   

[Xen-devel] [PATCH v9 11/27] xsplice: Implement payload loading

[Konrad Rzeszutek Wilk]

From: Ross Lagerwall 

Add support for loading xsplice payloads. This is somewhat similar to
the Linux kernel module loader, implementing the following steps:
- Verify the elf file.
- Parse the elf file.
- Allocate a region of memory mapped within a free area of
  [xen_virt_end, XEN_VIRT_END].
- Copy allocated sections into the new region. Split them in three
  regions - .text, .data, and .rodata. MUST have at least .text.
- Resolve section symbols. All other symbols must be absolute addresses.
  (Note that patch titled "xsplice,symbols: Implement symbol name resolution
   on address" implements that)
- Perform relocations.
- Secure the the regions (.text,.data,.rodata) with proper permissions.

We capitalize on the vmalloc callback API (see patch titled:
"rm/x86/vmap: Add v[z|m]alloc_xen, and vm_init_type") to allocate
a region of memory within the [xen_virt_end, XEN_VIRT_END] for the code.

We also use the "x86/mm: Introduce modify_xen_mappings()"
to change the virtual address page-table permissions.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 
Acked-by: Julien Grall 

---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v2: - Change the 'xsplice_patch_func' structure layout/size.
- Add more error checking. Fix memory leak.
- Move elf_resolve and elf_perform relocs in elf file.
- Print the payload address and pages in keyhandler.
v3:
- Make it build under ARM
- Build it without using the return_ macro.
- Add fixes from Ross.
- Add the _return macro back - but only use it during debug builds.
- Remove the macro, prefix arch_ on arch specific calls.
v4:
- Move alloc_payload to arch specific file.
- Use void* instead of uint8_t, use const
- Add copyrights
- Unroll the vmap code to add ASSERT. Change while to not incur
  potential long error loop
   - Use vmalloc/vfree cb APIs
   - Secure .text pages to be RX instead of RWX.
v5:
  - Fix allocation of virtual addresses only allowing one page to be allocated.
  - Create .text, .data, and .rodata regions with different permissions.
  - Make the find_space_t not a typedef to pointer to a function.
  - Allocate memory in here.
v6: Drop parentheses on typedefs.
  - s/an xSplice/a xSplice/
  - Rebase on "vmap: Add vmalloc_cb"
  - Rebase on "vmap: Add vmalloc_type and vm_init_type"
  - s/uint8_t/void/ on load_addr
  - Set xsplice_elf on stack without using memset.
v7:
  - Changed the check on delta = elf->hdr->e_shoff + elf->hdr->e_shnum * 
elf->hdr->e_shentsize;
The sections can be right at the back of the file (different linker!), so 
the failing conditional
for 'if (delta >= elf->len)' is incorrect and should have been '>'.
  - Changed dprintk(XENLOG_DEBUG to XENLOG_ERR, then back to DEBUG. Converted
some of the printk to dprintk.
  - Rebase on " arm/x86/vmap: Add vmalloc_xen, vfree_xen and vm_init_type"
  - Changed some of the printk XENLOG_ERR to XENLOG_DEBUG
  - Check the idx in the relocation to make sure it is within bounds and
implemented.
  - Use "x86/mm: Introduce modify_xen_mappings()"
  - Introduce PRIxElfAddr
  - Check for overflow in R_X86_64_PC32
  - Return -EOPNOTSUPP if we don't support types in ELF64_R_TYPE
v8:
  - Change dprintk and printk XENLOG_DEBUG to XENLOG_ERR
  - Convert four of the printks in dprintk.
v9:
  - Rebase on different spinlock usage in xsplice_upload.
  - Do proper bound and overflow checking.
  - Added 'const' on [text,ro,rw]_addr.
  - Made 'calc_section' and 'move_payload' use an dynamically
allocated array for computed offsets instead of modifying sh_entsize.
  - Remove arch_xsplice_[alloc_payload|free] and use vzalloc_xen and
vfree.
  - Collapse for loop in move_payload.
  - Move xsplice.o in Makefile
  - Add more checks in arch_xsplice_perform_rela (r_offset and
 sh_size % sh_entsize)
  - Use int32_t and int64_t in arch_xsplice_perform_rela.
  - Tighten the list of sh_flags we check
  - Use intermediate on 'buf' so that we can do 'const void *'
  - Use intermediate in xsplice_elf_resolve_symbols for 'const' of elf->sym.
  - Fail if (and only) SHF_ALLOC and SHT_NOBITS section is seen.
---
 xen/arch/arm/Makefile |   1 +
 xen/arch/arm/xsplice.c|  45 
 xen/arch/x86/Makefile |   1 +
 xen/arch/x86/xsplice.c| 165 +
 xen/common/xsplice.c  | 234 --
 xen/common/xsplice_elf.c  | 120 +-
 xen/include/xen/elfstructs.h  |   4 +
 xen/include/xen/xsplice.h |  24 +
 xen/include/xen/xsplice_elf.h |  11 +-
 9 files changed, 595 insertions(+), 10 deletions(-)
 create mode 100644 

[Xen-devel] [PATCH v9 03/27] xsplice: Design document

[Konrad Rzeszutek Wilk]

A mechanism is required to binarily patch the running hypervisor with new
opcodes that have come about due to primarily security updates.

This document describes the design of the API that would allow us to
upload to the hypervisor binary patches.

This document has been shaped by the input from:
  Martin Pohlack 
  Jan Beulich 

Thank you!

Input-from: Martin Pohlack 
Input-from: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ross Lagerwall 
Acked-by: Ian Jackson 

---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 

v1-2: review
v3: Split document in v1 and v2 (todo) to simplify implementation goals.
 - Add const on some structures. Truncate size to uint16_t where it makes sense.
 - Convert 'id' to 'name', Add Ross's comments about what is implemented.
 - Wei's and Ross's reviews.
 - Jan's review comments.
 - Jan's review comments.
s/int32_t state/uint32_t state/ now that return code is in seperate
field (rc). Add various other types, such as R_X86_64_PC64 in the list.
Mention the need for compiler check.
v4:
 - Drop the LOADED->CHECKED state and go directly to CHECKED state. Drop
LOADED.
v5: Julien mentioned ARM 32-bit would not use ELF64, so make the .xsplice.func
use uintXX_t types instead of ELF ones. Remove the OUT on idx subfield.
Mention that 'nr' being zero can be used for probing the number of payloads.
Update what 'idx' means.
v6: Update what 'idx' means again!
Move the "Interdependencies section" to make it easier to in the design
doc the movement of text (when the patch implements it).
Add also 'version' field to payload.
v9:
   uint64_t to void in struct xsplice_patch_func. Also mention the size
   on 32 and 64 bit hypervisors.
   Make the padding be called opaque.
   Add symbol+offset to Todo
---
 docs/misc/xsplice.markdown | 1047 
 1 file changed, 1047 insertions(+)
 create mode 100644 docs/misc/xsplice.markdown

diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
new file mode 100644
index 000..99711bf
--- /dev/null
+++ b/docs/misc/xsplice.markdown
@@ -0,0 +1,1047 @@
+# xSplice Design v1
+
+## Rationale
+
+A mechanism is required to binarily patch the running hypervisor with new
+opcodes that have come about due to primarily security updates.
+
+This document describes the design of the API that would allow us to
+upload to the hypervisor binary patches.
+
+The document is split in four sections:
+
+ * Detailed descriptions of the problem statement.
+ * Design of the data structures.
+ * Design of the hypercalls.
+ * Implementation notes that should be taken into consideration.
+
+
+## Glossary
+
+ * splice - patch in the binary code with new opcodes
+ * trampoline - a jump to a new instruction.
+ * payload - telemetries of the old code along with binary blob of the new
+   function (if needed).
+ * reloc - telemetries contained in the payload to construct proper trampoline.
+
+## History
+
+The document has gone under various reviews and only covers v1 design.
+
+The end of the document has a section titled `Not Yet Done` which
+outlines ideas and design for the future version of this work.
+
+## Multiple ways to patch
+
+The mechanism needs to be flexible to patch the hypervisor in multiple ways
+and be as simple as possible. The compiled code is contiguous in memory with
+no gaps - so we have no luxury of 'moving' existing code and must either
+insert a trampoline to the new code to be executed - or only modify in-place
+the code if there is sufficient space. The placement of new code has to be done
+by hypervisor and the virtual address for the new code is allocated 
dynamically.
+
+This implies that the hypervisor must compute the new offsets when splicing
+in the new trampoline code. Where the trampoline is added (inside
+the function we are patching or just the callers?) is also important.
+
+To lessen the amount of code in hypervisor, the consumer of the API
+is responsible for identifying which mechanism to employ and how many locations
+to patch. Combinations of modifying in-place code, adding trampoline, etc
+has to be supported. The API should allow read/write any memory within
+the hypervisor virtual address space.
+
+We must also have a mechanism to query what has been applied and a mechanism
+to revert it if needed.
+
+## Workflow
+
+The expected workflows of higher-level tools that manage multiple patches
+on production machines would be:
+
+ * The first obvious task is loading all available / suggested
+   hotpatches when they are available.
+ * Whenever new hotpatches are installed, they should be loaded too.
+ * One wants to query which modules have been loaded at runtime.
+ * If unloading is deemed 

[Xen-devel] [PATCH v9 15/27] xsplice, symbols: Implement fast symbol names -> virtual addresses lookup

[Konrad Rzeszutek Wilk]

The current mechanism is geared towards fast virtual address ->
symbol names lookup. This is fine for the normal use cases
(BUG_ON, WARN_ON, etc), but for xSplice - where we need to find
hypervisor symbols - it is slow.

To understand this patch, a description of the existing
method is explained first. For folks familar go to 'NEW CODE:'.

HOW IT WORKS:

The symbol table lookup mechanism uses a simple encoding mechanism
where it extracts the common ascii characters that the symbol's use.

This saves us space. The lookup mechanism is geared towards looking
up symbols based on address. We have one 0..N (where N is
the number of symbols, so 6849 for example) table:

symbols_addresses[0..N]

And an 1-1 (in a loose fashion) of the symbols (encoded) in a
symbols_names stream of size N.

The N is variable (later on that below)

The symbols_names are sorted based on symbols_addresses, which
means that the decoded entries inside symbols_names are not in
ascending or descending order.

There is also the encoding mechanism - the table of 255 entries
called symbols_token_index[]. And the symbols_token_table which
is an stream of ASCIIZ characters, such as (it really
is not a table as the values are variable):

@0   .asciz  "credit"
@6   .asciz  "mask"
..
@300 .asciz  "S"

And the symbols_token_index:
@0.short  0
@1.short  7
@2.short  12
@4.short  16
...
@84 .short  300

The relationship between them is that the symbols_token_index
gives us the offset to symbols_token_table.

The symbol_names[] array is a stream of encoded values. Each value
follows the same pattern -  followed by .
And the another  followed by .

Hence to find the right one you need to read , add 
(to skip over), read , add , and so on until one
finds the right tuple offset.

The  are the indicies into the symbols_token_index.

Meaning if you have:
  0x04, 0x54, 0xda, 0xe2, 0x74
  [4, 84, 218, 226, 116 in human numbering]

The 0x04 tells us that the symbol is four bytes past this one (so next
symbol offset starts at 5). If we lookup symbols_token_index[84] we get 300.
symbols_token[300] gets us the "S". And so on, the string eventually
end up being decode to be 'S_stext'. The first character is the type,
then optionally follwed by the filename (and # right after filename)
and then lastly the symbol, such as:

tvpmu_intel.c#core2_vpmu_do_interrupt

Keep in mind that there are two fixed sized tables:
symbols_addresses[0..symbols_num_syms], and
symbols_markers[0..symbols_num_syms/255].

The symbols_markers is used to speed searching for the right address.
It gives us the offsets within symbol_names that start at the .

The way to find a symbol based on the address is:
1) Figure out the 'tuple offset' from symbols_address[0..symbols_num_syms].
   This table is sorted by virtual addresses so finding the value is simple.
2) Get starting offset of symbol_names by retrieving value of
   symbol_markers['tuple offset' / 255].
3). Iterate up to 'tuple_offset & 255' in symbols_markers stream starting
   at 'offset'.
4). Decode the 

This however does not work very well if we want to search the other
way - we have the symbol name and want to find the address.

NEW CODE:

To make that work we add one fixed size table called symbols_sorted_offsets 
which
has two elements: offset in symbol stream, offset in the symbol-address.

This whole array is sorted on the original symbol name during build-time
(in case of collision we also take into account the type).

The values are for example:

symbols_sorted_offsets:
.long 83363, 6302 # [.bss, len=5]
.long 80459, 6084 # [.data, len=5]
..
[The # added for clarity]

Which makes it incredibly easy to get in the symbols_names and also
symbols_addresses (or symbols_offsets)

Searching for symbols is simplified as we can do a binary search
on symbols_sorted_offsets. Since the symbols are sorted it takes on
average 13 calls to symbols_expand_symbol.

Signed-off-by: Konrad Rzeszutek Wilk 
---
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 

v8: New
 - Remove the debug code
 - Return the 'mid' index in symbol_addresses, not the 'low'.
v9:
 - Make it return void*
 - Ditch the old implementation. Use a single fixed-size array
   with two uint32_t values - offset in stream and offset in address.
 - Change printf in symbols.c to %u. Change parameter to --sort-by-name.
 - Squash the two seperate implementation of symbols_lookup_by_name
   in one function using #ifdefs.
 - Fix comment and simplify compare_name_orig code.
---
 xen/arch/x86/Makefile  |  3 +++
 xen/common/Kconfig | 12 +++
 xen/common/symbols-dummy.c |  5 +
 xen/common/symbols.c   | 28 ++
 xen/include/xen/symbols.h  |  8 
 xen/tools/symbols.c| 50 --
 6 files changed, 104 insertions(+), 2 deletions(-)

diff --git 

[Xen-devel] [PATCH v9 13/27] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version'.

[Konrad Rzeszutek Wilk]

This change demonstrates how to generate an xSplice ELF payload.

The idea here is that we want to patch in the hypervisor
the 'xen_version_extra' function with an function that will
return 'Hello World'. The 'xl info | grep extraversion'
will reflect the new value after the patching.

To generate this ELF payload file we need:
 - C code of the new code (xen_hello_world_func.c).
 - C code generating the .xsplice.funcs structure
   (xen_hello_world.c)
 - The address of the old code (xen_extra_version). We
   retrieve it by  using 'nm --defined' on xen-syms.
 - The size of the new and old code for which we use
   nm --defined -S on our code and xen-syms respectively.

There are two C files and one header files generated
during build. One could make this one C file if the
size of the newly patched function size was known in
advance (or an random value was choosen).

There is also a strict order of compiling:
 1) xen_hello_world_func.c
 2) config.h - extract the size of the new function,
the old function and the old function address.
 3) xen_hello_world.c - which contains the .xsplice.funcs
structure.
 4) Link the object files in an xen_hello_world.xsplice file.

The use-case is simple:

$xen-xsplice load /usr/lib/debug/xen_hello_world.xsplice
$xen-xsplice list
 ID | status
+
xen_hello_world   APPLIED
$xl info | grep extra
xen_extra  : Hello World
$xen-xsplice revert xen_hello_world
Performing revert: completed
$xen-xsplice unload xen_hello_world
Performing unload: completed
$xl info | grep extra
xen_extra  : -unstable

Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 
Acked-by: Julien Grall  [ARM]
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v2: Do it using hypervisor Makefiles
v3: Remove the stale linker file.
Add Copyright and local definition block
s/name/xen_hello_world_name/
v6: Remove the 'install', and 'uninstall' destinations.
Remove xen/config.h from files.
v7: Made the build target be called 'tests'.
Changed the .name to have 'xen_extra_version' to be consistent
with the spec.
Add Julien's Ack and Andrew's Reviewed-by.
v9: old_code and new_code are void, so drop the unsigned long cast
and add void* - in both test-cases and document.
Make tests target on ARM phony
Add build dependencies on x86 build
Include public/sysctl.h as CONFIG_XSPLICE may not be exposed.
---
 .gitignore   |  2 ++
 docs/misc/xsplice.markdown   | 37 +++
 xen/Makefile |  8 --
 xen/arch/arm/Makefile|  3 +++
 xen/arch/x86/Makefile|  4 +++
 xen/arch/x86/test/Makefile   | 43 
 xen/arch/x86/test/xen_hello_world.c  | 32 
 xen/arch/x86/test/xen_hello_world_func.c | 22 
 8 files changed, 149 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/x86/test/Makefile
 create mode 100644 xen/arch/x86/test/xen_hello_world.c
 create mode 100644 xen/arch/x86/test/xen_hello_world_func.c

diff --git a/.gitignore b/.gitignore
index 39eb779..4a81f43 100644
--- a/.gitignore
+++ b/.gitignore
@@ -246,6 +246,8 @@ xen/arch/x86/efi.lds
 xen/arch/x86/efi/check.efi
 xen/arch/x86/efi/disabled
 xen/arch/x86/efi/mkreloc
+xen/arch/x86/test/config.h
+xen/arch/x86/test/xen_hello_world.xsplice
 xen/arch/*/efi/boot.c
 xen/arch/*/efi/compat.c
 xen/arch/*/efi/efi.h
diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
index 99711bf..62f143e 100644
--- a/docs/misc/xsplice.markdown
+++ b/docs/misc/xsplice.markdown
@@ -331,6 +331,43 @@ When reverting a patch, the hypervisor iterates over each 
`xsplice_patch_func`
 and the core code copies the data from the undo buffer (private internal copy)
 to `old_addr`.
 
+### Example of .xsplice.funcs
+
+A simple example of what a payload file can be:
+
+
+/* MUST be in sync with hypervisor. */  
+struct xsplice_patch_func {  
+const char *name;  
+void *new_addr;  
+void *old_addr;  
+uint32_t new_size;  
+uint32_t old_size;  
+uint8_t version;
+uint8_t pad[31];  
+};  
+
+/* Our replacement function for xen_extra_version. */  
+const char *xen_hello_world(void)  
+{  
+return "Hello World";  
+}  
+
+static unsigned char patch_this_fnc[] = "xen_extra_version";  
+
+struct xsplice_patch_func xsplice_hello_world = {  
+.version = XSPLICE_PAYLOAD_VERSION,
+.name = patch_this_fnc,  
+.new_addr = xen_hello_world,  
+.old_addr = (void *)0x82d08013963c, /* Extracted from xen-syms. */  
+.new_size = 13, /* To be be 

[Xen-devel] [PATCH v9 16/27] x86, xsplice: Print payload's symbol name and payload name in backtraces

[Konrad Rzeszutek Wilk]

From: Ross Lagerwall 

Naturally the backtrace is presented when an instruction
hits an bug_frame or %p is used.

The payloads do not support bug_frames yet - however the functions
the payloads call could hit an BUG() or WARN().

The traps.c has logic to scan for it this - and eventually it will
find the correct bug_frame and the walk the stack using %p to print
the backtrace. For %p and symbols to print a string -  the
'is_active_kernel_text' is consulted which uses an 'struct virtual_region'.

Therefore we register our start->end addresses so that
'is_active_kernel_text' will include our payload address.

We also register our symbol lookup table function so that it can
scan the list of payloads and retrieve the correct name.

Lastly we change vsprintf to take into account s and namebuf.
For core code they are the same, but for payloads they are different.
This gets us:

Xen call trace:
   [] revert_hook+0x31/0x35 [xen_hello_world]
   [] xsplice.c#revert_payload+0x86/0xc6
   [] check_for_xsplice_work+0x233/0x3cd
   [] domain.c#continue_idle_domain+0x9/0x1f

Which is great if payloads have similar or same symbol names.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 

---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 

v2: Add missing full stop.
v3: s/module/payload/
v4: Expand comment and include registration of 'virtual_region'
Redo the vsprintf handling of payload name.
Drop the ->skip function
v6: Add comment explaining the purpose behind the strcmp.
Redid per Jan's review.
v7: Add Andrew's Review-by
Drop the strcmp and just do pointer checks.
v9: Do pointer comparison on vsprintf by itself, no need for intermediate
payload bool_t
Add const in xsplice_symbols_lookup
Make 'best' in xsplice_symbols_lookup be unsigned int.
Use an RCU list for iterating the applied_list. Define the RCU lock.
---
---
 xen/common/vsprintf.c | 12 +
 xen/common/xsplice.c  | 69 ---
 xen/include/xen/xsplice.h |  1 +
 3 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
index 18d2634..70e1edf 100644
--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -354,6 +355,17 @@ static char *pointer(char *str, char *end, const char 
**fmt_ptr,
 str = number(str, end, sym_size, 16, -1, -1, SPECIAL);
 }
 
+/*
+ * namebuf contents and s for core hypervisor are same but for xSplice
+ * payloads they differ (namebuf contains the name of the payload).
+ */
+if ( namebuf != s )
+{
+str = string(str, end, " [", -1, -1, 0);
+str = string(str, end, namebuf, -1, -1, 0);
+str = string(str, end, "]", -1, -1, 0);
+}
+
 return str;
 }
 
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 6051ade..72a3b88 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -14,7 +14,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,10 +33,9 @@ static LIST_HEAD(payload_list);
 
 /*
  * Patches which have been applied. Need RCU in case we crash (and then
- * traps code would iterate via applied_list) when adding entries on the list.
- *
- * Note: There are no 'rcu_applied_lock' as we don't iterate yet the list.
+ * traps code would iterate via applied_list) when adding entries onthe list.
  */
+static DEFINE_RCU_READ_LOCK(rcu_applied_lock);
 static LIST_HEAD(applied_list);
 
 static unsigned int payload_cnt;
@@ -56,6 +57,8 @@ struct payload {
 unsigned int nfuncs; /* Nr of functions to patch. */
 const struct xsplice_symbol *symtab; /* All symbols. */
 const char *strtab;  /* Pointer to .strtab. */
+struct virtual_region region;/* symbol, bug.frame patching and
+exception table (x86). */
 unsigned int nsyms;  /* Nr of entries in .strtab and 
symbols. */
 char name[XEN_XSPLICE_NAME_SIZE];/* Name of it. */
 };
@@ -142,6 +145,55 @@ void *xsplice_symbols_lookup_by_name(const char *symname)
 return 0;
 }
 
+static const char *xsplice_symbols_lookup(unsigned long addr,
+  unsigned long *symbolsize,
+  unsigned long *offset,
+  char *namebuf)
+{
+const struct payload *data;
+unsigned int i, best;
+const void *va = (const void *)addr;
+const char *n = NULL;
+
+/*
+ * Only RCU locking since this list is only ever changed during 

[Xen-devel] [PATCH v9 04/27] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op

[Konrad Rzeszutek Wilk]

The implementation does not actually do any patching.

It just adds the framework for doing the hypercalls,
keeping track of ELF payloads, and the basic operations:
 - query which payloads exist,
 - query for specific payloads,
 - check*1, apply*1, replace*1, and unload payloads.

*1: Which of course in this patch are nops.

The functionality is disabled on ARM until all arch
components are implemented.

Also by default it is disabled until the implementation
is in place.

We also use recursive spinlocks to so that the find_payload
function does not need to have a 'lock' and 'non-lock' variant.

Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ross Lagerwall 
Reviewed-by: Andrew Cooper 
Acked-by: Daniel De Graaf 

---
Cc: Daniel De Graaf 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Wei Liu 

v2: Rebased on keyhandler: rework keyhandler infrastructure
v3: Fixed XSM.
 - Removed REVERTED state.
Split status and error code.
Add REPLACE action.
Separate payload data from the payload structure.
s/XSPLICE_ID_../XSPLICE_NAME_../
 - Add xsplice and CONFIG_XSPLICE build toption.
Fix code per Jan's review.
Update the sysctl.h (change bits to enum like)
 - Rebase on Kconfig changes.
 - Add missing pad checks. Re-order keyhandler.h to build on ARM.
 - Rebase on build: hook the schedulers into Kconfig
 - s/id/name/; s/payload_list_lock/payload_lock/
 - Put #ifdef CONFIG_XSPLICE in header file per Doug review.
 - Andrew review:
- use recursive spinlocks, change name to xsplice_op,
  sprinkle new-lines, add local variable block, include
  state diagram, squash two goto labels, use vzalloc instead of
  alloc_xenheap_pages.
- change 'state' from int32 to uint32_t
- remove the err label out of xsplice_upload
- use void* instaed of uint8_t
- move code around to make it easier to read.
- Add vmap.h to compiler under ARM.
 - Add missing Copyright in header file
 - Dropped LOADED state, make the payload go in CHECKED.
v4: Made it only work on x86 per Julien's (ARM) maintainer request.
v5: Dropped the load->check state example in sysctl.h
Made the ->nr=0 call work. Remove rc=0 in lots of cases. Update
header from design doc.
v6: Update what 'idx' means. Don't drop lock in find_payload. Make
find_name copy data.
v7: Don't print -EINVAL when payload_cnt is zero (and toolstack provides
idx as zero). Change return code to -ENOSYS, so change callback setting
based on -ENOSYS and -EOPNOTSUPP.
Add extra printk in keyhandler.
Use if (..) else in  xsplice_upload instead of two 'if'.
Remove #ifdef in XSM machinery.
Add Andrew's Reviewed-by.
Rebase on x86/cpu: Sysctl and common infrastructure for levelling context 
switching
and xen+tools: Export maximum host and guest cpu featuresets via SYSCTL
v9:
s/find_name/get_name/, drop locks when allocating data.
Drop conditional expression on copyback
Move the allocation on upload outside the spinlock.
Add (TECH PREVIEW) to the Kconfig help
Return -EINVAL if the CHECK or UNLOAD action is to be performed and the 
payload
state is not in expected state.
Print 'c' not 'u' when invoking the keyhandler.
---
 tools/flask/policy/policy/modules/xen/xen.te |   1 +
 xen/common/Kconfig   |  12 +
 xen/common/Makefile  |   1 +
 xen/common/sysctl.c  |   7 +
 xen/common/xsplice.c | 407 +++
 xen/include/public/sysctl.h  | 166 +++
 xen/include/xen/xsplice.h|  35 +++
 xen/xsm/flask/hooks.c|   4 +
 xen/xsm/flask/policy/access_vectors  |   2 +
 9 files changed, 635 insertions(+)
 create mode 100644 xen/common/xsplice.c
 create mode 100644 xen/include/xen/xsplice.h

diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
b/tools/flask/policy/policy/modules/xen/xen.te
index 2a2630d..daa1315 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -74,6 +74,7 @@ allow dom0_t xen_t:xen2 {
 get_symbol
 get_cpu_levelling_caps
 get_cpu_featureset
+xsplice_op
 };
 
 # Allow dom0 to use all XENVER_ subops that have checks.
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index ad9f7bf..692ef51 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -188,4 +188,16 @@ config SCHED_DEFAULT
 
 endmenu
 
+# Enable/Disable xsplice support
+config XSPLICE
+   bool "xSplice live patching support (TECH PREVIEW)"
+   default n
+   depends on X86
+   ---help---
+ Allows a running Xen hypervisor to be dynamically patched using
+ binary patches without rebooting. This is primarily used to binarily
+ 

[Xen-devel] [PATCH v9 27/27] MAINTAINERS/xsplice: Add myself and Ross as the maintainers.

[Konrad Rzeszutek Wilk]

If you have a patch for xSplice send it our way!

Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 

---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 

v5: Sort them F: fields (Jan)
v7: Added Andrew's Reviewed-by
---
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5af7a0c..de482ea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -435,6 +435,16 @@ F:  xen/include/xsm/
 F:  xen/xsm/
 F:  docs/misc/xsm-flask.txt
 
+XSPLICE
+M:  Konrad Rzeszutek Wilk 
+M:  Ross Lagerwall 
+S:  Supported
+F:  docs/misc/xsplice.markdown
+F:  tools/misc/xen-xsplice.c
+F:  xen/arch/*/xsplice*
+F:  xen/common/xsplice*
+F:  xen/include/xen/xsplice*
+
 THE REST
 M: Andrew Cooper 
 M: George Dunlap 
-- 
2.5.0


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

[Xen-devel] [PATCH v9 18/27] xsplice: Add support for exception tables.

[Konrad Rzeszutek Wilk]

From: Ross Lagerwall 

Add support for exception tables contained within xSplice payloads. If an
exception occurs search either the main exception table or a particular
active payload's exception table depending on the instruction pointer.

Also we add an test-case to make sure we have an exception that
is handled.

To not grow the code-base if xSplice is not compiled in we add
certain #define to help in determining if code needs to be __init
or not.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 
---
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v3:
 - s/module/payload/
 - sanity checks.
 - Move code around.
 - s/module/payload/
v4: Use 'struct virtual_region'
v5:
  - Expand test-case.
  - Deal with struct exception_table_entry being const.
v6:
 - Make the code have __init if not compiled with xSplice
 - Remove not needed declarations.
v7:
 - Make the non_canonical_addr be 0xdeadULL
 - Remove casts
 - Add Reviewed-by from Andrew
 - Change ifdef to be !ARM
v8:
 - Change dprintk XENLOG_DEBUG to XENLOG_ERR on dprintk.
 - Remove pointless parentheses on 0xdead...
 - Changed __INIT.. to init_or_xsplice
 - Added const to sort_exception_table last parameter.
 - Added __initconstrel #define
---
 xen/arch/x86/extable.c   | 31 ++-
 xen/arch/x86/test/xen_hello_world_func.c | 13 +
 xen/common/xsplice.c | 25 +
 xen/include/asm-x86/uaccess.h|  2 ++
 xen/include/xen/xsplice.h| 19 +++
 5 files changed, 77 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
index 2a06cca..349df79 100644
--- a/xen/arch/x86/extable.c
+++ b/xen/arch/x86/extable.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define EX_FIELD(ptr, field) ((unsigned long)&(ptr)->field + (ptr)->field)
 
@@ -20,7 +21,7 @@ static inline unsigned long ex_cont(const struct 
exception_table_entry *x)
return EX_FIELD(x, cont);
 }
 
-static int __init cmp_ex(const void *a, const void *b)
+static int init_or_xsplice cmp_ex(const void *a, const void *b)
 {
const struct exception_table_entry *l = a, *r = b;
unsigned long lip = ex_addr(l);
@@ -35,7 +36,7 @@ static int __init cmp_ex(const void *a, const void *b)
 }
 
 #ifndef swap_ex
-static void __init swap_ex(void *a, void *b, int size)
+static void init_or_xsplice swap_ex(void *a, void *b, int size)
 {
struct exception_table_entry *l = a, *r = b, tmp;
long delta = b - a;
@@ -48,19 +49,23 @@ static void __init swap_ex(void *a, void *b, int size)
 }
 #endif
 
-void __init sort_exception_tables(void)
+void init_or_xsplice sort_exception_table(struct exception_table_entry *start,
+ const struct exception_table_entry *stop)
 {
-sort(__start___ex_table, __stop___ex_table - __start___ex_table,
- sizeof(struct exception_table_entry), cmp_ex, swap_ex);
-sort(__start___pre_ex_table,
- __stop___pre_ex_table - __start___pre_ex_table,
+sort(start, stop - start,
  sizeof(struct exception_table_entry), cmp_ex, swap_ex);
 }
 
-static inline unsigned long
-search_one_table(const struct exception_table_entry *first,
- const struct exception_table_entry *last,
- unsigned long value)
+void __init sort_exception_tables(void)
+{
+sort_exception_table(__start___ex_table, __stop___ex_table);
+sort_exception_table(__start___pre_ex_table, __stop___pre_ex_table);
+}
+
+unsigned long
+search_one_extable(const struct exception_table_entry *first,
+   const struct exception_table_entry *last,
+   unsigned long value)
 {
 const struct exception_table_entry *mid;
 long diff;
@@ -85,7 +90,7 @@ search_exception_table(unsigned long addr)
 const struct virtual_region *region = find_text_region(addr);
 
 if ( region && region->ex )
-return search_one_table(region->ex, region->ex_end - 1, addr);
+return search_one_extable(region->ex, region->ex_end - 1, addr);
 
 return 0;
 }
@@ -94,7 +99,7 @@ unsigned long
 search_pre_exception_table(struct cpu_user_regs *regs)
 {
 unsigned long addr = (unsigned long)regs->eip;
-unsigned long fixup = search_one_table(
+unsigned long fixup = search_one_extable(
 __start___pre_ex_table, __stop___pre_ex_table-1, addr);
 if ( fixup )
 {
diff --git a/xen/arch/x86/test/xen_hello_world_func.c 
b/xen/arch/x86/test/xen_hello_world_func.c
index 1ad002a..2e4af9c 100644
--- a/xen/arch/x86/test/xen_hello_world_func.c
+++ b/xen/arch/x86/test/xen_hello_world_func.c
@@ -5,9 +5,22 @@
 
 #include 
 
+#include 
+
+static unsigned long *non_canonical_addr = (unsigned long 

[Xen-devel] [PATCH v9 12/27] xsplice: Implement support for applying/reverting/replacing patches.

[Konrad Rzeszutek Wilk]

From: Ross Lagerwall 

Implement support for the apply, revert and replace actions.

To perform and action on a payload, the hypercall sets up a data
structure to schedule the work.  A hook is added in the reset_stack_and_jump
to check for work and execute it if needed (specifically we check an
per-cpu flag to make this as quick as possible).

In this way, patches can be applied with all CPUs idle and without
stacks.  The first CPU to run check_for_xsplice_work() becomes the
master and triggers a reschedule softirq to trigger all the other CPUs
to enter check_for_xsplice_work() with no stack.  Once all CPUs
have rendezvoused, all CPUs disable their IRQs and NMIs are ignored.
The system is then quiscient and the master performs the action.
After this, all CPUs enable IRQs and NMIs are re-enabled.

Note that it is unsafe to patch do_nmi and the xSplice internal functions.
Patching functions on NMI/MCE path is liable to end in disaster on x86.
This is not addressed in this patch and is mentioned in the
design doc as a further TODO.

The action to perform is one of:
- APPLY: For each function in the module, store the first arch-specific
  number bytes of the old function and replace it with a jump to the
  new function. (on x86 it is 5 bytes, on ARM it will likey be 4 bytes).
- REVERT: Copy the previously stored bytes into the first arch-specific
  number of bytes of the old function (again, 5 bytes on x86).
- REPLACE: Revert each applied module and then apply the new module.

To prevent a deadlock with any other barrier in the system, the master
will wait for up to 30ms before timing out.
Measurements found that the patch application to take about 100 μs on a
72 CPU system, whether idle or fully loaded.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 
Acked-by: Julien Grall 

--
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Boris Ostrovsky 
Cc: Suravee Suthikulpanit 
Cc: Jun Nakajima 
Cc: Kevin Tian 

v2: - Pluck the 'struct xsplice_patch_func' in this patch.
- Modify code per review comments.
- Add more data in the keyboard handler.
- Redo the patching code, split it in functions.
v3: - Add return_ macro for debug builds.
- Move s/payload_list_lock/payload_list/ to earlier patch
- Remove const and use ELF types for xsplice_patch_func
 - Add check routine to do simple sanity checks for various
  sections.
- s/%p/PRIx64/ as ARM builds complain.
- Move code around. Add more dprintk. Add XSPLICE in front of all
  printks/dprintk.
  Put the NMIs back if we fail patching.
  Add per-cpu to lessen contention for global structure.
  Extract from xsplice_do_single patching code into xsplice_do_action
  Squash xsplice_do_single and check_for_xsplice_work together to
  have all rendezvous in one place.
  Made XSPLICE_ACTION_REPLACE work again (wrong list iterator)
  s/find_special_sections/prepare_payload/
  Use list_del_init and INIT_LIST_HEAD for applied_list
v4:
   - Add comment, adjust spacing for "Timed out on CPU semaphore"
   - Added CR0.WP manipulations when altering the .text of hypervisor.
   - Added fix from Andrew for CR0.WP manipulation.
v5: - Made xsplice_patch_func use uintXX_t instead of ELF_ types to easy
  making it work under ARM (32bit). Add more BUILD-BUG-ON checks.
- Add more BUILD_ON checks. Sprinkle newlines.
v6: Rebase on "arm/x86: Alter nmi_callback_t typedef"
   - Drop the recursive spinlock usage.
   - Move NMI callbacks in arch specific.
   - Fold the 'check_for_xsplice_work' in reset_stack_and_jump
   - Add arch specific check for .xsplice.funcs.
   - Seperate external and internal structure of .xsplice.funcs.
   - Changed per Jan's review
   - Modified the .xsplice.funcs checks
v7:
   - Modified old_ptr to void* instead of uint8_t*
   - Modified the xsplice_patch_func_internal for ARM32 to have padding.
   - Used #if BITS_PER_LONG == 64 for the xsplice_patch_func_internal along
 with ifndef CONFIG_ARM for the undo (which may be different size on ARM64)
v8:
  - Add "is empty" if special sections are in fact empty.
  - Added Andrew's Reviewed-by:
  - Rebase on v7.2 of  x86/mm: Introduce modify_xen_mappings()
  - Change some of printk to dprintk and some of the dprintk to printk.
  - Make the xsplice_patch_func (and the internal) structure have uint32_t
(instead of uint64_t) if BITS_PER_LONG==32. This makes the size and
offset different so note that in the design and common code.
  - Add #undef ACTION
  - Guard struct xsplice_patch_func in sysctl.h with __XEN__ as 

[Xen-devel] [PATCH v9 19/27] xsplice: Add support for alternatives

[Konrad Rzeszutek Wilk]

From: Ross Lagerwall 

Add support for applying alternative sections within xsplice payload.
At payload load time, apply an alternative sections that are found.

Also we add an test-case exercising a rather useless alternative
(patching a NOP with a NOP) - but it does exercise the code-path.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 

---
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v2: Make a new alternative function that does not ASSERT on IRQs and
don't disable IRQs in the code when loading payload.
v4: Include test-case
Include check for size of alternatives and that it is not a 0 size
section.
v6: Add #define INIT to preserve __initness on alternative code.
Double check that alt_instr are only patching payload code.
v7: Move cr0 manipulation in apply_alternatives.
ifdef around alternative.o in Makefile
Pick X86_FEATURE_LM in test-case
Drop casting from load_addr
It is alternative.init.o, not alternative_init.o (thanks Andrew!)
v8: Change XENLOG_DEBUG to XENLOG_ERR on dprintk.
v9: Use init_or_xsplice instead of __INIT macros
Take care of __initconstrel
Change message when .alt_instr has incorrect size.
Update add_nops with proper comment
Update test case to patch a long instruction with a short one
Used ..constrel on k6_nops and p6_nops.
Used #%lx on printk. But with load_addr being void * switched to %p
Use Jan's Makefile obj list incantation incantation incantation incantation
---
 xen/arch/x86/Makefile|  6 +++--
 xen/arch/x86/alternative.c   | 46 
 xen/arch/x86/test/xen_hello_world_func.c |  4 +++
 xen/common/xsplice.c | 31 +
 xen/include/asm-x86/alternative.h|  4 +++
 5 files changed, 72 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 900fa59..bd7ba9f 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -6,7 +6,9 @@ subdir-y += mm
 subdir-$(CONFIG_XENOPROF) += oprofile
 subdir-y += x86_64
 
-obj-bin-y += alternative.init.o
+alternative-y := alternative.init.o
+alternative-$(CONFIG_XSPLICE) :=
+obj-bin-y += $(alternative-y)
 obj-y += apic.o
 obj-y += bitops.o
 obj-bin-y += bzimage.init.o
@@ -61,7 +63,7 @@ obj-y += x86_emulate.o
 obj-y += tboot.o
 obj-y += hpet.o
 obj-y += vm_event.o
-obj-$(CONFIG_XSPLICE) += xsplice.o
+obj-$(CONFIG_XSPLICE) += alternative.o xsplice.o
 obj-y += xstate.o
 
 obj-$(crash_debug) += gdbstub.o
diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index f735ff8..c188a15 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -22,13 +22,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_PATCH_LEN (255-1)
 
 extern struct alt_instr __alt_instructions[], __alt_instructions_end[];
 
 #ifdef K8_NOP1
-static const unsigned char k8nops[] __initconst = {
+static const unsigned char k8nops[] init_or_xsplice_const = {
 K8_NOP1,
 K8_NOP2,
 K8_NOP3,
@@ -38,7 +39,7 @@ static const unsigned char k8nops[] __initconst = {
 K8_NOP7,
 K8_NOP8
 };
-static const unsigned char * const k8_nops[ASM_NOP_MAX+1] __initconstrel = {
+static const unsigned char * const k8_nops[ASM_NOP_MAX+1] 
init_or_xsplice_constrel = {
 NULL,
 k8nops,
 k8nops + 1,
@@ -52,7 +53,7 @@ static const unsigned char * const k8_nops[ASM_NOP_MAX+1] 
__initconstrel = {
 #endif
 
 #ifdef P6_NOP1
-static const unsigned char p6nops[] __initconst = {
+static const unsigned char p6nops[] init_or_xsplice_const = {
 P6_NOP1,
 P6_NOP2,
 P6_NOP3,
@@ -62,7 +63,7 @@ static const unsigned char p6nops[] __initconst = {
 P6_NOP7,
 P6_NOP8
 };
-static const unsigned char * const p6_nops[ASM_NOP_MAX+1] __initconstrel = {
+static const unsigned char * const p6_nops[ASM_NOP_MAX+1] 
init_or_xsplice_constrel = {
 NULL,
 p6nops,
 p6nops + 1,
@@ -75,7 +76,7 @@ static const unsigned char * const p6_nops[ASM_NOP_MAX+1] 
__initconstrel = {
 };
 #endif
 
-static const unsigned char * const *ideal_nops __initdata = k8_nops;
+static const unsigned char * const *ideal_nops init_or_xsplice_data = k8_nops;
 
 static int __init mask_nmi_callback(const struct cpu_user_regs *regs, int cpu)
 {
@@ -100,7 +101,7 @@ static void __init arch_init_ideal_nops(void)
 }
 
 /* Use this to add nops to a buffer, then text_poke the whole buffer. */
-static void __init add_nops(void *insns, unsigned int len)
+static void init_or_xsplice add_nops(void *insns, unsigned int len)
 {
 while ( len > 0 )
 {
@@ -114,7 +115,7 @@ static void __init add_nops(void *insns, unsigned int len)
 }
 
 /*
- * text_poke_early - Update instructions on a live kernel at boot time
+ * text_poke - Update instructions on a live 

[Xen-devel] [PATCH v9 05/27] libxc: Implementation of XEN_XSPLICE_op in libxc

[Konrad Rzeszutek Wilk]

The underlaying toolstack code to do the basic
operations when using the XEN_XSPLICE_op syscalls:
 - upload the payload,
 - get status of an payload,
 - list all the payloads,
 - apply, check, replace, and revert the payload.

Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ross Lagerwall 
Acked-by: Wei Liu 
Reviewed-by: Andrew Cooper 

---
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Wei Liu 

v2: Actually set zero for the _pad entries.
v3: Split status into state and error code.
Add REPLACE action.
 - Use timeout and utilize pads.
 - Update per Wei's review.
 - Extra space slipped in, remove it
v4: Add Wei's review, update comment and Ack.
v7: Sprinkle errno=-EINVAL on all the 'if (!len)', etc checks.
Added Reviewed-by from Andrew.
---
---
 tools/libxc/include/xenctrl.h |  62 
 tools/libxc/xc_misc.c | 355 ++
 2 files changed, 417 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 42f201b..54431de 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2610,6 +2610,68 @@ const uint32_t *xc_get_feature_deep_deps(uint32_t 
feature);
 
 #endif
 
+int xc_xsplice_upload(xc_interface *xch,
+  char *name, unsigned char *payload, uint32_t size);
+
+int xc_xsplice_get(xc_interface *xch,
+   char *name,
+   xen_xsplice_status_t *status);
+
+/*
+ * The heart of this function is to get an array of xen_xsplice_status_t.
+ *
+ * However it is complex because it has to deal with the hypervisor
+ * returning some of the requested data or data being stale
+ * (another hypercall might alter the list).
+ *
+ * The parameters that the function expects to contain data from
+ * the hypervisor are: 'info', 'name', and 'len'. The 'done' and
+ * 'left' are also updated with the number of entries filled out
+ * and respectively the number of entries left to get from hypervisor.
+ *
+ * It is expected that the caller of this function will take the
+ * 'left' and use the value for 'start'. This way we have an
+ * cursor in the array. Note that the 'info','name', and 'len' will
+ * be updated at the subsequent calls.
+ *
+ * The 'max' is to be provided by the caller with the maximum
+ * number of entries that 'info', 'name', and 'len' arrays can
+ * be filled up with.
+ *
+ * Each entry in the 'name' array is expected to be of XEN_XSPLICE_NAME_SIZE
+ * length.
+ *
+ * Each entry in the 'info' array is expected to be of xen_xsplice_status_t
+ * structure size.
+ *
+ * Each entry in the 'len' array is expected to be of uint32_t size.
+ *
+ * The return value is zero if the hypercall completed successfully.
+ * Note that the return value is _not_ the amount of entries filled
+ * out - that is saved in 'done'.
+ *
+ * If there was an error performing the operation, the return value
+ * will contain an negative -EXX type value. The 'done' and 'left'
+ * will contain the number of entries that had been succesfully
+ * retrieved (if any).
+ */
+int xc_xsplice_list(xc_interface *xch, unsigned int max, unsigned int start,
+xen_xsplice_status_t *info, char *name,
+uint32_t *len, unsigned int *done,
+unsigned int *left);
+
+/*
+ * The operations are asynchronous and the hypervisor may take a while
+ * to complete them. The `timeout` offers an option to expire the
+ * operation if it could not be completed within the specified time
+ * (in ms). Value of 0 means let hypervisor decide the best timeout.
+ */
+int xc_xsplice_apply(xc_interface *xch, char *name, uint32_t timeout);
+int xc_xsplice_revert(xc_interface *xch, char *name, uint32_t timeout);
+int xc_xsplice_unload(xc_interface *xch, char *name, uint32_t timeout);
+int xc_xsplice_check(xc_interface *xch, char *name, uint32_t timeout);
+int xc_xsplice_replace(xc_interface *xch, char *name, uint32_t timeout);
+
 /* Compat shims */
 #include "xenctrl_compat.h"
 
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 7d997d9..8cd398b 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -696,6 +696,361 @@ int xc_hvm_inject_trap(
 return rc;
 }
 
+int xc_xsplice_upload(xc_interface *xch,
+  char *name,
+  unsigned char *payload,
+  uint32_t size)
+{
+int rc;
+DECLARE_SYSCTL;
+DECLARE_HYPERCALL_BUFFER(char, local);
+DECLARE_HYPERCALL_BOUNCE(name, 0 /* later */, 
XC_HYPERCALL_BUFFER_BOUNCE_IN);
+xen_xsplice_name_t def_name = { .pad = { 0, 0, 0 } };
+
+if ( !name || !payload )
+{
+errno = EINVAL;
+return -1;
+}
+
+def_name.size = strlen(name) + 1;
+if ( def_name.size > XEN_XSPLICE_NAME_SIZE )
+{
+errno = EINVAL;
+return 

[Xen-devel] [PATCH v9 24/27] xsplice: Stacking build-id dependency checking.

[Konrad Rzeszutek Wilk]

We now expect that the ELF payloads be built with the
--build-id.

Also the .xsplice.deps section has to have the contents
of the hypervisor (or a preceding payload) build-id.

We already have the code to verify the Elf_Note build-id
so export parts of it.

This dependency means the hypervisor MUST be compiled with
--build-id - so we gate the build of xSplice on the availability
of said functionality.

This does not impact the ordering of how the payloads can
be loaded, but it does enforce an STRICT ordering when the
payloads are applied. Also the REPLACE is special - we need
to check that its dependency against the hypervisor - not
the last applied patch.

To make this easier to test we also add an extra test-case
to be used - which can only be applied on top of the
xen_hello_world payload.

As in, one can apply xen_hello_world and then xen_bye_world
on top of that. Not the other way.

We also print the dependency and payloads build_in the keyhandler.

Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 

---
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v3: First time included.
v4: Andrew fix against the build_id.o mutilations.
Andrew fix to not include extra symbols in binary.id
v5: s/ssize_t/unsigned int/
v6: s/an NT_GNU../a NT_GNU/
   - Squash "xsplice: Print dependency and payloads build_id in the keyhandler"
 in this patch.
   - Add in xen_build_id_check size of section for better checking.
v7: Added Andrew's reviewed-by.
Change the .name in test-case to adhere to spec.
Dropped NT_GNU_BUILD_ID and moved that to earlier patch
(build_id: Provide ld-embedded build-ids)
Amended spec and code to only have one of .xsplice.depends and
.note.gnu.build-id
Expanded comment about note.o and why we don't use arch/x86/note.o.bin
Moved xen_build_id_check definition to xsplice.h from version.h
(and dropping the #include's in version.h)
Sort header files in tests.
v8:
 - Change two of the dprinkt from XENLOG_DEBUG to XENLOG_ERR
v9:
 - Dropped the (unsigned long) casts since we use void.
 - Make the .xsplice_depends and .note.gnu_build_id be #defines.
 - Make the build section use $(XSPLICE_BYE)
 - Make the testcase include 
 - Made comparisons on descsz and namesz a bit different (overflow
   checks, against value of 4, and against size)
---
 .gitignore |   1 +
 Config.mk  |   1 +
 docs/misc/xsplice.markdown |  99 +--
 xen/arch/x86/test/Makefile |  49 --
 xen/arch/x86/test/xen_bye_world.c  |  34 ++
 xen/arch/x86/test/xen_bye_world_func.c |  22 ++
 xen/common/Kconfig |   6 +-
 xen/common/version.c   |  45 ++---
 xen/common/xsplice.c   | 119 -
 xen/include/xen/xsplice.h  |   4 ++
 10 files changed, 325 insertions(+), 55 deletions(-)
 create mode 100644 xen/arch/x86/test/xen_bye_world.c
 create mode 100644 xen/arch/x86/test/xen_bye_world_func.c

diff --git a/.gitignore b/.gitignore
index 4a81f43..88cec1d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -248,6 +248,7 @@ xen/arch/x86/efi/disabled
 xen/arch/x86/efi/mkreloc
 xen/arch/x86/test/config.h
 xen/arch/x86/test/xen_hello_world.xsplice
+xen/arch/x86/test/xen_bye_world.xsplice
 xen/arch/*/efi/boot.c
 xen/arch/*/efi/compat.c
 xen/arch/*/efi/efi.h
diff --git a/Config.mk b/Config.mk
index 41f8c44..614dc9e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -134,6 +134,7 @@ ifeq ($(call ld-ver-build-id,$(LD)),n)
 build_id_linker :=
 else
 CFLAGS += -DBUILD_ID
+export XEN_HAS_BUILD_ID=y
 build_id_linker := --build-id=sha1
 endif
 
diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
index 62f143e..377ed6a 100644
--- a/docs/misc/xsplice.markdown
+++ b/docs/misc/xsplice.markdown
@@ -283,8 +283,17 @@ The xSplice core code loads the payload as a standard ELF 
binary, relocates it
 and handles the architecture-specifc sections as needed. This process is much
 like what the Linux kernel module loader does.
 
-The payload contains a section (xsplice_patch_func) with an array of structures
-describing the functions to be patched:
+The payload contains at least three sections:
+
+ * `.xsplice.funcs` - which is an array of xsplice_patch_func structures.
+ * `.xsplice.depends` - which is an ELF Note that describes what the payload
+depends on. **MUST** have one.
+ *  `.note.gnu.build-id` - the build-id of this payload. **MUST** have one.
+
+### .xsplice.funcs
+
+The `.xsplice.funcs` contains an array of xsplice_patch_func structures
+which describe the functions to be patched:
 
 
 struct xsplice_patch_func {  
@@ -368,6 +377,23 @@ struct xsplice_patch_func xsplice_hello_world = {
 
 Code must be compiled with -fPIC.
 
+### .xsplice.depends and .note.gnu.build-id
+
+To 

[Xen-devel] [PATCH v9 17/27] xsplice: Add support for bug frames.

[Konrad Rzeszutek Wilk]

From: Ross Lagerwall 

Add support for handling bug frames contained with xsplice modules. If a
trap occurs search either the kernel bug table or an applied payload's
bug table depending on the instruction pointer.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 
---
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v2:- s/module/payload/
   - add build time check in case amount of bug frames expands.
   - add define for the number of bug-frames.
v3:
  - add missing BUGFRAME_NR, squash s/core_size/core/ in earlier patch.
  - Moved code around.
  - Changed per Andrew's recommendation.
  - Fixed style changes.
  - Made it compile under ARM (PRIu32,PRIu64)
v4: Use 'struct virtual_region'
  - Rip more of the is_active_text code.
  - Use one function for the ->skip
  - Include test-case
v5: Rip out the ->skip function.
v7: Add a text check as well.
Add Andrew's Reviewed-by.
v8: Changed dprintk XENLOG_DEBUG to XENLOG_ERR
v9: Removed pointless check on the side of conditional (sec->sec->sh_size)
  - Added const.
  - Use RCU list.
---
---
 xen/arch/x86/traps.c  |  5 +++--
 xen/common/xsplice.c  | 51 +++
 xen/include/xen/xsplice.h |  5 +
 3 files changed, 59 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index f73f7f3..8384158 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1287,7 +1288,7 @@ void do_invalid_op(struct cpu_user_regs *regs)
 
 /* WARN, BUG or ASSERT: decode the filename pointer and line number. */
 filename = bug_ptr(bug);
-if ( !is_kernel(filename) )
+if ( !is_kernel(filename) && !is_patch(filename) )
 goto die;
 fixup = strlen(filename);
 if ( fixup > 50 )
@@ -1314,7 +1315,7 @@ void do_invalid_op(struct cpu_user_regs *regs)
 case BUGFRAME_assert:
 /* ASSERT: decode the predicate string pointer. */
 predicate = bug_msg(bug);
-if ( !is_kernel(predicate) )
+if ( !is_kernel(predicate) && !is_patch(predicate) )
 predicate = "";
 
 printk("Assertion '%s' failed at %s%s:%d\n",
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 72a3b88..11b19dd 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -123,6 +123,35 @@ static int verify_payload(const 
xen_sysctl_xsplice_upload_t *upload, char *n)
 return 0;
 }
 
+bool_t is_patch(const void *ptr)
+{
+const struct payload *data;
+bool_t r = 0;
+
+/*
+ * Only RCU locking since this list is only ever changed during apply
+ * or revert context. And in case it dies there we need an safe list.
+ */
+rcu_read_lock(_applied_lock);
+list_for_each_entry_rcu ( data, _list, applied_list )
+{
+if ( (ptr >= data->rw_addr &&
+  ptr < (data->rw_addr + data->rw_size)) ||
+ (ptr >= data->ro_addr &&
+  ptr < (data->ro_addr + data->ro_size)) ||
+ (ptr >= data->text_addr &&
+  ptr < (data->text_addr + data->text_size)) )
+{
+r = 1;
+break;
+}
+
+}
+rcu_read_unlock(_applied_lock);
+
+return r;
+}
+
 void *xsplice_symbols_lookup_by_name(const char *symname)
 {
 const struct payload *data;
@@ -482,6 +511,28 @@ static int prepare_payload(struct payload *payload,
 region->start = payload->text_addr;
 region->end = payload->text_addr + payload->text_size;
 
+/* Optional sections. */
+for ( i = 0; i < BUGFRAME_NR; i++ )
+{
+char str[14];
+
+snprintf(str, sizeof(str), ".bug_frames.%u", i);
+sec = xsplice_elf_sec_by_name(elf, str);
+if ( !sec )
+continue;
+
+if ( sec->sec->sh_size % sizeof(*region->frame[i].bugs) )
+{
+dprintk(XENLOG_ERR, XSPLICE "%s: Wrong size of .bug_frames.%u!\n",
+elf->name, i);
+return -EINVAL;
+}
+
+region->frame[i].bugs = sec->load_addr;
+region->frame[i].n_bugs = sec->sec->sh_size /
+  sizeof(*region->frame[i].bugs);
+}
+
 return 0;
 }
 
diff --git a/xen/include/xen/xsplice.h b/xen/include/xen/xsplice.h
index bb8baee..7f4c8f7 100644
--- a/xen/include/xen/xsplice.h
+++ b/xen/include/xen/xsplice.h
@@ -29,6 +29,7 @@ struct xsplice_symbol {
 int xsplice_op(struct xen_sysctl_xsplice_op *);
 void check_for_xsplice_work(void);
 void *xsplice_symbols_lookup_by_name(const char *symname);
+bool_t is_patch(const void *addr);
 
 /* Arch hooks. */
 int arch_xsplice_verify_elf(const struct xsplice_elf *elf);
@@ -76,6 +77,10 @@ static inline int xsplice_op(struct xen_sysctl_xsplice_op 
*op)
 }
 
 static 

[Xen-devel] [PATCH v9 10/27] xsplice: Add helper elf routines

[Konrad Rzeszutek Wilk]

From: Ross Lagerwall 

Add Elf routines and data structures in preparation for loading an
xSplice payload.

We make an assumption that the max number of sections an ELF payload
can have is 64. We can in future make this be dependent on the
names of the sections and verifying against a list, but for right now
this suffices.

Also we a whole lot of checks to make sure that the ELF payload
file is not corrupted nor that the offsets point past the file.

For most of the checks we print an message if the hypervisor is built
with debug enabled.

Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
Acked-by: Ian Jackson 
Reviewed-by: Andrew Cooper
---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 

v2: - With the #define ELFSIZE in the ARM file we can use the common
 #defines instead of using #ifdef CONFIG_ARM_32. Moved to another
patch.
- Add checks for ELF file.
- Add name to be printed.
- Add len for easier ELF checks.
- Expand on the checks. Add macro.
v3: Remove the return_ macro
  - Add return_ macro back but make it depend on debug=y
  - Per Andrew review: add local variable. Fix memory leak in
elf_resolve_sections, Remove macro and use dprintk. Fix alignment.
Use void* instead of uint8_t to handle raw payload.
v4 - Fix memory leak in elf_get_sym
  - Add XSPLICE to printk/dprintk
v5: Sprinkle newlines.
v6: Squash the ELF header checks from 'xsplice: Implement payload loading' here,
Do better job at checking string sections and the users of them (sh_size),
Use XSPLICE as a string literal,
Move some checks outside the loop,
Make sure that SHT_STRTAB are really what they say
Sprinkle consts.
v7:
Check sh_entsize and sh_offset.
Added Andrew's Reviewed-by and Ian's Acked-by
Redo check on sh_entsize to not be !=
v8: Make all the dprintk(XENLOG_DEBUG be XENLOG_ERR
v9: Changed elf_verify_strtab to use const char and return EINVAL.
Remove 'if ( !delta )' check in elf_resolve_sections
Remove stale comments.
Fixed one off check against  sh_link.
Document boundary checks against shstrtab and symtab.
Fixed return codes in xsplice_header_check.
Add check for sections to not be within ELF header.
Added overflow check for e_shoff in xsplice_header_check.
Moved XSPLICE macro by four tabs.
Make ->sym be const.
---
 xen/common/Makefile   |   1 +
 xen/common/xsplice_elf.c  | 363 ++
 xen/include/xen/xsplice.h |   3 +
 xen/include/xen/xsplice_elf.h |  51 ++
 4 files changed, 418 insertions(+)
 create mode 100644 xen/common/xsplice_elf.c
 create mode 100644 xen/include/xen/xsplice_elf.h

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1e4bc70..afd84b6 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,6 +59,7 @@ obj-y += wait.o
 obj-$(CONFIG_XENOPROF) += xenoprof.o
 obj-y += xmalloc_tlsf.o
 obj-$(CONFIG_XSPLICE) += xsplice.o
+obj-$(CONFIG_XSPLICE) += xsplice_elf.o
 
 obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo 
unlz4 earlycpio,$(n).init.o)
 
diff --git a/xen/common/xsplice_elf.c b/xen/common/xsplice_elf.c
new file mode 100644
index 000..2fd48fb
--- /dev/null
+++ b/xen/common/xsplice_elf.c
@@ -0,0 +1,363 @@
+/*
+ * Copyright (C) 2016 Citrix Systems R Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+const struct xsplice_elf_sec *xsplice_elf_sec_by_name(const struct xsplice_elf 
*elf,
+  const char *name)
+{
+unsigned int i;
+
+for ( i = 1; i < elf->hdr->e_shnum; i++ )
+{
+if ( !strcmp(name, elf->sec[i].name) )
+return >sec[i];
+}
+
+return NULL;
+}
+
+static int elf_verify_strtab(const struct xsplice_elf_sec *sec)
+{
+const Elf_Shdr *s;
+const char *contents;
+
+s = sec->sec;
+
+if ( s->sh_type != SHT_STRTAB )
+return -EINVAL;
+
+if ( !s->sh_size )
+return -EINVAL;
+
+contents = sec->data;
+
+if ( contents[0] || contents[s->sh_size - 1] )
+return -EINVAL;
+
+return 0;
+}
+
+static int elf_resolve_sections(struct xsplice_elf *elf, const void *data)
+{
+struct xsplice_elf_sec *sec;
+unsigned int i;
+Elf_Off delta;
+int rc;
+
+/* xsplice_elf_load sanity checked e_shnum. */
+sec = xmalloc_array(struct xsplice_elf_sec, elf->hdr->e_shnum);
+if ( !sec )
+{
+dprintk(XENLOG_ERR, XSPLICE"%s: Could not allocate memory for section 
table!\n",
+   elf->name);
+return -ENOMEM;
+}
+
+elf->sec = sec;
+
+/* e_shoff and e_shnum overflow checks are done in xsplice_header_check. */
+delta = elf->hdr->e_shoff + elf->hdr->e_shnum * elf->hdr->e_shentsize;
+if ( 

[Xen-devel] [PATCH v9 20/27] build_id: Provide ld-embedded build-ids

[Konrad Rzeszutek Wilk]

This patch enables the Elf to be built with the build-id
and provide in the Xen hypervisor the code to extract it.

The man-page for ld --build-id says it is:

"Request the creation of a ".note.gnu.build-id" ELF note
section or a ".build-id" COFF section.  The contents of the
note are unique bits identifying this linked file. style can be
"uuid" to use 128 random bits, "sha1" to use a 160-bit SHA1 hash
on the normative parts of the output contents, ..."

One can also retrieve the value of the build-id by doing
'readelf -n xen-syms'.

For EFI builds we re-use the same build-id that the xen-syms
was built with.

The version of ld that first implemented --build-id is v2.18.
We check for to see if the linker supports the --build-id
parameter and if so use it.

For x86 we have two binaries - the xen-syms and the xen - an
smaller version with lots of sections removed. To make it possible
for readelf -n xen we also modify mkelf32 and xen.lds.S to include
the PT_NOTE ELF section.

The EFI binary is more complicated. We only build one type of
binary and expanding the amount of sections the EFI binary has to
include an .note one is pointless - as there is no concept of
PT_NOTE. The best we can do is move this .note in the .rodata section.

Further development wise should move it to .buildid section
so that DataDirectory debug data nor CodeView can view it.
(The author has no clue what those are).

Note that in earlier patches the linker script had:

 __note_gnu_build_id_start = .;
 *(.rodata.note.gnu.build-id)
 __note_gnu_build_id_end = .;
 *(.note)
 *(.note.*)

Which meant you could have different ELF notes _outside_ the
__note_gnu_build_id_end. However for EFI builds we take the whole
.note* section and jam it in the EFI to be between
__note_gnu_build_id_start and __note_gnu_build_id_end.
To not make this happend we make on the ELF build the section
be called .note.gnu.build-id  (instead of just .note).
If there is a need for a different type of note other folks
can add it as a different section name.

Note that we do call --binary-id=sha1 on all linker invocations.
We have to do to enforce that the symbol offsets don't changes
(the side effect is that we we would have multiple binary ids -
except that the last one is the final one).

Without this working the symbol table embedded in Xen ends
up incorrect - some of the values it contains would be offset by the
size of the included build id.

This obviously causes problems when resolving symbols.

We also define the NT_GNU_BUILD_ID in the elfstructs.h as we
need to use it in various places.

Suggested-by: Andrew Cooper 
Signed-off-by: Martin Pohlack 
Signed-off-by: Konrad Rzeszutek Wilk 
Acked-by: Julien Grall 
Reviewed-by: Andrew Cooper 
Acked-by: Jan Beulich 

---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v1: Rebase it on Martin's initial patch
v2: Move it to XENVER hypercall
v3: Fix EFI building (Ross's fix)
Don't use the third argument for length.
Use new structure for XENVER_build_id with variable buf.
Include Ross's fix.
Include detection of bin-utils for build-id support, add
probing for size, and return -EPERM for XSM denied calls.
Build xen_build_id under ARM, required adding ELFSIZE in proper file.
Rebase on top XSM version class.
v4:
Include the build-id .note in the xen ELF binary.
s/build_id/build_id_linker/
For EFI build, moved the --build-id values in .data section
Rebase on staging.
Split patch in two. Always do --build-id call. Include the .note in
.rodata. USe const void * and ssize_t
Use -S to make build_id.o and objcopy differently (Andrew suggested)
v5: Put back the #ifdef LOCK_PROFILE on ARM. (Bad change). Move the _erodata
around. s/ssize_t/unsigned int/
v6: Redid it per Jan's review.
v7: Move build-id note in .rodata.note for EFI builds only.
Move build-id note in .rodata for EFI builds only. Retain
it in .note. Change name of object file used by EFI builds to notes.o
Make on ELF builds the PT_NOTE section name be .note.gnu.build-id and
ingest that in ELF build.
Define NT_GNU_BUILD_ID in elfstructs.h
v8: s/num_phdrs/notes_phdrs/
   Added Andrew's Reviewed-by
v9:
   Made mkelf32 parse --notes as first argument
   Moved _erodata past .note.gnu.. section
   Added rm -f note.o on clean target.
   Make build_id_[p|len] be __read_mostly
   Add Jan's Acked-by
   Made the detection be smarter and just check for option requested being 
mirrored.
   (That takes care of checking unrecognized in different languages).
---
 Config.mk|  11 
 xen/arch/arm/Makefile|   2 +-
 xen/arch/arm/xen.lds.S   |  15 -
 xen/arch/x86/Makefile|  30 

[Xen-devel] [PATCH 9] xSplice v1 design and implementation.

[Konrad Rzeszutek Wilk]

Hey!

Changelog:
v8.1: http://lists.xen.org/archives/html/xen-devel/2016-04/msg01903.html
 - Worked on Jan's comments.
v8: since http://lists.xen.org/archives/html/xen-devel/2016-04/msg01873.html
 - Posting the _RIGHT_ set of patches.

v7: http://lists.xen.org/archives/html/xen-devel/2016-04/msg01476.html
 - Ingested newer version of x86/mm: Introduce modify_xen_mappings()
 - Implemented faster symbol table lookup (NEW)
 - Carried out tests on large CPU machine (240CPUs)
 - Made the struct xsplice_patch_func work on ARM32 and changed its size
   (64bit it is 64bytes, 32bit is 52 bytes - and the offset is different too)
 - Changed a bunch of printk to dprintk, adjusted XENLOG_ levels.
 - Resurrected the XENVER_build_id.
 - Reverted VERSION_op.
v6: http://lists.xen.org/archives/html/xen-devel/2016-04/msg00871.html
 - Acted on all comments from Andrew, Julien, and Jan.
 - Got help from Andrew on one of them over the weekend.
 - Dropped: xsplice: Add .xsplice.hooks functions and test-case,
   xsplice: Add support for shadow variables.
v5: http://lists.xen.org/archives/html/xen-devel/2016-03/msg03286.html
 - Acted at all comments from Jan.
v4: http://lists.xen.org/archives/html/xen-devel/2016-03/msg01776.html
 - Lots of review. Lots of rework. Some patches checked in.
v3: http://www.gossamer-threads.com/lists/xen/devel/418262
and 
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg04106.html
 - Act on all reviews.
 - Redo the flow of patches
v2: http://lists.xen.org/archives/html/xen-devel/2016-01/msg01597.html
 - Updated code/docs/design with review comments.
 - Make xen also have an PT_NOTE
 - Added more of Ross's patches
 - Combined build-id patchset with this.
(since the RFC and the Seattle Xen presentation)
 - Finished off some of the work around the build-id.
 - Settled on the preemption mechanism.
 - Cleaned the patches a lot up, broke them up to easy
   review for maintainers.
v1: http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg02116.html
  - Put all the design comments in the code
Prototype: 
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg02595.html
[Posting by Ross]
 - Took all reviews into account.
 - Redid the patches


*Maintainers*

Since v8.1, all patches except:
 xsplice, symbols: Implement fast symbol names -> virtual addresses lookup

have reviewed-by.

*Maintainers*

Legend:
 *- See below
 R- Reviewed 
 R+   - Reviewed by two folks
 A- Acked by maintainer of the area (hypervisor or toolstack)

  Revert "libxc/libxl/python/xenstat/ocaml: Use new
  A   Revert "HYPERCALL_version_op. New hypercall mirroring
  A   xsplice: Design document
   R  xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op
  AR  libxc: Implementation of XEN_XSPLICE_op in libxc
  A   xen-xsplice: Tool to manipulate xsplice payloads
  AR  arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception 
tables lookup.
[Julien Acked the ARM part]
  AR  arm/x86/vmap: Add v[z|m]alloc_xen, vfree_xen and vm_init_type
[Julien Acked the ARM part]
   R+  x86/mm: Introduce modify_xen_mappings()
   R  xsplice: Add helper elf routines
   R  xsplice: Implement payload loading
   R  xsplice: Implement support for applying/reverting/replacing patches.
   R  x86/xen_hello_world.xsplice: Test payload for patching 
'xen_extra_version'.
   R  xsplice,symbols: Implement symbol name resolution on address.
* xsplice, symbols: Implement fast symbol names -> virtual addresses lookup
   R  x86, xsplice: Print payload's symbol name and payload name in backtraces
   R  xsplice: Add support for bug frames.
   R  xsplice: Add support for exception tables.
   R  xsplice: Add support for alternatives
  AR  build_id: Provide ld-embedded build-ids
  AR  xsplice: Print build_id in keyhandler and on bootup.
  A   XENVER_build_id/libxc: Provide ld-embedded build-id
  A   libxl: info: Display build_id of the hypervisor.
   R  xsplice: Stacking build-id dependency checking.
   R  xsplice/xen_replace_world: Test-case for XSPLICE_ACTION_REPLACE
   R  xsplice: Prevent duplicate payloads from being loaded.
   R  MAINTAINERS/xsplice: Add myself and Ross as the maintainers.


*Are there any TODOs left from v5,v6,v7,v8.1 reviews?*

None.

*What is xSplice?*

A mechanism to binarily patch the running hypervisor with new
opcodes that have come about due to primarily security updates.

*What will this patchset do once I've it*

Patch the hypervisor.

*Why are you emailing me?*

Please please review as many patches as possible.

*OK, what do you have?*

They are located at a git tree:
  git://xenbits.xen.org/people/konradwilk/xen.git   xsplice.v9

(Copying from Ross's email):

Much of the work is implementing a basic version of the Linux kernel module
loader. The code:
* Loading of xSplice ELF payloads.
* Copying allocated sections into a new executable region of memory.
* Resolving symbols.
* Applying relocations.
* Patching of altinstructions.
* Special handling of bug 

[Xen-devel] [PATCH v9 22/27] XENVER_build_id/libxc: Provide ld-embedded build-id

[Konrad Rzeszutek Wilk]

If the hypervisor was built with build-ids we can expose the
build-id value to the toolstack (if it is not built with
it will just return -ENODATA). This is a priviligied operation
so only the controlling stack is able to request this.

Signed-off-by: Konrad Rzeszutek Wilk 
Acked-by: Wei Liu 
Acked-by: Daniel De Graaf 
Acked-by: Jan Beulich 

---
CC: Daniel De Graaf 
CC: Ian Jackson 
CC: Wei Liu 

v1: Rebase it on Martin's initial patch
v2: Move it to XENVER hypercall
v3: Don't use the third argument for length.
   - Use new structure for XENVER_build_id with variable buf.
v8: Resurrected from v3!
v9: Added Acks from Wei, Daniel and Jan
Removed pointless initializers.
---
---
 tools/flask/policy/policy/modules/xen/xen.te |  1 +
 tools/libxc/xc_private.c |  7 ++
 tools/libxc/xc_private.h | 11 +
 xen/common/kernel.c  | 36 
 xen/include/public/version.h | 18 +-
 xen/xsm/flask/hooks.c|  3 +++
 xen/xsm/flask/policy/access_vectors  |  2 ++
 7 files changed, 77 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
b/tools/flask/policy/policy/modules/xen/xen.te
index daa1315..bef33b0 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -82,6 +82,7 @@ allow dom0_t xen_t:xen2 {
 allow dom0_t xen_t:version {
 xen_extraversion xen_compile_info xen_capabilities
 xen_changeset xen_pagesize xen_guest_handle xen_commandline
+xen_build_id
 };
 
 allow dom0_t xen_t:mmu memorymap;
diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
index c41e433..d57c39a 100644
--- a/tools/libxc/xc_private.c
+++ b/tools/libxc/xc_private.c
@@ -495,6 +495,13 @@ int xc_version(xc_interface *xch, int cmd, void *arg)
 case XENVER_commandline:
 sz = sizeof(xen_commandline_t);
 break;
+case XENVER_build_id:
+{
+xen_build_id_t *build_id = (xen_build_id_t *)arg;
+sz = sizeof(*build_id) + build_id->len;
+HYPERCALL_BOUNCE_SET_DIR(arg, XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
+break;
+}
 default:
 ERROR("xc_version: unknown command %d\n", cmd);
 return -EINVAL;
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index aa8daf1..75b761c 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -197,6 +197,17 @@ enum {
 #define HYPERCALL_BOUNCE_SET_SIZE(_buf, _sz) do { (HYPERCALL_BUFFER(_buf))->sz 
= _sz; } while (0)
 
 /*
+ * Change the direction.
+ *
+ * Can only be used if the bounce_pre/bounce_post commands have
+ * not been used.
+ */
+#define HYPERCALL_BOUNCE_SET_DIR(_buf, _dir) do { if 
((HYPERCALL_BUFFER(_buf))->hbuf) \
+assert(1); 
   \
+   
(HYPERCALL_BUFFER(_buf))->dir = _dir;  \
+} while (0)
+
+/*
  * Initialise and free hypercall safe memory. Takes care of any required
  * copying.
  */
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index a4a3c36..1a6823a 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -376,6 +376,42 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 return -EFAULT;
 return 0;
 }
+
+case XENVER_build_id:
+{
+xen_build_id_t build_id;
+unsigned int sz;
+int rc;
+const void *p;
+
+if ( deny )
+return -EPERM;
+
+/* Only return size. */
+if ( !guest_handle_is_null(arg) )
+{
+if ( copy_from_guest(_id, arg, 1) )
+return -EFAULT;
+
+if ( build_id.len == 0 )
+return -EINVAL;
+}
+
+rc = xen_build_id(, );
+if ( rc )
+return rc;
+
+if ( guest_handle_is_null(arg) )
+return sz;
+
+if ( sz > build_id.len )
+return -ENOBUFS;
+
+if ( copy_to_guest_offset(arg, offsetof(xen_build_id_t, buf), p, sz) )
+return -EFAULT;
+
+return sz;
+}
 }
 
 return -ENOSYS;
diff --git a/xen/include/public/version.h b/xen/include/public/version.h
index 24a582f..cb84565 100644
--- a/xen/include/public/version.h
+++ b/xen/include/public/version.h
@@ -30,7 +30,8 @@
 
 #include "xen.h"
 
-/* NB. All ops return zero on success, except XENVER_{version,pagesize} */
+/* NB. All ops return zero on success, except XENVER_{version,pagesize}
+ * XENVER_{version,pagesize,build_id} */
 
 /* arg == NULL; returns major:minor (16:16). */
 #define XENVER_version  0
@@ -87,6 +88,21 @@ typedef struct xen_feature_info 

[Xen-devel] [PATCH v9 06/27] xen-xsplice: Tool to manipulate xsplice payloads

[Konrad Rzeszutek Wilk]

A simple tool that allows an system admin to perform
basic xsplice operations:

 - Upload a xsplice file (with an unique name)
 - List all the xsplice payloads loaded.
 - Apply, revert, replace, or unload the payload using the
   unique name.
 - Do all two - upload, and apply the payload in one go (load).
   Also will use the name of the file as the 

Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ross Lagerwall 
Acked-by: Wei Liu 

---
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Wei Liu 

v2:
 - Removed REVERTED state.
 - Fixed bugs handling XSPLICE_STATUS_PROGRESS.
 - Split status into state and error.
   Add REPLACE action.
v3:
 - Utilize the timeout and use the default one (let the hypervisor
   pick it).
 - Change the s/all/load and infer the  from name of file.
 - s/id/name/
 - Don't use hypercall buffer in upload_func, instead do it in libxc
 - Remove the debug printk.
 - Remove goto's (per Wei's review)
 - Use fprintf(stderr in error paths.
 - Add local variable block.
 - Syntax, expand comment, and don't overwrite rc if xc_xsplice_upload failed.
v4:
 - Remove LOADED state. Only have CHECKED state.
---
---
 .gitignore   |   1 +
 tools/misc/Makefile  |   4 +
 tools/misc/xen-xsplice.c | 463 +++
 3 files changed, 468 insertions(+)
 create mode 100644 tools/misc/xen-xsplice.c

diff --git a/.gitignore b/.gitignore
index 20ffa2d..39eb779 100644
--- a/.gitignore
+++ b/.gitignore
@@ -182,6 +182,7 @@ tools/misc/xen_cpuperf
 tools/misc/xen-cpuid
 tools/misc/xen-detect
 tools/misc/xen-tmem-list-parse
+tools/misc/xen-xsplice
 tools/misc/xenperf
 tools/misc/xenpm
 tools/misc/xen-hvmctx
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index a94dad9..3a5f842 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -32,6 +32,7 @@ INSTALL_SBIN   += xenlockprof
 INSTALL_SBIN   += xenperf
 INSTALL_SBIN   += xenpm
 INSTALL_SBIN   += xenwatchdogd
+INSTALL_SBIN   += xen-xsplice
 INSTALL_SBIN += $(INSTALL_SBIN-y)
 
 # Everything to be installed in a private bin/
@@ -103,6 +104,9 @@ xen-mfndump: xen-mfndump.o
 xenwatchdogd: xenwatchdogd.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
+xen-xsplice: xen-xsplice.o
+   $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 xen-lowmemd: xen-lowmemd.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) 
$(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
new file mode 100644
index 000..fb9228e
--- /dev/null
+++ b/tools/misc/xen-xsplice.c
@@ -0,0 +1,463 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static xc_interface *xch;
+
+void show_help(void)
+{
+fprintf(stderr,
+"xen-xsplice: Xsplice test tool\n"
+"Usage: xen-xsplice  [args]\n"
+"  An unique name of payload. Up to %d characters.\n"
+"Commands:\n"
+"  help   display this help\n"
+"  upload upload file  with  name\n"
+"  list   list payloads uploaded.\n"
+"  applyapply  patch.\n"
+"  revert   revert name  patch.\n"
+"  replace  apply  patch and revert all 
others.\n"
+"  unload   unload name  patch.\n"
+"  load upload, check and apply .\n"
+" name is the  name\n",
+XEN_XSPLICE_NAME_SIZE);
+}
+
+/* wrapper function */
+static int help_func(int argc, char *argv[])
+{
+show_help();
+return 0;
+}
+
+#define ARRAY_SIZE(a) (sizeof (a) / sizeof ((a)[0]))
+
+static const char *state2str(unsigned int state)
+{
+#define STATE(x) [XSPLICE_STATE_##x] = #x
+static const char *const names[] = {
+STATE(CHECKED),
+STATE(APPLIED),
+};
+#undef STATE
+if (state >= ARRAY_SIZE(names) || !names[state])
+return "unknown";
+
+return names[state];
+}
+
+/* This value was choosen adhoc. It could be 42 too. */
+#define MAX_LEN 11
+static int list_func(int argc, char *argv[])
+{
+unsigned int idx, done, left, i;
+xen_xsplice_status_t *info = NULL;
+char *name = NULL;
+uint32_t *len = NULL;
+int rc = ENOMEM;
+
+if ( argc )
+{
+show_help();
+return -1;
+}
+idx = left = 0;
+info = malloc(sizeof(*info) * MAX_LEN);
+if ( !info )
+return rc;
+name = malloc(sizeof(*name) * XEN_XSPLICE_NAME_SIZE * MAX_LEN);
+if ( !name )
+{
+free(info);
+return rc;
+}
+   

[Xen-devel] [PATCH v9 01/27] Revert "libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall"

[Konrad Rzeszutek Wilk]

This reverts commit d275ec9ca8a86f7c9c213f3551194d471ce90fbd.

As we prefer to still utilize the old XENVER_ hypercall.

Signed-off-by: Konrad Rzeszutek Wilk 
Requested-and-acked-by: Jan Beulich 
---
 tools/libxc/include/xenctrl.h  | 32 +-
 tools/libxc/xc_core.c  | 35 
 tools/libxc/xc_dom_boot.c  | 12 +-
 tools/libxc/xc_domain.c|  3 +-
 tools/libxc/xc_private.c   | 53 +++
 tools/libxc/xc_private.h   |  7 ++--
 tools/libxc/xc_resume.c|  3 +-
 tools/libxc/xc_sr_save.c   |  9 ++--
 tools/libxc/xg_save_restore.h  |  6 +--
 tools/libxl/libxl.c| 77 +-
 tools/ocaml/libs/xc/xenctrl_stubs.c| 39 ++---
 tools/python/xen/lowlevel/xc/xc.c  | 30 ++---
 tools/xenstat/libxenstat/src/xenstat.c | 12 +++---
 tools/xentrace/xenctx.c|  3 +-
 14 files changed, 146 insertions(+), 175 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index f5a034a..42f201b 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1536,37 +1536,7 @@ int xc_tbuf_set_evt_mask(xc_interface *xch, uint32_t 
mask);
 int xc_domctl(xc_interface *xch, struct xen_domctl *domctl);
 int xc_sysctl(xc_interface *xch, struct xen_sysctl *sysctl);
 
-/**
- * This function returns the size of buffer to be allocated for
- * the cmd. The cmd are XEN_VERSION_*.
- */
-ssize_t xc_version_len(xc_interface *xch, unsigned int cmd);
-
-/**
- * This function retrieves the information from the version_op hypercall.
- * The len is the size of the arg buffer. If arg is NULL, will not
- * perform hypercall - instead will just return the size of arg
- * buffer that is needed.
- *
- * Note that prior to Xen 4.7 this would return 0 for success and
- * negative value (-1) for error (with the error in errno). In Xen 4.7
- * and later for success it will return an positive value which is the
- * number of bytes copied in arg.
- *
- * It can also return -1 with various errno values:
- *  - EPERM - not permitted.
- *  - ENOBUFS - the len was to short, output in arg truncated.
- *  - ENOSYS - not implemented.
- *
- * @parm xch a handle to an open hypervisor interface
- * @parm cmd XEN_VERSION_* value
- * @param arg Pointer to xen_version_op_buf_t or xen_version_op_val_t
- * @param len Size of arg
- * @return size of bytes copied in arg on success, -1 on failure (and
- * errno will contain the error)
- *
- */
-int xc_version(xc_interface *xch, unsigned int cmd, void *arg, size_t len);
+int xc_version(xc_interface *xch, int cmd, void *arg);
 
 int xc_flask_op(xc_interface *xch, xen_flask_op_t *op);
 
diff --git a/tools/libxc/xc_core.c b/tools/libxc/xc_core.c
index cfeba6b..d792566 100644
--- a/tools/libxc/xc_core.c
+++ b/tools/libxc/xc_core.c
@@ -270,43 +270,42 @@ elfnote_fill_xen_version(xc_interface *xch,
  *xen_version)
 {
 int rc;
-xen_version_op_val_t val = 0;
 memset(xen_version, 0, sizeof(*xen_version));
 
-rc = xc_version(xch, XEN_VERSION_version, , sizeof(val));
+rc = xc_version(xch, XENVER_version, NULL);
 if ( rc < 0 )
 return rc;
-xen_version->major_version = val >> 16;
-xen_version->minor_version = val & ((1 << 16) - 1);
+xen_version->major_version = rc >> 16;
+xen_version->minor_version = rc & ((1 << 16) - 1);
 
-rc = xc_version(xch, XEN_VERSION_extraversion,
-xen_version->extra_version,
-sizeof(xen_version->extra_version));
+rc = xc_version(xch, XENVER_extraversion,
+_version->extra_version);
 if ( rc < 0 )
 return rc;
 
-rc = xc_version(xch, XEN_VERSION_capabilities,
-xen_version->capabilities,
-sizeof(xen_version->capabilities));
+rc = xc_version(xch, XENVER_compile_info,
+_version->compile_info);
 if ( rc < 0 )
 return rc;
 
-rc = xc_version(xch, XEN_VERSION_changeset, xen_version->changeset,
-sizeof(xen_version->changeset));
+rc = xc_version(xch,
+XENVER_capabilities, _version->capabilities);
 if ( rc < 0 )
 return rc;
 
-rc = xc_version(xch, XEN_VERSION_platform_parameters,
-_version->platform_parameters,
-sizeof(xen_version->platform_parameters));
+rc = xc_version(xch, XENVER_changeset, _version->changeset);
 if ( rc < 0 )
 return rc;
 
-val = 0;
-rc = xc_version(xch, XEN_VERSION_pagesize, , sizeof(val));
+rc = xc_version(xch, XENVER_platform_parameters,
+_version->platform_parameters);
 if ( rc < 0 )
 return rc;
-xen_version->pagesize = val;
+
+rc = xc_version(xch, XENVER_pagesize, NULL);
+if ( rc < 0 )
+   

Re: [Xen-devel] [PATCH v2] docs: update FLASK cmd line instructions

[Daniel De Graaf]

On 04/25/2016 08:17 AM, Jan Beulich wrote:

On 18.03.16 at 17:46,  wrote:

The command line instructions for FLASK include a note on how to compile
Xen with FLASK but the note was out of date after the change to Kconfig.

Signed-off-by: Doug Goldstein 
---
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
CC: Konrad Rzeszutek Wilk 
CC: Daniel De Graaf 


Daniel,

any chance we could get your ack (or otherwise) on this?

Thanks, Jan




Sure, I didn't realize you were waiting on it.  The patch looks good.

Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v3] docs/arm64: update the documention for loading XSM support

[Stefano Stabellini]

On Mon, 25 Apr 2016, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH v3] docs/arm64: update the documention for 
> loading XSM support"):
> > Stefano has committed the previous version with some modifications. Is 
> > it better to read?
> 
> IMO it is better than the original but I still think my proposed
> wording is an improvement over Stefano's.
> 
> Should I "rebase" it and resubmit ?

Sure, thanks.

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

Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

[Yu, Zhang]

On 4/25/2016 10:01 PM, Paul Durrant wrote:

-Original Message-
From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
George Dunlap
Sent: 25 April 2016 14:39
To: Yu Zhang
Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
Andrew Cooper; Tim (Xen.org); Paul Durrant; Lv, Zhiyuan; Jan Beulich; Wei Liu
Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
Rename p2m_mmio_write_dm to p2m_ioreq_server.

On Mon, Apr 25, 2016 at 11:35 AM, Yu Zhang 
wrote:

Previously p2m type p2m_mmio_write_dm was introduced for write-
protected memory pages whose write operations are supposed to be
forwarded to and emulated by an ioreq server. Yet limitations of
rangeset restrict the number of guest pages to be write-protected.

This patch replaces the p2m type p2m_mmio_write_dm with a new name:
p2m_ioreq_server, which means this p2m type can be claimed by one
ioreq server, instead of being tracked inside the rangeset of ioreq
server. Patches following up will add the related hvmop handling
code which map/unmap type p2m_ioreq_server to/from an ioreq server.

changes in v3:
  - According to Jan & George's comments, keep

HVMMEM_mmio_write_dm

for old xen interface versions, and replace it with HVMMEM_unused
for xen interfaces newer than 4.7.0; For p2m_ioreq_server, a new
enum - HVMMEM_ioreq_server is introduced for the get/set mem type
interfaces;
  - Add George's Reviewed-by and Acked-by from Tim & Andrew.


Unfortunately these rather contradict each other -- I consider
Reviewed-by to only stick if the code I've specified hasn't changed
(or has only changed trivially).

Also...



changes in v2:
  - According to George Dunlap's comments, only rename the p2m type,
with no behavior changes.

Signed-off-by: Paul Durrant 
Signed-off-by: Yu Zhang 
Acked-by: Tim Deegan 
Acked-by: Andrew Cooper 
Reviewed-by: George Dunlap 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Tim Deegan 
---
 xen/arch/x86/hvm/hvm.c  | 14 --
 xen/arch/x86/mm/p2m-ept.c   |  2 +-
 xen/arch/x86/mm/p2m-pt.c|  2 +-
 xen/arch/x86/mm/shadow/multi.c  |  2 +-
 xen/include/asm-x86/p2m.h   |  4 ++--
 xen/include/public/hvm/hvm_op.h |  8 +++-
 6 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index f24126d..874cb0f 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1857,7 +1857,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,

unsigned long gla,

  */
 if ( (p2mt == p2m_mmio_dm) ||
  (npfec.write_access &&
-  (p2m_is_discard_write(p2mt) || (p2mt == p2m_mmio_write_dm))) )
+  (p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
 {
 __put_gfn(p2m, gfn);
 if ( ap2m_active )
@@ -5499,8 +5499,8 @@ long do_hvm_op(unsigned long op,

XEN_GUEST_HANDLE_PARAM(void) arg)

 get_gfn_query_unlocked(d, a.pfn, );
 if ( p2m_is_mmio(t) )
 a.mem_type =  HVMMEM_mmio_dm;
-else if ( t == p2m_mmio_write_dm )
-a.mem_type = HVMMEM_mmio_write_dm;
+else if ( t == p2m_ioreq_server )
+a.mem_type = HVMMEM_ioreq_server;
 else if ( p2m_is_readonly(t) )
 a.mem_type =  HVMMEM_ram_ro;
 else if ( p2m_is_ram(t) )
@@ -5531,7 +5531,8 @@ long do_hvm_op(unsigned long op,

XEN_GUEST_HANDLE_PARAM(void) arg)

 [HVMMEM_ram_rw]  = p2m_ram_rw,
 [HVMMEM_ram_ro]  = p2m_ram_ro,
 [HVMMEM_mmio_dm] = p2m_mmio_dm,
-[HVMMEM_mmio_write_dm] = p2m_mmio_write_dm
+[HVMMEM_unused] = p2m_invalid,
+[HVMMEM_ioreq_server] = p2m_ioreq_server
 };

 if ( copy_from_guest(, arg, 1) )
@@ -,7 +5556,8 @@ long do_hvm_op(unsigned long op,

XEN_GUEST_HANDLE_PARAM(void) arg)

  ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d)) )
 goto setmemtype_fail;

-if ( a.hvmmem_type >= ARRAY_SIZE(memtype) )
+if ( a.hvmmem_type >= ARRAY_SIZE(memtype) ||
+ unlikely(a.hvmmem_type == HVMMEM_unused) )
 goto setmemtype_fail;

 while ( a.nr > start_iter )
@@ -5579,7 +5581,7 @@ long do_hvm_op(unsigned long op,

XEN_GUEST_HANDLE_PARAM(void) arg)

 }
 if ( !p2m_is_ram(t) &&
  (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm)

&&

- (t != p2m_mmio_write_dm || a.hvmmem_type !=

HVMMEM_ram_rw) )

+ (t != p2m_ioreq_server || a.hvmmem_type !=

HVMMEM_ram_rw) )

 {
 

Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

[Borislav Petkov]

On Mon, Apr 25, 2016 at 10:42:15AM -0400, Boris Ostrovsky wrote:
> Hmm... I thought that everything specified in boot.txt was ABI.

But those are not there.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

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

Re: [Xen-devel] [PATCH v2] docs: update FLASK cmd line instructions

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] [PATCH v2] docs: update FLASK cmd line 
instructions"):
> On 18.03.16 at 17:46,  wrote:
> > The command line instructions for FLASK include a note on how to compile
> > Xen with FLASK but the note was out of date after the change to Kconfig.
...
> Daniel,
> any chance we could get your ack (or otherwise) on this?

TBH I would have just committed this - it being only a docs patch.

But I am happy to wait a bit to give Daniel a chance to comment.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH] travis: enable building of the tools

[Wei Liu]

On Mon, Apr 25, 2016 at 10:02:55AM -0500, Doug Goldstein wrote:
> On 4/25/16 9:53 AM, Wei Liu wrote:
> > On Mon, Apr 25, 2016 at 09:46:18AM -0500, Doug Goldstein wrote:
> >> For native (non-cross compiles) we now only require bcc, ld86, as86 for
> >> building rombios, we can build the toolstack sans rombios and using the
> >> system SeaBIOS due to known build issues. At the same time capture the
> >> output of the configure scripts to help with tracking down future build
> >> issues. This does not enable building of the toolstack with clang for
> >> now due to multiple failures.
> >>
> >> Signed-off-by: Doug Goldstein 
> > 
> > It would be useful if you can provide a link to a success travis run so
> > that people who are interested (e.g. me :-P) can have a look.
> 
> Apologies. I meant to just didn't.
> 
> https://travis-ci.org/cardoe/xen/builds/125166028
> 

Thanks. Looks good to me.

Reviewed-by: Wei Liu 

Though this patch is not strictly coupled with 4.7 I would like to see
it in as soon as possible.

I will let this patch floating on xen-devel for a bit in case other
people have comments.

Wei.

> -- 
> Doug Goldstein
> 




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

Re: [Xen-devel] [PATCH] travis: enable building of the tools

[Andrew Cooper]

On 25/04/16 15:46, Doug Goldstein wrote:
> For native (non-cross compiles) we now only require bcc, ld86, as86 for
> building rombios, we can build the toolstack sans rombios and using the
> system SeaBIOS due to known build issues. At the same time capture the
> output of the configure scripts to help with tracking down future build
> issues. This does not enable building of the toolstack with clang for
> now due to multiple failures.
>
> Signed-off-by: Doug Goldstein 

Looking at the results of
https://travis-ci.org/cardoe/xen/builds/125166028 , this is definitely a
good improvement.

Acked-by: Andrew Cooper

> ---
>  .travis.yml  |  8 
>  scripts/travis-build | 31 +++
>  2 files changed, 35 insertions(+), 4 deletions(-)
>  create mode 100755 scripts/travis-build
>
> diff --git a/.travis.yml b/.travis.yml
> index 741a8ab..0eea94e 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -75,18 +75,18 @@ addons:
>  - gcc-5
>  - g++-5
>  - clang-3.8
> +- seabios
>  # we must set CXX manually instead of using 'language: cpp' due to
>  # travis-ci/travis-ci#3871
>  before_script:
>  - export CXX=${CC/cc/++}
>  - export CXX=${CXX/clang/clang++}
>  script:
> -- ( [ "x${RANDCONFIG}" = "xy" ] && ( make -C xen randconfig )
> -  || exit 0 )
> -- ( ./configure --disable-tools --disable-stubdom --enable-docs &&
> -  make dist )
> +- ./scripts/travis-build
>  after_script:
>  - cat xen/.config
> +- cat tools/config.log
> +- cat docs/config.log
>  notifications:
>  irc:
>  channels:
> diff --git a/scripts/travis-build b/scripts/travis-build
> new file mode 100755
> index 000..b553f20
> --- /dev/null
> +++ b/scripts/travis-build
> @@ -0,0 +1,31 @@
> +#!/bin/bash -ex
> +
> +# random config or default config
> +if [[ "${RANDCONFIG}" == "y" ]]; then
> +make -C xen randconfig
> +else
> +make -C xen defconfig
> +fi
> +
> +# build up our configure options
> +cfgargs=()
> +cfgargs+=("--disable-stubdom") # more work needed into building this
> +cfgargs+=("--disable-rombios")
> +cfgargs+=("--enable-docs")
> +cfgargs+=("--with-system-seabios=/usr/share/seabios/bios.bin")
> +
> +if [[ "${XEN_TARGET_ARCH}" == "x86_64" ]]; then
> +cfgargs+=("--enable-tools")
> +else
> +cfgargs+=("--disable-tools") # we don't have the cross depends installed
> +fi
> +
> +# Due to multiple build failures and the desire to get more
> +# build testing (GCC only) enabled this is disabled
> +if [[ "${clang}" == "y" ]]; then
> +cfgargs+=("--disable-tools")
> +fi
> +
> +./configure "${cfgargs[@]}"
> +
> +make dist

However, I do have one suggestion for an improvement which we might want
to consider (likely as a followup patch).

It would be very useful if we could get travis to build 32bit tools as
well as 64bit.  It is moderately frequently that the build breaks
because of a stray use of unsigned long vs uint32_t or uint64_t.

This can be done using XEN_TARGET_ARCH=x86_32, although you would still
need x86_64 to the hypervisor, or omit the hypervisor build entirely.

~Andrew

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

Re: [Xen-devel] [PATCH v3] docs/arm64: update the documention for loading XSM support

[Ian Jackson]

Julien Grall writes ("Re: [PATCH v3] docs/arm64: update the documention for 
loading XSM support"):
> Stefano has committed the previous version with some modifications. Is 
> it better to read?

IMO it is better than the original but I still think my proposed
wording is an improvement over Stefano's.

Should I "rebase" it and resubmit ?

Ian.

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

Re: [Xen-devel] [PATCH] travis: enable building of the tools

[Doug Goldstein]

On 4/25/16 9:53 AM, Wei Liu wrote:
> On Mon, Apr 25, 2016 at 09:46:18AM -0500, Doug Goldstein wrote:
>> For native (non-cross compiles) we now only require bcc, ld86, as86 for
>> building rombios, we can build the toolstack sans rombios and using the
>> system SeaBIOS due to known build issues. At the same time capture the
>> output of the configure scripts to help with tracking down future build
>> issues. This does not enable building of the toolstack with clang for
>> now due to multiple failures.
>>
>> Signed-off-by: Doug Goldstein 
> 
> It would be useful if you can provide a link to a success travis run so
> that people who are interested (e.g. me :-P) can have a look.

Apologies. I meant to just didn't.

https://travis-ci.org/cardoe/xen/builds/125166028

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH for-4.7] docs/build: Work around apparent bug with multi-target rules

[Andrew Cooper]

On 25/04/16 14:35, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH for-4.7] docs/build: Work around apparent bug 
> with multi-target rules"):
>> The `make` manual documents that a rule of the form
>>
>>   target1 target2: prereq
>>  recipe
>>
>> is equivilent to
>>
>>   target1: prereq
>>  recipe
>>   target2: prereq
>>  recipe
>>
>> This is correct if only target1 or target2 is wanted, but is not the
>> case if both target1 and target2 are wanted to be rebuilt in the
>> same pass.  In such a case, executing the recipe to generate target1
>> causes the entire rule to be considered complete, short circuiting
>> the search to regenerate target2.
> This is not a bug in make.  From the manual I have here (wheezy):
>
>  Suppose you would like to vary the prerequisites according to the
>target, much as the variable `$@' allows you to vary the commands.
>You cannot do this with multiple targets in an ordinary rule, but
>you can do it with a "static pattern rule".  *Note Static Pattern
>Rules: Static Pattern.

But we don't want to vary the prerequisite with the target.  We want the
single (Patterned) prerequisite to cause a regeneration of each three of
the (Patterned) targets using the same recipe, as the $@ and $< are
sufficiently expressive for our needs.

i.e. I only chose to do it like that originally to avoid copy
the recipe.

>
> and (from `Pattern Intro'):
>
>  Pattern rules may have more than one target.  Unlike normal
>rules, this does not act as many different rules with the same
>prerequisites and commands.  If a pattern rule has multiple
>targets, `make' knows that the rule's commands are responsible for
>making all of the targets.  The commands are executed only once to
>make all the targets.

This is the bit of documentation that I missed.  IMO, this is at least a
documentation bug, and that the multi-target documentation should
warning that multi-target pattern rules behave differently.

`make' knows, does it...  How can that possibly be the sensible choice? 
There is no automatic variable which encompasses multiple targets, and
using $* still requires you to hand-code the non-stem parts of the
targets.  This smells like a bug which was documented around.

>
> So this is a bug in the Makefile.  Your patch looks like a right
> approach to me.  A static pattern rule would be the other option.

However, a static pattern rule wouldn't avoid the repetition of the recipe.

> Acked-by: Ian Jackson 

Thanks.  I will see about adjusting the commit message, but the patch
itself doesn't need to change.

~Andrew

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  bd6ad54403019f213e18791b9856e4b7b71a4d47
baseline version:
 xen  e0ec0a717d882ff0c0935b4893792d6aa95df3ef

Last test of basis92401  2016-04-23 00:01:53 Z2 days
Testing same since92710  2016-04-25 13:01:06 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=bd6ad54403019f213e18791b9856e4b7b71a4d47
+ . ./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 
bd6ad54403019f213e18791b9856e4b7b71a4d47
+ branch=xen-unstable-smoke
+ revision=bd6ad54403019f213e18791b9856e4b7b71a4d47
+ . ./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.6-testing
+ '[' xbd6ad54403019f213e18791b9856e4b7b71a4d47 = 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] travis: enable building of the tools

[Wei Liu]

On Mon, Apr 25, 2016 at 09:46:18AM -0500, Doug Goldstein wrote:
> For native (non-cross compiles) we now only require bcc, ld86, as86 for
> building rombios, we can build the toolstack sans rombios and using the
> system SeaBIOS due to known build issues. At the same time capture the
> output of the configure scripts to help with tracking down future build
> issues. This does not enable building of the toolstack with clang for
> now due to multiple failures.
> 
> Signed-off-by: Doug Goldstein 

It would be useful if you can provide a link to a success travis run so
that people who are interested (e.g. me :-P) can have a look.

> ---
>  .travis.yml  |  8 
>  scripts/travis-build | 31 +++

I guess the reason for this is because travis's yaml is not expressive
enough for our purpose?

The rest looks sensible to me.

Wei.

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

Re: [Xen-devel] [PATCH v2 09/11] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending

[Xu, Quan]

On April 25, 2016 9:58pm,  wrote:
> On 25/04/16 12:52, Jan Beulich wrote:
>  On 18.04.16 at 16:00,  wrote:
> >> --- a/xen/drivers/passthrough/arm/smmu.c
> >> +++ b/xen/drivers/passthrough/arm/smmu.c
> >> @@ -2540,7 +2540,7 @@ static int force_stage = 2;
> >>*/
> >>   static u32 platform_features = ARM_SMMU_FEAT_COHERENT_WALK;
> >>
> >> -static void arm_smmu_iotlb_flush_all(struct domain *d)
> >> +static int arm_smmu_iotlb_flush_all(struct domain *d)
> >>   {
> >>struct arm_smmu_xen_domain *smmu_domain =
> domain_hvm_iommu(d)->arch.priv;
> >>struct iommu_domain *cfg;
> >> @@ -2557,13 +2557,15 @@ static void arm_smmu_iotlb_flush_all(struct
> domain *d)
> >>arm_smmu_tlb_inv_context(cfg->priv);
> >>}
> >>spin_unlock(_domain->lock);
> >> +
> >> +return 0;
> >>   }
> >
> > Even if indentation looks inconsistent in this file, please make your
> > addition match surrounding code.
> 
> The file smmu.c was imported from Linux and supposed to use only Linux
> coding style. This is in order to help porting fixes.
> 

 Julien,  A 'tab'  ? 
Quan



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

[Xen-devel] [PATCH] travis: enable building of the tools

[Doug Goldstein]

For native (non-cross compiles) we now only require bcc, ld86, as86 for
building rombios, we can build the toolstack sans rombios and using the
system SeaBIOS due to known build issues. At the same time capture the
output of the configure scripts to help with tracking down future build
issues. This does not enable building of the toolstack with clang for
now due to multiple failures.

Signed-off-by: Doug Goldstein 
---
 .travis.yml  |  8 
 scripts/travis-build | 31 +++
 2 files changed, 35 insertions(+), 4 deletions(-)
 create mode 100755 scripts/travis-build

diff --git a/.travis.yml b/.travis.yml
index 741a8ab..0eea94e 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -75,18 +75,18 @@ addons:
 - gcc-5
 - g++-5
 - clang-3.8
+- seabios
 # we must set CXX manually instead of using 'language: cpp' due to
 # travis-ci/travis-ci#3871
 before_script:
 - export CXX=${CC/cc/++}
 - export CXX=${CXX/clang/clang++}
 script:
-- ( [ "x${RANDCONFIG}" = "xy" ] && ( make -C xen randconfig )
-  || exit 0 )
-- ( ./configure --disable-tools --disable-stubdom --enable-docs &&
-  make dist )
+- ./scripts/travis-build
 after_script:
 - cat xen/.config
+- cat tools/config.log
+- cat docs/config.log
 notifications:
 irc:
 channels:
diff --git a/scripts/travis-build b/scripts/travis-build
new file mode 100755
index 000..b553f20
--- /dev/null
+++ b/scripts/travis-build
@@ -0,0 +1,31 @@
+#!/bin/bash -ex
+
+# random config or default config
+if [[ "${RANDCONFIG}" == "y" ]]; then
+make -C xen randconfig
+else
+make -C xen defconfig
+fi
+
+# build up our configure options
+cfgargs=()
+cfgargs+=("--disable-stubdom") # more work needed into building this
+cfgargs+=("--disable-rombios")
+cfgargs+=("--enable-docs")
+cfgargs+=("--with-system-seabios=/usr/share/seabios/bios.bin")
+
+if [[ "${XEN_TARGET_ARCH}" == "x86_64" ]]; then
+cfgargs+=("--enable-tools")
+else
+cfgargs+=("--disable-tools") # we don't have the cross depends installed
+fi
+
+# Due to multiple build failures and the desire to get more
+# build testing (GCC only) enabled this is disabled
+if [[ "${clang}" == "y" ]]; then
+cfgargs+=("--disable-tools")
+fi
+
+./configure "${cfgargs[@]}"
+
+make dist
-- 
2.7.3


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

Re: [Xen-devel] [PATCH] libfsimage: fix bad header guard

[Wei Liu]

On Mon, Apr 25, 2016 at 09:39:03AM -0500, Doug Goldstein wrote:
> The #ifndef / #define value used was not consistent so it did not
> function as a proper header guard.
> 
> Signed-off-by: Doug Goldstein 

Acked-by: Wei Liu 
Release-acked-by: Wei Liu 

And queued. Thanks for fixing this.

> ---
>  tools/libfsimage/ufs/ufs.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libfsimage/ufs/ufs.h b/tools/libfsimage/ufs/ufs.h
> index 4e7c736..62135f3 100644
> --- a/tools/libfsimage/ufs/ufs.h
> +++ b/tools/libfsimage/ufs/ufs.h
> @@ -4,7 +4,7 @@
>   */
>  
>  #ifndef _GRUB_UFS_H
> -#define _GRUB_UFS_H_
> +#define _GRUB_UFS_H
>  
>  /* ufs specific constants */
>  #define UFS_SBLOCK   16
> -- 
> 2.7.3
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[Xen-devel] [PATCH] libfsimage: fix bad header guard

[Doug Goldstein]

The #ifndef / #define value used was not consistent so it did not
function as a proper header guard.

Signed-off-by: Doug Goldstein 
---
 tools/libfsimage/ufs/ufs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libfsimage/ufs/ufs.h b/tools/libfsimage/ufs/ufs.h
index 4e7c736..62135f3 100644
--- a/tools/libfsimage/ufs/ufs.h
+++ b/tools/libfsimage/ufs/ufs.h
@@ -4,7 +4,7 @@
  */
 
 #ifndef _GRUB_UFS_H
-#define _GRUB_UFS_H_
+#define _GRUB_UFS_H
 
 /* ufs specific constants */
 #define UFS_SBLOCK 16
-- 
2.7.3


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

Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

[Paul Durrant]

> -Original Message-
> From: George Dunlap
> Sent: 25 April 2016 15:28
> To: Paul Durrant
> Cc: Jan Beulich; Kevin Tian; Wei Liu; Andrew Cooper; Tim (Xen.org); xen-
> de...@lists.xen.org; Yu Zhang; Zhiyuan Lv; Jun Nakajima; Keir (Xen.org)
> Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
> Rename p2m_mmio_write_dm to p2m_ioreq_server.
> 
> On Mon, Apr 25, 2016 at 3:19 PM, Paul Durrant 
> wrote:
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 25 April 2016 15:16
> >> To: Paul Durrant
> >> Cc: Andrew Cooper; George Dunlap; Wei Liu; Jun Nakajima; Kevin Tian;
> >> Zhiyuan Lv; Yu Zhang; xen-devel@lists.xen.org; Keir (Xen.org); Tim
> (Xen.org)
> >> Subject: RE: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
> >> Rename p2m_mmio_write_dm to p2m_ioreq_server.
> >>
> >> >>> On 25.04.16 at 16:01,  wrote:
> >> > The p2m type changes are also wrong. That type needs to be left alone,
> >> > presumably, so that anything using HVMMEM_mmio_write_dm and
> >> compiled to the
> >> > old interface version continues to function. I think
> HVMMEM_ioreq_server
> >> > needs to map to a new p2m type which should be introduced in patch
> #3.
> >>
> >> I don't understand this part: I thought it was agreed that the old
> >> p2m type needs to go away (not the least because we're tight on
> >> these), and use of the old HVMMEM_* type needs to result in
> >> errors.
> >>
> >
> > I may have misunderstood. I thought we'd back-tracked on that because
> there's a concern that we also need to keep anything compiled against the
> old header working. If not then this patch should also remove that p2m type,
> not rename it.
> 
> You mean remove the old HVMMEM type?
> 
> There are two issues:
> 1. Whether old code should continue to compile
> 2. How old code should act on new hypervisors
> 
> I think we've determined that we definitely cannot allow code compiled
> against old hypervisors to accidentally use a different p2m type; so
> we certainly need to "burn" an enum here.
> 
> I'd personally prefer we just straight-up rename it to HVMMEM_unused,
> so nobody continues to think that the HVMMEM_mmio_write_dm
> functionality might still actually work; I think Jan thinks that's not
> allowed.
> 
> Honestly I don't see the point of letting it compile and then return
> -EINVAL when we run it.  If people complain that it doesn't work
> anymore we should either make it compile *and* maintain the
> functionality, or say "Sorry, just use an older version" and make it
> neither compile nor maintain the functionality.
> 
> But I sort of assumed this discussion on what support looked like had
> already been had and Jan was just enforcing it.
> 
> (Maybe we should have had a talk about this in person at the Hackathon...)
> 

I'm now confused as to what was agreed, if anything.

The fact of the matter is though that the old type escaped into the wild. I 
wanted it to go away but because it escaped I guess that may just not be 
possible.

  Paul

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

Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

[George Dunlap]

On Mon, Apr 25, 2016 at 3:19 PM, Paul Durrant  wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 25 April 2016 15:16
>> To: Paul Durrant
>> Cc: Andrew Cooper; George Dunlap; Wei Liu; Jun Nakajima; Kevin Tian;
>> Zhiyuan Lv; Yu Zhang; xen-devel@lists.xen.org; Keir (Xen.org); Tim (Xen.org)
>> Subject: RE: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
>> Rename p2m_mmio_write_dm to p2m_ioreq_server.
>>
>> >>> On 25.04.16 at 16:01,  wrote:
>> > The p2m type changes are also wrong. That type needs to be left alone,
>> > presumably, so that anything using HVMMEM_mmio_write_dm and
>> compiled to the
>> > old interface version continues to function. I think HVMMEM_ioreq_server
>> > needs to map to a new p2m type which should be introduced in patch #3.
>>
>> I don't understand this part: I thought it was agreed that the old
>> p2m type needs to go away (not the least because we're tight on
>> these), and use of the old HVMMEM_* type needs to result in
>> errors.
>>
>
> I may have misunderstood. I thought we'd back-tracked on that because there's 
> a concern that we also need to keep anything compiled against the old header 
> working. If not then this patch should also remove that p2m type, not rename 
> it.

You mean remove the old HVMMEM type?

There are two issues:
1. Whether old code should continue to compile
2. How old code should act on new hypervisors

I think we've determined that we definitely cannot allow code compiled
against old hypervisors to accidentally use a different p2m type; so
we certainly need to "burn" an enum here.

I'd personally prefer we just straight-up rename it to HVMMEM_unused,
so nobody continues to think that the HVMMEM_mmio_write_dm
functionality might still actually work; I think Jan thinks that's not
allowed.

Honestly I don't see the point of letting it compile and then return
-EINVAL when we run it.  If people complain that it doesn't work
anymore we should either make it compile *and* maintain the
functionality, or say "Sorry, just use an older version" and make it
neither compile nor maintain the functionality.

But I sort of assumed this discussion on what support looked like had
already been had and Jan was just enforcing it.

(Maybe we should have had a talk about this in person at the Hackathon...)

 -George

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

Re: [Xen-devel] [PATCH RFC v1 09/14] Makefile: delete STUBDOMPATH target

[Wei Liu]

On Fri, Apr 01, 2016 at 11:03:28AM +0100, Wei Liu wrote:
> On Fri, Apr 01, 2016 at 01:41:40AM +, Xu, Quan wrote:
> > On March 31, 2016 9:50pm, Wei Liu  wrote:
> > > On Thu, Mar 31, 2016 at 10:21:22AM +, Xu, Quan wrote:
> > > > On March 11, 2016 12:53am, Wei Liu  wrote:
> > > > > -build: $(STUBDOMPATH)
> > > > > +build: $(STUBDOM_BUILD)
> > > >
> > > > Wei,
> > > > in original code, in stubdom/vtpm and stubdom/vtpmmgr, the code style is
> > > > inconsistent and ugly.
> > > I personally prefer small patches in a series, but I don't object to 
> > > having large
> > > patch(es) either. 
> > 
> > ok. I think so too. It may be one file per patch.
> > 
> > 
> > > At the end of the day, I think Daniel's opinion matters most.
> > > After a plan is agreed upon, you can then provide a branch for us to pull 
> > > in.
> > 
> > I think I am not authorized to branch, could you provide a branch and tell 
> > me how to commit to that branch?
> > Sorry, I am unfamiliar with the upstream process.
> > 
> 
> Oh, you don't need to branch on the main tree (xen.git or future
> stubdom.git). You can just do the following:
> 
>   $ git clone xen.git # or stubdom.git
>   $ cd xen.git # or stubdom.git
>   $ git branch wip.vtpm-coding-style-fix-v1
>   ... do work, commit as you go alone ...
>   $ git push $some_public_remote wip.vtpm-coding-style-fix-v1
>   ... post your patch series on xen-devel, along with the git repository
>   and branch
> 
> When your patches are all acked by Daniel, you can then fold
> all the tags into your own branch (wip.vtpm-coding-style-fix-v$X-acked)
> and prod committers to pull from that branch.
> 
> > > Note
> > > that upstream don't test vtpm in any fashion so you do need to run your 
> > > tests.
> > > 
> > I will test it. I think I hope Daniel could help my patches. 
> > btw, I have made a quick patch to fix the seal/unseal issue. I will send 
> > out later.
> > 
> > > The only thing that matters to me is that when you will do it -- you will 
> > > need to
> > > patch a different tree after I split off stubdom. In order to minimise 
> > > the fuss one
> > > of us will need to wait for the other.
> > > 
> > Once you have done, please let me know. 
> 
> OK, I will try to sort it out within April.  Feel free to ping me if I
> drop the ball.
> 

OK, so the plan has become a bit more complicated. I'm still trying to work
out everything -- I've collected some opinions during hackathon and
people seemed to be of the opinion that things can be done a bit
differently. I don't expect to have everything ready in April. So if you
want to work on vtpm code, please let me know.

Wei.

> Wei.
> 
> > Quan

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

Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 25 April 2016 15:16
> To: Paul Durrant
> Cc: Andrew Cooper; George Dunlap; Wei Liu; Jun Nakajima; Kevin Tian;
> Zhiyuan Lv; Yu Zhang; xen-devel@lists.xen.org; Keir (Xen.org); Tim (Xen.org)
> Subject: RE: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
> Rename p2m_mmio_write_dm to p2m_ioreq_server.
> 
> >>> On 25.04.16 at 16:01,  wrote:
> > The p2m type changes are also wrong. That type needs to be left alone,
> > presumably, so that anything using HVMMEM_mmio_write_dm and
> compiled to the
> > old interface version continues to function. I think HVMMEM_ioreq_server
> > needs to map to a new p2m type which should be introduced in patch #3.
> 
> I don't understand this part: I thought it was agreed that the old
> p2m type needs to go away (not the least because we're tight on
> these), and use of the old HVMMEM_* type needs to result in
> errors.
> 

I may have misunderstood. I thought we'd back-tracked on that because there's a 
concern that we also need to keep anything compiled against the old header 
working. If not then this patch should also remove that p2m type, not rename it.

  Paul

> Jan


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

Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

[Jan Beulich]

>>> On 25.04.16 at 16:01,  wrote:
> The p2m type changes are also wrong. That type needs to be left alone, 
> presumably, so that anything using HVMMEM_mmio_write_dm and compiled to the 
> old interface version continues to function. I think HVMMEM_ioreq_server 
> needs to map to a new p2m type which should be introduced in patch #3.

I don't understand this part: I thought it was agreed that the old
p2m type needs to go away (not the least because we're tight on
these), and use of the old HVMMEM_* type needs to result in
errors.

Jan


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

Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

[George Dunlap]

On 25/04/16 15:01, Paul Durrant wrote:
>> -Original Message-
>> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
>> George Dunlap
>> Sent: 25 April 2016 14:39
>> To: Yu Zhang
>> Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
>> Andrew Cooper; Tim (Xen.org); Paul Durrant; Lv, Zhiyuan; Jan Beulich; Wei Liu
>> Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
>> Rename p2m_mmio_write_dm to p2m_ioreq_server.
>>
>> On Mon, Apr 25, 2016 at 11:35 AM, Yu Zhang 
>> wrote:
>>> Previously p2m type p2m_mmio_write_dm was introduced for write-
>>> protected memory pages whose write operations are supposed to be
>>> forwarded to and emulated by an ioreq server. Yet limitations of
>>> rangeset restrict the number of guest pages to be write-protected.
>>>
>>> This patch replaces the p2m type p2m_mmio_write_dm with a new name:
>>> p2m_ioreq_server, which means this p2m type can be claimed by one
>>> ioreq server, instead of being tracked inside the rangeset of ioreq
>>> server. Patches following up will add the related hvmop handling
>>> code which map/unmap type p2m_ioreq_server to/from an ioreq server.
>>>
>>> changes in v3:
>>>   - According to Jan & George's comments, keep
>> HVMMEM_mmio_write_dm
>>> for old xen interface versions, and replace it with HVMMEM_unused
>>> for xen interfaces newer than 4.7.0; For p2m_ioreq_server, a new
>>> enum - HVMMEM_ioreq_server is introduced for the get/set mem type
>>> interfaces;
>>>   - Add George's Reviewed-by and Acked-by from Tim & Andrew.
>>
>> Unfortunately these rather contradict each other -- I consider
>> Reviewed-by to only stick if the code I've specified hasn't changed
>> (or has only changed trivially).
>>
>> Also...
>>
>>>
>>> changes in v2:
>>>   - According to George Dunlap's comments, only rename the p2m type,
>>> with no behavior changes.
>>>
>>> Signed-off-by: Paul Durrant 
>>> Signed-off-by: Yu Zhang 
>>> Acked-by: Tim Deegan 
>>> Acked-by: Andrew Cooper 
>>> Reviewed-by: George Dunlap 
>>> Cc: Keir Fraser 
>>> Cc: Jan Beulich 
>>> Cc: Andrew Cooper 
>>> Cc: Jun Nakajima 
>>> Cc: Kevin Tian 
>>> Cc: George Dunlap 
>>> Cc: Tim Deegan 
>>> ---
>>>  xen/arch/x86/hvm/hvm.c  | 14 --
>>>  xen/arch/x86/mm/p2m-ept.c   |  2 +-
>>>  xen/arch/x86/mm/p2m-pt.c|  2 +-
>>>  xen/arch/x86/mm/shadow/multi.c  |  2 +-
>>>  xen/include/asm-x86/p2m.h   |  4 ++--
>>>  xen/include/public/hvm/hvm_op.h |  8 +++-
>>>  6 files changed, 20 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>>> index f24126d..874cb0f 100644
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -1857,7 +1857,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
>> unsigned long gla,
>>>   */
>>>  if ( (p2mt == p2m_mmio_dm) ||
>>>   (npfec.write_access &&
>>> -  (p2m_is_discard_write(p2mt) || (p2mt == p2m_mmio_write_dm))) )
>>> +  (p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
>>>  {
>>>  __put_gfn(p2m, gfn);
>>>  if ( ap2m_active )
>>> @@ -5499,8 +5499,8 @@ long do_hvm_op(unsigned long op,
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>  get_gfn_query_unlocked(d, a.pfn, );
>>>  if ( p2m_is_mmio(t) )
>>>  a.mem_type =  HVMMEM_mmio_dm;
>>> -else if ( t == p2m_mmio_write_dm )
>>> -a.mem_type = HVMMEM_mmio_write_dm;
>>> +else if ( t == p2m_ioreq_server )
>>> +a.mem_type = HVMMEM_ioreq_server;
>>>  else if ( p2m_is_readonly(t) )
>>>  a.mem_type =  HVMMEM_ram_ro;
>>>  else if ( p2m_is_ram(t) )
>>> @@ -5531,7 +5531,8 @@ long do_hvm_op(unsigned long op,
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>  [HVMMEM_ram_rw]  = p2m_ram_rw,
>>>  [HVMMEM_ram_ro]  = p2m_ram_ro,
>>>  [HVMMEM_mmio_dm] = p2m_mmio_dm,
>>> -[HVMMEM_mmio_write_dm] = p2m_mmio_write_dm
>>> +[HVMMEM_unused] = p2m_invalid,
>>> +[HVMMEM_ioreq_server] = p2m_ioreq_server
>>>  };
>>>
>>>  if ( copy_from_guest(, arg, 1) )
>>> @@ -,7 +5556,8 @@ long do_hvm_op(unsigned long op,
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>   ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d)) )
>>>  goto setmemtype_fail;
>>>
>>> -if ( a.hvmmem_type >= ARRAY_SIZE(memtype) )
>>> +if ( a.hvmmem_type >= ARRAY_SIZE(memtype) ||
>>> + unlikely(a.hvmmem_type == HVMMEM_unused) )
>>>  goto setmemtype_fail;
>>>
>>>  while ( a.nr > start_iter )
>>> @@ -5579,7 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-xl-xsm  14 guest-saverestore fail REGR. vs. 60684
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-libvirt 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR. vs. 60684
 test-amd64-amd64-xl-credit2  17 guest-localmigrate/x10fail REGR. vs. 60684
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 60684
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl-xsm   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-xl   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-pair  22 guest-migrate/dst_host/src_host fail blocked in 60684
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 60684
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 60684

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 14 guest-saverestorefail  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-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linux3887972945122d7a3defbe372a682cfbaa37cf45
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  256 days
Failing since 60712  2015-08-15 18:33:48 Z  253 days  195 attempts
Testing same since92666  2016-04-25 04:25:44 Z0 days1 attempts

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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  fail
 test-amd64-i386-xl   fail
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm fail
 

Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

[Jan Beulich]

>>> On 25.04.16 at 15:39,  wrote:
> On Mon, Apr 25, 2016 at 11:35 AM, Yu Zhang  wrote:
>> --- a/xen/include/public/hvm/hvm_op.h
>> +++ b/xen/include/public/hvm/hvm_op.h
>> @@ -83,7 +83,13 @@ typedef enum {
>>  HVMMEM_ram_rw, /* Normal read/write guest RAM */
>>  HVMMEM_ram_ro, /* Read-only; writes are discarded */
>>  HVMMEM_mmio_dm,/* Reads and write go to the device model */
>> -HVMMEM_mmio_write_dm   /* Read-only; writes go to the device model 
>> */
>> +#if __XEN_INTERFACE_VERSION__ < 0x00040700
>> +HVMMEM_mmio_write_dm,  /* Read-only; writes go to the device model 
>> */
>> +#else
>> +HVMMEM_unused, /* Placeholder; setting memory to this type
>> +  will fail for code after 4.7.0 */
>> +#endif
>> +HVMMEM_ioreq_server
> 
> Also, I don't think we've had a convincing argument for why this patch
> needs to be in 4.7.  The p2m name changes are internal only, and so
> don't need to be made at all; and the old functionality will work as
> well as it ever did.  Furthermore, the whole reason we're in this
> situation is that we checked in a publicly-visible change to the
> interface before it was properly ready; I think we should avoid making
> the same mistake this time.

Good point.

> So personally I'd just leave this patch entirely for 4.8; but if Paul
> and/or Jan have strong opinions, then I would say check in only a
> patch to do the #if/#else/#endif, and leave both the p2m type changes
> and the new HVMMEM_ioreq_server enum for when the 4.8 development
> window opens.

Doing that alone would break the build - it would need to be a
little more than that.

Jan


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

Re: [Xen-devel] [PATCH] x86/vMSI-X: avoid missing first unmask of vectors

[Jan Beulich]

>>> On 25.04.16 at 15:25,  wrote:
> On Thu, Apr 21, 2016 at 03:38:26AM -0600, Jan Beulich wrote:
>> Recent changes to Linux result in there just being a single unmask
>> operation prior to expecting the first interrupts to arrive. However,
>> we've had a chicken-and-egg problem here: Qemu invokes
>> xc_domain_update_msi_irq(), ultimately leading to
>> msixtbl_pt_register(), upon seeing that first unmask operation. Yet
>> for msixtbl_range() to return true (in order to msixtbl_write() to get
>> invoked at all) msixtbl_pt_register() must have completed.
>> 
>> Deal with this by snooping suitable writes in msixtbl_range() and
>> triggering the invocation of msix_write_completion() from
>> msixtbl_pt_register() when that happens in the context of a still in
>> progress vector control field write.
>> 
>> Note that the seemingly unrelated deletion of the redundant
>> irq_desc->msi_desc checks in msixtbl_pt_register() is to make clear to
>> any compiler version used that the "msi_desc" local variable isn't
>> being used uninitialized. (Doing the same in msixtbl_pt_unregister() is
>> just for consistency reasons.)
>> 
>> Signed-off-by: Jan Beulich 
>> ---
>> TODO: How to deal with REP MOVS to the MSI-X table (in msixtbl_range())?
>> 
> 
> As I understand it, this should be future improvement.

Yes. I've actually been working on this the last couple of hours.

> The patch itself
> is an improvement in its own right so it can go in:
> 
> Release-acked-by: Wei Liu 

Thanks, Jan


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

Re: [Xen-devel] [PATCH v8.1 15/27] xsplice, symbols: Implement fast symbol names -> virtual addresses lookup

[Konrad Rzeszutek Wilk]

On Mon, Apr 25, 2016 at 02:38:57AM -0600, Jan Beulich wrote:
> >>> On 22.04.16 at 17:21,  wrote:
> > Here is what I came up using your idea. Do you want me to add 
> > 'Suggested-by' 
> > Jan on it?
> 
> I'll leave that up to you; it was really just a vague idea that I gave...
> 
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -74,6 +74,9 @@ efi-y := $(shell if [ ! -r 
> > $(BASEDIR)/include/xen/compile.h -o \
> >  
> >  ifdef CONFIG_XSPLICE
> >  all_symbols = --all-symbols
> > +ifdef CONFIG_FAST_SYMBOL_LOOKUP
> > +all_symbols = --all-symbols --add-extra-sorted
> > +endif
> >  else
> >  all_symbols =
> >  endif
> 
> This now even more calls for using the common list model, at least as
> later cleanup.

OK, put it on the Wiki.
> 
> > --- a/xen/common/symbols-dummy.c
> > +++ b/xen/common/symbols-dummy.c
> > @@ -5,6 +5,7 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #ifdef SYMBOLS_ORIGIN
> >  const unsigned int symbols_offsets[1];
> > @@ -14,6 +15,10 @@ const unsigned long symbols_addresses[1];
> >  const unsigned int symbols_num_syms;
> >  const u8 symbols_names[1];
> >  
> > +#ifdef CONFIG_FAST_SYMBOL_LOOKUP
> > +const struct symbol_offset symbols_sorted_offsets[1];
> > +#endif
> 
> Oh, nice - you even do the sorting at build time!

:-)
..snip..
> > +#ifdef CONFIG_FAST_SYMBOL_LOOKUP
> >  void *symbols_lookup_by_name(const char *symname)
> >  {
..snip..
> > +/* Unsupported search for filename in symbol right now. */
> > +if ( strpbrk(symname, filename_token) )
> > +return NULL;
> 
> That's unfortunate - why are you filtering these out? (Related to
> the earlier comment - this could even be strchr(), with no need at
> all for a string literal.)

This was an artificat of the earlier version. Removed it all now.

> 
> > +low = 0;
> > +high = symbols_num_syms;
> > +while ( low < high )
> > +{
> > +unsigned long mid = low + ((high - low) / 2);
> > +const struct symbol_offset *s;
> > +int rc;
> > +
> > +s = _sorted_offsets[mid];
> > +(void)symbols_expand_symbol(s->stream, namebuf);
> > +/* Format is: [filename]#. symbols_expand_symbol eats 
> > type.*/
> 
> [#]
> 
> And what relevance does the type part of the comment have here?

Artifact of the older version - Where I was searching for #.
.. snip.p
I removed the comment.

> > +   for (i = 0; i < table_cnt; i++) {
> > +   printf("\t.long %d", table[i].stream_offset);
> > +   printf(", %d", table[i].addr_idx);
> > +   printf("\n");
> 
> How about making this just a single printf()? Also both are unsigned,
> so please at least %u, but even better %#x.

I would rather have it as %u. As when debugging this I found it quite
useful for these values to be decimal as I could edit the .xen-sym.0.S file
and see in the editor where it would match up with the symbols_addresses
or the symbol_names in a quite easy way. Doing it in hex means doing extra
calculations.

> 
> > @@ -561,6 +614,8 @@ int main(int argc, char **argv)
> > input_format = fmt_sysv;
> > else if (strcmp(argv[i], "--sort") == 0)
> > unsorted = true;
> > +   else if (strcmp(argv[i], "--add-extra-sorted") == 0)
> > +   extra_sorted = 1;
> 
> s/extra/name/ ?
> 
> Or --sort-by-name?
> 
> Jan

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

Re: [Xen-devel] [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest

[Borislav Petkov]

On Mon, Apr 25, 2016 at 09:54:37AM -0400, Boris Ostrovsky wrote:
> Yes, those.

I don't think the ones in arch/x86/kernel/head_{32,64}.S are ABI.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

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

Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7): Rename p2m_mmio_write_dm to p2m_ioreq_server.

[Paul Durrant]

> -Original Message-
> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
> George Dunlap
> Sent: 25 April 2016 14:39
> To: Yu Zhang
> Cc: xen-devel@lists.xen.org; Kevin Tian; Keir (Xen.org); Jun Nakajima;
> Andrew Cooper; Tim (Xen.org); Paul Durrant; Lv, Zhiyuan; Jan Beulich; Wei Liu
> Subject: Re: [Xen-devel] [PATCH v3 1/3] x86/ioreq server(patch for 4.7):
> Rename p2m_mmio_write_dm to p2m_ioreq_server.
> 
> On Mon, Apr 25, 2016 at 11:35 AM, Yu Zhang 
> wrote:
> > Previously p2m type p2m_mmio_write_dm was introduced for write-
> > protected memory pages whose write operations are supposed to be
> > forwarded to and emulated by an ioreq server. Yet limitations of
> > rangeset restrict the number of guest pages to be write-protected.
> >
> > This patch replaces the p2m type p2m_mmio_write_dm with a new name:
> > p2m_ioreq_server, which means this p2m type can be claimed by one
> > ioreq server, instead of being tracked inside the rangeset of ioreq
> > server. Patches following up will add the related hvmop handling
> > code which map/unmap type p2m_ioreq_server to/from an ioreq server.
> >
> > changes in v3:
> >   - According to Jan & George's comments, keep
> HVMMEM_mmio_write_dm
> > for old xen interface versions, and replace it with HVMMEM_unused
> > for xen interfaces newer than 4.7.0; For p2m_ioreq_server, a new
> > enum - HVMMEM_ioreq_server is introduced for the get/set mem type
> > interfaces;
> >   - Add George's Reviewed-by and Acked-by from Tim & Andrew.
> 
> Unfortunately these rather contradict each other -- I consider
> Reviewed-by to only stick if the code I've specified hasn't changed
> (or has only changed trivially).
> 
> Also...
> 
> >
> > changes in v2:
> >   - According to George Dunlap's comments, only rename the p2m type,
> > with no behavior changes.
> >
> > Signed-off-by: Paul Durrant 
> > Signed-off-by: Yu Zhang 
> > Acked-by: Tim Deegan 
> > Acked-by: Andrew Cooper 
> > Reviewed-by: George Dunlap 
> > Cc: Keir Fraser 
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > Cc: Jun Nakajima 
> > Cc: Kevin Tian 
> > Cc: George Dunlap 
> > Cc: Tim Deegan 
> > ---
> >  xen/arch/x86/hvm/hvm.c  | 14 --
> >  xen/arch/x86/mm/p2m-ept.c   |  2 +-
> >  xen/arch/x86/mm/p2m-pt.c|  2 +-
> >  xen/arch/x86/mm/shadow/multi.c  |  2 +-
> >  xen/include/asm-x86/p2m.h   |  4 ++--
> >  xen/include/public/hvm/hvm_op.h |  8 +++-
> >  6 files changed, 20 insertions(+), 12 deletions(-)
> >
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index f24126d..874cb0f 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -1857,7 +1857,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
> unsigned long gla,
> >   */
> >  if ( (p2mt == p2m_mmio_dm) ||
> >   (npfec.write_access &&
> > -  (p2m_is_discard_write(p2mt) || (p2mt == p2m_mmio_write_dm))) )
> > +  (p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
> >  {
> >  __put_gfn(p2m, gfn);
> >  if ( ap2m_active )
> > @@ -5499,8 +5499,8 @@ long do_hvm_op(unsigned long op,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> >  get_gfn_query_unlocked(d, a.pfn, );
> >  if ( p2m_is_mmio(t) )
> >  a.mem_type =  HVMMEM_mmio_dm;
> > -else if ( t == p2m_mmio_write_dm )
> > -a.mem_type = HVMMEM_mmio_write_dm;
> > +else if ( t == p2m_ioreq_server )
> > +a.mem_type = HVMMEM_ioreq_server;
> >  else if ( p2m_is_readonly(t) )
> >  a.mem_type =  HVMMEM_ram_ro;
> >  else if ( p2m_is_ram(t) )
> > @@ -5531,7 +5531,8 @@ long do_hvm_op(unsigned long op,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> >  [HVMMEM_ram_rw]  = p2m_ram_rw,
> >  [HVMMEM_ram_ro]  = p2m_ram_ro,
> >  [HVMMEM_mmio_dm] = p2m_mmio_dm,
> > -[HVMMEM_mmio_write_dm] = p2m_mmio_write_dm
> > +[HVMMEM_unused] = p2m_invalid,
> > +[HVMMEM_ioreq_server] = p2m_ioreq_server
> >  };
> >
> >  if ( copy_from_guest(, arg, 1) )
> > @@ -,7 +5556,8 @@ long do_hvm_op(unsigned long op,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> >   ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d)) )
> >  goto setmemtype_fail;
> >
> > -if ( a.hvmmem_type >= ARRAY_SIZE(memtype) )
> > +if ( a.hvmmem_type >= ARRAY_SIZE(memtype) ||
> > + unlikely(a.hvmmem_type == HVMMEM_unused) )
> >  goto setmemtype_fail;
> >
> >  while ( a.nr > start_iter )
> > @@ -5579,7 +5581,7 @@ long do_hvm_op(unsigned long op,
>